A couple of months ago I was busy developing a number of nodes. Multiple delays later, I deployed 16 of them four weeks ago. While some showed some defects early on, 12 are working fine (although some batteries ran out by now). I configured them in a handful of ways, with 6 using ABP and 6 using OTAA.
Problem is: about 4 of the 12 working nodes show extraordinary amounts of downlinks being generated. With extraordinary meaning ~1000 downlinks for 2000 uplinks. Funnily enough, 2 of the ABP camp and 2 of the OTAA camp.
Before everyone starts jumping on this: I know that those amounts of downlinks are far beyond the policy guidelines. I will contact the people who borrowed the nodes and ask them to power the nodes off.
The nodes are set up to measure air quality etc. and transmit their readings without ever looking for a response. I disabled ADR for the ABP devices, hoping to prevent this problem of all the downlinks generating.
I should note that in general, all my nodes seem to perform way worse in receiving downlinks than sending succesful uplinks. So even though almost every uplink comes through, they might receive hardly any downlink.
The nodes are spread over varying distances from my (and two random other) gateway(s), between 500m and 5km NLOS as that represents their final usecase once this comes out of the current beta-testing.
I am quite lost… what could be generating all these downlinks? Why on both OTAA and ABP (even with disabled ADR)? What could I do to prevent all these downlinks?
It is a mismatch between the device and the console settings and at present the Network Server is over-zealous about trying to make them match - plus add in a bit of potential non-compliance in the firmware MAC.
This is a common theme across the forum of late although it manifests itself in a number of ways so I’d have to hunt out prior discussions, but suffice to say you’re off the hook on the downlinks as this is an issue and it’s a tough nut to crack.
Generally I can trigger this with a slightly left-field config using LMIC. I rarely see it with LoRaMac-node based firmware.
There are CLI commands to turn things off that help. I’ll ferret around for some of the previous discussions & link back here.
Thanks for jumping on it tirelessly once again
I would like to add that I as of yet have not been able to find an exact guide to configure a LoPy4 node on TTN. It might be the case that I selected one of the (new) parameters wrongly, e.g. the regional parameters versions etc… could that be a source for all these downlinks?
(Personally, I guess not, since 8 of the 12 behave like they should with 20~80 downlinks for ~2000 uplinks)
Have you looked at the RSSI and SNR of these 4 nodes?
Do a comparison of them with the ones that don’t have that many downlinks. (RSSI / SNR)
I have found that the nodes that are not preforming RF wise that good, the MAC keep on adjusting them. Setting the ADR margin higher limits the MAC downlinks.
Also found turning off the ADR causes more havoc. (At lease that is what I have noticed so far).
Almost identical stats for the incorrect nodes:
OTAA node 1000 uplinks: RSSI -120, SNR -14 ± 5
ABP node 1000 uplinks: RSSI -120, SNR -8 ± 5
Worst performers of the behaving nodes (although I do not have that many):
OTAA node 50 uplinks: RSSI -110, SNR 4 ± 5
ABP node 50 uplinks: RSSI -120, SNR -13 ± 5
I could try settings the margin to max value or something else very high, while enabling ADR… if that’s your suggestion?
Sure sounds like a solution for stationary nodes, but mine are not.
Students from high school will be taking a node home for two weeks after which they are returned to school and likely a week or two later that same node is taken home by another student living at a completely different location with different RSSI and SNR results.
It looks like a too high margin will also cause a downlink since the node will be requested to alter its transmission power.
Do you have an idea that could solve the problem for this usecase?
So you are concern about the current situation? This is the only solution I have seen sort of works. If you set to say 25 it will stabilize the node for the 2 weeks and then when you move it it will need to “learn” it new RF environment.
If you turn it off it causes more trouble, or that is my experience.
Or please find a alternate solutions for me, as the one node, for 20 Uplinks / 15 Downlinks, now it is 40/5, and I cant get it better.
Besides RSSI/snr can you also correlate sf value. At -120 rssi they may be marginal and each sf tolerates a different snr headroom (higher sf allows worse snr) but that then cuts number of allowed messages/day. If at margins of reception then nodes may struggle to pick up MAC command and react causing the deluge of dl’s.
Most of the messages are coming in at SF12. The beta test currently is using a Blind ADR with SF9 and SF12, but hardly any nodes are successful at connecting messages at SF9. SF9 falls behind fast when the node is in NLOS and a bit distant from the antenna.
