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

[grazy]

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

[nograin]

@grazy

I have seen a change in ADR handling on TTN.

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…

[arjanvanb (Arjan)]

@nograin

get downlinks as response to every packet…

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:

@arjanvanb

Now, an example has proved that, when using RX2, TTN surely is smart enough to repeat ADR on SF12 if nothing changed when the node ignored the ADR downlink in the documented SF9. The same can been seen in the code. But I feel TTN should not keep using SF12 for ADR in RX2 then; assuming your node is using the TTN specific settings that it got in the EU868 OTAA Join Accept, it will never receive the RX2 downlinks when TTN uses SF12…

[jezd (JD)]

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

[nograin]

@arjanvanb

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

well, no.

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…

[UdLoRa]

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.

[pomplesiegel]

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:

[jezd (JD)]

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

[alanp]

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.

[nograin]

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.

[nograin]

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.

[Verkehrsrot]

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.

[Verkehrsrot]

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

[Verkehrsrot]

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

[nograin]

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

please keep this thread updated if you find a solution

[nograin]

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…

[BjoernA]

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

[Verkehrsrot]

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.

[cslorabox]

It would really help if you could capture a series of actual uplink (and ideally corresponding downlink) packets showing this.

[nograin]

oh look - what i’m getting now

(this being with the same code as before, just updating the mcci lmic library after the fixes discussed in this thread)