LiFePO4wered/ESP32

ESP32

I'm using the ESP32-WROVER-I with external antenna for this project to take advantage of the PSRAM.  Downsides are large physical size and losing two GPIO.

Ethernet PHY

The LAN8720A works well on the #wESP32, is well supported by the ESP32 tools and is readily available at low cost in the Chinese market so I'm sticking to it for this project as well.

I have been considering moving to one of the PHY clocking modes where the ESP32 outputs the PHY clock instead of using an external crystal oscillator.  Firmware support for this seems to be improving.  But the most common way to do this is by using GPIO16 or GPIO17, which are not available on the ESP32-WROVER module because they are in use for the PSRAM.

Another option is using GPIO0 for clock output instead of input, but that seems to be less well supported, as can be seen in the MicroPython patch lined above, where it is disabled.  Alas, I think I'll keep the oscillator for now.

PoE chip

Same for the PoE power chip, I'm sticking with the SI3404A used in the wESP32.  I've been looking at the TPS23755 as a possible replacement that does away with the need for an opto-coupler, but considering this is a new part that I haven't tested yet and that is not as common in distribution, and considering there's enough to figure out and plenty of risk on the charger side of this project, I have decided to pick my battles and go with a proven solution for this part. :)

Charge / system controller

In the custom design that is the inspiration for this part of the project, I was using the NXP MK02FN64VLF10.  This is a pretty powerful Cortex-M4F running at 100 MHz and probably overkill, but a good safe core with plenty of margin for developing something new.

The excellent voltage reference and 16-bit ADC with several differential inputs were the most important features I was after.  I had added optional current sense amplifiers to make sure I would be able to measure the minute voltages across the 0.001 ohm and 0.02 ohm current sense resistors accurately enough, but it turns out they aren't needed--the ADC by itself does the job just fine!

It also has a great supply voltage range of 1.71 V to 3.6 V, which perfectly matches what we get from a LiFePO4 or LTO cell.  When I designed in the part, I also assumed it would give me 100 MHz PWM clock, but the devil is in the details.  What in the PWM peripheral's documentation was called the "system clock" turned out to be the controller's "bus clock", which is half the actual 100 MHz system clock.  Thanks for the confusing docs, NXP.  Still, the charger worked just fine at 50 MHz and I didn't need the extreme PWM accuracy I had been aiming for.

For the LiFePO4wered/ESP32, I'm scaling down this part to the lower cost MKL17Z32VFM4, a 48 MHz Cortex-M0+.  It shaves about half a dollar off the 10K cost, is still plenty powerful for what I need, seems to have more low-power optimizations (it's an "L" part), has a similarly great ADC peripheral, and is in the same family so I can re-use a bunch of the code I have.

The biggest downside seems to be that the PWM signals for driving the buck converter MOSFETs will have lower resolution (PWM clock of 24 MHz), giving less accuracy in maintaining maximum power point.  But I think it will still be sufficient.

Buck/boost converter

To generate the regulated 3.3 V for the ESP32 and external customer circuitry, I need a buck-boost converter to generate this voltage from a possible input range of ~2 V to 3.6 V.  Looking at current requirements, part cost and availability in China, the TPS63020 seems to be a good option.  It should be able to deliver 1 A from even the lowest expected input voltage of ~2 V, while offering decent efficiency across the whole range.

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:

• Unlike with the CN3801, where the MPP voltage for a particular solar panel needs to be configured with a resistor, this would provide automatic MPP tracking using a perturb and observe approach.  Just connect any power source, even a weak one like a solar panel, and it will work with maximum efficiency.
• Set points that are software configurable over the I2C bus for things such as battery charge and discharge voltage thresholds, maximum charge current, temperature thresholds, ...
• Battery, power system and temperature measurements that are readable over the I2C bus for smart system management and remote monitoring.
• Since the system is continuously measuring incoming and outgoing power, it may be possible to offer a coulomb counter based battery gauge.  To be developed, don't hold your breath. :)
• Since charge and discharge thresholds would be settable, this would make it possible to also support Lithium Titanate (LTO) chemistry batteries in addition to LiFePO4!  I've been looking at providing this option for a while now.  If you're not familiar with them, LTO batteries are like LiFePO4 on steroids and unmatched when it comes to battery life (>10K cycles) and ruggedness (charge/discharge at any outdoor temperature).
• It would be possible to monitor both on-board temperature and, if available, battery thermistor temperature.  Use the thermistor to control charging if it is available, but use on-board as a fallback if there is no battery thermistor.
• Battery heater control, and the power applied to the heater could automatically match incoming power so it's MPP tracked as well.
• Now there's a micro, we can have a smart low power system manager and can easily implement things like low power sleep modes with wake timer or wake on certain events, and have software control over whether the 3.3V power or the Ethernet PHY should be on or not.  All of this controllable over the I2C bus from either the ESP32 or another connected micro, which means no lost GPIO pins.
• Since we lose some ESP32 GPIO due to the PSRAM and we already didn't have that many because of what is in use by the Ethernet PHY, we may be able to use the micro as a GPIO expander.
• My own IP versus relying on a single-source Chinese vendor.  In these times where chaos rules, that might be prudent.

Of course, there are some downsides as well:

• Likely more costly.
• New / untried technology.  We're much more likely to run into some issues during development and need a respin.
• Will take significantly longer to develop the hardware compared to copying the CN3801 circuitry I already have.
• A good chunk of firmware development is needed.

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?

Since this board is squarely aimed at professional IoT deployments, my first inclination was that this would be a bring-your-own-battery type board like the #LiFePO4wered/Solar1.  Customers will most likely deploy this in the field with a sizable LiFePO4 battery such as a 10Ah or 20Ah cell, to be able to bridge many gloomy days when solar powered.

However, some users might be able to get away with much smaller cells.  This isn't just a solar board--when powered by PoE for instance, it's more likely there will only be short power interruptions and power will be present 99% of the time.

Also, since LiFePO4 cells aren't as common in the market as consumer-level lithiums, and I hope to eventually launch this as a product on Crowd Supply, I have to consider market appeal, out-of-the-box experience and ease of development as well.  I need to lower the threshold for adoption as much as possible.

So I'm leaning toward providing an on-board battery option too.  Looking at the #wESP32 for the basic floor plan and holding an 18650 battery holder by it, this is likely going to make my life difficult. :)  Considering the location of through-hole parts such as connectors, headers and Ethernet jack, the isolated PoE power island, and mounting hole options, there's really only one place where an on-board battery holder can fit.  And it's going to put one of the battery terminals in the opposite corner of the board from where the rest of the power system will most likely live.

But, I think it will be doable.  A long battery trace isn't going to be as big a problem on this board as it would be on a #LiFePO4wered/Pi+ for instance, because we're working with lower currents.  The ESP32 isn't nearly as much a power hog as the latest Raspberry Pi's are!

What do you think?  Should I go for it?

Initially, my customer who's driving this project wanted to know how he could combine the #wESP32 with my #LiFePO4wered/Solar1 to have a single LiFePO4 based supply that can be powered from DC, solar, or PoE.  He sells smart city IoT products and it turns out everyone has different requirements and availability of power sources, so his products need to be able to take pretty much anything.

Unfortunately, combining the existing wESP32 and LiFePO4wered/Solar1 in a sensible way isn't really possible.  The problem is that while the wESP32 power output could be used as a charging source for the LiFePO4 battery, it produces its own 3.3V to power the ESP32.  It was never created to accept back-power on the 3.3V rail.  So, the ESP32 would only run when PoE was present, and not from the battery, which defeats the whole idea.  While talking to Crowd Supply about the concept (they had been asking if I had any new products in the pipeline), they suggested making a wESP32 variant that would make this possible.  But I did not see a good way to do this, so that it would work both stand-alone and in combination with a LiFePO4wered/Solar1.

Also, I prefer to create well-designed products that work well and make things really easy for the customer, and hacking together a wESP32 and LiFePO4wered/Solar1 did not appeal as a quality product.  Additionally, it would pretty much preserve the status quo, and not push technology further.  Where's the fun in that? :)

So, the idea to create a new product was born.

Power only, or more than that?

I initially explored the idea that this would be a power-only board like the LiFePO4wered/Solar1.  However, it became quickly obvious that this was not really possible, if one of the power sources would be Power over Ethernet.  When you have this Ethernet connection running to your system, it doesn't really make sense to not use it for communications as well.  One option would be to just run the TX and RX pairs to a header and let the customer deal with them if they want to use Ethernet comms, but since these are high speed signals requiring controlled impedance, this seemed like asking for trouble.  It would also push the Ethernet complication to the customer, which goes against my product philosophy.  I prefer to pull technical difficulties onto my board so the customer can focus on their application.

Since these things had already been taken care of on the wESP32, it makes sense to provide the same ESP32 based functionality on this board as well.  The ESP32 Ethernet works great and it's just an awesome, well supported and low cost platform that many makers are already familiar with.  So why change?

So, which ESP32?

Having settled on making this an ESP32 core board, the next question became: which ESP32?

I could stick to the ESP32-WROOM module used on the wESP32, but when deploying this in the field, my customer would need an external antenna for WiFi and Bluetooth.  There is the ESP32-WROOM-32U with U.FL connector that would offer a size advantage.  But in talking to ESP32-using customers it had also become obvious that available memory would become tight when using the BLE stack or a high-level firmware like MicroPython.

So I'm tentatively designing in the ESP32-WROVER-I module, which provides PSRAM and a U.FL connector.  Unfortunately, Espressif didn't do the sensible thing they did with the ESP32-WROOM-32U and remove the antenna part of the PCB for this external antenna option.  The size of this module is a big disadvantage since the unused PCB antenna is still going to take up space.

GPIO header

My initial goal was to keep the GPIO header the same as the one on the wESP32, but I may need to shelve that idea.

First, the ESP32-WROVER module uses the IO16 and IO17 signals internally for the PSRAM.  On the wESP32 they are used for the MDIO and MDC signals to the Ethernet PHY, so these signals will have to be assigned to different IO pins, IO pins that now won't be available on the GPIO header anymore.  Darn.

Second, the customer wants to have both the battery voltage and regulated 3.3V available on the GPIO header.  Understandable--this provides maximum flexibility for the user.  Even if my customer didn't decide they wanted it, I probably would have done this.  The wESP32 provides a high voltage power output (12V) and 3.3V.  On the LiFePO4wered/ESP32, we'll have the power input (DC or solar or USB or PoE, 5-28V), regulated 3.3V and battery voltage.

So we'll have to see about GPIO compatibility with the wESP32 and what's possible.

Screw terminals

On the LiFePO4wered/Solar1 I provide solder pads for the external connections.  But I think to ease deployment, it will be much easier for a customer to be able to use screw terminals for the battery and power connections.  So I want to use solder pads that are at least compatible with screw terminals for this product. :)