Hi all, i have sent a config “09 00” to my device an it will not stop rebooting - even after having the device cut off from the battery and starting it again.
09 00 repeats again and again.
How can i stop this?
You scheduled a confirmed downlink. And apparently TTN is not getting a confirmation from your node, so rightfully repeats the downlink.
I think you could schedule another downlink, ensuring it’s not set to be confirmed, and ensuring it has “Scheduling” set to “replace”, to discard the current confirmed downlink.
Thx! that did the job. Sent an 0x81 and everything was OK.
Nice, but just to be sure: this is a workaround. Of course a proper LoRaWAN device should support confirmed downlinks just fine. It does not have to send a confirmation right away, but it should set the ACK bit in its next uplink. It seems your device did not do that. This implies it indeed never received any of the downlinks, or that something is wrong in its LoRaWAN stack.
My guess is that the device never received the downlinks? (So: the settings in the downlink had no effect?) You might need to look at LMIC_setClockError to make that work. But the OTAA Join Accept is a downlink too, which seems to work just fine for you, so that’s a bit strange.
(You could paste a full LoRaWAN packet as taken from a gateway’s Traffic page into an online LoRaWAN decoder to confirm that the FCtrl.ACK bit is indeed not set.)
I was just playin around with the downlink. In common the “ack” works, but it did not for the reboot “09 00”.
Maybe it depends on the high distance (8km) and the poor link SF12.
Thanks for your thoughts.
Paxcounter code calls LMIC_shutdown after receiving an applicaton reset command (0x09), before restarting the CPU. Intention was to clear the LMIC stack and send out a waiting ACK, before resetting the device. This approach seems not to work. So this ends up in a boot loop if the reset command was sent with acknowledge, because the device never sends the ACK due to resetting.
Any suggestions how to solve this straight forward?
I discovered this behavior too. I was thinking it was my deepsleep command tweak (see my other post) and sending with confirmation didn’t help. As my queued instruction was ‘sleep’ I ended up in a loop. Arjan’s reply suggests we should send an ACK when waking from reset, as well as dealing with the counter and clock difference requirement.