Close

Good and bad news

A project log for LiFePO4wered/Pi

LiFePO4 battery / UPS / power manager for Raspberry Pi

patrick-van-oosterwijckPatrick Van Oosterwijck 05/26/2016 at 18:300 Comments

First the good news: after building up my "final" prototype of the LiFePO4wered/Pi board, I was able to do some testing. It seems I managed to improve the efficiency by going to a smaller but less resistive inductor, so now I got a run time of 1:14 with a Raspberry Pi 3, with WiFi connected and an active SSH connection. My previous prototype only ran for 1:04, so that's 10 minutes extra, or 15% improvement, even though this prototype also switched to actually generating 5V for the Pi instead of 4.75V before. Very nice. :)

So I was starting to get ready to order production parts, when I ran into an unexpected problem when doing some more tests. I had been so focused on doing pure battery run time tests that I hadn't been running UPS functionality tests very much (Pi on continuously, power on and off for testing). I ran into the problem that once the battery had died, the LiFePO4wered/Pi would turn the Pi back on when power returned, it would run for a little bit, but then the Pi would turn off again. Not good!

After investigating this for a while, I've figured out what's going on. To be able to run the Pi and charge the battery at the same time, I bridge the solder jumper on the base #LiFePO4wered/USB to run it at the higher charge current of 480mA. Unfortunately the PCB is quite small and uses a linear charge controller, which generates quite a bit of heat. When the chip heats up too much, it starts to limit the charge current to keep the heat in check. It seems it limits it enough that with a high power Pi (model Bs) running as a load, the charger gets thermally limited enough that it doesn't even provide enough current to just power the Pi, so the battery discharges even when the system is plugged in.

This problem is the worst when the battery voltage is low, because in this condition the difference in voltage between the input (USB) and the battery voltage is the greatest, the power the chip needs to dissipates is the highest as well, heating it up the most. At normal room temperature, when the voltage get "over the hump" (~3.2V), the system will successfully charge the battery all the way, because the heat dissipation will reduce as the battery voltage increases.

I decided to check what would happen at elevated ambient temperature. I increased my room's temperature to 40C. With the connected Pi 3 running, unfortunately the added ambient heat was enough that a fully charged LiFePO4wered/Pi would start to lose battery charge as well.

So in its current state, the LiFePO4wered/Pi works as a UPS for the lower power Pi's (Model A+, Pi Zero), but not for the higher power Model Bs. I find this unacceptable, so I'm looking for a solution. (I haven't tested it yet, but there's a chance that the 3.2V version doesn't have this problem, because it is more efficient, allows the Pi to run more efficient (both of which reduce the current needed to run the Pi) and doesn't produce its own heat like the 5V version does.)

The quickest solution I can think of is doing a better job of sinking heat away from the charging chip. One obvious way is to add a heat sink, so I have some on order to experiment with this. I'm not sure how effective it will be since the heat sink will be sandwiched between the two boards. I could also improve the layout of the #LiFePO4wered/USB by adding more copper to help with heat dissipation, and/or go to 2 oz copper on the PCB. Another option is to make the PCB rectangular instead of having the narrow tail, again in an effort to have more mass and copper to sink heat away from the chip. An option I find unacceptable is telling users to add a fan. :)

A longer term solution would be to switch the #LiFePO4wered/USB to a switching instead of a linear charge controller. This should result in less power dissipation and would have added benefits such as allowing a wider input voltage range (not just 5V/USB). But that would likely delay this project for months, so I'm hoping improving the power dissipation will work.

Discussions