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.
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.
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.