Hi,
I’m wondering if someone could help me the understand the purpose of ADR.
Currently, my node (Radiolib-based, AU915 FSB2) joins fine on ADR at SF10. ADR is enabled, and link quality is good. After join, I send a larger payload (currently ~19 bytes). This fails and radiolib throws RADIOLIB_ERR_DWELL_TIME_EXCEEDED.
Now, I understand why this is, because from the debug output, I can see it is trying to send at SF10, and in my region, the airtime of 19 bytes on this datarate will exceed the 400ms duty cycle limit.
From my understanding, it’s the LNS’s job to send ADR commands (if enabled) to change the DR if the conditions are appropriate. But if the LNS has no way of knowing the size of my next payload, and the node must treat ADR commands as authoritative (i.e. can’t pick the next best DR based on payload size), what is the purpose of ADR unless your payloads are always under 11 bytes?
And if the LNS sent no ADR command with it’s downlink, why is radiolib trying to use SF10?
I get that there is an easy fix to this, to simply override the datarate manually, but I want to know if ADR is only meant to optimise link budgets with very small payloads, or if I am just using it wrong.
For the latter part concerning RadioLib using SF7 and still showing dwelltime limits, could you please file an Issue on GitHub with your code and debug logs (using DEBUG_PROTOCOL flag) displaying this behaviour?
Gut instinct says that there’s a user misunderstanding / error because RadioLib does pass certification runs for dwell-time bands, but I’ve seen before that certification runs aren’t definitive in numerous areas so happy to investigate!
Sorry, I meant to say that the datarate of the subsequent uplinks remains at SF10/125khz, which exceeds the dwell time limit for my payload. I have edited the post accordingly.
For the JoinRequest, any datarate DR0 to DR5 is allowed here - given dutycycle restrictions, DR0 and DR1 are not possible for the JoinRequest on your band.
RadioLib by default uses dr = (maxDr + minDr) / 2. Using the maximum datarate would result in too many posts about people not getting a Join to their neighbourhood gateway; using minimum datarate would be overkill for 99% of scenarios. That’s why we settled on average datarate favouring range.
For subsequent uplinks after join, this datarate is kept - given that the join was successful, why not stick to that datarate? If it’s overkill, ADR should almost immediately kick in. If not on the first, then on the second downlink, unless SF10 is actually a reasonable SF given the RSSI and SNR.
But if it’s not, it can take a few dozen uplinks before the TTS algorithm (that is the Semtech algorithm, Google for details) kicks in.
Some degree of intelligence has to be included in the firmware about such matters - like using Blind ADR (Semtech again, Google etc). TL;DR: change your local DR after the join if you know you are going to hit the limits! Your backend can monitor for a join and then nothing heard and you can buy another gateway. Or you may, on Tuesdays that fall on the 32nd of the month, send a confirmed uplink. Although the LinkCheck option is an, er, option.
Please don’t do this again, it can skew responses.
It’s meant to optimise all payloads to get the best out of the available spectrum/bandwidth. One or two devices this seems like an imposition, but when you have a few thousand water meters in an area, ADR makes this work nicely.
The dwell time restrictions for AU is the radio authorities way of telling you to install more gateways or locate them better or use bigger antenna or some such. This is an unfortunate intersection between the needs of the RF spectrum in a geographic location vs a world wide specification that has to cater somehow for all the different views on the same set of physics!