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.
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?
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.
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.