Okay, so in FCtrl no ADR or ACK is set. FOpts is for example 05 03 D2 AD 84 22 07 D4 4A,
that means it is a RXParamSetupReq. RX2 frequency 869.5250 MHz. What the 22 07 D4 A4 is about, I don’t know.
Edit: In the uplink from the end node, there is a RXParamSetupAns with ACK to all 3 settings (RX1DRoffset, RX2 data rate and channel ACK).
Does expanding the uplink in the gateway’s Traffic page of TTN Console give you any details in the Trace part?
Given your:
…your node must receive the downlink, so it’s probably not sent in SF12. Just to be sure:
Is the downlink transmitted in RX2, using SF12? Then I guess the endless repetition is a bug:
If true, then the above would be triggered by the node not acknowledging the settings after the very first ADR, which presumably was sent in RX2/SF9. (Like maybe it simply did not receive that downlink.)
That does not explain why TTN was even trying to send such first ADR, if your node does not set the ADR bit in its uplinks. It also does not explain the remaining 22 07 D4 A4 that you saw in FOpts…
If all above is true, then making the device join again, if possible, might solve it?
Hello Arjan,
Thank you for your anwser. The downlink is indeed transmitted in SF12BW125. For the timing, actually I cannot give any informations. I think the trace in the TTN console (gateway) showed something approx. 1002ms until the send (isn’t that RX1?) after a delay calculation by TTN.
I will post the complete trace and screenshot from the console later (1-2 hours), at the moment the end node is disabled. I will also see, if the first downlink is send in RX2/SF9.
FYI: The node is not activated via OTAA, it is ABP, so there is no rejoin necessary, a simple restart does the job.
Thanks so far, will post the informations later 
Then I think your node is to blame as well:
869.525 MHz tells you it’s RX2, for which TTN uses SF9. The SF12 is the fallback as a courtesy to non-compliant nodes like I described earlier, which indeed seems to be repeated endlessly.
Your node should not receive this, as it should be listening using SF9.
Still, your node is acknowledging it received it:
So:
Why does your node acknowledge settings it should not have received?
In other words: for RX2, why does your node keep listening on SF12 while it acknowledged the RX2 settings that tell it to use SF9?
As for the Trace in TTN Console: I wondered what the text said, like the code for the LinkADRAns indicates it might show things like “data-rate-ack: true”.
Ah. Did you configure it to use SF9 for RX2? For OTAA, in EU868 the network settings are included in the CFList of the Join Accept. For ABP you need to program that manually.
No, I do not make any changes to the modem firmware itself, except starting at SF12 and disabling ADR. It is LoRaWAN-certified with specification v. 1.0.2.
I will see if there is any informations about the node using SF9 for RX2, but I guess it do not use it… strange.
Hmm, I didn’t know that. I guess I am allowed to do so by law but networks have to deny access. Nevermind, I will change that later to SF10 or maybe SF9, depends on the distance to the next reachable gateway.
Is this the cause of the endless repeating downlinks?
Recently reactivated the device:
No up- or downlink at SF9 from TTN.
The trace for the downlink:
I guess you also disabled the frame counter security settings? That’s all for testing only. You cannot just reset an ABP device without also resetting its counters in TTN Console. (And even that will not work for large counter values.) See the downlink counter, which is at 169 in your screenshot.
OTAA is really to be preferred.
The regulations specify a maximum duty cycle, which is the minumum time between two transmissions at any time, but not all day long. Note that your node is using a whopping 1.1 seconds in a shared radio spectrum…
If it’s on a fixed location, then don’t disable ADR.
The combination of a bug in TTN that repeats its courtesy fallback SF12 downlink endlessly, along with your node not listening to SF9 for RX2 that triggered that courtesy fallback. (And your node acknowledging settings it apparently did not actually process won’t be helping either.)
Yes. First: It is for testing only at the moment. We are sending every five minutes, so the 1% duty cycle is fine. When it is at its fixed location, we’ll reactivate ADR again 
Second: Okay, thanks for that. We’ll test now with a resetted counter and set it to SF10 after that test (or SF12 with enabled ADR, depends on location).
Thanks… resetting frame counters stopped the downlinks.
Hello again,
Just a last question for clarification. We’ve now started (for debugging) with SF10 with disabled ADR. After 64 uplinks, the end node does set the ADRACKReq Bit without a ADR bit. No ACK is send in a downlink and the end node does lower its data rate to SF11 after additionally 32 packets (64 + 32 in total). Seems like the behavoir from LoRaWAN specification chapter 4.3.1.1.
So the question is: Why does the end node use an ADR algorithm without it enabled? Is this correct? Second question: Why does the network not ACK the request. Due to that, the end node keeps lowering its data rate and after 128 uplinks, it is using SF12. Or is it possible that the gateway cannot reach the node (all ACKs are loss and not shown up in the console)?
Thanks for making me understanding LoRaWAN a bit more 
Okay… the problem is back… We have started an end node with SF12 and enabled ADR. TTN sends an LinkADRReq at SF9 first which is not responded because the message was not received by the end node.
With the next uplink, a second downlink at SF12 is transmitted with RXParamSetupReq which is answered with RXParamSetupAns (05 07) with the next uplink. But TTN keeps sending the RXParamSetupReq again and again.
This time, resetting the counters does not solve the problem. I’m not able to drive all the distance to the end node again and again. What to do?
And please, maybe somebody could give me an answer to my last question about ADR. Thanks a lot!
You’d need to ask whoever created the node’s LoRaWAN stack. It doesn’t make sense to me either.
Still using ABP? Did you properly configure RX2 then? (Or better yet: start using OTAA, which for EU868 will configure RX2 in the OTAA Join Accept’s CFList.)
So, TTN keeps repeating the RXParamSetupReq in RX2, using SF12, and the node keeps responding with an RXParamSetupAns? Then I still think the RXParamSetupAns is false: the node is telling TTN that it changed its RX2 settings, but apparently it keeps using SF12 for RX2?
Yes, we can’t use OTAA for the moment due to some testing scenarios. Also we do not have any access to configure the RX2 window. If it is an error on the node side, I can live with that. But ADR should work even if using ABP.
Yes it looks like that (after 20 uplinks I’ve resetted the frame counters):
Each uplink contains a RXParamSetupAns, weird.
I’ve running 3 sensors for now. One of the 3 already lowered its SF to SF11 after 3 uplinks and no downlinks are generated again. Strange…
Then you should not use ABP. Using ABP comes with some extra responsibilities.
Indeed, ADR should work with ABP, but I’d say your device is not LoRaWAN compliant. Too hard to debug everything that might go wrong then.
Again, just to be sure: you should not reset the frame counters when not also resetting the device. (The device will be rejecting the invalid FCnt values for the downlinks if you don’t reset the device.)
(As an aside: a DevAddr is not a secret, not encrypted in the radio messages, and not unique.)
It does have a LoRaWAN certificate for version 1.0.2 by the LoRa Alliance… It should act like it is descripted in the specification. I don’t know what is going on…
So, just to be safe: Is the mismatch between the end node RX2 configuration and TTNs RX2 triggering this issue? If so, I will look into it or use another LoRaWAN module or switch over to OTAA if possible.
I have no clue why one of the 3 sensors has lowered its SF to 11 and not the others.
Did you reset the nodes? Any chance TTN did tell all nodes to improve to SF11, but that nodes for which you only reset the counters in TTN Console but did not reset the nodes as well, ignored those settings, due to the downlink FCnt being lower than the last value they saw?
There’s only so much that can be tested during certification… Also, things like the very early RN2483 were certified too, but still have seen firmware updates to fix bugs.
I’d say the certification is useless if you cannot even configure the network settings when using ABP. Or you’re just missing some documentation about how to do that? Also, I’d say it’s weird that it is setting the ADRACKReq bit when ADR is disabled.
I don’t know. It surely is wrong and won’t help. Also, the node telling TTN it changed its settings while it did not won’t do any good:
By the way, are you still seeing this weird 22 07 D4 A4 too? That’s originating from TTN then…
Yes that is maybe possible. I cannot reset the nodes because they are positioned on the roof of a building and it is difficult to go there every day. What MAC is changing the SF? It is LinkADRReq, isn’t it? This has nothing to do with the RXParamSetupReq. Maybe the LinkADRReq and Ans are working correctly and only the new RX2 setting is ignored by the end node. Does TTN detect if a node is still listening on SF12 and then retransmitts the same RXParamSetupReq again maybe?
True story…
Yes, it is. See a downlink:
Isn’t that FOpts including a RXParamSetupReq AND a LinkADRReq (0311FF0001)?
That last one looks fine to me; no weird 0x22 MAC command?
I think it sees that the node is still using SF12 in its uplink. I’ve linked to the code before.
It cannot really detect what the node’s listening on, except for the fact that the node keeps responding to downlinks that are sent in SF12. (While TTN should not keep using SF12 for those downlinks, but that’s another issue.)
