Optimizing power for battery usage


We've been playing with an Arduino Duemilanove + XBee. Works lovely, BUT... now we'd like to use a battery on the board instead of a fixed power supply. I don't know much about electronics, but it seems that the current setup of the board requires ~85 mA. According to the one who checked this, a battery would only last for about 2 weeks... Without the XBee it still requires ~25 mA.

My question is how to optimize this? As for the setup: - An XBee shield is connected with a XBee Pro, 60 mW wire antenna - Board transmits a small packet of data each second - A button kinda like sensor is connected to the Arduino 5Volt. It makes or breaks contact with a digital input on the same board. A 10 kOhm resistor is connected between that pin and the ground to prevent "floating" signals. - No other I/O or external components used - 9 Volt adapter net supply has been used

Ideas? Using a weaker antenna, running on 3.3 Volt...? Thanks! Rick

Use a switching regulator or no regulator at all. Do not use the “standard” regulator.
“Sleep” the processor for as long as possible.
Lower the frequency (to reduce current consumption AND to decrease lowert possible operating voltage).
Switch off unneeded peripherals (the XBee!!). If you “always” need your XBee check if it might be sufficient if it is active 1s every minute or every hour.

Read the datasheet.


My current record is to get the processor down to an average of <5uA. Of course it sleeps most of the time.


If you do not want to push the limits but just have a somewhat lower consumption start here:



Thanks for the tips! So having a sleep is one of the keys here. Currently the module is sending its sensor reading every second. Now that's not really nessesary, but it should send a signal at least once a minute to tell the host it's still alive. Would it be helpfull to send that signal, and then turn off again the next ~55 seconds?

Another problem that will come around is users that want info on demand. That means the XBee could receive a request any moment. How to deal with that?


1) Sleeping will decrease power consumption 2) Sending usually consumes more power than receiving 3) If you can configure the Xbee to trigger an interrupt on incoming transmissions you should still be able to sleep

This is bascially something that will require some trial and error.


I second Richard's view. Unless you tell us a little bit more what you are actually doing it is very hard to tell how you could decrease power consumption.


Sorry for the late reply,

A little bit hard to say what is measured. I made a communication protocol for all kinds of devices we have here in the factory. For example: - Raise an alarm if an airfilter got jammed (simple digital sensor goes on or off) - Humidity & Temperature readings. Changes relative slow - Machine counters (x packages produced). Changes rapidly. - Heater regulator (switches a regulator based on time and/or manual input)

With on demand, I mean an user can view the current readings/statistics whenever they like. And in some cases also operate (switch on the lights 15 minutes before someone arrives).

I agree a temperature/humdity sensor doesn't need to measure each second. A moving average would be better here indeed, but still requires the board to keep running right? I think 1 sample per minute is enough, but that means I'll need to wake up the module each minute as well. No idea if that would be really helpfull to reduce power consumption...

An interrupt to wake up sounds good, but I'm not sure if the hardware gives such a pulse. It's an XBee + shield. As far as I can see, it communicates through the I2C pins. Someone knows if I can get interrupts there somehow? I don't have the board until thursday, so it's difficult to test now.


Well, none of the regulations or readings are "critical", so missing packages aren't that bad... In the worst case the heaters didn't jump on in the winter:) The reason we choose for wireless is because of the large number and changing locations of devices. Not impossible to put wires everywhere, but certainly one hell of a job.

Anyhow, when it comes to interference/corrupt packets, is this truly a problem? I don't know, never tried XBee before on this scale. But from what I understand, the ZigBee protocol has methods for error detection like TCP/IP does. On top, I check my packets as well. Pretty many bytes have to be correct, otherwise the packet will be dumped. A wrong bit in a parameter value could deliver crazy setpoints though...

As for batteries, I thought one of the ZigBee targets was to create communications suitable for batteries. Well, with the "sleep" tips mentioned earlier we might get that working. Otherwise a fixed power supply is still an option, although it would require some extra wiring.


hmmm... I could be wrong, but I thought the protocol for ZigBee is based on TCP/IP, where multiple incoming messages are queued so you won't get a mix of multiple packets when reading incoming data. Got to add that messages always fit inside 128 bytes. There won't be multiple packets for a single command/reading.

Each module can send and receive indeed. Basically there is one server PC with an XBee "Coordinator", and X end-devices. Each one can send/receive any moment, there is no timing involved (living on the other side of the planet by the way, Netherlands). That means the PC for example could receive 2 messages from 2 different modules at the same time.