What is the correct way to implement a WDT, for reset on a Sleeping node?

  • Hi,

    I have a node, which is both remote (middle of the garden, measuring oil level, and external temperature) ,and battery powered, it sleeps for 10 Mins, then wakes, measures and reports. All is mostly well, however occasionally, it fails to report for an extended period, and I have to manually reset it, when all is then well for weeks.
    I have tried to implement using the onboard WDT, however this results in the board never really initialising, and sending data.
    I can build an external WDT, however before revisiting this, I thought I should ask for other wisdom, as there may be an established method for doing this, that I can't seem to find.

    Many thanks

  • @njwyborn are you sure the board is not responding? Perhaps the message is never delivered due to connection issues? What type of transceiver are you using?

  • RFM69 Series, Signal strength is good, circa -77db.
    When this occurs, the battery is significantly drained, if I don't reset it, This leads me to believe that it is hanging mid process, and leaving the sensors powered.
    The sensors are powered via logic level mosfets, which are controlled via digital pins on the processor.
    As I say, it works fine for weeks on end, then hangs on an indeterminate frequency, this has worked in this fashion for 8 months, the code transmits the data several times for each loop, which is once every 10 mins, I (when I have specifically checked on occasion) get all the transmits of a loop. The ultrasonic sensor, can pull in the order of 60mA, when operating, hence the power mosfet(s).
    I have concluded thus, that the "system" is hanging after the mosfet is enabled, but before it is disabled. There may be myriad reasons as to why, but the system is otherwise OK, when reset, hence the wish to employ a hardware WDT, as the onboard WDT is used by the Sleep function, I don't seem able to employ that, at least I haven't been able to successfully.

    Thus I am asking mysensors people (so to speak) as how I may implement a WDT, other than building a external circuit.


  • @njwyborn No offence but would it not be better to figure out or obviate the cause other than use the nuclear option of a reboot which may not actually fix the problem ? 😉 Your range should be well within parameters so the problem probably lies with sensors locking up processor somehow, the question to answer is why.
    I have several pro-mini/rfm69 nodes around, only two of which have "locked up" in over a year of operation. The two problem nodes turned out to be locked due to accumulated condensation on the downfacing ultrasonic sensors in underground tanks during intensely cold weather. When accessible a wipe across the face recovered it, sometimes a bang on the conduit would clear it, today they were wiped with a glove after a week long outage, now reporting as normal.
    What I did to get around the issue when buried under a metre of snow at -15 was for the sketch to make X attempts, if it got a reading which was within parameters send it, otherwise at X attempts, go to sleep.
    This could go on for days, but at least it saved battery power, and IF the drip release in the interim, reporting would recommence.
    If the sensor starts up differently on reboot to sleep recovery, something is mis-set, otherwise there's the equivalent of the drip scenario IMHO...

  • Mod

    @njwyborn to my knowledge, there is no easy way to use the wdt while sleeping.

    What was the battery voltage when the node died? There have been a few cases where the voltage got below the accepted range (2.34V for a 8MHz atmega328 for example) which resulted in undefined behavior (mcu hang).

  • Hi,

    3.8v on a 8Mhz , Rocket Scream unit, with onboard regulator, and a input range 3.4 – 6 V
    This system is a Lithium, charged by solar, even through the winter, it has maintained circa 3.8v, until the week of no data receiving (my assumption of locking up with sensor powered).

    I am uncertain as to why or how a condensated sensor surface would cause the processor to lock, incorrect readings for sure, I suppose it is conceivable that the library I am using might get stuck in a loop, and thus never return to the main loop of the program, thus never sleep, or turn off the power to the sensor. The library is located here -
    [https://bitbucket.org/teckel12/arduino-new-ping/downloads/](link url) The installed version is 1.9.0, I see there is an update, Ill re-build and upload any way, and see if that helps over time.

    However to return to the origional question, it seems that using the onboard WDT is not really possible, I did try enabling it at the top of the main loop, and disabling before sleep, but that didn't allow it to run either.

    Unless there are any other suggestions, Ill, have to employ a TPL5110 timer, and power cycle the board every interval. Not what I really want to do, anybody have a better solution?


  • @njwyborn
    I see from your post you referenced "new-ping", so by pure coincidence you are referring to ultrasonic also.
    In my own case they are 5v JSN type single transducer "waterproof" heads which have been reliable except in -10 -20 weather conditions. They are relay controlled boards with 5v supply, fired every hour from an onboard RTC - I ultimately discovered the problem was a build up of condensation ultimately forming a drip on the face of the transducer, which interferes with both emit and receive.
    After a wipe yesterday, today both are reading consistently after an absence of around a week.
    You said a reboot resolves it so perhaps yours is a different issue, or perhaps you are inadvertently shaking the head somehow when rebooting?
    I can certainly recommend limiting the number of attempts to get a valid result, battery loss in the last week of NIL reporting has been minimal...

  • I have an idea that it still might be a low voltage situation. You say your ultrasonic sensor consumes about 60mA. When your battery voltage is at 3.8V those currents combined with the spikes caused by your radio can pull your battery down to below 3.3V.
    I have an outdoor sensor with a Moteino as board and that uses a MCP1703 as voltage regulator. Same family as the MCP1700-33 of your board. When my supply voltage drops in the direction of the regulated voltage, the MCP faults into some sort of short circuit mode which draws an insane amount of power but does not output any usable voltage. And that will drain your battery quick, fast, in a hurry... (©️ AvE )

    My sensor is being topped up by a solar panel so theoretically, it should never run out. But theory and real world are NOT the same. Your board is also capable of charging a LiIon battery with both the Vin and 5V connections. The BQ24074 will charge your batt.

    Hope this helps you towards your solution.

  • @davidzh Indeed possibly voltage related, but unlikely due to be the radio which should not be operational during the reading. An interesting/curious observation on that voltage regulator behaviour though.
    Possibly the fault lies not with the processor but the ultrasonic module if on the edge of it's operating voltage, both board versions trialled here were occasionally flaky unless provided a solid 5v, despite allegedly 3.3-5.5v capable.

  • Many thanks, Do you think then that given I wish to remain with a lithium battery, which otherwise has performed suitably, that inclusion of a step-up regulator, to provide a 5v rail for the ultrasonic sensor?
    Do you imagine the battery drain with the additional regulator to be a problem?
    Would you supply the whole system with the stepped up 5v, or just the ultrasonic?
    The radio and temperature sensor are supplied via the 3.3v regulator on the mcu board, the ultrasonic, via a logic level Nch mosfet, fed off the main battery rail.
    The ultrasonic device is supposed to have a supply range of 3.3 - 5.5v


  • As a simple fix, i've stepped up the whole supply , with the addition of a step up booster to 5v, I'll see the results!

  • @njwyborn Ditto on the stated voltage for the two ultrasonics I have, they didn't work reliably at 3.3v if at all, but the common pro-mini has an onboard booster down to <1v input from 2AA alkaline.

    I can only observe on the two different solutions I trialed, both of which used a a small DPDT latching signal relay fired by mosfet triggers. (ca 50mA for 6ms On/Off)
    The original uses a Master 3.3, the relay firing a Slave 5v pro-mini on a 6v battery, in turn powering the Ultrasonic and doing all the processing then passing results on I2C via a level converter to the Master to radio in.
    The second uses only the 3.3, the relay powers up a step-up to power from RAW for the ultrasonic and level converter, turned off after either a correct result or 10 attempts.
    The first is reasonably frugal but uses 6AA in total, is clunky, problematic, bulky.... Probably it will be changed to the 2nd version when the snows clear.
    The second version is only 3 months in, but thus far seems reasonably frugal on the 2AA cells, probably >9 months battery life.
    In both cases the problem of power demand was identified as the ultrasonic head developing a drip blinding the head, hence the max X attempts to minimise battery drain when it doesn't get a reading.
    The second version is for sure the simplest and most reliable.
    Not sure how efficient the 5v booster is but the greatest power loss is probably the remaining LED on the 5v booster (US LED was removed).
    The pins on the pro-mini used for the relay are the onboard LED pins which I'm reluctant to remove as they confirm the hourly routine and whether the result was successful or not.
    You might try a variable voltage to the Ultrasonic to see where it falls over, but be careful if the pins on your board are not 5v tolerant (hence level converter)
    Hope this helps.