I use packet confirmation and don’t send quicker than 30 seconds between uploads.
Using an internal buffer to save payload incase upload failure, then resend at different intervals.
Sometimes, when moving out of LORAWAN coverage, I force upload, which fails and then I upload at a later stage. This seems to result in a AT_BUSY_ERROR condition…whenever that happens only a reboot/reset works.
Question :
If the stack is stuck, can I recover from this without loosing my data? I run the RAK4630, no external memory devices.
Can I somehow prevent this AT_BUSY_ERROR from happening? If it does happen, what are my options to recover?
I’ve used Wistoolbox and dfu in the past. The dfu image below contains V4.2.1 and I see RAK4631_latest_final.hex was updated 5 months ago…which seems very old ?
I only use confirmed packets, no switching. Still getting AT_BUSY_ERROR when I send a message while outside coverage, and then when I return inside network coverage it gives me a AT_BUSY_ERROR when trying to send again.
How does one recover from AT_BUSY_ERROR without power cycling?
When in this AT_BUSY_ERROR state, I issue a JOIN request …I get back +EVT:JOINED, but sending anything fails.
[update]
When in this error state, if I now change confirmation to OFF ( AT+CFM=0 )…then I can upload messages again.
As soon as I set confirmation ON again ( AT+CFM=1 ) …I get AT_BUSY_ERROR.
Potential workaround is to set confirmation OFF, and use my own flag inside receiveCallback to track if a message was received or not. Need further testing, initial testing looked positive.
