Cubcell hangs after few days

#1

Hi,

i use cubcell De-board for a lora raingauge. My software is based on ext_interrupt example. After a few hours to days the software hangs and I do not receive lora packets anymore. I have to reset the board with reset switch to get it working again. The board is powered with battery and solar cell (also tested without solar cell). I have rgb led activated for tests and it does not flash so it is not a gateway issue. After reset the board work again, so I don not think it is a battery problem.
My current software can be found at https://github.com/schenlap/Lora_raingauge
How can I debug to find the root cause?

Count events with Interrupt during Deep Sleep and LoRaWan
#2

Possible, make a test (compile) with Version 0.0.5.

Also you can use the watchdog-timer, but i can’t say how to use it. Heltec must publish an example-code for watchdog-implementation.

E_T

#3

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.

#4

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.

1 Like
#5

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.

1 Like
HTCC-AB01, ADS1115 and LORAWAN (Chirpstack)
#6

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

#7

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

#8

this commit added a watchdog example:

#9

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

#10

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?

image
image.png1068×241 5.82 KB

#11

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

#12

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

#13

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).

#14

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.

#15

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

#16

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.

HTCC-AB01, ADS1115 and LORAWAN (Chirpstack)
#17

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

#18

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.

#19

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

#20

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

[SOLVED] CubeCell AB01 and LoRaWAN: frame counter is not incrementing after few days of running time