I’m using two RN2483, the first one with firmware 1.0.4, and the second one with 1.0.5 version; and both have the same behavior.
I can join normally using OTAA, and I can send messages, up to here everything seems correct. The problem comes that after every single message that my radios send, TTN keeps scheduling the same messages that you can see in the picture:
And I don’t know what’s really happening here and how to handle it. Any ideas?
To administrators/moderators, feel free to move this thread to another subforum or close this message if it is already solved in another thread. It’s my first post, and I tried to find a solution to this, but I didn’t.
The network is issuing a device status request, and not receiving an answer.
This could be a bug in the node’s firmware, or it could be something like a mismatch in the LoRaWAN version of the node vs. how it’s registered in TTN.
Given the OTAA join success, presumably it’s not a problem in downlinks getting through, unless somehow post-join the RX window settings have been force reverted to the old 1 second timing rather than the new 5 second timing commanded in the join accept.
As you said @cslorabox it’s a problem with timings on the node. After your message, I decided to remove all the sleeps I have in my node, and then the messages from TTN are received correctly by my node and they send the information back. But that means I need to wait for some time before the nodes can go to sleep.
Sleeping itself should not be an issue if done correctly, but you may decide that sleeping between a transmission and the corresponding RX windows just isn’t worth the trouble - it’s only a few seconds, and your processor is probably only consuming around a milliamp (if it’s well chosen and not cranking the clock PLL) so that may not save much.
But when you do sleep, make sure that your LoRaWAN stack’s sense of time after waking includes the time asleep. Otherwise, it may think its used up all its duty cycle if it only sees the wakeful time as time elapsed.
