I received the PCB assembled by PCBWay. The board looked great, assembly quality is excellent. After a complete test session, the board already has several straps and modifications. This is the fate of any prototype: direct confrontation with hardware reality. 

All critical subsystems (buck, supercap, LoRa, I²C, MCU, watchdog) are validated.
Despite the modifications made, the current board enables almost complete firmware development and should reliably support the first real-world tests.

Hardware test program is available on my GitHub: https://github.com/Bertrand-selvasystems/LoRaTube_V3_PCB_Test

This prototype clearly calls for a version 4. I've listed the required changes as I went along. All modifications aim for further simplification: fewer components, a simpler architecture.

Mechanical fit

It must fit into the 50 mm tube (otherwise it’s no longer LoRaTube). And it does. It’s tight, but OK.

First Power-Up and Power Rail Changes

At first, nothing worked: the MAX16956AUBA/V+ buck provided permanent 5 V, the TPS62840DLCR gave 3 V, but the supercaps wouldn’t charge. Direct start-up on empty supercaps was impossible without manually toggling EN (using a signal generator) after precharging them manually. After precharging to about 3.7 V, EN_TPS2553 started working via PWR CONTROL, with currents around 220 mA at 12 V.

Comparator TLV6700 — Threshold Verification

The TLV6700 was not handling EN_TPS2553 correctly. Measured voltages:

Node	Measured (V)	Vcap (V)	Divider Ratio	Equivalent Threshold (V)
U4_3 (INA+)	0.318	3.80	0.0837	≈ 4.78 V
U4_4 (INB−)	0.305	3.80	0.0803	≈ 4.98 V

Pull-up R26 was suspected (too high impedance), keeping the comparator output stuck at 0 V.
I soldered a resistor in parallel with R26 and I swap the resistors between INA+ and INB− entries as shown in the photo.

After swapping INA+ and INB−, the problem persisted — EN output was still stuck low.

Other mistake : The SN74AUP1G32DBVR (logic OR) was powered at 5 V, though rated only for 3.3 V — a design mistake. Yet, when forcing PWR CTRL high, EN responded correctly.

I later realized the root cause: a fundamental logic flaw. The dual comparator alone cannot hold a hysteresis (no latch). Expected behavior:

• Enable EN_TPS2553 when voltage < 4.78 V.
• Keep ON until 4.98 V, then disable.
• Let voltage drop naturally to 4.78 V, then restart charge.

A latch is required to achieve this, and it was missing. It's a design mistake...

To continue testing, I connected MAX16956AUBA output directly to the supercap. Current rose to 220 mA @ 12 V during initial charge, then tension stabilized around 5.01 V and current become very low.

For V4: Remove current regulator, comparator, and logic OR. Leave MAX16956 in SKIP mode — direct charge. 85 mA charge current @ 30 V (TX/recharge phases) → OK 
MAX16956 rated 300 mA continuous / 500 mA peak — acceptable for duty cycle.
Improve thermal dissipation around MAX16956.

TPL5010

A MCU GPIO was supposed to drive the DONE input of the TPL5010 watchdog (“service dog” function). The LED associated with the DONE line, supposed to indicate MCU activity, remained constantly on. When measuring the voltage, there was an oscillation between both states, at a frequency of a few tens of kHz.

Pin 31 of the ESP32-C3 MCU is TXD0 (U0TXD), which is a UART output (push-pull, idle high, and “talks” at boot and in log mode). It is impossible to distinguish a true “service dog” activity from simple UART flood: the pin must be changed.

I still, for testing, short-circuited the TX0 output with a 47-ohm resistor (borderline for the health of the pin), just long enough to verify that the TPL5010 correctly cycled RSTn. And it does, with a period of roughly 1 minute – so that part works.

The behavior is completely validated: when DONE is “tickled” by UART0, RSTn never goes low.

For version 4: Add a 100 k pulldown, add a 1 k resistor between the MCU and the DONE node, and use another pin than TX0 for DONE. Add test pads for RESETn, DONE, and WAKE. Also add a jumper on RESETn to disable the reset function when inconvenient (for example during ESP32 flashing).

Controlled voltage divider

A permanent, very high impedance divider would also work for low energy cost.

VBUS (0...40 V) ── Rtop ──●── Rbot ── GND
                          │
                          100 Ω
                          │
                          ADC_in
                                   
                          │
                          Cfilter (47–100 nF) to GND

Node	Rtop (Ω)	Rbot (Ω)	Vbus (V)	Vout (V)	Loss (µA)
ANALOG1	10.2 M	680 k	40	≈ 2.5	≈ 3.7

For version 4: I propose to replace this with a static divider for 30 V and remove the other divider, since now the supercap is always powered. This goes in the direction of simplification. It was a lot of components for negligible gain.
ANALOG1: 10.2 MΩ / 680 kΩ → 40 V → ~2.50 V; ~3.7 µA. 22–47 nF to hold the node’s value. A large 1206 resistor will probably be required for the 10 MΩ – not a problem.
ANALOG2 is removed for simplification and to free the GPIO.

MCU and USB

The ESP32-C3 was alive from the start, chattering on UART0 (and therefore breaking the DONE logic for the 5010).  

Otherwise, everything works perfectly: with the flash toggle switch, I can start the ESP32 in flash mode. I uploaded the first “hello world” firmware without any issue. It runs fine, and USB logs work as expected.

For version 4: Move DONE and WAKE, remove the analog input pin for the 5 V bus, and remove the comparator output. New pin assignment: DONE on IO04, WAKE on IO05.
And it will be necessary to have two solder pads and a jumper to quickly disconnect the MCU power supply.

RTC PCF8523 and WAKE

The RTC responds correctly at address 0x68 as expected — it works. I had placed a SN74LVC1G06DBVR inverter on the WAKE line of the TPL5010 to match the logic levels with the WAKE output of the RTC. I realized that when I connected the RTC, voltage dropped to 1 V on the WAKE node. Without the RTC, the output of the inverter was at 2.97 V.

Actually, the SQW pin of the RTC is shared between ALARM and CLOCK (square wave) functions. I had to call the function pcf8523_make_sqw_hi_z() to make the node return to 3 V.

For version 4: Remove the inverter, disconnect WAKE from the RTC, and increase the ESP32-C3 wake-up period to 1 hour via the 5010. I lose the precise “wake at a specific hour” feature (potentially useful for logs), but I simplify the wiring and remove one component.

The logging process would then proceed as follows: 

1/ ESP32 exits deep sleep (TPL WAKE GPIO).
2/ Reads the current time from the PCF8523 via I²C.
3/ If the day has changed (compared to a stored day_last value in FRAM/NVS) → perform logs and daily tasks.
4/ Sends DONE to the TPL5010 and returns to deep sleep.

As a result, I lose exact midnight logging, but logs will still occur around midnight ±1 hour, while removing the inverter and simplifying the design.

Power switch E22

The function works correctly: if I force RESET_E22 to GND, the power rail discharges with a first-order decay, as expected from the 56k resistor I placed between its output and ground. However, I made an error during testing by shorting the output, and I burned the chip. I then continued testing by shorting the input and output of the TPS22917.
No big deal — its correct operation had already been validated.

UART and E22

E22 responds correctly to commands and operates as expected.

PCA9536DGKR Multiplexer

Works as intended.

For V4: Remove red/orange LEDs,
move DONE LED on the multiplexer,
add pulldown on MODE (MAX16956) and link to the multiplexer output for “eco” control.

FRAM and level shifter

After adding the FRAM breakout board, I realized it did not work. It remained silent — the I²C scan could not detect any device (see the test firmware on my github). After checking the wiring, I confirmed that pullups were present on the FRAM side of the BSS138. But the circuit requires pullups on both sides. Still, it works for the multiplexer on the same I²C bus.

Why not for the FRAM? With only internal pullups on the MCU side, the rise time is probably too slow, keeping the BSS138 half-conducting. That creates ambiguous logic levels and no ACK.

I continued without the FRAM.

For version 4: I’m questioning the “level-shifter” approach using BSS138 in terms of leakage current. Moreover, the fact that it doesn’t work right now adds risk for the next revision. I plan to replace it with an SN74LVC2G66, a bidirectional analog switch. It’s widely available, inexpensive, easier to wire, and guarantees zero leakage.

Transmission test

Full-power TX without buck:

• Supercap voltage drops from 4.97 V to 4.68 V in 10 s (ΔV ≈ 0.29 V).
• Capacitance = 20 F → average current ≈ 0.58 A.
• Extracted energy ≈ 28 J per cycle.

Considering pauses between bursts, the maximum expected current around 1 A matches the 0.58 A average observed.

Measured noise (pk-pk)

Location	Mode	Noise (mVpp)	Comment
After decoupling	RX	16	Clean
After decoupling	TX	120	Clean
Before decoupling (on supercap)	No TX	24	Clean
Before decoupling (on supercap)	TX	264	Normal di/dt burst

After decoupling, the VCC rail is clean in both RX and TX. No critical spurs appear on the FFT (the x-axis spans from 0 to 26 MHz with 2048 points, giving a frequency resolution of approximately 12.7 kHz). 

Note: my oscilloscope bandwidth (100 MHz) likely underestimates the real noise. The FFTs reach a maximum frequency of 26 MHz, so I don’t observe the full spectrum. The following figures show the typical spectrum shape.

The supercap itself exhibits relatively high raw noise, but it is efficiently filtered locally by the decoupling capacitors of the module.

For version 4: A power-grade ferrite bead (≥ 100–220 Ω @ 100 MHz) could be added between the E22 module and the supercaps. However, this is not strictly necessary: the measured noise levels are low and do not degrade the module’s RX/TX performance.

Consumption

Idle (“floor”) current

Vin (V)	Iq (µA)	Power (mW)	Annual (Wh)	on 500 Wh (years)
30	218	6.54	57.3	8.7
25	182	4.55	39.8	12.5
20	142	2.84	24.9	20

At high Vin, the buck converter’s quiescent losses dominate (8–9 years at 30 V, 20 years at 20 V). In practice, considering the voltage decay of the LR20 battery pack, a autonomy of about 15 years is expected from the “floor” consumption alone.

To this, we must add the consumption of all peripherals, on which the energy management strategy has a direct impact (see previous logs). Based on these preliminary results, multi-year autonomy is guaranteed.

Low-power assumptions (no transmission)

• ESP32-C3 deep sleep: ~40 µA
• E22 LoRa in WOR 2s: ~20 µA
• FRAM: off most of the time → negligible
• PCA9536 / SN74LVC2G66: idle ≈ 3 µA
• PCF8523 (low-power, Vbat): ~2 µA
• MAX16956 buck “floor” current: 142–218 µA

Total idle current: 207–265 µA depending on Vin. That gives roughly ten years of autonomy excluding transmissions — not bad at all.

Planned modifications for version 4

• Remove TPS2553 + comparator + OR AUP1G32
• Charge supercap directly via MAX16956 (SKIP mode, keep input diode)
• Replace BSS138 (I²C) with SN74LVC2G66
• Fix TPL5010 (dedicated DONE pin + series resistor + pulldown)
• Add test pads (RESETn, DONE, WAKE)
• Add thermal pad / copper pour for MAX16956
• New MCU pin mapping: DONE → IO04, WAKE → IO05, drop 5 V analog divider
• Disconnect RTC ALARM → WAKE MCU (remove SN74LVC1G06DBVR)
• Add jumper to fully disconnect MCU power
• Add jumper to disconnect RESETn from TPL5010 (avoid reboots during flashing)

Conclusion

Despite the design errors, the overall assessment of this V3 is very positive.
The expected ultra-low power consumption, compatible with several years of autonomy, has been achieved (between 265 µA and 207 µA estimated on average, excluding transmission).

The RF noise level is well controlled, and at its current value, it should ensure optimal operation of the LoRa Ebyte E22 module.

The power supply has been simplified, with fewer components and a more straightforward architecture. At the heart of the system lies the MAX16956 buck converter, borrowed from the automotive world — the true keystone of the LoRaTube. It perfectly matches the device’s requirements (high entry tension) and operates with a very low quiescent current.
The planned simplifications will further reduce costs and improve reliability.

Most peripherals work as intended — except for the FRAM (issue identified) and the active voltage dividers (which will be removed in V4).

All critical subsystems (buck, supercap, LoRa, I²C, MCU, watchdog) are validated. None of the encountered issues are structural: no netlist error, no crosstalk, no layout fault.

Despite the straps and a few adjustments, the current board already enables almost complete firmware development and should support the first real-world tests

Next steps

• Continue firmware development on V3, 
• draw the V4, 
• and launch its fabrication.

Thanks again to PCBWay — their build quality and exchanges during production clearly helped the project move forward faster.