being a member of the Sensing Labs team and seeing the issues experienced by gigi130358, I passed some time to understand exactly what happens with ADR on TTN network with Sensing Labs devices.
My starting point was : “I am sure ADR works fine on Sensing Labs devices” as they have already been certified by LoRa Alliance testing house for years now and successfully passed interoperability extensive tests with several operators.
What I did is quite simple: connect a device on TTN network through a local gateway and see what happens while directly debugging the node. With this method, I have been able to check the following items:
- the SF9 configuration of RX2 window configured through the Join Accept is taken into account by the devide
- sending application level downlink messages works on RX1 and RX2 windows
- after between 50 to 100 uplink frames, the network had not yet sent any ADR request as we can check on gateway console or with downlink counters
From this step, I could conclude there was no particular issue on the device: it was not switching its datarate because it was not requested to by the network. But why?
From the LoRaWAN specifications, it is specified that a device configured for transmitting with its lower datarate (DR0 or SF12 in the case of Sensing Labs devices) never sets the ADRAckReq bit. As the device starts in SF12 by default, that means that it will never set its ADRAckReq bit unless the network first changes its datarate.
Looking at the ADR documentation for TTN (https://www.thethingsnetwork.org/docs/lorawan/adr.html), I found that there where several conditions that can trigger an ADR request from the network (3 in our case as these are EU868 devices):
- enough measurements and datarate is not optimal: ADR request is scheduled for being piggy-backed with the next downlink (“optimize” tag)
- enough measurements and the device is using DR0 --> it seems to be the case here
- ADRAckReq bit set by the device which cannot happen here as the device is configured in DR0
However, the status is that the device does not receive any ADR request from the network.
I thus modified the device behavior for allowing it to set the ADRAckReq bit even if configured in DR0 and in this case it received and accepted successfully the ADR request from the network. However this tricky behavior does not respect the LoRaWAN specifications and should not be considered as THE solution to this issue.
What I need to understand now is:
- what does “enough measurements” mean?
- why the second condition does not trigger the transmission of an ADR request from the network (“enough measurements and the device is using DR0”)?
I hope these experiments will help solving the issue but I think I need help from TTN side now for going further.
Thank you in advance for any feedback.