Bring-up of LoRaTube PCB V4

V4 is good enough to start firmware work !
This log takes stock of the bring-up: what works, what still blocks, and what will be fixed in V5.

Power, Supercap and Precharge

On the power front, the foundation is solid: the 5V comes out as expected, and the nominally 3.3V rail is currently about 3.0V. This is actually good for consumption, but offers less brownout margin. Still, in the current configuration everything starts and runs fine. To recover a true 3.3V, for V5 just set R45 to about 267kΩ.

The 5V supercap performs exactly as intended: at 33dBm TX, the buck handles E22 bursts without flinching. On a generous burst of 1000 characters, cap voltage only drops from 4.91V to 4.79V, showing that the buck supplies its max 500mA and the supercap delivers the rest (about 700mA at 33dBm TX).

However, an important point was confirmed for power-up sequencing: if you try to start with the supercap at 0V, the buck sees a near-short, goes into protection and collapses. By precharging the supercap to ~4V before enabling the buck, everything latches instantly and the system stabilizes. V5 will have to integrate this behavior in the power-up strategy (not sure yet how).

How I Measure Power Consumption: Reading the Supercap

To quantify power consumption, especially in ECO mode, the only truly reliable method is to watch the slope of the supercap voltage over time.

The buck does not draw a steady current: it operates in recharge bursts spaced by a few minutes. Between bursts, current seen at the battery pack drops to about 3.4µA (buck off). In that phase, the supercap supplies the 5V rail.

I ≈ C × ΔV / Δt
with C ≈ 20F for the supercap.

E22 NORMAL mode + ESP32-C3 on:
Measurements: 5.10V at t=0s and 4.91V after 240s. The 0.19V drop over 240s corresponds to an average current of:
I ≈ 20 × 0.19 / 240 ≈ 15.8 mA
Which is in the 16–18 mA range, consistent with what is expected for TX/active mode.
E22 WOR mode + ESP32-C3 on:
Same method, 5.06V down to 4.992V after 120s, i.e. 0.068V drop.
I ≈ 20 × 0.068 / 120 ≈ 11.3 mA
Which matches the announced ~11 mA.
WOR + ESP32-C3 deep sleep:
Measures go from 4.915V to 4.907V over 330s (8mV drop):
I ≈ 20 × 0.008 / 330 ≈ 0.000485 A ≈ 485µA
So about 480µA in “deep idle” (C3 deep sleep, E22 in WOR, RTC & FRAM powered). Theoretically, with no TX, this gives several decades of autonomy on a pack of 19 LR20s at 18Ah (513Wh). In reality, the cells will die of old age before they run out.
Exactly the goal: hardware is no longer the limiting factor.

From the Pack’s Point of View in PWM Mode (no ECO)

With the buck in classic PWM mode (ECO disabled), pack-side measurements confirm the orders of magnitude but the buck’s quiescent current in PWM mode is very high.
With C3, RTC, FRAM and E22 in RX: current is about 9.44mA @ 25V.
Switching E22 to WOR drops it to ~7.62mA.
By difference, E22 in RX thus consumes about 1.82mA @ 25V, i.e. about 9mA @ 5V : matching the module datasheet and the current calculated from the supercap voltage drop.

The C3 itself, active but idle, is around 2.82mA @ 25V, i.e. ~22mA @ 3.3V (about 70mW). No surprise here either.

Power Rail Noise: PWM vs ECO

I re-did noise measurements with a T3100 probe and a proper ground spring. This completely changes the result from my previous bring-up, where the probe ground was hacked and grossly overestimated the noise (especially in TX, where I picked up noise from the LoRa module’s RF emission).

In WOR mode, buck in ECO, noise on the 5V rail is between 0.8 and 1.6mV peak-to-peak. This is excellent. At 33dBm TX, still in ECO, it climbs to about 6.4mV p-p, with occasional peaks around 7.2mV. Switch the buck to PWM, and you get up to about 8mV p-p. Paradoxically, it's a bit noisier (juste a little bit).

But it’s still very, very good. In all cases, the measured spectrum stays clean, flat, no significant spurs. Conclusion: dynamic buck mode control via PCA9536 expander brings nothing for noise. ECO mode will be the nominal config for consumption, and software control of the buck mode will likely be dropped in V5.

ESP32-C3, I²C Bus, RTC, Expander and UART

On the digital side, everything is OK.

The ESP32-C3 boots and flashes without trouble, logs work, test program hits all the essential hardware blocks and behaves as intended.
The I²C scanner detects RTC, FRAM and PCA9536 expander correctly. Communication is stable, even over time.
On the RTC, register read and write works, CLKOUT is cleanly disabled, and the SQW/INT line is now well-managed: put in Hi-Z when needed, no weird levels or parasitic leakage like during V3 bring-up.
The PCA9536 initializes with no surprises; outputs GP0–GP3 drive E22 power, both LEDs, and buck 5V mode. For V4, this last point is useful for ECO mode characterization, but the final firmware will probably just use a hardware strap.
Radio side: UART1 at 9600 baud works after fixing a missing solder on RX (I'd forgotten to solder the center pin of the E22’s female header). C1 00 07 command returns a header and seven coherent parameter bytes, which validates the C3 ↔ E22 link. TX power register writes work, and a full-power TX test with 1000-char bursts, 2 seconds apart, passes with no issue.

VSENSE: Measuring and Calibrating Pack Voltage

The pack voltage measurement uses a divider (10 MΩ / 680 kΩ) behind an input diode (about 0.5V drop).
I swept the pack voltage from ~13V to ~31V and logged for each plateau: average of raw ADC readings (moyenne_raw), max-min spread (ecart_raw), and actual voltage via DMM. The ADC has a noise of a few LSB (which increases with pack voltage), but the overall trend is very clean despite the high divider impedance, probably because measurement is slow.

On the plot: mean raw value (X), pack voltage (Y), noise shown as horizontal error bars (half-width xerr = ecart_raw / 2). Points line up well, justifying a polynomial fit.

In Python, a simple 2nd order numpy.polyfit gives:

V(K) = -1.60420846e-7 * K² + 1.19180720e-2 * K + 6.02492535e-1

where K is the raw ADC value. This law matches closely what I had estimated “by hand”; numerical fit confirms and refines the digits.

In embedded C, it will be:

double adc_to_voltage(double K) {
    return -1.604208e-7 * K * K
           + 1.191807e-2 * K
           + 6.024925e-1;
}

The final firmware will use this law directly to convert ADC readings to pack voltage.

Mechanical and Thermal Integration

Mechanically everything is OK. The PCB fits cleanly into the PVC tube with the 3D-printed endcaps, all in line with the LoRaTube concept. Everything is secure and seems well-arranged.

Thermally: Continuous TX tests (33dBm, 1000-char frames, 2s pause, several minutes) show the 5V buck just gets warm. The PCB under the converter heats up by a few degrees, barely perceptible to the touch. No hot spots; dissipation appears sufficient for long-term use.

What Doesn't Work (Yet) & What I’ll Change in V5

TPL5010: Logic Fine, Integration Needs Rework

The TPL5010 behaves as expected: it generates periodic resets, and the frequency matches the delay resistor value. The problem is the chosen configuration. With the current R4 (jumper-selectable: can set ~1h or ~900ms), we get about a 900ms period, which is too short to boot the system, initialize all peripherals, and perform a realistic work cycle between resets.

Another issue: to force a new R4 value, I currently have to short the 3.3V buck output so it reboots and reads the new delay. Not acceptable. In V5, R4 will be raised to ~22kΩ for a ~1 minute period, and TPL5010 power will be behind a jumper or switch for easy disable during development — no more violence to the 3.3V rail.

2A Fuse: Too Optimistic

The 2A input fuse turned out to be too optimistic. It blows during initial supercap charge, even with reasonable current limiting, simply because inrush and recharge peaks exceed what it can handle. In steady-state, we’re well under 1A (e.g., TX tests show ~110mA @ 25V at the pack, or 500mA from the buck @ 5V, leaving 700–800mA to supercap charging), but what matters here is the “precharge” peak. That’s likely when it fails. Once shorted, everything works but there’s no protection.

For V5, I’ll use a time-lag (slow-blow) 5×20mm, T 3.15A, 250V fuse. This gives a comfortable margin for average current, handles supercap and TX burst surges, and still protects against real downstream shorts.

M0 Control on E22

M0 control via an analog switch was a bad idea, plus wiring was botched. The goals were: force default WOR mode at power-up, avoid any backfeed to the E22 MCU via that pin during hard resets (controllable by MCU via the expander’s output 0), and allow clean resets by cutting 5V to the module. In practice, none of these goals are met.

For bring-up, it works “well enough”: C3 can drive M0 and talk to the module, but pull-up isn’t guaranteed. For V5, I’ll simply drop this analog switch and go with something simpler: fixed pull-up to 5V for default WOR, maybe a diode or MOSFET to isolate 5V from the MCU pin driving M0.

Voltage Supervisor: Reference Mistake, Plain and Simple

Here, a pure blunder. I chose a TPS3703B5180 as voltage supervisor, noting I’d need to change its reference for ~2.5V threshold. And forgot to do it!

The “B5180” monitors around 1.8V, with a UV/OV logic that makes no sense for a 3.3V rail. Result: it “sees” imaginary overvoltages, tries to protect against a non-existent problem, and interferes at startup causing reset/reboot loops. On this rail, the right choice would have been a TPS3703E5250: E version, single undervoltage threshold at 2.5V, aligned with a true 3.3V operating limit. Luckily I’d added a jumper to kill its action on RESETn, which limits V4’s trouble.

Anyway, it brings insufficient benefit to justify another BOM item. For V5, I won’t just fix the reference: I’ll delete the supervisor. The C3’s software brownout detector is sufficient.

V5: Corrections Roadmap

Restore the 3.3V rail by adjusting R45 to ~267kΩ (?).
Rework TPL5010 setup (R4 ≈ 22kΩ, switchable supply, pull-up placement).
Delete TPS3703B5180.
Properly size the supercap fuse (time-lag, 3.15A should do).
Simplify M0 pull-up for E22.
Hard-strap the buck 5V in ECO mode, no dynamic expander control (or keep, it doesn't hurt).

The rest of the hardware (power chain, C3, I²C, RTC, FRAM, expander, VSENSE, UART to E22) is validated and will serve as the base for the final firmware.

Test Program and Next Steps

The supplied software is a bring-up code. It scans I²C at boot, configures RTC (CLKOUT off, IRQ management), initializes PCA9536 and blinks the LEDs, powers E22 and 5V buck, does a radio smoke test (CONFIG mode, register reads, power setup, switch to WOR), continually tracks pack voltage via VSENSE, logs C3 internal temperature, and can (optionally) run continuous TX via an e22_burst_tx_task.

It’s deliberately rough, just to validate hardware as fast as possible!

But the final firmware will be clean and structured: FreeRTOS, hardware (with DONE, WAKE of the TPL5010) and software watchdog, separated modules, clear state machine, well-controlled wake/sleep sequences... ;)

Conclusion

V4 is validated as the hardware base for firmware implementation. All essential functions are there, consumption numbers match the initial goals, power noise is very low, thermal is managed, tube integration is clean.

Some design errors remain : notably the too-nervous watchdog, fuse sizing, and voltage supervisor to be removed, jumper place around TPL5010, but they’re easy fixes for V5.

It’s slow. But it’s converging…