LoRaWAN in Alpine Terrain: Why Your Link Budget Was Right and the Mountain Was Wrong

The link budget said the path would close. The math was right. Add up EIRP, subtract FSPL, add antenna gain, compare to receiver sensitivity — margin was positive at SF10, comfortable. The plan looked solid on paper.

Then someone placed the gateway at 3,200 metres elevation on the Argentine side of the Paso Los Libertadores, and the sensor node down in the Chilean valley couldn't be heard.

Not "barely heard." Not "heard at SF12 but not SF10." Couldn't be heard at all. The link budget had been right about the free-space case. The problem was that the path wasn't free space.

What the spreadsheet doesn't see

Free-Space Path Loss (FSPL) assumes a clear path — radio waves spreading out from a point source into open air, attenuated only by the inverse-square law. It's a valid starting point. It's also the case that almost no real-world LoRaWAN path in mountainous terrain resembles that assumption.

Between a gateway at altitude and a sensor node in a valley, there is almost always a ridge. Often several. The radio signal doesn't pass through the ridge — it diffracts around it. Diffraction happens. But diffraction loss is additive on top of FSPL. A ridge that the FSPL calculation treats as non-existent might add 15, 20, or 30 dB of loss to the link.

At 868 MHz — the EU band, and the band used in most of South America's AU915 region at similar frequencies — the first Fresnel zone radius at the midpoint of a 20 km path is approximately:

That's the radius of the ellipsoid around the direct ray that must be at least 60% clear for the path to behave like free space. A terrain feature 30 metres higher than the direct ray at path mid-point obstructs the first Fresnel zone. The FSPL calculation never sees it.

The Andes: a useful test case

The Paso Los Libertadores crossing on the Chile-Argentina border (−32.8°S, −70.0°W, approximately 3,200 m) is a useful example because it's well-documented, publicly available in the Copernicus GLO-30 DEM, and represents a deployment scenario that appears regularly in South American IoT projects: sensors in Chilean river valleys, gateways on Argentinian ridgelines, or vice versa.

A path from a gateway at the pass down into a valley 15 km distant at 1,800 m elevation crosses terrain that drops and rises significantly along the way. Running this path through FresnelPath's profile engine reveals something the spreadsheet misses: the direct ray passes above a secondary ridge at the 8 km mark. That ridge is only 40 metres below the direct LoS line — but it obstructs the Fresnel zone. The path is NLOS, and has been all along.

The auto-routing logic in FresnelPath's path analysis detects this terrain, counts obstacles, and selects the appropriate diffraction method. When obstacle height variation exceeds 150 metres or obstacle count exceeds 10, Deygout diffraction applies.

Why Deygout — and what it computes

The ITU-R P.526-15 standard describes four diffraction methods. FresnelPath implements all four and selects automatically based on terrain characteristics:

• Knife-edge: Single dominant obstacle — the Fresnel-Kirchhoff v-parameter and J(v) loss function
• Bullington: 2–10 obstacles in rolling terrain — reduces to equivalent single obstacle
• Deygout: >10 obstacles or height variation >150 m — recursive sub-path analysis on each dominant ridge
• Epstein-Peterson: Successive knife-edge summation for comparison

Deygout's recursive approach matters in Andean terrain because paths rarely have a single dominant obstacle. A crossing at high altitude typically encounters multiple ridges of comparable height. Treating the problem as a single knife-edge underestimates total diffraction loss; Bullington's equivalent-obstacle simplification can also underestimate it. Deygout, by analysing each sub-path independently and summing the results, handles this correctly.

A convex-hull pre-filter on the terrain profile reduces 200–600 sample points to the 5–20 vertices that actually determine diffraction geometry — so computation stays fast even for complex terrain with many measurement points.

LoRaWAN regional parameters in South America

One thing that catches deployments in this region: Chile and Argentina use AU915, not EU868. The sub-bands, EIRP limits, and dwell-time rules differ. AU915 operates at 915 MHz with a 30 dBm EIRP limit (in practice, regulated locally — verify with the national authority) and no duty-cycle cap, but FCC-derived dwell-time limits apply per channel.

At 915 MHz rather than 868 MHz, the first Fresnel zone radius is slightly smaller (higher frequency = tighter zone), which means terrain features need to be proportionally closer to the direct ray to cause obstruction. The difference is not large enough to change the physics in high-terrain scenarios — ridgelines that obstruct at 868 MHz obstruct at 915 MHz too.

FresnelPath's country selector handles this automatically: selecting Chile or Argentina resolves to AU915, prefills the correct frequency, EIRP limit, and dwell-time parameters.

What the profile tells you that the link budget doesn't

The path profile view — terrain cross-section with Fresnel zone arcs and the direct LoS line — makes the problem visible in a way that a single dB number doesn't. When you see the terrain rising into the Fresnel ellipsoid at the 8 km mark, you understand why the link failed. You also see immediately what would fix it: moving the gateway 200 metres higher would clear the secondary ridge; alternatively, a relay node on the intervening terrain would bridge the two line-of-sight segments.

The terrain analysis uses 30 m resolution elevation data from Copernicus GLO-30. That means features smaller than 30 m — a building, a dense tree line, a cliff face — may not appear in the profile. The tool is honest about this: GLO-30 has approximately 4 m vertical RMSE. It's reliable for ridge and valley geometry. It's not a substitute for a field survey of the last 50 metres of obstruction at the antenna site.

The practical takeaway

Before committing hardware and a long drive to a mountain site:

1. Run the path profile. Not FSPL — the full terrain-aware analysis with Fresnel zone overlay.
2. Check whether the Fresnel zone is obstructed, not just whether the LoS line clears the terrain.
3. Look at which diffraction method fired and what additional loss it computed. That's the number the spreadsheet was missing.
4. If the path crosses multiple ridges, Deygout is the right method. Verify the model selection in the results drawer's Model tab.

LoRaWAN is remarkable at making marginal links work. CSS modulation decodes below the noise floor; SF12 extends range by roughly 15 dB relative to SF7. But those 15 dB don't compensate for 30 dB of unaccounted diffraction loss. The mountain wins if you don't see it first.