An update to my stability testing, this partly makes me collect the dates and status.
A test system “tu_rc_EC” standalone EC “Stream Disconnect” monitor built on 0.25.0 has been running since the beginning of Oct very well. I plan on describing this and haven’t done so yet.
The “TUCA-NA13” remote Verizon wireless system in the wilds measuring a stream depth, with two gauges – Keller and LTC500 – built on 0.25.0, has stopped recording on MMW on March 28. It started on Jan 29<sup>th</sup> after a previous outage, so ran for 2months. It is very remote and appears to go through periods when the Verizon network has low signal or MMW is not responding, but it has always recovered. A site visit next week might restore it.
An early beta “tu_rc_test06” is in my yard, and a duplicate of the TUCA-NA13, with version0.28.3. This is from my fork, with extra features, but based on 0.28.3. It stopped running, and I have a terminal on it that caught what happened
So tu_rc_test06 started Apr 1st (it survived Apr 1st), and froze on Apr 19<sup>th</sup> . Looking at the log, the Mayfly awoke at
… zzzZZ Awake @ 2021-04-19T16:07:00-08:00
then POSTED to MMW successfully
— Response Code — 201 waited 2107 mS Timeout 5000
Going to sleep. Ram( 6127 ) ZZzzz…
Watchdog disabled. barksUntilReset 150 <–WatchDogAVR
then never woke up.
At a guess, a hypothesis, the RTC clock never woke it up.
@srgdamiano I wonder if you’ve seen anything like this?
Looking at the Sodaq_DS3231 RTC it reinitializes every sleep cycle. In another life, working on a large product, we had some very occasional reliability issues with the I2C bus. When there was an issue it was spectacular, and once happened before a very visible customer. We came up with a workaround.
The I2C hardware protocol is not a guaranteed transaction, and could have noise on the line. So I’m trying a modification that does a read of the Sodaq_DS3231 registers to verify that they have been set correctly. It is a long shot, and happy to take any suggestions.