Here is the schematic for V4.

Changes from V3 / Design decisions

I changed my mind on some aspects when redoing the schematic, compared to what I had announced.

Notably, I kept the possibility to wake up the MCU via the RTC because it offers more resilience. In fact, I now have three perfectly independent ways for wake-up: 

• WAKE_RTC, with the RTC alarm; 
• WAKE from the TPL5010 (hardware watchdog); 
• AUX from the E22.

 And I no longer have an OR-wire on the wakes, which allows removing the inverter that was previously on WAKE RTC, to "read" explicitly in software the source of the wake-up, and also to offer an extra pin from the MCU for the interrupt (more resilience). All the pins for deep sleep wakeup interrupts are wired between IO0 and IO5 (the only compatible pins).

This new wake-up architecture is allowed by freeing several pins, made possible by the overall simplification of the schematic: notably, no more management of the comparator state (because no more comparator here: the 5 V buck is always connected to the supercap), no more management of the FRAM power (the FRAM was measured in idle at 9 µA, which is 0.2% of our energy budget over 5 years). So there is no need to bother managing whether the FRAM is powered or not, nor the ghost currents on I²C when it is off (that means fewer components).

Memory and logging : Fram vs EEPROM

Concerning the choice of FRAM, I hesitated a lot to switch to EEPROM on I²C. But the big advantage of FRAM is being able to serve both for logging and counting, without using the RTC RAM of the C3 (more resilient, the functions are well separated). And the absence of paging also makes the use of memory more efficient. The planned daily logs are 16 bytes and will be detailed in the next log.

Watchdog & Debugging improvements

The TPL5010 has not really changed in its implementation except that there is now a jumper to change the delay resistance. With jumper H5 activated, the resistance drops and gives delays of ~2 min: much simpler for debugging and firmware writing.

E22 interface & power rails

I added decoupling capacitors for the E22. M0 of the E22 is associated with a pull-up as before, which makes its use compatible with IO02 of the MCU (new assignment) which must be kept high at MCU startup.

The multiplexer resumes responsibility for the two LEDs present (not three as before). The green LED is always switchable by jumper (to facilitate maintenance without useless consumption). The multiplexer also manages the MODE of the 5 V buck: it will now be possible to exit the "eco" mode of the buck to limit RF noise, as soon as a first reception is detected or a transmission is in progress.

Power management and voltage adjustments

The 3 V buck has not changed except for one detail: the VSET resistor. At 49.9 k it was out of spec to start the buck at 3.3 V; it was starting at 3.0 V. I hesitated to modify it because it saves ~10% on the 3.3 V rail. At the same time, it gets me closer to brown-out in very cold weather, and the current is very low on this rail except during MCU activity periods. So I changed the resistor to go back to 3.3 V.

One of the voltage dividers has been removed. The other is always active. A C34 capacitor has been added to allow a stable reading despite the very high impedance of the divider. The R16 resistor functions to limit the current at the moment of analog sampling and to protect the ADC stage of the ESP32; it also helps dampen charge injection from the ADC’s sample/hold, and with C34, to reduce HF transient spikes.

The input stage has not changed: fuse to limit current, voltage clamp at 36 V, diode to prevent back-current and manage polarity inversion issues.

MCU I/O allocation

For the MCU, I added decoupling capacitors to better manage brownout risk. IO02, IO08, and IO09 are assigned to tasks compatible with a high state at startup, as expected for a functional boot with the C3. The serial TXD0 and RXD0 pins have been completely freed (and assigned to pins for possible debug/communication). ANALOG 1 is on IO03, which is indeed a pin suitable for analog reading.

The big change was to wire the RESETn of the TPL5010 no longer directly to the EN pin (which is now connected to a pull-up, to a C45 cap for stability, and always to the reset button) but directly to the control pin of the power-switch U30. The power-switch functions to force a "hard" reset of the MCU and all components on the 3.3 V bus: RTC, FRAM, and multiplexer. This is considered more resilient, especially as it avoids "gray" states (EN=1 with rails still unstable), imposes a deterministic cold-start after fault, and keeps all peripherals unpowered as long as 3.3 V is not clean.

For the E22 module, the R44 pull-up is taken from permanent 3.3 V: if the switched 3.3 V drops to 0 at the moment of an MCU reset, it does not necessarily mean we want to reset the E22 as well. For the pull-up on M0 it is necessary so that the E22 starts in WOR and does not "switch" on its own at startup. In reset phase, this poses a problem: it can maintain phantom powering of the E22 from the 3.3 V bus. That makes one more path, which will consume a bit. I therefore added an analog switch SN74LVC1G66DCKR which cuts the M0 pull-up when it is in reset.

Another important modification concerns the configuration of the TPS22917 load switches used to sequence the power rails for both the E22 module (5 V) and the MCU (3.3 V). The QOD pin is now explicitly connected to VOUT on both devices, which activates the integrated quick output discharge feature and guarantees a clean, rapid fall of the supply rail when the switch is turned off. This prevents ambiguous “grey states” on the peripherals, especially the radio, and ensures a deterministic reset under all power-down scenarios. The CT (capacitor timing) pin has also been dimensioned according to the total downstream capacitance: approximately 80 nF on the E22 5 V switch (for a controlled ramp-up of around 20 ms with ~670 µF bulk) and 10 nF on the MCU 3.3 V switch (for a fast but controlled ~2–3 ms ramp). These changes make the power-up and power-down sequences more robust, reduce inrush current to acceptable levels, and improve the overall resilience of the system during resets or battery end-of-life events.

Battery end of life management

Regarding battery end-of-life management: As soon as the voltage of the 3.3 V rail drops below the defined threshold (typically between 3.0 and 3.2 V), the TLV803S forces the MCU into hardware reset. This prevents any out-of-spec code execution, thus eliminating the risk of undesirable writes or corruption of internal memory or the FRAM.

Even before reaching this threshold, the firmware ensures to stop all sensitive communications: it stops LoRa transmissions and ends dialogue with the E22 module, also stops all exchanges on the I2C bus (FRAM, RTC) after writing "battery end-of-life" in the FRAM. Depending on the case, the MCU disconnects the interrupts and switches to deep sleep.

The FRAM is no longer solicited and receives no write requests, preventing any degradation or corruption in case of voltage drop. For its part, the E22 module remains passive, does not transmit or receive any data by command; it simply stays in WOR. If power drops totally, the system powers down cleanly, without imposing hardware stress. Finally, the configuration pins of the E22 (M0, M1, RESET) are maintained in a state defined by hardware pull-up/pull-down, which avoids any floating and guarantees the module remains in a stable state, even after the MCU stops.

The problem remains of end of life for the batteries (with the risk of polarity reversal, leakage, swelling, etc.). The system greatly reduces its activity and consumption as soon as the low threshold of the pack voltage is reached. But consumption is not brought down to zero. If we keep a voltage margin of 1 V, blocking at 19 V, we are left only with the consumption of the two converters (quiescent), the E22 in WOR, and the RTC + FRAM duo; under these conditions, the drop of the remaining 1 V takes about ~6 to ~28 months (wide range), which leaves time to identify and intervene. And If no intervention occurs, it's not a big deal : nothing of value is lost on the electronics side, but the risk of leaks from the pack increases at the very end of life. It is acceptable.

Assumptions for the estimation: quiescent 5 V ≈ 25–50 µA, E22 in WOR ≈ 2–10 µA, FRAM ≈ 9 µA, RTC ≈ 1–2 µA → typical total 37–70 µA. The exact kinetics will also depend on the batteries, temperature, etc.

Next steps

The PCB layout and gerbers will follow soon.