I’m wondering why the TTN application and / or the gateway are sending so many downlink messages to the end node that has it’s ADR disabled. It seems like the app and the gateway are trying to reduce the spreading factor and / or power ignoring the ADR bit of the end node without any success. Every uplink message from the end node generates a new downlink message with 17 bytes of payload on frequency 869.525 MHz and that is going to be wasteful.
Thanks for you reply. I don’t know how to decode the downlink. In the application, there is no payload and the gateway payload is encoded and unreadable. The same is for the uplink, I cannot see if there is any MAC command in it.
Does expanding the uplink in the gateway’s Traffic page of TTN Console give you any details in the Trace part?
…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?
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.
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?
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.)
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 184.108.40.206.
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.)