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.)
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.