Guide · LoRa links
Your uplinks arrive but your downlinks don't: the asymmetric LoRa link trap.
The sensor at the far gate reports on schedule. Every reading lands in the dashboard, the signal shows around -118 dBm, and everything looks fine. Then you try to push a configuration change to it over the air and nothing happens. The device never acknowledges. You try again. Still nothing. This page explains why a LoRa link that works one way can fail the other way, why that failure mode is dangerous when you rely on remote reconfiguration, and the rule we now follow on the bench.
Last reviewed: 18 July 2026 · by Alien IT Solutions
What we saw
A Dragino door sensor on a long paddock link ran between -108 and -121 dBm at the gateway, drifting with weather and vegetation. Uplinks, the sensor's own reports, kept arriving across that whole range. A few dropped at the very bottom end, but LoRa's coding gain and the retry behaviour meant the data stream stayed usable.
Downlinks were a different story. Configuration messages queued for the device delivered fine when the link sat near -108, and failed almost every time once it sank past roughly -115. Same device, same distance, same antennas. The link only worked properly in one direction.
Why the link budget isn't symmetric in practice
On paper a radio link is reciprocal: path loss is the same in both directions. In the field, the two ends of a LoRa link are nothing alike.
The gateway hears better than the node does. A gateway has a proper antenna, usually mounted high, with a low-noise front end designed to dig signals out at the sensitivity floor. The node is a battery sensor with a stub antenna, mounted wherever the job needed it: often low, often near metal, sometimes inside a plastic housing screwed to a steel post.
The noise floor differs at each end. The gateway sits on your homestead or shed, but it's listening toward open paddock. The node might be listening back toward the homestead, toward your solar inverter, pump controller, and every other electrically noisy thing on the property. Interference at the receiving end is what kills reception, and the two ends do not share an environment.
Downlink timing is unforgiving. A class-A LoRaWAN node only opens two short receive windows after each uplink. The gateway gets one or two chances to hit a marginal receiver at exactly the right moment. Uplinks, by contrast, are heard by a receiver that listens continuously on multiple channels.
Add those together and a link that delivers uplinks at -118 dBm can be a link where downlinks stop working at -112. The margin is not the same in both directions, and the direction you can't see failing is the one pointed away from your dashboard.
The trap: reconfiguring a marginal node over the air
Here is where it gets expensive. The obvious response to a weak remote node is to push new settings to it: a higher spreading factor, a different reporting interval, a transmit-power change. Over a marginal downlink, that is exactly the wrong move. The failure cases stack badly.
The command never arrives
Annoying but harmless. You wait, retry, wait again.
The command arrives but the acknowledgement doesn't
Now your network server and the device disagree about the device's state. Frame counters and channel settings can drift apart, and the node's uplinks may stop being accepted at all.
Half a multi-part change arrives
The node ends up on settings neither you nor the server expected. If the change touched radio parameters, the node may now be transmitting where the gateway isn't listening.
That last case is how you brick your access to a device that is still running fine. The sensor keeps waking, reading and transmitting into a configuration mismatch, and the only fix is a drive to the far gate with a ladder and a laptop, which is what over-the-air configuration was meant to avoid.
The rule: worse than about -115 dBm, configure at the bench
Our working rule from that Dragino job: once a node's RSSI at the gateway is worse than about -115 dBm, treat the downlink as unavailable. Read from the device, but don't write to it over the air.
Configuration changes go over serial or USB at the bench instead. Pull the node, or walk to it, plug in, and set it up with a cable where nothing can half-arrive. Serial configuration is boring and reliable, which is the point. Do the risky settings work, region, sub-band, keys, spreading factor, report interval, before the device goes up the hill, and design the deployment so you never depend on downlink to keep control of it. (Getting those settings right in the first place is its own checklist: see AU915 and TTN: the settings that stop your node joining.)
If a site genuinely needs remote reconfiguration, fix the link first, not the settings. Raise the node's antenna, swap the stub for a small external whip, move the gateway, or add height at either end. Every dB of margin you buy serves both directions; a link that reports at -105 instead of -118 is a link you can actually manage.
Reading your own numbers
Check the RSSI your gateway logs for each device, and watch it over days, not minutes. Vegetation, rain and temperature swing a marginal link several dB. A node that shows -112 on a clear morning may be a -120 node in a wet week, and it's the wet week that decides whether your downlinks work. Judge the link by its worst regular reading, then apply the rule above.
The short version
LoRa uplinks and downlinks fail at different signal levels because the gateway's receiver, antenna and noise environment are far better than the node's. A node reporting reliably at -118 dBm can be unreachable for configuration downlinks. Pushing settings over a marginal downlink risks a state mismatch that cuts you off from a working device. Once RSSI is worse than about -115 dBm, configure over serial or USB at the bench and treat the radio as report-only.
General guidance from bench experience: your hardware, terrain and firmware will shift the exact numbers.
Who works this out for you
Long Range WiFi is a service of Alien IT Solutions, 18 years of networks and wireless in places without a power point in sight. Marginal links get found before they get deployed: see the site & line-of-sight survey, or masts & relays for buying back margin with height.
Got a sensor you can hear but can't reach?
Tell us what's deployed and where. We'll look at the link, not just the settings, and come back with a plan that keeps every node manageable.
Get a quote