Strategies for better battery management

The reason I get so few wakes and Wifi connections with an old 80mAh battery is because it is a weak Wifi signal. I would expect at least double if it were closer to the router.

You can use 3x 1.3v NiMh without the regulator if you have a diode drop in series. I theorize that 3.9v while sleeping would not be harmful? Anyone?

See attached spreadsheet - I just made it now, but I think it’s correct. You get to input your battery voltage, capacity, time in each power mode (sleeping, shallow wake, and wifi on wake with and without powersave), number of events per day, system current, etc and it tells you an estimate of battery life.

I put a couple of tabs in there for different scenarios (direct from a CR123A and from 4xAA).

Hugo, does Wifi work at 2.0v or 2.9v?

WiFi technically should work down to 2.5v, but we recommend staying above 2.7v generally to give some headroom. Below that point… YMMV. Not recommended for reliable operation :slight_smile:

That makes sense. My voltage according to Squirrel is 2.9v, but after it begins to transmit I’m sure it quickly lowers to 2.5v when it quits.

@sbright33 Thanks for the experimentation data. I recharged my LiPos to 4.2V and I’m watching them for real data. @Hugo Thanks for the spreadsheet. I think that confirms my very rough calculations. I’m expecting anywhere from 100 to 130 days of life from my batteries with the firmware the way it is today. I think I can lower the number of times the ADC is checked (and, therefore, the number of times the WiFi is awakened) and extend the battery life even more. If I can squeak a year out of them, I’d be one super happy camper.

Thanks everyone for the great discussion!

Checking back in with some empirical findings, if anyone is interested…

I have had the above (described up above there somewhere up there) configuration running since about September 18th-ish (the day before I left for the Kentucky Bourbon Festival) and I check the batteries this morning. Both are still showing slightly above 4V, which is VERY impressive and VERY promising for battery life!

Summary: Imps wake up from deep sleep every 5 seconds (which I’m planning on extending to 7 seconds) and read the ADC which has an ambient light sensor on it. ONLY if the value has changed by X amount from the last read, the Imp will wake up the WiFi and send the latest reading and some miscellaneous other bits of data to the agent which then sends that JSON on to a Node.js server with an API and a client app. It’s been doing this all that time and the voltage on the LiPo batteries has barely been touched, which is awesome.

So I’m looking into doing something similar with a garage door. Rather than run AC to it I’d rather power from batteries… if our cold winters allow for decent battery behavior. Anyhow, I’m thinking about doing something similar with deep sleep except to wake every 30 seconds or so, check state of door, check temp sensor, and battery voltage. If the door has changed state I’d like an instant iphone notification with prowl (which I have working). Every couple hours I’d like to email other temperature data to my own logger.

When you are using deep sleep above, it isn’t paired with server.expectonlineat(). I thought it should be, but when you don’t exactly know at what time it will be back online (in the case of the garage door opening or closing) how is this to be managed? What sort of errors could I experience server side?

Also, do I assume WiFi is turned back on with a simple agent.send call? I don’t really see any explicit exiting of power save mode in the example above.

Anything that requires talking to server will bring WiFi back up, including server.log. Do you not want to control the door, just monitor it?

Just monitor for now…

It sounds like you need to do two things. You can put the Imp into deep sleep, and schedule it to wake regularly to handle those events. When the door opens, you’ll want a switch or sensor connected to Pin 1 to drive it high. That will wake the Imp from deep sleep and you can handle that specific event. using hardware.wakereason(). If you write up a how you want the events to flow, we can suggest some code.