explanation of adr implementation

[Michael]

We are running different field-test scenarios with the MTCDT-LEU1-210A with firmware 1.6.2, EU868 channel plan and RN2483A motes. We use OTAA to connect and confirmed Uplinks with ADR enabled to communicate. In the first experimental inhouse setup we saw everything working as expected including the data rate adaption due to signal strength.

But now we are facing problems on our extended field test. The distance between mote and gw is about 1 mile almost line of sight. Our mote joines OTAA with SF12 and we would expect ADR to lower the SF after multiple uplinks under the following conditions:

datr: SF12BW125 lsnr: -1 rssi: -112 fcnt: 9
datr: SF12BW125 lsnr: -0.5 rssi: -112 fcnt: 10
datr: SF12BW125 lsnr: -2.5 rssi: -115 fcnt: 11
datr: SF12BW125 lsnr: -1 rssi: -111 fcnt: 12
datr: SF12BW125 lsnr: 0 rssi: -114 fcnt: 13
datr: SF12BW125 lsnr: -1 rssi: -117 fcnt: 14
datr: SF12BW125 lsnr: -2.5 rssi: -113 fcnt: 15
datr: SF12BW125 lsnr: -1 rssi: -113 fcnt: 16
datr: SF12BW125 lsnr: -1.5 rssi: -114 fcnt: 17
datr: SF12BW125 lsnr: 0.5 rssi: -113 fcnt: 18
datr: SF12BW125 lsnr: -3.7999999999999998 rssi: -114 fcnt: 19
datr: SF12BW125 lsnr: -1.8 rssi: -115 fcnt: 20
datr: SF12BW125 lsnr: -6 rssi: -113 fcnt: 21
datr: SF12BW125 lsnr: -1.2 rssi: -131 fcnt: 22
datr: SF12BW125 lsnr: -2 rssi: -114 fcnt: 23

With SNR ~0dB we would expect a clear DR adaption.

Can you please give us a short overview how ADR is implemented on the gateway and why our mote does not get a DR adaption in this given case.

Thank you, best regards
Michael

[Jason Reiss]

ADR in EU868 will update the datarate when it is allowed by the end-device configuration.

If the ADR bit is set in the uplink the network server will send an ADR update after several packet with sufficient SNR. RSSI is not factored in.

SNR must exceed -15 dB for DR1, -12 dB for DR2 … -3 dB for DR5

I would expect the network server to update the device to DR5 when this sequence of packets was received if ADR is enabled.

http://www.multitech.net/developer/software/lora/lora-network-server/mqtt-messages/
Ensure “adr”: true in received “up” messages
“opts” should be set in “packet_sent” and “mac_sent” messages

[Michael]

Hi Jason,
thank you for your quick answer.
The gateway requets ADR with “opts”:”0350ff0001″, which I interprete to DR=5, PWRIndex=0.
The mote responds with “opts”:”0303″, which I interprete to PowerACK=false, DataRateACK=true, Channel Mask ACK=true.

As stated here (only have a look at the last three posts) the RN2483 rejects the complete ADRReq as it does not know a PWRIndex=0 for 868 Mhz frequency band, as 0 would mean MAX EIRP=16 dB.

How should we deal with that now?

• This reply was modified 5 years, 5 months ago by Michael.
• This reply was modified 5 years, 5 months ago by Michael.
• This reply was modified 5 years, 5 months ago by Michael.

[Jason Reiss]

LoRaWAN 1.0.3 page 24 section 5.2 lines 664-666 specifies that a device should accept a power level higher than allowed but then use the allowed power.

The power index ADR will start with is not configurable.

The network server would then send lower power levels if the SNR level is sufficent at the last power set.

[Michael]

Okay, thats bad news, as ADR is really important for us…
Is it possible to inject mac send options using the MQTT interfaces? Or do you have any other recommandations how we could work arround this issue?

Thank you, best regards,
Michael

[Jason Reiss]

The end-device should evaluate MAC commands in a downlink payload with port=0.

# mosquitto_pub -t lora/<DEV-EUI>/down -d '{"data":"A1H/AAE=","port":0}'

> new Buffer("0351ff0001", "hex").toString("base64")
'A1H/AAE='

• This reply was modified 5 years, 5 months ago by Jason Reiss.

[Michael]

Thank you a lot, that did the job!

[Author]

Posts