Computing stuff tied to the physical world

Low power – µA’s in perspective

In AVR, Hardware on Jun 23, 2012 at 00:01

Ultra-low power computing is a recurring topic on this weblog. Hey – it’s useful, it’s non-trivial, and it’s fun!

So far all the experiments, projects, and products have been with the ATmega from Atmel. It all started with the ATmega168, but since some time it’s now all centered around the ATmega328P, where “P” stands for pico power.

There’s a good reason to use the ATmega, of course: it’s compatible with the Arduino and with the Arduino IDE.

With an ATmega328 powered by 3.3V, the lowest practical current consumption is about 4 µA – that’s with the watchdog enabled to get us back out of sleep mode. Without the internal watchdog, i.e. if we were to rely on the RFM12B’s wake-up timer, that power-down current consumption would drop considerably – to about 0.1 µA:

Screen Shot 2012 06 22 at 22 03 30

Whoa, that’s a factor 40 less! Looks like a major battery-life improvement could be achieved that way!

Ahem… not so fast, please.

As always, the answer is a resounding “that depends” – because there are other power consumers involved, and you have to look at the whole picture to understand the impact of all these specs and behaviors.

First of all, let’s assume that this is a transmit-only sensor node, and that it needs to transmit once a minute. Let’s also assume that sending a packet takes at most 6 ms. The transmitter power consumption is 25 mA, so we have a 10,000:1 sleep/send ratio, meaning that the average current consumption of the transmitter will be 2.5 µA.

Then there’s the voltage regulator. In some scenarios, it could be omitted – but the MCP1702 and MCP1703 used on JeeNodes were selected specifically for their extremely low quiescent current draw of 2 µA.

The RFM12B wireless radio module itself will draw between 0.3 µA and 2.3 µA when powered down, depending on whether the wake-up timer and/or the low-battery detector are enabled.

That’s about 5 to 7 µA so far. So you can see that a 0.1 µA vs 4 µA difference does matter, but not dramatically.

I’ve been looking at some other chips, such as ATXmega, PIC, MSP430, and Energy Micro’s ARM. It’s undeniable that those ATmega328’s are really not the lowest power option out there. The 8-bit PIC18LF25K22 can keep its watchdog running with only 0.3 µA, and the 16-bit MSP430G2453 can do the same at 0.5 µA. Even the 32-bit ARM EFM32TG110 only needs 1 µA to keep an RTC going. And they add lots of other really neat extra features.

In terms of low power there are at two more considerations: other peripherals and battery size / self-discharge.

In a Room Node, there’s normally a PIR sensor to detect and report motion. By its very nature, such a sensor cannot be shut off. It cannot even be pulsed, because a PIR needs a substantial amount of time to stabilize (half a minute or more). So there’s really no other option than to keep it powered on at all times. Well, perhaps you could turn it off at night, but only if you really don’t care what happens then :)

Trouble is: most PIR sensors draw a “lot” of current. Some over 1 mA, but the most common ones draw more like 150..200 µA. The PIR sensor I’ve found for JeeLabs is particularly economical, but it still draws 50..60 µA.

This means that the power consumption of the ATmega really becomes almost irrelevant. Even in watchdog mode.

The other variable in the equation is battery self-discharge. A modern rechargeable Eneloop cell is quoted as retaining 85% of its charge over 2 years. Let’s assume its full charge is 2000 mAh, then that’s 300 mAh loss over 2 years, which is equivalent to about 17 µA of continuous self-discharge.

Again, the 0.1 µA vs 4 µA won’t really make such a dramatic difference, given this figure. Definitely not 40-fold!

As you can see, every microamp saved will make a difference, but in the grand scheme of things, it won’t double a battery’s lifetime. There’s no silver bullet, and that Atmel ATmega328 remains a neat Arduino-compatible option.

That doesn’t mean I’m not peeking at other processors – even those that don’t have a multi-platform IDE :)

  1. Teasing last sentence – what does it mean?

    • Oh, just always exploring, also outside the Arduino IDE ecosystem, that’s all.

  2. I find sensors that last at least a year on batteries very acceptable, altough longer is always nice!

    I’m still happy with the cheap S555TH humi/temp sensors (see http://www.jansipke.nl/measuring-temperature-and-humidity-with-a-jeenode/), they last about 3 years on two batteries. No idea what mcu is used.

    The newer z-wave sensors last about one year on batteries or even longer, such as the roomnode equivalent aeon labs multi sensor (http://www.smarthome.com/75504/Aeon-Labs-DSB05xxx-ZWUS-Z-Wave-Multi-Sensor/p.aspx), which should last 2 years on 4 batteries…

    These are al send only nodes. I guess theat if you would want vey low power receiving nodes, that would require very smart wake-up-at-the-right-moment software or a very low power replacement of the RFM12B.

  3. While searching for a very low power PIR sensor I found this application note from Texas Instuments: http://www.ti.com/lit/an/slaa283a/slaa283a.pdf

    They claim to run a PIR sensor with a power budget of 9.37 μA. Also, it has a very low component count, so it’s cheap :).

    I’ve ordered a PIR detector (just the detector, not a complete module) to try if I can get this working with an AVR.

  4. I noticed some behaviour on the z-wave PIR sensors which I use over here which could come in handy to get the power usage down (a bit). When motion is detected it will turn off the PIR for like 20 seconds and then start a 10 second check to see if there is still motion. It then goes to sleep for another 20 seconds and so on. Not sure at what level the PIR is turned off without getting the startup delay problems …

  5. This is why I bypass the whole voltage regulator thing and then run it off of a 3.7 volt lithium poly 18650 battery. Its been tunning for a year – transmiting once every 5 seconds. Its not even really optimized that well. I could probably shave a few more milliamps off by disabling brownout and whatnot. But there is a certain point at which I am not sure getting another doubling in efficiency matters. Optimize too much and the self drain of my old lithium batteries I throw at my expirimental projects would probably excede the current being drawn by the node.

    **warning to all – running you jeenode on a 3.7 volt lithium ion battery may not be a good idea. It works for me, but it might burn out for you. Also, never charge the battery while attached to the jeenode. More likely to burn out. Just make a molex splice in the battery cable, and modify a universial lithium battery charger with another molex connector – forcing the user to disconnect the unit befroe charging.

  6. @Andrew, good tip on avoiding the higher charging voltage reaching the jeenode. Not sure I share the concern though about using the raw 3.7v lithium output – the ATMega is fine up to 5.5v and the RFM12B module, though it recommends up to 3.8v, lists 6v in the ‘not to exceed’ ratings which seems plenty of margin.

Comments are closed.