Hi all,
This topic is related to this other one, where the main problem was the first receive window was kept to 1 second after waking up. I’ve already solved that problem, but the TTNv3 is still scheduling the same downlinks: 1st message for setting the Rx Delay to 5 seconds and the 2nd message to set a new ADR; the problem is that the Rx Delay is already set up to 5 seconds, and the new ADR is the same as my node is sending.
Any ideas what’s happening?
Your node has to acknowledge the MAC commands for the backend to know these have been processed. Does the node include these acknowledgements in the next uplink that is transmitted after receiving the downlink? (There is no need to send an immediate uplink, even if the next uplink is 24 hours later the acknowledgment will be processed)
This should automatically be handled by the LoRaWAN stack, however if your node can’t persist all stack state during sleep this will fail.
You are right, but I’m using RN2483A modules with 1.0.5 firmware version, and as far as I know, this acknowledgment is handled by the radio module itself. Is there a way to check this kind of message?
What version of LoRaWAN standard and MAC did you use while creating the node? Do the settings match the device firmware? The RN2483 is LoRaWAN version 1.0.2 according to Microchip.
Do you have access to the nodes traffic at gateway level? If so run it through a decoder to get the MAC data and decode that using the LoRaWAN specification. Both downlink and uplink to see what is actually happening.