ADR implementation example?

[Eric Tsai]

I see that ADR has been supported on the conduit since about June, and there’s been a couple of updates since then too. What’s the current state of the ADR functionality? Is there an example end-node mbed code out there? I’m looking for guidance on how to use it on the end point, as well as what settings are involved on the gateway.

From what I can gather, these are the three gateway configuration changes relating to ADR are:

ADRStep: Step in cB between SNR based datarate assignment for ADR

minDatarate: Min datarate for ADR, default: US915/AU915 DR0 – SF10BW125

maxDatarate: Max datarate for ADR, default: US915/AU915 DR4 – SF8BW500

If your application is packet size sensitive and you can’t do 11-bytes, you may need to set the minimum spreading factor (minDatarate) to something lower than SF10. But why is the default maxDatarate SF8 instead of SF7?

On the end node, it looks like we’re suppose to set TX power to max, so dot->setTxPower(20). Beyond that, it looks like we have to call link check in order to receive new TXPower and datarate settings? Should Link Check only get called after we’ve sent 8 packets (the number of packets ADR on conduit uses to calculate valid new values). In 2.0.1 firmware update log, there is this line:

 

ADR check if datarate was lowered below current payload size and increment as necessary

 

What does that mean? Does ADR automatically increase the datarate if dot->send(data) with a packet size greater than the automatically determined spreading factor?

[Jason Reiss]

On the end-node you only need to enable ADR.
This will signal the network server to control the device datarate based on SNR. This will happen inline with sending uplink packets.
When the network server determines that the device may use a higher datarate or lower power, when at max datarate, it will send a command for the device to change settings.

The ADR step can be used to adjust the aggressiveness of datarate switching. Theoretically there is a 25 cB link budget difference between each datarate. Therefore the min value for ADR step is 25 cB. Default value of 30 cB is used to allow a small variation of SNR. Higher values will require greater SNR to reach the highest datarates.

DR4 is the default max and the maximum uplink datarate in the US/AU channel plans. DR3 – SF7BW125 and DR4 – SF8BW500, the bandwidth is 500k which more 4x faster than a 125k channel. Each SF or BW step will double datarate.

The link check does NOT need to be called in order for ADR to work. It is merely a way for the device to query the network link health. The link check could be used by the device to implement manage its own datarate in similar fashion to ADR but this would not be AUTOMATIC. Managing ADR at the server is more efficient as downlink packets will be minimum.

When ADR is enabled and ACK is requested with >2 retransmissions the datarate will be lowered after 2 missed ACK’s. The ADR check will not allow ADR to lower the datarate below the minimum required to send the current payload size. It will NOT automatically increase the datarate to match a new payload.

[Faustin Empis]

Hi Jason,

Your explanation is very clear, however I have the following situation :

3 LoRaWAN devices connected to a single gateway (AEP conduit with lorawan network server).
1 of the device has some trouble to communicate with the gateway (not because of distance but obstacles), with about 18% frames lost. This ratio can be improved/solved with better antenna (UFL antenna is connected to the LoRaWAN device, classic 3dbi antenna to the gateway)

Now my wondering is about the ADR management of the network server (ADR is enabled on device side).
I have a weird behaviour of my device with periods up to 12 hours with no frame lost, and other periods with about 1 on 3 frames lost. Maybe this is due to the environment (multiple walls, disturbance ?), but the device is static.
The device is started by default with SF9, but most of the time the ADR is down to SF7 even when the device has trouble to communicate. SF can be set at 8, then 9, 10, 11 by network server, and finally set at 7 for no specific reason (still transmitting the same frame)
Low Spreading Factor and lost frames do not coincide, I have cases where communication is good with SF7 for a long period, sometimes it is not.

The LoRaWAN device is class C, and sending unconfirmed frames (1 time, no ack required) with 58 bytes of payload most of the time (every 5 minutes), and sometimes 70 (3 times a day), 47 (1 time a day), and 80 (1 time a month).

Thank you

• This reply was modified 7 years, 4 months ago by Faustin Empis.

[Author]

Posts