ADR standard activated in V3 applications?

V2 to V3 Upgrade V3 Applications
#1

Hello!

Whenever I do register a device based on a RN2483 in my V3 application it looks like ADR is automatically applied and the SF reduced to 7 step by step. Basically this is OK, but in some cases I would like to stick with SF9 for redundancy reasons. How can this automatic ADR-activation be disabled in V3 applications?

Adding the same device in a V2 application (removing it in V3 first) does not activate ADR automatically but only with the respective Downlink message to the device. The way it should be.

Thank you for your advise!

#2

I have not tested it, but it seems that the device is updated without ADR
ttn-lw-cli d update <APP> <DEV> --unset mac-settings.use-adr

Download the CLI tool (pre-compiled binary) from here.

If you need more info: Installation instructions

#3

Whenever I change DR to 2 (SF10) an “Link ADR request” is enqueued afterwards and SF changes to SF 7 after 1-2 datasets with SF10.

This “Link ADR request” has
“name”: “ns.mac.link_adr.request”,
“data”: {
“type.googleapis.com/ttn.lorawan.v3.MACCommand.LinkADRReq”,
“data_rate_index”: 5,
“tx_power_index”: 5,…

#4

You’ve effectively duplicated what you said in your original post.

This is normal for v3 and is part of being a good air waves citizen.

The answer is there on how to disable it but ideally you have firmware that checks in occasionally or receives a downlink occasionally to reassure that it is online, rather than quadruple your airtime usage.

#5

just wanted to be technically more precise :wink:

with SF7 we receive 40-61% uplinks only with an airtime of 8.88sec/24h. too less in our case. SF9 would help a lot (like it was in v2).

#6

Can this behaviour be disabled on device basis in the v3 console or must it be disabled on the device firmware itself?

#7

At present you can disable it using the Command Line utility but not the console, with no expectation that the it will be on the console ever and certainly not any time soon.

On the V3 stack you’ll have to do this regardless as if the device receives an ADR request which it ignores, it will just get another one and another one and another one.

If you have new devices to employ, then having firmware that works to the ADR but sends the occasional packet either as confirmed or at a lower data rate (or indeed, both) and have code on the server side that looks at what’s happening and sends command downlinks to adjust the ratios on the device accordingly.

So if the server sees that a device has a good signal strength on two or more gateways, it can tell the device to obey the ADR requests. If it’s only got one gateway with a marginal strength, then tell the device to stick to an appropriate DR. And values in between.

#8

is this behaviour implemented in any LoRaWAN Version higher than V1.0.2 ?

#9

No, it’s a technique I implement in my firmware.