Cubcell hangs after few days

ernst.schulz · June 1, 2020, 8:15am

case DEVICE_STATE_SLEEP:
{
if (accelWoke) {
increment_rain_meter();
accelWoke = false;
}
LoRaWAN.sleep();

Not the main-problem, but t think, when you get fast interrupts then the software swallows some values, because the sending takes some time.

wasn · June 1, 2020, 8:58am

There was a discussiob about a flow meter here

http://community.heltec.cn/t/count-pulses-for-flow-meter/1720/17

Using a little mcu like attiny as i2c slave doing the counts is a solution.
It takes only little power and wont miss a pulse.

If there is heavy rain your node would send so fast that would not be in the fair use policy of ttn.

Aaron · June 1, 2020, 3:27pm

It may be that the system has run to an unknown location. I can think of adding a watchdog, but the integrated watchdog function of the ASR650X chip is very bad:

Anyway, I will add 2 second watchdog in the next few day, and we will come out with a watch module later.

chris · June 2, 2020, 10:46am

Thank you! I would also like to include watchdog function even if “unfriendly”.

memo5 · June 15, 2020, 5:23pm

Is there already a watchdog demo available?
Currently I am not sending on every pulse but have a timer do send data.

wasn · June 15, 2020, 6:33pm

this commit added a watchdog example:

github.com

HelTecAutomation/ASR650x-Arduino/blob/master/libraries/LoRa/examples/LoRaWAN/LoRaWan_watchDog/LoRaWan_watchDog.ino

#include "LoRaWan_APP.h"
#include "Arduino.h"
#include "innerWdt.h"
/*
 * set LoraWan_RGB to Active,the RGB active in loraWan
 * RGB red means sending;
 * RGB purple means joined done;
 * RGB blue means RxWindow1;
 * RGB yellow means RxWindow2;
 * RGB green means received done;
 */

/* OTAA para*/
uint8_t devEui[] = { 0x22, 0x32, 0x33, 0x00, 0x00, 0x88, 0x88, 0x02 };
uint8_t appEui[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
uint8_t appKey[] = { 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x66, 0x01 };

/* ABP para*/
uint8_t nwkSKey[] = { 0x15, 0xb1, 0xd0, 0xef, 0xa4, 0x63, 0xdf, 0xbe, 0x3d, 0x11, 0x18, 0x1e, 0x1e, 0xc7, 0xda,0x85 };
uint8_t appSKey[] = { 0xd7, 0x2c, 0x78, 0x75, 0x8c, 0xdc, 0xca, 0xbf, 0x55, 0xee, 0x4a, 0x77, 0x8d, 0x16, 0xef,0x67 };

This file has been truncated. show original

memo5 · July 1, 2020, 3:58pm

Thank you for the example. I will test it in the next days

dbazza1 · July 2, 2020, 2:04am

Hi memo5,
I’m testing your code to see if its stable on my board (HTCC-AB01 915MHz).

I was wondering, it seems you are using a scheduled downlink once per day to reset the rain counter?
What parameters are you using for the downlink in ttn console?

memo5 · July 5, 2020, 6:57am

Hi,

sorry for the late reply, I did not see your question.

No, I don’t use the daily reset. I had only implemented it for tests. I calc the daily rain in thingspeak with a matlab script. This script is also able to handle a baord reset (rain_total get zero).

You should be able to reset the rain_counter to 0 when sending “1” to any port

skipper_is · July 6, 2020, 1:28pm

I have a similar issue, not using a rain counter, but a DS18B20 temp sensor (Have also experienced with a BME-280). A simple wake, take a reading, send it, and sleep for 60 mins, then repeat. Would rock along fine for a few days, then just hang. Sometimes even pressing the reset button wouldn’t help, and I’d have to remove the battery and reinsert for it to work.
Happened on 2 boards, another 2 boards, running basically the same script - have been running non stop for the last couple of months.
Weird

memo5 · July 7, 2020, 6:33pm

mine is hanging mostly during send after an interrupt. The interrupt does not send data, but on the next transfer it can happed that it hangs. If it is not raining it works for one month (did not test longer).

dbazza1 · July 8, 2020, 6:29am

Thanks for that info.
I’ve modified the code a little bit and its been running outside with a solar panel for about 7 days now.

Are you just sending the total amount of ticks from the device each day (not resetting count on device?) and then using thingspeak to calculate daily total? E.g 500 ticks were sent over 5 day period, 500/5 equals 100 ticks per day.

mutton · July 30, 2020, 11:46am

what did you do to the code @dbazza1 to make it more reliable?

txsrooster · July 30, 2020, 9:32pm

Mine would rock along then stop. I unchecked ADR and it has been rock solid ever since. I tested it with two different boards and one stopped at frame count 161 then other kept on going. I restarted them and switched the ADR on them and the ones with ADR checked stopped at 161 both times while the ones without ADR kept on going.

mutton · July 30, 2020, 9:45pm

OK that’s weird I have frame counts way past that with no issues.

I had to add an external pull up on GPIO0 (the pin I use to count rain gauge interrupts) to avoid getting random interrupt counts

memo5 · August 29, 2020, 6:54am

I added watchdog a month ago, https://github.com/schenlap/Lora_raingauge/commit/5318f21596336a9fe185ac65a6ae005cbb492236

Since that it worked as expected even the watchdog never triggered.

leroyle · September 3, 2020, 7:07pm

I am new to LoRa/Cubecell so this may be in left field, but I’m curious as to the size of your send data packets vs the configured DR as in the
#define LORAWAN_DEFAULT_DATARATE
as found in the runtimes: libraries/LoRa/src/LoRaWan_APP.cpp

I’ve seen DR_0 in, I believe is was 0.0.7
DR_5 in 1.0.0 ( which is invalid for US902-US928)

From looking at that code, an untested theory, it looks like data rate can be decreased over time, which I think is desired, and may reach DR_0, for US902 that would mean packets greater than 11 bytes would fail to send, silently fail. (V1.0.0 of the Arduino/Platformio runtime)

I need to test this theory out. Just curious for those that see the failures after awhile, what is your packet size and default date rate?

Thanks

memo5 · September 4, 2020, 6:58am

I do not use ADR, it should not be a problem.

leroyle · September 4, 2020, 12:59pm

The reason I ask is that I’ve seen a local report similar to yours where transmission stopped after a period of time.

In that case it looks like the data rate reduction appears to be happening even if ADR is set to off at the application level.
In this local case disabling the code that decreases the data rate within the runtime appeared to have solved the problem.

If data rate reduction is still happening and you are transferring more than the LORAWAN_DEFAULT_DATARATE allows, the transmission will fail.

Do you know if the app is hung, requiring the watch dog reset vs it’s still trying to transmit but the transmit fails? Perhaps turning on an led if the transmit fails, off it it succeeds. A constant on would tell you it’s always failing. That would need to be done in the lower runtime code.

I’ve not yet confirmed this but that is my next task. I’ll report back what I find.

Regards

techtroll · March 21, 2022, 5:46pm

Is this problem solved or not?
I have the same problem as many people have described here. My setup:

HTCC-AB01 with hdc1080 sensor send data every 15 min to TTN.
After 14 days I see no data coming in the TTN console. But my gateway says the node is still active and sends data.

Is there any wokraround or official solution?