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.


1 Like

This issue is extremely frustrating and that they haven’t released a firmware patch is ridiculous. What good is an environmental sensor that needs to be manually reset every 50 days. Was really impressed with RAK products but this is unacceptable.

Hi @kkalbaugh ,

This is a FW for RAK5205 with configurable auto reset.

AT command is at+set_config=lora:periodic_rst_interval:xxx

xxx is the period to reset the device. The unit is in seconds.

For example, at+set_config=lora:periodic_rst_interval:86400

1 Like

@carlrowan I just got around to retrieving some of the 5205s we had deployed to apply this firmware and the zip file I downloaded days ago is corrupt and the link you provided above no longer works. Can you send it again? Thanks!

Hi @kkalbaugh ,

Please check if you can download this Dropbox - RAK5205_p_rst.0304 - Simplify your life.

If not, give me your email and I will email it to you.

Ok. Got the download and used the STM32CubeProgrammer to install the app and the bootloader because the RAK Upgrade Tool V1.0 just hung when I tried to just update the firmware.

However, now I get this:

LoRa (R) is a registered trademark or service mark of Semtech Corporation or its affiliates. LoRaWAN (R) is a licensed mark.

______  ___   _   __  _    _ _          _               
| ___ \/ _ \ | | / / | |  | (_)        | |              
| |_/ / /_\ \| |/ /  | |  | |_ _ __ ___| | ___  ___ ___ 
|    /|  _  ||    \  | |/\| | | '__/ _ \ |/ _ \/ __/ __|
| |\ \| | | || |\  \ \  /\  / | | |  __/ |  __/\__ \__ \
\_| \_\_| |_/\_| \_/  \/  \/|_|_|  \___|_|\___||___/___/
RAK5205 Version:
periodic rst is enabled. (interval:86400)
UART1 work mode: RUI_UART_NORMAL, 115200, N81
UART3 work mode: RUI_UART_USER, 9600, N81
BME680 init success.
LIS3DH init OK.
GPS Init OK.GPS timeout:100s
autosend_interval: 600s
Current work_mode:LoRaWAN, join_mode:OTAA, MulticastEnable: false, Class: A
Initialization OK 
OK Sleep

And it won’t join.


After a firmware update of any type by any means the settings for the device need to be re-entered.

There isn’t an area of flash set aside that doesn’t get hit with a flash wipe on programming so this is absolutely required.

1 Like