Relocating a LoRaWAN Sensor: Separate Old and New ADR Test Evidence
A LoRaWAN sensor reports reliably on a commissioning bench, then becomes intermittent after it is moved to its final mounting point. The old signal readings still look reassuring in the network console. Before changing transmit power or declaring the new position acceptable, separate the radio evidence collected before and after the move.
Adaptive Data Rate (ADR) uses observations of the radio link. A location change is therefore a reason to review the evidence behind the settings, not simply carry forward a successful bench test. The practical task is to establish a new baseline, record what configuration is actually in use, and assess delivery under representative operating conditions.
Original conceptual illustration; not a specific product, optical specification, live measurement or customer installation.
Key takeaways
Treat relocation as a new radio acceptance condition.
Keep old and new observation windows distinct.
Assess actual delivery alongside server radio settings.
1. A stationary sensor can still experience a changed link
The Things Network’s ADR guidance identifies sufficiently stable RF conditions as the basis for using ADR. A fixed installation often provides that stability, but an obstruction can change it. Relocation, changed shelving or a different enclosure can make yesterday’s radio observations unrepresentative.
This does not mean ADR must always be disabled after a move. It means the operating environment must be reassessed. A sensor that stays in its new position is different from a device that repeatedly travels between locations. Define which behaviour the application actually requires before choosing a policy.
2. Identify the transmitter location separately from the sensing point
The Dragino LHT65N indoor temperature and humidity sensor includes an external sensor connection. The catalogue photograph shows the radio unit and a cabled probe. Record both positions: the probe’s measurement location and the enclosure’s radio location answer different commissioning questions.
Dragino’s LHT65N/S documentation distinguishes the LHT65N’s built-in spring antenna from the LHT65S’s external SMA antenna. It also documents ADR, data-rate and transmit-power settings. Do not transfer antenna instructions or command assumptions between models without checking the exact device and firmware.
3. Understand what the server is using
The current Things Stack ADR reference describes an implementation that considers the maximum SNR over recent transmissions, the SNR required for the current parameters, and an optimisation margin. It uses frame counters when assessing packet loss. These details describe that server implementation, rather than every LoRaWAN network.
An observation set that spans two mounting positions therefore needs careful interpretation. Label the move time in your test record and examine subsequent transmissions separately. Do not assume that changing a dashboard name, restarting the sensor or rejoining universally clears every server setting or item of radio history. Check the network server’s documented behaviour.
4. Build a relocation acceptance record
Before moving the device, save its model, firmware, regional frequency plan, reporting interval, ADR state and recent delivery evidence. Keep credentials out of shared screenshots.
Record the move time, final enclosure position, orientation, surrounding materials and the separate probe location. Preserve the original baseline rather than overwriting it.
At the final position, record received uplink times, frame counters, receiving gateways, data rate and signal metadata available from the server. Distinguish an observed value from a configured target.
Observe normal operating conditions, including relevant obstruction changes. Define the observation period and acceptable delivery performance before deciding the installation has passed.
If a configuration change is authorised, record it as a new test phase. Change one relevant variable at a time where practical, then retain the resulting evidence and unresolved limitations.
5. A hypothetical observation window
Suppose a project chooses 20 scheduled reporting opportunities at a 15-minute interval as one part of its relocation test. Allow five hours for those 20 intervals; collecting the first 20 received messages alone could conceal missing reports. This is a project example, not a universal ADR convergence time or acceptance standard.
Separate reception counts from retransmissions and from messages received through multiple gateways. Explain what you counted. If a warehouse door remains open throughout the test but is normally closed, the result has not demonstrated performance in that normal closed-door condition.
Original explanatory diagram. Numerical values are hypothetical where shown; follow the actual equipment documentation and approved application method.
6. Close the test with evidence, not a preferred setting
Avoid changing regional parameters or forcing a generic maximum-range profile merely to obtain a successful packet. An intermittent link needs a documented investigation, with application-specific decisions about coverage, reporting needs and installation constraints.
For ProSense application support, provide the exact device, final mounting photographs, move time, network server and version, reporting interval, radio settings and timestamped delivery records. That information supports a useful review of whether the new installation has enough evidence for acceptance.
Need help with your application?
For instruments and product selection, visit ProSense Instruments, email sales@prosenseinstruments.com.au or call 1800 560 854.
For monitoring and automation projects, visit ProSense Solutions or email sales@prosense.com.au.
For software enquiries, visit ProSight Software or email info@prosightsoftware.com. Confirm integration requirements for the exact instruments and system.
Comments