Close

Power system & Battery charger

A project log for LiFePO4wered/ESP32

ESP32 IoT core board with flexible power and flexible communications

Patrick Van OosterwijckPatrick Van Oosterwijck 08/20/2019 at 19:080 Comments

Buck-boost

In principle, the ESP32 can be powered directly from a LiFePO4 cell, as the cell voltage range perfectly matches the ESP32's recommended operating conditions (2.3V - 3.6V).  But the customer who is driving this project requires regulated 3.3V for the ESP32 and the application-specific external circuitry he is connecting.

This means that instead of a simple load switch to prevent over-discharge of the battery, we need to have a buck-boost converter because the battery voltage can be both higher (up to 3.6V) or lower (down to 2.0V or so) than the 3.3V output voltage.

UPS topology

To provide true UPS functionality, I have always designed my LiFePO4wered products to have the battery permanently in the power path, instead of switching from external power to battery when the external power fails.  Plenty of user complaints about system resets in other products designed with such a switching topology prove this is the right way to go for maximum reliability (and to be a proper UPS).  Using LiFePO4 makes it possible to do this without affecting battery lifetime, due to the low float voltage.  In my topology, no switching takes place.  External power always passes the battery and when external power fails, the battery is right there to pick up the slack.  Think of it as a giant decoupling capacitor.

The downside of this topology is that the battery (or a large cap) needs to be present for the power system to work.  This is of course not a big problem since this is assumed for a product under the LiFePO4wered brand name. :)  Also, predictable shutdowns go a long way in creating reliable embedded/IoT systems anyway.  True, an ESP32 isn't a Linux system for which a clean system shutdown is much more critical to prevent corruption.  But even an ESP32 or similar deeply embedded device can benefit from knowing when the power fails and having the opportunity to take some action.  Think being able to report the power failure to a cloud system, or finishing a write to flash or an SD card.  Or continuing normal operation for quite a long time on battery power only, and being completely unaffected by crappy input power.

LiFePO4 charger

So I'm sticking to the same battery-in-the-power-path topology for this project.  Initially I had assumed I was going to use the tried and true CN3801 LiFePO4 charging chip used in the #LiFePO4wered/Solar1 and #LiFePO4wered/Pi+ for this project as well.  After all, it has been working very well in those products.  But there is another option to consider this time.

I have been working on a proprietary system for a customer that implements a microcontroller based MPPT charger.  The customer has graciously allowed me to apply some of the IP to other products, as long as they don't compete in his market.

Now his system is a bit different because it uses a boost topology to charge the battery from a single solar cell with ~0.5V output voltage, while in this project, I'd need to use a buck topology to charge the battery from 5-28V input.  But some of the IP could still be applied.

There's a good list of advantages in taking this approach:

Of course, there are some downsides as well:

Since I like to push my technology forward instead of being stagnant and just repackaging the same stuff, I am leaning heavily toward going the microcontroller charger route. :)

Any thoughts, comments?  Anything you need that would become possible with a separate system/power manager micro?

Discussions