I have an mDot registered on TTN with OTAA using the AU915 channel plan. The node transmits every 4 hours in practice but for testing it’s every minute. I’ve been studying the behaviour of joins/re-joins and DR changes, and most of it is logical but some mysteries remain.
Isn’t it odd that after 191 uplink with SNR > 8.5 we’re still stuck on SF8 when SF7 is both possible and more suitable? And why does the DR always change on the second uplink after a join?
Here’s another example where the DR went to SF7, but on the second uplink (not after the 40 or so ADR is supposed to monitor):
time ctr dr rssi snr
---- --- -------- ---- -----
2018-05-23T01:24:20 1 SF7BW125 -78 10.25
2018-05-23T01:23:16 0 SF10BW125 -60 11.75
I see the fix in v2.9.3 enables data rates 4 and 5. That seems to correspond with the change between Regional Parameters v1.0 and v1.0.2, which added SF11 and SF12. Unfortunately I don’t believe mBed supports the new data rates so who knows what will happen if it’s instructed to use them! Also strange - v1.0.2 also added power levels between 20 and 30dBm, but v2.9.3 seems to ignore that part, sticking with 10 to 20.
It doesn’t seem to be related to the issue I’m seeing though, since even DR3 didn’t get invoked.
What is the mechanism that changes the DR on the second uplink? Is that orthogonal to ADR?
In v2.9.3 we indeed add data rates 4 and 5 to the AU915 ADR configuration. This has nothing to do with the specified data rates, only with the ones we use for ADR.
The TxPower values in the file you were looking at are actually not used as absolute values, but rather as values relative to the DefaultTXPower in the band. It’s a bit hacky, and we’ll fix this in v3.
The way ADR works for US/AU915 in v2 (currently: May 2018) is as follows:
After a device joins, we directly send a “preliminary” ADR command in order to set the channels the device can use. This will also perform initial DR change, but it won’t send the device to the most efficient data rate yet, because we don’t have enough data to calculate this yet, and we don’t want to immediately “lose” the device.
When we have enough data (usually after 20 uplinks) we may send another ADR command that sends the device to the most efficient data rate that still has a high chance of successful transmission.
We avoid sending downlinks, so unless the device is on a very inefficient DR, we wait with sending ADR commands until the application sends a downlink (payload or even ACK), or until the device requests and ADR Ack.
We are going to deploy v2.9.3 with the fixed AU915 ADR in a couple of hours, you’ll likely see some changes then.
Oh okay, I’ve read all those and the recommended behaviour is not what is happening (since I’m stuck on SF8 after 191 uplinks where every 3rd has a downlink). Will have to do some more debugging.
Technically SF12BW125 doesn’t exist for AU915 in LoRaWAN 1.0.1, so the error might be right.
SF11 and SF12 were introduced with the 1.0.2 Regional Parameters.
was actually reproduced with devices running 1.0.2 regional parameters so it must be some issue on TTN unless there is a way to indicate version of the parameters device is running with and that wasn’t done on the device side so TTN got confused (quite possible).
As you mentioned SF12 and SF11 were introduced for AU915-928. Is it possible that ADR works correctly only if
These issues have indeed been caused by the fact that our server used to implement the (revoked) 1.0.1 (also called 1.0.2RevA) Regional Parameters. I’ve prepared a fix that updates our implementation to 1.0.2 (RevB), which I hope we can deploy early next week.
