Is this behaviour what one would expect from ADR on AU915?

Thanks to threads like How can I see if ADR (Adaptive Data Rate) is working with my end device (MultiTech's mDot module)? and ADR - not what I expected I have a good understanding of how ADR is supposed to work in practice, but still not great.

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.

This is the sort of thing I see:

time                 ctr dr        rssi snr
----                 --- --------  ---- -----
2018-05-22T18:02:30  0   SF10BW125 -88  9.75
2018-05-22T18:03:34  1   SF8BW125  -90  11
2018-05-22T18:04:38  2   SF8BW125  -91  11.25
2018-05-22T18:05:41  3   SF8BW125  -88  10.25
2018-05-22T18:06:46  4   SF8BW125  -88  8.75
2018-05-22T18:07:50  5   SF8BW125  -88  10
2018-05-22T21:25:21  190 SF8BW125  -90  10.75
2018-05-22T21:26:26  191 SF8BW125  -90  9.75

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
1 Like

as far as I know ADR is not enabled in TTN for region AU915, it is only enabled for EU868 and US915

today TTN will be updated to to fix ADR AU915

1 Like

Oh, well that’s interesting. I concluded it was already active from this thread: How can I see if ADR (Adaptive Data Rate) is working with my end device (MultiTech’s mDot module)?

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:

  1. 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.
  2. 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.
  3. 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.

Terrific - great info!

The piggy-backing on another downlink is interesting.

As for the actual algorithm, I think I need to leave this in the black box for now and assume things are working as they’re supposed to.

More details on our ADR algorithm can be found in the docs, on github and in this document

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.

I think I’m seeing the same issue, gateway trace, this is with a RM191, don’t know which is causing the issue


I have been sending a lot of confirmed packets for testing, stuck at SF12BW125, hope this is helpful.


These details could be useful for debugging. Thanks, @AdamJP.

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.

I think I’m getting some sort of ttn down link now, or its something else … cant tell as I cant open the details:


Andrew, you are spot on there.

Issue that I reported in another thread


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

  1. Device is running on AU915 pre-1.0.2 parameters.


  1. Device is running on AU923

Has anyone tried ADR on AU923 ?

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.

BTW: There is no such thing as AU923.

Thanks @htdvisser - this will solve a few different issues we’re seeing.

Thanks for update. This explains issues we’ve had on AU915.

Yeah you are right. I’ve wrongly quoted AU923 while I meant AS923 as per LoraWan definition.