RAK7204 stops sending data

I have about 20 of these 7204’s with 3.0.0.14 software and they still have this problem. Although it is possible the battery would be used up trying to rejoin a Gateway that isn’t there, the 7204 may as well have a dead battery if it won’t even try to rejoin. How do you change send_interval x:y to affect the rejoin interval? Please post the command required. Also, please add a watchdog as a firmware option. I for one would adopt it as the 7204 failing to report is a much more common issue than a missing Gateway.

Mine goes offline too - and I’ve just changed the battery after only a few months so I’m not sure it sleeps properly either.

I think a watchdog would be useful so we’d at least get a reset / rejoin that we can track. But it’s not in RUI as far as I’ve seen.

Would the command be "at+set_config=lora:join_interval:X:Y” ??

What happened when you tried it?

Haven’t yet. Awaiting response from RAK. It will take weeks of testing to know as the 7204’s generally run for a few weeks before failing to send data.

What’s stopping you trying it?

Haven’t yet. Awaiting response from RAK.

I suppose I could to see if it accepts the command, but no point if it is wrong, and will take weeks to find out if it works if the command is correct, so I can wait for an answer from RAK.

Where did you get the idea for the command?

Higher up in this thread Tomi from RAK says the Send command can also be used for Join, so I just substituted Join in place of Send. I would set it to 1:86400 so it Joins once per day. We send and chart temps every 30 minutes, so I should be able to see no chart for a period of time. I can also set our software up to text me if no data received from the 7204 for “x” minutes. This way I can test if the Re-Join actually works.

Hi, got on my laptop so no need for one-liners on my iPhone.

It might be worth trying a at+help to see what commands the module supports - mines in pieces on my desk in the office so I can’t check, but I’ve not seen any join_interval on any of the core modules and it’s not documented for the RAK811 which is used in the 7204.

I’m not sure quite how a join_interval could be implemented. A device joins, ideally once in its life, and then transmits uplinks. It’s then in a double-negative mode - as in, how does it know if it’s not in range or joined or that the gateways haven’t been switched off or stolen or similar. There’s been quite some discussion on the TTN forum about this.

The only sensible way is for it to perform a confirmed uplink at some appropriate interval - like once a day - at the expense of the entire local community as the gateway can’t hear any uplinks whilst it’s transmitting it’s confirm, however briefly. One way of mitigating this is to have some significant overlap of gateways, so other devices are still in range of a listening gateway whilst the another one is transmitting.

The other scheme is to send a downlink at a particularly interval and if the device doesn’t get it’s downlink as expected, it performs a re-join.

Multiple re-joins then make a mess of the join nonce as firmware tends toward some questionable mechanisms for deriving the nonce. And if you have a few hundred devices being serviced by a gateway, all those gateway transmissions can result in a cascade - so the gateway transmitting means it doesn’t hear a confimed uplink, the device doesn’t get it’s confirmation, performs a join, which requires a transmitted response, which blocks another devices confirmed uplink and it just goes round in circles. Mathematically unlikely, but hugely entertaining / interesting when it happens, but I’ve only seen it for real on devices on RS485 chains.

Ideally you want the device not to go offline or fail to sleep, thereby running the battery down. The next best alternative is to watchdog &/or enforced reset at defined intervals, but keep the join keys & counters in flash.

Or, RAK could just fix whatever the underlying problem actually is, or take the product off the market…as this has been going on for far to long.

I can confirm the behaviour here. All 3 of my 7204 (firmware on 3.0.0.12) died at the same time after ~2-3 months. One device drained the battery completely. The other two devices ran for another 2-3 months until the same problem came up.
I generally like the nodes but with this bug I wouldn’t recommend them in any project.

1 Like

Same issue here. Restarted RAK 7204 on 2020-12-10 16:22 to set send_interval to 1200s. Last transmission on 2020-12-27 22:22.

V3.0.0.14.H.beta4

===============Device Status List================
Board Core: RAK811
MCU: STM32L151CB_A
LoRa chip: SX1276

Battery Voltage:3.585 V
BME680 sensor data:
Humidity:43.267 %RH
Temperature:22.73 degree
Pressure:1002.21 hPa
Gas_resistance: 2959 Ohms
===================List End======================

at+get_config=lora:status
OK Work Mode: LoRaWAN
Region: EU868
Send_interval: 1200s
Auto send status: true
Send_interval work at sleep
MulticastEnable: false
DutycycleEnable: false
Send_repeat_cnt: 0
Join_mode: OTAA
DevEui: xxx
AppEui: xxx
AppKey: xxx
Class: A
Joined Network:true
IsConfirm: unconfirm
AdrEnable: true
EnableRepeaterSupport: false
RX2_CHANNEL_FREQUENCY: 869525000, RX2_CHANNEL_DR:3
RX_WINDOW_DURATION: 3000ms
RECEIVE_DELAY_1: 1000ms
RECEIVE_DELAY_2: 2000ms
JOIN_ACCEPT_DELAY_1: 5000ms
JOIN_ACCEPT_DELAY_2: 6000ms
Current Datarate: 5
Primeval Datarate: 5
ChannelsTxPower: 0
UpLinkCounter: 1
DownLinkCounter: 0

I have 20 such devices and all have a similar problem! Dear RAK, help us! each device turns off at random there is no pattern (((

FWIW, just noticed the one here as gone offline - cycled the power & it’s back on.

The problem seems related to the message format changing after a time, and the Gateway doesn’t recognize it. I have some test firmware that has an AT command to cycle power. I have been running it for a couple of months, automatically cycling power once a day. Solved the random shutdown problem. No issues at all. I will ask my contacts at RAK if I can share it with you yet.

Does this mean we have to have a computer attached that sends the AT command once per day?

No, the AT command resides in the firmware on the 7204. It’s a new Restart Interval AT command added to a 7204 with the Serial Tool, just like any other RAK AT command. Restarting it once a day clears the cache or the memory or whatever is causing the underlying problem before it can cumulate into a non report issue. Works great.

Hi @nmcc please check this RAK7204 "stops transmitting" issue workaround

2 Likes