I am currently trying to implement ABP since my node is not very good at receiving OTAA join accept messages.
All communication is coming through well, except that the node must somehow be requesting a downlink for every uplink that is sent. Of course that is not good due to the max 10 downlinks a day.
I confirmed through packet decoding that ACK and ADR are set to False, so I am really wondering what is causing this behaviour. Any suggestions are welcome and I will be happy to provide more information!
Frames reset after power loss as can be seen above, so I have set the Advanced MAC settings on TTN to conform to that.
EDIT: I just found ADR features recently introduced to TTS March 2022 and since this seems to apply to my situation, I added lora.sf(12) twice extra to try and mitigate that problem. This only applies to LoRa RAW mode, not to LoRaWAN. I do expect using s.setsockopt(dr) should be sufficient. Results are still the same, though.
Other considerations aside, SF12 is pretty anti-social and somewhat prone to failure due to the massive airtime - and eats hard in to the FUP - and the LoRaWAN Alliance asks networks to limit the activity of nodes that are on 11 & 12.
The CLI command should resolve the issue for you as it will command the device to the rate you set.
Thanks; you do expect that the downlinks will be gone when using that command in your linked post? I have never ever used the CLI for TTN so I will have to figure out how to do so⌠may take a couple of days before I have it figured out if it is a bit of work to set up.
Regarding SF12: yes, I know. I am still in debugging mode though so I want to be sure on my side that range itself is not the issue for now. I will try and see how low I can get the SF when it is functioning properly.
Download from the âHow to setup the CLIâ doc page, follow instructions, copy & paste the command adding in your own application & device idâs and desired rate - should be 5 minutes tops.
Why not just leave that to ADR as it automagically does all that for you.
Do IRC using gps trackers for the college students to help map coverage on routes to/from their homes etcâŚADR not recommended for devices that move frequently or continuously, also for coverage checks and heatmapping one may want to use several devices at same site/location each set to a different SF to compare coverage and reliability. Often when doing coverage checks to key specific location for clients or collaborators I will carry a set of nodes with fixed SF of interest, often all from 7-12, and tx interval set to gradually higher limits to keep inside usage constraints just so I can check methodically without ADR potentially stepping in âautomagicallyâ and messing up data collection Original SMTC LoRaMOTE site survey SF sweep mode also useful for this too.
Thanks for both responses; once the boxes are done with sensor calibration I will have a look at the TTN CLI. Got four Lion King musical performances coming up this week so will see when thatâs finished.
Same nodes with different fixed SF sounds like a very good idea to map coverage indeed. Will keep that in mind and will also check out the sweep mode you mentioned. Thanks for the input and hopefully this will fix the downlinks!
It sounds like maybe youâre saying that your node is just plain bad at receiving, either in terms of sensitivity or much more likely timing issues.
Thatâs going to cause no end of trouble - for example, it likely means that configuration downlinks are going to be sent endlessly, because the node isnât adapting its behavior to reflect those never received configuration changes.
TTN simply does not support transmit-only nodes. You might work around one symptom of that, but as long as the node is not properly implementing LoRaWAN (which include the receive side) issues are likely to re-occur in the future.
Original SMTC LoRaMOTE site survey SF sweep mode also useful for this too.