Alright, it’s been 2 days with zero occurrences of that mysterious duplicate LoRa message I had previously. Pretty sure the clearRepeatingInterrupt() right when we wake up took care of that. I’m at 2 full days with consistent message timing just like this. Everything staying in sync and no mysteries double messages.
EXCEPT: I had another occurrence of a single LoRa node falling asleep and seemingly never waking back up. This is the second time it happened in over a month across 13 nodes but it happened again yesterday. I chalked the first occurrence up to something random or dead battery but the second occurrence today got me thinking… I am a bit perplexed on how it would forever sleep. Here is the logic I had going into/out of sleep.
// Constrain the time to 5 seconds to 21 minutes so we shall always wake up.
uint32_t slpTimems_cons = constrain(slpTimems,5000,1260000);
tm.stopWDT();
LowPower.deepSleep(slpTimems_cons); // We should always wake up via interrupt but in case we don't still set a max time.
tm.resumeWDT();
Even if something funky happened with the AB1805 interrupt (I.e. set it too far into the future or set it in the past due to some calc error/rollover) the device should of still woke up due to the sleep duration timer elapsing. If it got stuck in code execution, then the watchdog should of reset it. But nope…
As soon as I hit a reset on it it came right back to life but was a bit concerning that it took intervention for it to wake up. Since it was seemingly in an infinite sleep mode orphan rescue mode or anything like that wouldn’t of helped anyhow since it was never awake.
I made two changes today to help combat this unusual scenario. Appreciate any ideas, suggestions, thoughts behind my approach.
Possible Point Fix: Use a repeating alarm interrupt on the AB1805 that repeats every 1 hour instead of every 1 month. Not sure if this will fix the scenario or not, just drawing straws thinking of what could be done to make it more robust. This assumes an interrupt is set.
I.e. use REG_TIMER_CTRL_RPT_MIN instead of REG_TIMER_CTRL_RPT_DATE when setting the alarm to wake up at. This way if some reason the alarm is set wrong, some sort of alarm should go off and wake it up once an hour.
REG_TIMER_CTRL_RPT_MIN = 0x14; //!< Countdown timer control, repeat hundredths, seconds, minutes match (once per hour) (5)
REG_TIMER_CTRL_RPT_DATE = 0x08; //!< Countdown timer control, repeat hundredths, seconds, minutes, hours, date match (once per month) (2)
Within the AB1805 code select which type or repeating interrupt to set. Change this to be REG_TIMER_CTRL_RPT_MIN
bool AB1805::interruptAtTm(struct tm *timeptr, uint8_t hundredths) {
return repeatingInterrupt(timeptr, REG_TIMER_CTRL_RPT_MIN, hundredths);
}
Universal catch all fix: Keep the AB1805 external hardware watchdog active all the time even when sleeping. If for any reason at all, the watchdog isn’t getting pet, then reset the board. However, here’s the catch… the AB1805 has a max watchdog of 124 seconds. So the only way to pet the watchdog is wake up the MCU at least every 2 minutes some finite amount of time only to pet the watchdog and then go back to sleep. This was easier than I thought to accomplish programmatically:
case st_Slp:
{
LED.off();
IRQ_Reason = IRQ_Invalid; // Reset the interrupt reason (this is set within the interrupt routine)
LowPower.deepSleep(60000); // Sleep a max duration of 1 minute to pet the watchdog
// We just woke up, if it was from AB1805 interrupt we are done sleeping,
if(IRQ_Reason == IRQ_AB1805){
newState = st_AwokeFromSlp;
}
else{
//We woke up but not due to the AB1805 interrupt. Must be time to pet the watchdog.
tm.setWDT();
// Stay in this state to immediately go back to sleep for another 60 seconds.
}
break;
}
However, the disadvantage is now it’s waking up/sleeping every minute (or at least every 120 seconds).
So question for the group… is it reasonable to keep a watchdog active like this even when sleeping and wake up/sleep on some cadence just to pet the watchdog? Besides consuming some finite amount of battery power each time we need to pet the watchdog, what’s the disadvantage of this?
Then this weekend it's setting at least 10 of these up outside spread apart to truly be mesh for some endurance testing.
