I am using an nRF52840 feather + RFM95 Lora Wing, LoRaWAN MAC 1.02 REV B and US 902-928 Mhz FSB 2. I had a node running without any issue however recently when the node attempts a rejoin it becomes stuck at “Forward join-accept to Application Server” from TTN side.
The device will then continue trying to rejoin, or if it successfully joins it will send data but the data will not be processed, the payload won’t show.
From the feather side, I can see that the event “EV_TXCOMPLETE” was successfully processed as I am using the MCCI LMIC library .
I have to re-schedule the job another time for the payload to get displayed properly.
Basically, I am sending the data twice to TTN for it to get processed and display.
Just making sure, are you perhaps starting from scratch trying to join every time you want to send something?
If I recall, with LMiC if you try to send when you aren’t joined, it joins instead.
But once joined, you need to retain state so that it can stay in the joined session, and then sending should work - subject of course to the usual chance of packet loss on an open-ended RF network.
Ideally LoRaWAN devices complete only one join and then use that for the entire rest of their service life on the network; of course doing development various mixups may result in having to start over a few times, but it’s not supposed to be done more than infrequently.
I agree with you. Ideally I should have only 1 join request but the thing is that I implemented a sleep function for my feather board and when it wakes up the code gets re-executed from the beginning and thus the board will initiate a new join request every time.
Not sure if there is any other or better way to handle this.
Joining after every sleep is not going to work, and you need to stop even trying to make it work. You’d rapidly consume the re-use prohibited join nonce space, and you’d waste lots of power having to transmit and receive at least an extra packet (more likely several) before you can move any useful data.
The nRF52840 has wonderful state-retaining low power sleep modes, switch to using those.
Okay that makes sense. Thank you for the clarification. I think instead of using the “systemOFF” command and shutdown the board completely, I could use the “delay()” function which acts more like a sleep function in the Adafruit libraries and retain state.
If you have any further suggestions, I would be happy to listen to them.
" delay() in your library is more than delay as you figure out, more like sleep() now. Since we implement freeRTOS tickless Tickless Low power features in FreeRTOS Everytime delay() is invoke it will put mcu into decent sleep mode"
Interesting… would be nice however to be able to have the LoRaWAN stack directly use FreeRTOS scheduling rather than have to do its own thing on top of FreeRTOS trying to emulate Arduino behavior.
But give it a try and see what you get for current. One thing that jumps out in that adafruit forum link (and is always a concern) is other potential power drains on a board beyond just the operating mode of the main MCU core.