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…
1 Like
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.)
No, none in my traffic so far. But I don’t have the complete traffic log. The question is: Why is the end node not changing its SF as requested in the SF12 downlink (03 = LinkADRReq, 11 = DR1 (SF11/125kHz), TX1 (MaxEIRP - 2dB), FF = all Channels for uplinks. And why is it sending a RXParamSetupAns only, and no LinkADRAns… Strange bahavoir of the end node.
For me, it looks like the following:
If a LinkADRReq is sent alone, the end node does change its Link. If a RXParamSetupReq is sent alone or with a LinkADRReq piggybacked, it is ignored. Unfortunately, I cannot say if any of the requests is sent in a SF9 RX2 or a SF12 RX2 for now.
At least that can be avoided if you find a way to properly configure the node for ABP. 
By the way, as you cannot change the RX2 settings: how does the ABP node know about the frequencies and data rates that TTN uses? The LoRaWAN specifications only defines 3 defaults, but for EU868 TTN uses 9 LoRaWAN data rates on 8 frequencies (plus FSK) for the uplinks. Can you configure those?
Oh, and in case you cannot configure the TTN frequencies (channels) in your ABP node, then are you 100% sure that the above is true? The node should reject settings for data rates or channels it does not even know. (So, is the LinkADRAns payload 0b00000111, hence: is FOpts 0x0307?)
I don’t know. It is a WiMOD Shield for Arduino an that is including a iM880B from IMST, I could not find any channel default settings so far, I have to look into its documentation a bit more when I have the time for that.
Can’t remember (really, TTN traffic gateway logging should be a bit better, it is thrown away if the session expires…) it and currently I have no 4th node here to test it. So… I have to collect up the sensor nodes from the roof again to look into that behavoir. Or buy a 4th module.
I will come back to this and debug the complete traffic between gateway and end node to see whats going on and how to stop the endless repeating, because it wastes a lot of air time from our gateway.
Thanks so far!
Sounds like parsing probably halts at the first unrecognized command - that’s almost obligatory, since the fact that their length varies means it’s not really possible to decode past the unknown. The materials also make it sound as if their implementation is derived from LMIC, and if I recall correctly there have been some MAC command parsing issues of that nature in LMIC that are slowly getting corrected in various LMIC based projects.
Ultimately that contains a Semtech radio and a reprogrammable STM32L151 MCU with exposed SWD lines for programming. So if you had a lot of them and didn’t like their stock behavior, you could in theory develop new firmware.
But first it’s probably worth figuring out what the split in functionality between the module firmware and the hosting Arduino is - it may be that the code which implements the concerning behavior is actually on the Arduino side. There seem to be two options for module firmware which embed more or less of the functionality inside, or leave more for the outside MCU (your Arduino) to do. So it’s possible that what you want to change is Arduino code.
Ultimately how many of these do you have? If only a few and they are proving difficult to work with, the path of least resistance may be to use something else.
Hello,
I now was able to debug a new started end node near the gateway. This is the resulting flow:
Seems that the end node is able to listen on SF9 in RX2, because with counter 3 it answers an LinkADRReq that was send in SF9 with an LinkADRAns. This behavoir seems to work correctly except that the first RX2 on SF9 was not received, but TTN uses SF12 as a fallback.
I don’t know, why it is not working with end nodes that are far away from the gateway, maybe that’s my next debug test 
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.