LoRa Intermittence Connection

Wireless & IoT LoRa (Long Range)
1

  1. During direct serial testing of the LoRa device, we observed intermittent “ERROR” outputs during AT command execution. Despite troubleshooting with both \r\n and \r termination sequences, the issue persists and the device fails to consistently return the correct output.

    What is the recommended method to reliably poll and execute AT commands?

  1. We are experiencing an issue where our paired LoRa devices automatically disconnect. This occurs reliably after 3 hours of sending data at 15-minute intervals, but it also happens randomly when the radios sit idle for anywhere from a few minutes to several hours. When this failure occurs, both the paired loRa device the yellow status LEDs turn off completely, and we must physically power-cycle the USB cable or reset the serial COM port to re-establish the connection. Is there a known fix or a configuration change to resolve this?

  2. Similarly, we also noticed an intermittent issue where the yellow status LED on one of the LoRa device automatically turned off and then illuminates again after a few seconds. In some instances, a manual reconnection of the serial COM port is required to reactivate the device and restore normal operation. Could you please advise what might be causing this behaviour?

  1. In some edge cases, the communication link drops permanently and becomes completely unresponsive to hard power-cycles or serial COM port re-initializations. Normal transceiver operations can only be recovered by executing a new pairing sequence with an alternate LoRa device. Is there any explanation that causes this permanent link loss and how to prevent it?

  1. Using two terminals, each connected to a LoRa device, we tested message transmission from one device to the other. The transmission was not consistently successful on the first attempt; a second or third attempt was required before the message was successfully received. Does the LoRa device possess any built-in functionality or configuration settings to resolve this and ensure that the first transmission attempt succeeds consistently?

We have reviewed the RSSI readback values and used the AT6 command to verify the link connection. During our investigation, we found that setting the airspeed to 9600 improved communication stability in our test cases. However, to better understand the above behaviours and the underlying causes, we would appreciate any additional insights or information you can provide.

2

This is a really long post; make sure to review the pertinent links (I did not re-link for subsequent repeat references…for example I only linked to AT commands once but refer to that section quite a bit!)

1. Intermittent ERROR: Could be a few things, but the root cause here is almost always command mode timing and response handling.

The radio enters command mode via +++ and must return OK before it is ready to accept AT commands. If your code sends +++ and immediately fires the next AT command without waiting for that OK, the command lands while the radio is still processing the mode switch, producing an ERROR.
Reliable polling sequence:

  • Send +++ and wait for OK\r\n before sending anything else (allow at least 1–2 seconds)
  • Send each command and wait for its response before queuing the next one — don’t pipeline
  • Use \r\n line endings (standard AT command convention)
  • Be aware that during AT configuration, echo is turned on regardless of the Echo setting, so your parser needs to strip the echoed command text before reading the actual response Link the AT commands
  • After configuration, explicitly send ATO to exit command mode, or ATZ to reboot

Additionally, be cautious that the AT-Param=xxx syntax requires the exact parameter name — for example AT-AirSpeed=9600, not ATS9600. A name mismatch returns ERROR.

2. Automatic Disconnects After Timed or Idle Periods:

This is driven by two separate mechanisms.

Heartbeat timeout (the core mechanism): Heartbeats are transmitted on a regular basis by the server and in point-to-point mode by the clients. If a HEARTBEAT frame is not received within three (3) times the HeartbeatTimeout interval, the point-to-point link is broken. The default HeartbeatTimeout is 5000 milliseconds. This means any RF gap longer than ~15 seconds will drop the link.

In P2P mode, if data is not able to traverse the link for 3 × Heartbeat Timeout, the link is marked as down and any data in the buffer is flushed. Radio linkup is then initiated. Operating Modes

USB power management (why physical power-cycling is required): The fact that you need to physically cycle the USB cable or reset the COM port strongly points to the host OS suspending the USB device during idle periods (Windows USB Selective Suspend, Linux autosuspend, etc.). The radio itself may have re-linked over RF, but the USB serial port has been suspended or dropped by the OS.

Fixes to try:

  • Disable USB Selective Suspend on the host for those COM ports (Device Manager → USB Root Hub → Power Management)
  • Set AT-UsbSerialWait=1 — this causes the radio to wait for the USB port to be enumerated and opened before beginning operation. This prevents the radio from proceeding into an unrecoverable state when the USB connection drops
  • If possible, send a keep-alive byte periodically during idle periods to maintain the heartbeat
  • Save settings with ATW after adjustments so they survive a power cycle

3. Yellow LED Turning Off and Re-illuminating Intermittently

LED behavior depends on the SelectLedUse mode. In the default RSSI mode (mode 4), the yellow LED indicates when serial data is received from the host and sent over the radio. In LEDS_RADIO_USE mode (mode 3), the yellow LED blinks when a duplicate frame is received, or when a frame’s software CRC does not match. LED States

The yellow LED going completely dark and then recovering — especially when it requires a COM port reconnection — is consistent with the device briefly resetting. When the device is first powered on or is reset, all LEDs blink quickly three times. If you observe that three-blink pattern preceding the yellow LED going out, it is a spontaneous/unexpected reset.

Possible causes include USB voltage sag (if powered from a hub without adequate current), the host OS re-enumerating the port, or a firmware watchdog trigger. Switching to a direct USB port (not a hub), enabling AT-UsbSerialWait=1, and switching LED mode to LEDS_RADIO_USE (mode 3) will give you more diagnostic visibility into whether CRC mismatches or duplicate frames are the underlying trigger.

4. Permanent Link Loss Requiring Re-pairing

This is the most serious failure mode and points to NVM (non-volatile memory) corruption of the radio settings — specifically the NetID or encryption key — causing the two radios to become mutually incompatible.

Some settings must be identical on both radios for the link to be possible. These settings are used to generate the unique hop table. If settings are not compatible, they will not communicate

If a power interruption occurs mid-write during an ATW save-to-NVM operation, the stored settings on one radio can become corrupt or partially written, while the other retains the prior valid settings. The two radios then have mismatched parameters and can never re-link.

To prevent this: never send ATW during active data transmission, and always follow a configuration change with ATW + ATZ (reboot) to verify the settings are read back correctly with ATI0 or AT-NetID?.

To recover without a full re-pair in future: you can factory reset a radio by pressing and holding the training button for 10 seconds until all LEDs blink quickly three times. This erases NVM and returns the radio to factory settings. The ATF command achieves the same result. Factory resetting both radios and re-pairing will restore operation without needing a new device. Training Mode

5. Inconsistent First-Transmission Success

This is expected behaviour linked to link establishment timing and the default MaxResends setting.

In P2P mode, radio linkup is performed at Channel 0 — both radios power on and begin pinging each other until another radio is detected. Once a handshake is complete, both radios begin hopping through their channel tables. If your application sends data before this handshake completes, the first frame may be lost.

The MaxResends parameter controls the number of retransmission attempts when an ACK is not received. The default of zero represents infinite retries — retransmission will continue as long as the two radios are receiving HEARTBEAT frames from each other. The transmission will fail only if/when the link breaks.

This means the system is designed to eventually deliver data — but it does not guarantee the first physical frame succeeds. Practical fix:

  1. Before transmitting, use ATI6 to confirm the link is fully up: ATI6 displays the current radio state, for example “State: P2P: Receiving Standby LinkUptime: 2:45:08”. Only send data once LinkUptime shows a non-zero value
  2. Keep MaxResends=0 (infinite) for important data so the radio handles retransmission automatically
  3. Implement an application-layer acknowledgement (e.g. a short reply message) so your software can confirm end-to-end delivery and retransmit at the application level if needed

6. Regarding AirSpeed 9600 and Stability

Your finding that 9600 bps improves stability is because AirSpeed overwrites five underlying parameters simultaneously: HeartbeatTimeout, RadioBandwidth, RadioCodingRate, RadioSpreadFactor, and TxToRxUsec. At 9600 bps, the radio uses a wider bandwidth and shorter symbol time, which reduces the sensitivity to timing errors and RF noise in typical indoor/near-field test environments

Note that the AirSpeed setting can be queried but is not back-calculated after a system reset — after reset the AirSpeed will report 0. To verify the actual airspeed, check the five underlying parameters against the AirSpeed calculation table in the firmware repository. This is worth confirming after any power cycle to ensure settings persist as expected