When performing range testing, disable Automatic Datarate (ADR) adaptation.

When performing range testing, disable Automatic Datarate (ADR) adaptation.

If you are performing a range testing session with a LoRa device, and you are walking are driving, you may get into connectivity problems while moving away from the nearest LoRa base station if you use a normal production connectivity plan.

Normal ThingPark connectivity plans for static devices enable the LoRa dynamic datarate adaptation (LoRa ADR feature).
This means that when the LoRa device is close to the base station and RF connectivity is good, the network will instruct the LoRa device to communicate with a low spreading factor (e.g. SF7), and as a consequence a high datarate. This is for battery optimization (fast datarate = low air time = lower energy consumption), and scalability of the network.

However, this algorithm is slow as it takes into account the signal level of the last 10 uplink packets from the device, and is optimized for static objects only. If you were near the base station and then move away from the base station, then you may loose connectivity with the device because it is set to use a high datarate (lower range), and now the radio link is weaker and may not enable the LoRa device to use the network commands to lower the datarate. The LoRa protocol ensures that the device will reconnect eventually, because the device itself will detect that it is no longer in reach of network and will try lower and lower datarates, but this takes a long time. Much too long for range testing...

When you do range testing with a mobile device, it is preferable to use a special connectivity plan that forces the LoRa device to use the lowest possible datarate at all times, and not try to optimize it (disable ADR feature) .

Ask your operator to allocated you one license to such special Connectivity plan (e.g. "range-testing-sf12"). It should not be used in production, but if you want to force your LoRa device to use the lowest bitrate( best range) at all times, just switch it to use "range-testing-SF12" (go to device manager, EDIT the device, then go to network section of the device treeview, and update the subcription connectivity plan on the right-side panel).

Now you can do range testing without loosing connectivity while moving away from the base station. From a range test performed at SF12 only, it is easy to infer which SF(datarate) would have been used if the object had remained static on a connectivity plan with ADR enabled, by analyzing the SNR of uplinks. Ask Actility support for more details or if you need access to our specific range testing application.