Power. Faced with the design challenges of keeping things that don’t sleep awake as long as possible. One of the more intriguing aspects of the Flavonoid project has been to find ways that it can stay active and recording without it requiring a large, heavy battery. This battery here — the “Powerizer” — is about as big as I want to get. I also have some “flat-pack” style LiPo cells that might work well. The Powerizer is an industrial 3.6v 650mAh cell. Here Flavonoid is drawing about 18mA while recording data — the A2D converter is on and pretty actively sampling, the I2C/TWI bus is running frequently reading the time from the real-time clock. And every 15 seconds the LED blinks for a moment just so I know its alive. It’s also running a command line console interface over USB, so the FT232RL RS-232<->USB chip is spun up.
One problem I faced — still facing — is how to recharge the battery, which is basically “fixed” (non-removable, or only removable by removing soldered connections.) The design presently uses the Maxim MAX1555, which a chip that will charge a single LiPo cell over USB or from a +5 volt, higher current source, about 200mA, whereas USB will max out at 100mA. My laptop’s USB port won’t charge at more than 80mA at best. The idea here is that USB charging would be more convenient than having another wall plug and wire running around. Since the Flavonoid uses USB for configuration and downloading data, you’d have it hooked up over USB anyway. I assumed USB would be fine, and generally it is. But the times that I’ve tested the Flavonoid’s ability to run for a couple days, the battery went way low — 1.8v — and I had to recharge it from the higher current +5v source. Getting the Flavonoid to charge in the flat-battery circumstance is tricky. Presumably, since there’s no on-off switch, the Flavonoid is trying to start up, which draws a modicum of power, making it more difficult for the battery to just chill and charge.
What’s the alternative? Well, the immediate fix is to keep the Flavonoid plugged in at night so it maintains its charge. And I’m looking at adding a battery monitor (Maxim MAX6439) that will be able to let the Flavonoid microcontroller know when the battery voltage drops to a certain level. There’s built-in hysterisis so the battery needs to go above a specified voltage before the MAX6439 will let it know that its back in some kind of nominally revived state. The thinking here is that the battery monitor could trigger a pin-change interrupt that would put the Flavonoid to sleep so it draws barely any power at all. When the battery is back to normal, it’ll come back to and carry on as usual.
Have you considered using smaller batteries of the same total volume and flip-flop the batteries? In this arrangement, one of the batteries is always charging while the other is powering the RTC and the rest of the board. I use LiPo cells (flat pack Union batteries) ranging from 100mAh to 2000 mAh for most of my battery operated projects. I was putting together a project one day and didn’t have one of the 2000 mAh batteries that I needed, so I decided to use 2 1000 mAh batteries in parallel. The project wasn’t a big power user (120 mA peak), but I like the fact that the larger capacity batteries give me very long run times between charges. While hooking everything up and trying to figure out what the discharge/charge cycle was going to have to be, I realized that charge time for one cell (using a MAX1555 and USB power) was less than discharge time. I was also in trouble at that point because the MAX1555 is designed to charge a single LiPo cell and I’ve learned that with LiPo cells you follow the rules or you risk your project (and possibly your work bench). So with a couple of changs to how I use the battery monitor in my code and a bit of rewiring, I was able to reduce the power requirements when the operating battery reached a low threshold, switch in the fresh battery (still in parallel as far as the project was concerned) and switch the now depleted battery over to charge. I still have some problems with this setup if the project runs at peak for too long. The discharge time is less than the charge time and it switches to a not fully charged battery. The whole project then goes into what I call battery pendulum mode. The maximum voltage in both batteries will eventually get to the low voltage tthreshold and the only thing going on is battery swithcing. I’ve partially solved the problem by utilizing the small LED on the breakout board of the MAX1555, The LED goes out when the battery is fully charged. I placed a photodetector on the board and when the LED goes out, I log the date/time (project has a GPS receiver that provides date/time data). When I detect a battery low threshold and go into the battery switch routine, I compare the current date/time with the stored charge end date/time and log the difference. If the discharge time gets too close to the charge time (time representing “too close” still being determined). I have to make a decision to reduce power or call for help (alarm to indicate that the system needs to be plugged into a proper wall wart for a while to top off both batteries.
That’s a good idea. I actually ended up knuckling under and adding a 12mm coin cell battery holder to the design so that the RTC would continue to keep time even if the battery went flat. I also went a bit bonkers and added a bunch of things to the power management part of the design — easily over design in hind sight, but I wanted to button the thing up.
Details are here:
http://www.nearfuturelaboratory.com/2007/09/06/the-benefits-of-zealous-design/