ADR Not Working on AU915 (Device stuck on SF12)

End Devices (Nodes) Hardware
1

I’ve been testing several end devices and no matter what I try ADR info is never added to Downlink or ACK message generated by server.

Devices are using 1.0.2 Region paraamters (SF12 and SF11 were added to Data rate in that version).

Yes, I’ve let device to do 20-30 uplinks before setting ADR flag on uplink packet expecting that ADR will optimize data rate.

I’ve done some analysis of trace on gateway and what is common is that error is reported by the trace and it seems to be related to “link-adr” command. Error is “the given data-rate does not exist”.

Only that portiion of the trace is listed bellow.
Would anyone be in a position to clarify what is the cause of this and where that message originates from ?

359.57ms networkserver ttn-networkserver-eu set ack
360.11ms networkserver ttn-networkserver-eu schedule mac command
cmd:link-adr
reason:initial
360.32 ms networkserver ttn-networkserver-eu mac error
cmd:link-adr
error:lorawan/band: the given data-rate does not exist
362.13ms broker ttn-broker-eu forward
handler:ttn-handler-eu

Regards

2

Yes I have seen this also, on AU915, what kind of device is it? I only ask as I’m trying to narrow it down to a device issue or a TTN issue.

3

This happens on several devices that I’ve tried. They are custom made STM32+SX1276 bare metal devices running official Semtech stack. One that I have most control of is actually STM32L100 discovery board wired to Modtronix SX1276 915 device and it is running Mbed.

I am 100% certain that all devices operate OK. As uplink and downlinks are working reliably.
Setting request for ACK works fine and I can see messages coming back to device.
Issue is that ADR info never comes back so devices are stuck on SF12.

4

Yes I have seen the same with a couple of different boards also, so I’m guessing its not the Semtech stack.

@htdvisser any news on this? Is it something we have to work around for the moment or something that might be resolved before the V3 stack?

Cheers

5

It indeed seems that SF11 and SF12 are not properly set up on AU915. This is a server-side problem that we want to get resolved in v2.

6

Cross-post from Is this behaviour what one would expect from ADR on AU915? - #13 by dub :

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.

7

Thanks.

Let us know when you’ve applied your fixes so we can test it here in AU.

Also, another thing comes to mind is that even 1.0.1 might be revoked there still might be some devices in a field that are using it. As it is right now my understanding is that ADR on TTN works for devices using 1.0.1 band plan but not 1.0.2.

Are your fixes going it cater for both 1.0.1 and 1.0.2 or only 1.0.2 (E.g. if device joined at SF12 it is 1.0.2 and if it joined on SF10 it is runing 1.0.1 band plan) ?

8

We just deployed the patches to the “meshed” region of the public community network. Let us know if this solves your issues.

Unfortunately, our v2 stack isn’t able to work with “mixed” versions of LoRaWAN and the Regional Parameters specification, so from now on we only support v1.0.2 (RevB). In our upcoming v3 stack, it will be possible to select the LoRaWAN and Regional Parameters version for each device that you register.

9

Hi,

It doesn’t seem that ADR is working at all on AU915. 1.0.02b

I’ve restarted device,
It joined network at SF12 and it stays there despite ADR info being requested.

Question:

Have you updated “ttn-handler-eu” or “meshed-handler” or both ?
Our test application uses “ttn-handler-eu”.

I’ve waited for 30+ uploads and server traces are still showing “given data-rate does not exist” as before.

Here is an example of trace section around set-ack.

360.29 ms networkserver ttn-networkserver-eu set ack
361.02 ms networkserver ttn-networkserver-eu schedule mac command
cmd:link-adr
reason:initial
361.47 ms networkserver ttn-networkserver-eu mac error
cmd:link-adr
error:lorawan/band: the given data-rate does not exist
363.94 ms broker ttn-broker-eu forward
handler:ttn-handler-eu
366.1 ms handler ttn-handler-eu receive

Let me know if you need some more info.

Regards

10

Great will test it out, does this mean that the meshed handler is the only handler that supports ADR for AU915?

11

Correct. If it works well, we’ll also deploy the new version to our other regions.

12

Ok. This means that I’ll have to reregister at least on of my apps to point to meshed-handler.
Will do it tonight and will let you know as soon as I test it.

13

Updates to other regions are being rolled out today, so if you can wait, you won’t have to re-register apps and devices.

14

Hi Hylke,

I’ve re-registered few devices to meshed-handler and it all seems to be working fine now.

Device joins at SF12 does first uplink with ACKREQ set and servers moves it to SF9.

Thanks for very quick fix !

Regards

15

Which library do you use for TTN in your nodes? LMIC?

16

I am using Semtech LoraWan .

I used LMIC too.

17

And LMIC is working with ADR? Have you a code example, in my case it doesn’t work, see here Error: too many failed ADR requests

18

Haven’t tried ADR on LMIC but it should work.
I’ll comment in your thread Error: too many failed ADR requests bit more.

19

Should work…, i have read that very often in the last days since searching for solutions of the problem, but it seems that no one has a working node which uses LMIC and ADR. It’s little bit frustrating at the moment, i will try your suggestions and post more screenshots from the TTN console.

20

ADR for AU915 working on the EU handler, thanks @htdvisser