ADR is not working (nucleo - raspberry -italy)

Gateways Raspberry Pi Gateways
23

Yes, any dummy downlink will quite likely work, as then TTN can piggy-back the ADR on that dummy downlink. Did you meanwhile try?

I think that in the past TTN would force creating a downlink for ADR itself when a node was on SF12 and it could not piggy-back on an existing downlink (like I explained above), but it seems that might no longer be the case.

(I am investigating myself too; in LMiC it seems that using LMIC_setLinkCheckMode(0) to disable explicit checks indeed makes ADR no longer being sent, even when a node dropped to SF12.)

24

Hi Arjan,

Thanks for reply and please apologize for my late answer, I was very busy these days.

I first tried to send some downlinks to my nodes using the console but I didn’t see any effects.
Then I realized that all the “Frame Counter Checks” checkboxes was unchecked in the device settings.
I checked all boxes. After few hours, all nodes (except one) came back from SF9 to SF7 just after receiving a downlink automatically send by the gateway

Now, I have still one one node that is at SF12. It doesn’t go down to SF7.
Any idea ?

Eric

25

If we are forcing a ADRACKReq, even though the device is at SF12 (should not need to do this according to LoRaWan specification), then the ADR is working as expected.

Can’t see why TTN is using the ADRACKReq from the device as an indication from how the ADR should be sent via downlink.
And why should the device need to set the bit when it is at SF12? At SF12 the NS should be aggresive and try to push the device to a better SF.
This should also cost very much in battery etc as the device takes long time to change to a more accurate SF.

It seems to be 64 uplinks where is has been completly quiet on the downlink. After 64 uplink, it seems to be some request from the NS to raisen its Datarate.
Why is this so? As mentionend earlier, should’nt this be the state where the NS is aggressive and sending downlinks to raise the Datarate to minimize the airtime?

This seems to happen when we are in DR0 as default value. But I can’t see any “good” from by using SF11 or .ex SF7.

Example. Installer mounts LoRa-device in a basement, concrete and a thick door. When the installer is there, the thick door is open, and the Device starts to send at SF7.
When the door is closed, it will take long time before the device by self goes to SF12. In the “real world” it should start on SF12 and go down.

26

At the Port of Antwerp in Belgium we are currently conducting tests witch some ‘of-the-shelf’ LoRa sensors from Adeunis, Atim and Nemeus. All of them have the same issue: ADR bit is on but the devices keep sending data at SF12/125. The manufacturers all tell me that the TTN ADR implementation is not correct and are very reluctant to modify the sensor firmware to implement workarounds. Has anyone an idea when this issue will be fixed?
(So getting an LinkADRReq downlink command without requiring an ADRACKReq and not only piggybacking on acks or application downlinks)

27

Hi Gzazo, hi @all

I am new to thethings network - and i try to understand ADR.
is it not the default behavior of lorawan that ADR only increases the datarate?

how does this work in the things network. Can ADR increase and decrease the datarate of a node or only increase?

regards, sil

28

Hi,

Adr can only increase your sf, it’s on node shift back sf if it does’t receive an adr in 128 uplink messages, if it happens it could means the node is not reachable by any gateway, decrease sf help the node to reach more far gateaway . Sometimes ttn forgot to send the adr, make the messages with ack help a lot, don’t abuse of ack system it waste the gateway channels.

Regards

29

Edit: i am a bit confused by the anser with the icrease and decrease of SF… should not ADR decrease the SF (from SF9 to SF8 for example - and increase DR) and the node increase the SF (from SF8 to SF9 - and decrease DR)?

Thanks for your feedback anyway.

one more question: Is it defined by LoraWAN Specifications, that a LoRa-Server (the things network or others) can’t decrease DR? And is the 128 Uplinks also a LoRaWAN Specification or can nodes handle it the way they want/configured?

Last: Do you know where the “shift back” algorithem is documented in LoRaWAN specifications?

many thanks and regards, Sil

30

from LraWan v 1.1

If no reply is received within the next ADR_ACK_DELAY uplinks (i.e., after a total of ADR_ACK_LIMIT + ADR_ACK_DELAY), the end-device MUST try to regain connectivity by first stepping up the transmit power to default power if possible then switching to the next lower data rate that provides a longer radio range. The end-device MUST further lower its data rate step by step every time ADR_ACK_DELAY is reached. Once the device has reached the lowest data rate, it MUST re-enable all default uplink frequency channels.

If your nodes are stationary enable adr, beware if you use the semtech lorawan stack there are some minor bugs that blocks the node to move from sf12.

31

hi
Today I tried using sf12 for uplink and based on the log on my gateway side after an uplink there was a downlink on sf9 and the reason was optimizing
means nodes should switch to higher data rate but this did not happen and regarding all downlinks my node did not change the sf from 12 to lower sf
what would be the problem?
I have enabaled adr

32

SF9 is the standard downlink for TTN for the Rx2 slot.

It will take a few more uplinks for ADR to cut in, depending on which stack you are on.

Please note that you replied to a 2 year old post!

1 Like
33

thank you for the reply,
I am using v2 and I have tried for 12 uplinks which I did not see any changes in sf from 12 to lower ones,
after how many uplinks i can see the adr effect?
I have another problem when I use sf7 after 12 uplinks i got adr ack downlink for every uplink And as I have read from this forum this shows the problem but I could not find any answer regarding sovling this problem for the old lmic library by matt

34

The docs will answer:

https://www.thethingsnetwork.org/docs/lorawan/adaptive-data-rate/

35

thank you so much
what about my second question, is it normal to receive adr ack after every uplink?

36

Can you show the log info that shows these downlinks - preferably from the device, the gateway log and the gateway console - assuming you mean ADR Req (the downlink) and the devices lack of ADR Ack in its next uplink?

Then brighter minds than mine can look at the details for you.

37

these are the logs from gateway and application part:
data_log
gateway_log
1
2
3

38

Doesn’t show any of the payload details to determine what’s being sent & why

39

about the adr effect , I have just tried for less than 1 packets and as you said I must try for more uplinks to see the result
here is my gateway log when I tried SF12:
start-with_sf12

40

payload from application part in downlink is empty and it is in port 0

41

LoRa Alliance requires network providers to restrict SF11 & 12 so you are likely to get an immediate response if your link margin is ridiculously hight.

At some point you will be told that your uplinks are far far to frequent - put a push button on your device so you can send an uplink on demand rather than have it hammering out one every minute.

We can guess at some of the detail but if you want to debug this, you’ll need to capture the actual payloads / headers etc

42

thank you I will put a push button,
here is downlink payload from gateway side when i use SF7 and after 12 packets I receive this downlink after every uplink :
payload1
and from application side:
payload2
2222
11111