Recent change in ADR handling in TNN and LMIC generate downlink loop

End Devices (Nodes) LMIC
1

Hi,

I have seen a change in ADR handling on TTN.

There is a loop of send of ADR ACK from LMIC and LinkADRReq from TTN.

I think it is due to https://github.com/TheThingsNetwork/ttn/commit/60d50d8d7e7882a806897e5bfb1d3cb709c43334

If I understand, now TTN always send LinkADRReq if there is an Adr Ack Request in uplink, even if the parameter (DR, power) do not change.

LMIC receive the request handle it and then schedule an ask for an Ack in next uplink (https://github.com/mcci-catena/arduino-lmic/blob/master/src/lmic/lmic.c#L704) for checking that the new communication parameter allow communication.

Example of exchange

D=> 60AD280126A547040355FF0001908C3FA9
    FOpts = 0355FF0001 (SF7, power 6dBm, channel 1..8, nb transmission =1)
U=> 40AD280126C23D43030701E2668330ED88328A
    FOpts = 0307 (all adr ack)
    FCtrl = C2   (ADR + ADRACKReq)
D=> 60AD280126A548040355FF0001DDA586F2
    FOpts = 0355FF0001 (same as before)
U=> 40AD280126C23E43030701FA51F7A2414F902C
    FOpts = 0307 (all adr ack)
    FCtrl = C2   (ADR + ADRACKReq)
D=> 60AD280126A549040355FF00015F1E8318
U=> 40AD280126C23F43030701E23D1E0A5DC5CBC8
...

Can TTN send LinkADRReq only if there is a change like before ?
Or should i make a pull request for LMIC to only ask ack in 64 uplink ?

1 Like
2

This appears to be an end-device issue.

The network is expected to send the end-device a LinkADRReq within ADR_ACK_DELAY packets when the AdrAckRequest bit is set.

The end-device should unset the AdrAckRequest bit after receiving LinkADRReq for ADR_ACK_LIMIT packets.

LoRaWAN Defaults
ADR_ACK_LIMIT 64
ADR_ACK_DELAY 32

1 Like
3

Ok I open issue https://github.com/mcci-catena/arduino-lmic/issues/275

4

so it’s not me alone…

happen to know about when this started? i just got two nodes working with ADR over the last weekend and everything looked like expected at first with downlinks every now and then, but about mon/tue i started to get downlinks as response to every packet…

2 Likes
5

Any chance it’s in EU868, and that those responses are in RX2 (869.525 MHz), using SF12?

If yes, is your node responding to those? (More specifically: do you think that the node is actually receiving the SF12 downlinks in RX2, while it should be listening to SF9 for EU868?)

If it’s indeed SF12 but your node is (rightfully so) not responding to those, then your node might have missed an ADR downlink in RX2 using SF9, after which TTN retries in SF12. That’s nice, but it seems TTN might keep trying on SF12 then:

6

same here on my bench test nodes, SF7 here, started recently

7

well, no.
image

i did read your explanations in various threads top to bottom several times, but from what i could tell everything was working fine when i finally got it right last weekend.

but as mentioned - without restarting any of these nodes, both happily sending at SF7 things started to change at the beginning of the week. i think @grazy is well on the right track…

3 Likes
8

I see the same behavior with a MKR WAN 1300 that is not LMIC based. In this case, downlinks are now in SF12 869.525. I will switch off the node this afternoon.

9

Experiencing this as well with the tip of the mcci-catena arduino-lmic master branch. Every uplink is followed by an ADR downlink I believe:image

10

Same here, had to turn ADR off at the moment - not sure what has been changed but it an issue and not resolved

11

Just to close off this thread, a fix has been merged into the master branch of the MCCI-Cantena arduino-lmic github project. Thanks to all those that worked on this.

3 Likes
12

well, yes, i too am not getting downlinks after every uplink packet while LMIC_setAdrMode(1); anymore … but i also wasn’t able to verify yet if ADR actually is working.

to test this i usually had put

LMIC_setDrTxpow(DR_SF10,14);

in EV_JOINING and got the ADR-downlinks which adjusted the SF after ~15 packets. now i haven’t gotten any even after more than 50 packets - sitting as close to my gateway as usual.

am i missing something obvious that has changed with the fixes?

brief summary how it had worked before:
to the OTAA-example provided i added

   LMIC_setAdrMode(1);
   LMIC_setLinkCheckMode(1);
   LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);

to init and removed LMIC_setLinkCheckMode(0); from EV_JOINED

thanks for any hints.

13

left it running for a couple of hours - just leaving the console open in the browser (so can’t go back in time very far): currently being at about uploaded packet #500 i’m down to SF7, but again am getting a downlink packet after each upload.

quite likely it seems the ‘old way’ of doing this isn’t working anymore, would appreciate any input for how to do it correctly now - wasn’t able to figure it out yet from the comments in the github-issue.

thanks.

14

same here (EU868), with LMIC and ADR set to on i now get a zero payload packet after each tranmission of the node. Before this happened a while (10-15 times, i guess), then stopped until radio parameter changed.

15

same here, i had to switch off ADR to keep the gateway’s duty cycle clean :frowning:

16

I’m using same scheme in my paxcounter software. Not sure how to modify it now?

17

well - hopefully someone in the know will chime in - i’m just a lego-brick-stacking-kind-of-coder :woman_shrugging:

please keep this thread updated if you find a solution

18

but re-reading your post - if you’re getting a downlink right from the start, then you’re probably still using an older version of the mcci-library. if you check the issue on github linked in the first post you’ll see there’s been done quite a lot of fixing.

haven’t tested yet how it behaves when starting with SF7, but starting with SF10 i again end up (way later than with the prior version) getting downlinks as response to each packet…

19

Even with the latest version the paxcounter will get a downlink after the 65. packet which never ends.

1 Like
20

i’m using HEAD of mcci lmic in paxcounter software, currently 1432ba0, with EU868.

Meanwhile found: If i switch off ADR, then those spurious downlinks disappear.