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. :)