Designing a LoRa Mesh for Mountain Races
Mountain ultras punish assumptions. The course folds behind granite, weather erases line-of-sight, and aid stations are often the only dependable power source. Our network design starts from those constraints instead of pretending race day looks like a lab bench.
- Relay nodes are staged around terrain transitions, not evenly spaced mileage markers.
- Runner devices transmit on narrow duty cycles so the mesh can scale with field size.
- Backhaul is optional; the local command network must still function when internet links fail.
Start with terrain, not topology diagrams
Mesh density changes as the race stretches
Backhaul is useful, but it is not the system
Start with terrain, not topology diagrams
We map every course against ridgelines, canyons, and likely shadow zones before we place a single relay. The useful question is not how many nodes fit on the course, but which terrain breaks line-of-sight at the moments when race command most needs telemetry.
Aid stations, summits, and road crossings become structural anchors because they offer power, volunteers, and repeatable access. We then add mobile relay capacity only where the terrain model says the course will fracture into isolated segments.
- Summit relay for cross-valley rebroadcast
- Aid-station relay for dense runner traffic and power availability
- Portable road-access relay for temporary dead-zone recovery
Mesh density changes as the race stretches
The first hour of a race looks nothing like the twenty-fourth. Early on, tracker density is high and packet collisions are the main risk. Later, the field spreads out and the problem becomes sparse connectivity with long propagation gaps between runners.
Our firmware uses bounded retry windows and short burst scheduling so the network can absorb start-line density without permanently raising airtime for the rest of the event. The objective is predictable latency, not maximum chatter.
start_window: 45s uplink, 2 retries, 6s jitter
spread_window: 60s uplink, 1 retry, 10s jitter
sos_window: immediate uplink, priority rebroadcastBackhaul is useful, but it is not the system
Cellular and satellite backhaul improve observer access, but race safety depends on the local mesh reaching command even when the public internet is unavailable. That changes how we budget power, where we deploy gateways, and what data gets priority when bandwidth tightens.
Every node in the chain needs to answer a simple question: if the uplink disappears for thirty minutes, does race command still know who moved, who stopped, and who pressed SOS? If not, the architecture is not finished.