Stop to send in 50 days

Issue: stop to send data to ttn 50 days after restart I have 4 sensors and all stoped

Setup: I must go to the sensor and restart manualy



What are the sensors?

What is the graph showing us?

all sensors of the rak 7205 stoped, the graph is only humidity but you can see when it stoped and after I manualy restart it works again

Here you can see the points

Unless you think it’s a humidity problem, this is a distraction.

Can you provide a chart with the battery voltage?

Where are these sensors located?

Have they been running for longer than 50 days previously?

the sensor has stopped but it is not due to the battery or the sensors all worked well, it is some of the firmware maybe
Battery :

Can you answer these please

Two potential areas of concern here:

First 50 days is approximately 2^32 milliseconds and thus a common point at which logic bugs in code that uses a 32 bit millisecond counter are exposed.

Another could be a 16-bit rollover of a LoRaWAN frame count where the node and server disagree if a 16 bit or 32 bit frame counter is being used, for that it would be useful to have a record of the frame count values just before failure.

It would also be very useful to know if the nodes are still transmitting and being picked up by a gateway only to have the packets rejected by TTN, or if they are no longer transmitting at all.

The sensors are outdoor in diferents places
and yes these sensor was working fine before but the same issue was happend before

Thank you Chris
I´m sure that this issue will pass again and then I will try to verify if the node send data and the ttn counter.
Do you think that this issue can be solved reseting de counter?

That’s something you could only determine by finding out if the node is still transmitting packets which are not being accepted for some reason, or if it is no longer transmitting at all.

If there is any of your own code running on the node you should look through any timing-related logic for potential overflow hazards. If you don’t have access to the code, there could still be issues but you can’t readily review them.


I am also experienced this on my RAK811 module in RUI.
After 5 days running, the module stop sending data.
Is there any script to detect this event, and to re-join to the LoRaWAN network ?

That sounds like a distinct issue probably unrelated to the one in this thread

I have been looking into this issue with the RAK5205 sensors for some time now. Unfortunately the problem is in the low level code which is not available to the end users using RUI.

I have had to revert back to the original API the RAK wireless provided for the RAK811 (on GIThub) and build my project up from there. The RAK811 API is based on reference code from Semtech. It uses the RTC alarm timer to wake the modules from the STM32 stop mode. There are some bugs with the implementation of this which eventually cause the device to be put in to the low power stop mode without a valid wake up alarm being set. So, it will sleep forever.

Furthermore, there is another bug which causes the RAK811 module to wake early. The module should return back to deep sleep, but it doesn’t and consumes mA instead of uA which will prematurely drain the battery.

Both of these issues have been already bought to RAK’s attention, but they are yet to acknowledge and fix them.