Use this page when a LoRaWAN device is joined (or is an ABP device) but its readings do not arrive, arrive wrong, or its downlinks do not reach it. Start from the frames log and the device’s LoRaWAN tab.
Uplinks do not arrive
| Frames log shows | Cause | What to do |
|---|---|---|
| Nothing from the device | No gateway heard it. | Check a nearby gateway is Online; check the device’s battery and that it is sending (its own LED or tool). |
| Unknown device address | No session of yours has this DevAddr. OTAA: the device runs an old session (for example after you used Reset session), or it never joined. ABP: the DevAddr differs from the stored one. | OTAA: make the device join again. ABP: check the DevAddr. |
| Integrity check failed | The frame’s MIC does not match the session key. ABP: the NwkSKey differs. OTAA: an old session after the device re-joined elsewhere. | ABP: enter the keys again with Replace keys. OTAA: make it join again. |
| Replayed frame | The counter did not move forward. | ABP device restarted: Reset counters. Otherwise someone may be replaying recorded frames. |
| Frame counter jumped | The counter jumped by more than 16,384. | ABP: Reset counters. OTAA: make it join again. |
| Processed | The network server accepted it. | The problem is after the network server; see below. |
Processed, but no readings on the device
| Check | Cause and fix |
|---|---|
| FPort is 0 | MAC-only frame; it never carries readings. Normal. |
The device message has only raw | No codec decoded it. Choose a codec on the device or profile; see Codecs. Test with the codec’s Test bench. |
| Values arrive with odd names | The codec uses the maker’s key names. See Cleaning up decoded values. |
| Nothing stored at all | The root flow (organisation or profile) has no Save telemetry step, or a flow fails. Check the flow and its failed messages. |
| The device is held | A device added by pairing mode stores nothing until approved. |
Readings are wrong
- Decode the same payload on the codec’s Test bench and compare with the maker’s documentation.
- Check whether a different codec was chosen than you think: device choice first, then profile, then automatic.
- When the chosen codec was withdrawn or deleted, the device falls back to the automatic choice; choose a codec again.
Duplicates and missing frames
- One uplink heard by several gateways is one device message. Copies are merged within a short window (200 ms by default). A copy that arrives later is ignored as late; it never creates a second message.
- A confirmed uplink that the device repeats because it missed the acknowledgement shows as Retransmission. It is acknowledged again, never stored twice.
- Gaps in FCnt mean frames that no gateway heard. Occasional gaps are normal for radio. Many gaps mean weak coverage: look at RSSI and SNR on Latest reception and consider another gateway.
The device shows offline although it sends
LoRaWAN end devices on the built-in profile are online while the last uplink is younger than three expected intervals (3 hours with the default 3,600 s interval). A device that reports less often than every hour shows offline between reports. Raise the expected interval on the profile’s Online status tab to match the device. See Connection status and activity.
Downlinks do not arrive
| Symptom | Cause | What to do |
|---|---|---|
| Command stays queued (Class A) | A Class A device receives only after it sends. | Wait for the next uplink, or make the device send. |
| Command stays queued (Class C) | The device’s last uplink is older than 15 minutes, so it waits for the next one. Or the device is registered as Class A. | Check the class on the LoRaWAN tab. |
| Command EXPIRED | Its expiry passed, or the parameters were wrong (fPort outside 1–223, data not hex or base64), or the payload was too large. | Check the parameters and sizes in Sending downlinks. |
| Command TIMEOUT | It was sent as two-way; LoRaWAN devices do not answer commands. | Send lora.downlink as one-way. |
| Downlink Sent via … but the device does nothing | Wrong FPort or bytes for this device, or the device did not receive it. | Check the maker’s downlink format. Use "confirmed": true to learn whether the device received it. |
| Downlinks often go via RX2 | The gateway’s round trip is too slow for RX1, or RX1 duty cycle is used up. | Check the gateway’s Round trip and lora.gw.dc_used_pct.*. Keep the RX1 delay at 5 s. |
Duty cycle
When a gateway’s duty-cycle budget in a sub-band is nearly used up, downlinks wait or go through another gateway, and the gateway’s default alarm warns above 80 %. Common causes:
- Many devices sending confirmed uplinks; each needs an acknowledgement. Switch sensors to unconfirmed uplinks.
- Frequent ADR changes on devices with an unstable signal. Turn ADR off for moving devices.
- Many confirmed downlinks with re-sends.
See Regions and frequency plans.
Gateway problems
| Symptom | What to check |
|---|---|
| Gateway Offline | Its power and internet link; its token and address. See Connect a Basics Station gateway. |
| Round trip above 800 ms | The gateway’s internet link (mobile signal, Wi-Fi). |
| Many failed downlinks | The gateway’s own log; a busy radio or its duty cycle. |