Jut to be sure: in LoRaWAN 1.0.x, that should only be set every 64 packets (and only if no downlink was received in the meantime). But for each uplink, the ADR bit should be set as well, so TTN knows it needs to keep track of the link quality.
So: is the ADR bit indeed set for every uplink?
Using an online LoRaWAN decoder you can easily check:
- if
ADRis set for every uplink (like if it hasFCtrl= 0x80 = 0b10000000, hence has bit 7 forADRset) - and if
ADRACKReqis set for every 64th uplink (like if it hasFCtrl= 0xC0 = 0b11000000, hence has bit 6 forADRACKReqset) - and if any downlink is an ADR response (like† for me, after an
ADRACKRequplink, TTN would generate a downlink right away, but and ADR downlink could also be postponed for another 32 uplinks if TTN feels like that).
If the uplinks look fine: any chance the uplinks are received by multiple gateways, and TTN tells another gateway to send the ADR downlink, which is then somehow lost?
Note that at some point TTN will give up to not waste more downlinks†; such is then shown as “too many failed ADR requests” in the “trace” part of an expanded downlink in the gateway’s Traffic page in TTN Console:
† Well, actually the above screenshot still resulted in a downlink, which I linked to in the 3rd bullet above… I did not investigate; see Error: too many failed ADR requests.
Maybe it even gives up if it has tried to send ADR commands before your node even has set ADRACKReq, which I think can happen when the node is using SF12 despite a good link quality?