Computing stuff tied to the physical world

It’s about survival

In AVR, Hardware, Software on May 29, 2012 at 00:01

When running off solar power, ya’ gotta deal with lack of (sun-) light…

As shown in a recent post, a 0.47F supercap appears to have enough energy storage to get through the night, at least when assuming that the day before was sunny and that the nights are not too long.

There are still a couple of issues to solve. One which I won’t go into yet, is that the current approach won’t start up properly when there is only a marginal power budget to begin with. That’s a hard problem – some other time!

But another tactic to alleviate this problem, is to try and sail through a low-power situation by reducing power consumption until (hopefully) more energy becomes available again, later on.

Here’s my first cut at implementing a “survival strategy”, using the radioBlip2 sketch:

Screen Shot 2012 05 15 at 14 00 12

It’s all in the comments, really: when power is low, try to avoid sending packets, since turning on the transmitter is by far the biggest power “hog”. And when power is really low, don’t even measure VCC – just slow down even more in maximally efficient sleep mode – I’ve set the times to 5 and 60 minutes. The 1-hour sleep being a last effort to get through a really rough night…

But I’ve also added some kamikaze logic: when running low, you don’t just want the sketch to go into sleep mode more and more and finally give up without having given any sign of life. So instead, when the sketch is about to decide whether it should send a packet again, it checks whether the voltage is really way too low after what was supposedly a long deep-sleep period. If so, and before power runs out completely, it will try to send out a packet anyway, in the knowledge that this might well be its last good deed. That way, the central node might have a chance to hear this final swan song…

The thresholds are just a first guess. Maybe there are better values, and maybe there is a better way to deal with the final just-about-to-die situation. But for now, I’ll just try this and see how it goes.

One last point worth mentioning: all the nodes running this sketch can use the same group and node ID, because they are transmit-only. There is never a need to address packets sent towards them. So the BLIP_ID inside the payload is a way to still disambiguate incoming packets and understand which exact node each one came from.

Re-using the same node ID is useful in larger setups, since the total number of IDs in a group is limited to 30.

I’ll do some tests with the above logic. Let’s hope this will keep nodes alive in long and dark winter days nights.

  1. It’s a pity you’re going to have to wait about six months before we get any long and dark winter nights. Still, at least you’ll be ready come November. I’m wondering whether the MSP430 (which is described as ULTRA low-power) might do better. Also, how long do your sleeps ACTUALLY sleep? Think that might be crucial when the chips are really down. In any case, I’m interested to see how you get on with this.

  2. PS. Winter days may be dark-ish, but they’re not long ;-)

  3. Heh – touché ;)

    I’ve been exploring several other processors, but note that with say a Room Board, the PIR really eats all the energy anyway, and… it sure would have to be an excellent reason to ditch standard Arduino compatibility.

    Last time I checked, the JeeNode drew about 6 µA – including regulator and radio. I think there’s still quite a bit of leeway w.r.t. long autonomous life. More tricks are still being explored – so stay tuned!

    • But I’m guessing that a Room Board with PIR won’t be able to survive the night whatever micro we use, plus you’re not going to put a PIR at the mercy of available sunlight if it’s needed for intrusion detection. If we’re talking extreme low-power operation then the current-draw of the micro during sleep modes becomes critical. The MSP430 can sleep with the VLO active (to trigger wakeup) using less than 1uA. Not sure that the AVR can match that. Don’t get me wrong, I’m no Texas fanboy, but your experimentation is making me think hard – I have AVRs, MSP430s and RFM12Bs ready for a personal project and I’m trying to figure the best solution.

    • You’re right – the PIR isn’t really usable in ultra-low power contexts.

      The ATmega won’t go below about 4 µA with its watchdog still running. Indeed, the MSP430’s goes lower (so can some other chips) – so if you really want to push the boundaries, I’d encourage you to try that. If you do, please consider posting about it on the forum – I’d definitely be interested.

    • I started first tests with a disabled ATmega Watchdog – looks very nice… It gets the sleep-mode consumtion down a a few µA. 3µA (maybe even 2µA) should be doable when using RF12b as watchdog.

      Good thing about RF12b watchdog is that we don’t loose track of time. If an external interrupt wakes the ATmega while the RFM12b watchdog is in use we have absolutely no idea how much uf the time has passes but as soon as the RF12b watchdog fires we have the (quite exact) time again.

      I’ll post in the forum as soon as I have some worthy results.

    • I hope you get it working reliably – I used to do things with the RFM12B watchdog, but always ran into some sort of race condition, causing it to hang after a while and never wake up again.

  4. If the transmitter is consuming that much (relative), why not lower the output power with the “TX-control – Power out”?

    Or implement it in the sketch so that it always transmits at the lowest lowest power and only on higher power if ack’s are missed.

    0 dBm is 1 mW -3 dBm is 0,5 mW -6 dBm is 0,251 mW -9 dBm is 0.126 mW -12 dBm is 0.063 mW (what happened to -15 dBm?) -18 dBm is 0.016 mW -21 dBm is 0.008 mW

    • True – but you lose range, and you can accomplish something similar by transmitting at larger intervals. If a transmission needs 25 mA during 3 milliseconds, then sending once every 3s averages out to 25 µA, and once every 5 minutes will take 0.25 µA. This is low enough for other parts of the system to start dominating.

  5. Have you ever considered a BEAM approach ? BEAM robots collect energy , then shortly wake up and do their job (mostly running a motor). if the receiving station keeps the time, the sensor can just live it’s live the same way… (google for beam robotics)

  6. Jean-Claude, you remind me of a wonderful Motel sign I passed on a highway here in New Zealand years ago .. “Winter Special – Longer Nights – Same Price”

  7. Would it be an option to batch transmit the measurements? Or collect the data only and transmit upon request even.

    Or is that what is commonly referred to as cheating? ;-)

  8. Would it be beneficial to run the MCU at lower speed and only speedup for RF transmission?

Comments are closed.