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.
Did you decode the downlink to ensure it’s indeed ADR? Likewise: did you check the uplink does not include some MAC command that triggers the downlink?
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.
It’s in FOpts, like I explained in the post I linked to. The gateway’s Traffic page in TTN Console shows the full LoRaWAN packet that you need for that. The same explanation applies to the uplink.
It might very well be just an ACK response to a confirmed uplink?
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?
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.
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?
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).
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):
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.)
