Project Logs

Collapse

• Firmware architecture (WIP)

  Bertrand Selva • 3 days ago • 0 comments

  Hackaday log – Firmware architecture (Work in progress)

  I am currently writing the firmware.
  Time is limited at the moment and I am quite busy, so progress is steady but deliberately slow.

  I am aligning the codebase with a new firmware “skeleton” I am developing:
  https://github.com/Bertrand-selvasystems/firmware_skeleton_espidf

  Architecture rules

  Drivers (module_*.c) are self-contained

  • No FreeRTOS includes
  • No queues
  • No event bits
  • Clean C API only: init / read / write / deinit

  Tasks (task_*.c) orchestrate hardware access through drivers
  Tasks are the only place where the system:

  • uses FreeRTOS primitives (queues, event groups, notifications)
  • implements retry and delay logic
  • sets, clears and waits on event bits
  • manages health monitoring and fault handling

  APIs (API_*.c) talk to tasks, not to hardware

  • They provide intent-level functions
  • They hide internal queues and events from the rest of the application

  Configuration is split into two layers

  • Frozen hardware configuration (system_cfg.*): wiring, addresses, frequencies (const, never modified)
  • Runtime state: handles, flags, counters, queues, event groups

  Layers and dependencies

  app_main / initialization
  → API_* (facade, intent-level calls)
  → task_* (FreeRTOS actors, ownership and logic)
  → module_* (drivers, hardware access only)

  Allowed dependencies

  • module_* may depend only on ESP-IDF drivers (I2C, UART, GPIO, etc.), never on system_*
  • task_* may depend on system_types, system_queues, system_state, system_faults and module_*
  • API_* may depend on task-facing command queues and system_* but never on hardware

  Design rationale

  The goal is clean, stable firmware, especially by enforcing one service per critical hardware block.
  This guarantees zero concurrent access to the same peripheral, even in unexpected edge cases, which is a major stability gain.

  This point is absolutely central for a system designed to run unattended for five years, or close to it, such as a remote LoRa repeater deployed in the field.

  At this stage, I have implemented:

  • the I2C service
  • the PCA (I/O expander) service

  The current work-in-progress code is available here:
  https://github.com/Bertrand-selvasystems/loratube_firmware

  There is still a lot to do, but the foundation is now in place. 

  The LEDs are blinking, which is usually a good sign.

• Response to feedback on D-cell lifetime

  Bertrand Selva • 12/06/2025 at 10:47 • 0 comments

  I’ve read the comments on the Hackaday.com article : https://hackaday.com/2025/12/02/lora-repeater-lasts-5-years-on-pvc-pipe-and-d-cells/.
  Thanks for the feedback.

  Most questions focus on two points

  1. the real-world lifetime of alkaline D cells outdoors (You’re right: this is likely the main structural limitation of the current design), and

  2. PCB protection in case a cell leaks.

  I About alkaline D-cell leakage

  Leakage can occur for two main reasons:

  1. Deep discharge inside a series pack

  At end of life, in any series string, the weakest cell will eventually be forced into reverse polarity if current keeps flowing.
  This pushes the chemistry outside its intended operating region, causing:

  • gas generation,

  • internal overpressure,

  • seal rupture,
    → leading to electrolyte leakage.

  In my design, I continuously monitor pack voltage and put the device into a almost full shutdown if the voltage drops too low.
  The whole point is to avoid that deep-discharge region which dramatically increases leakage risk.

  2. Mechanical/assembly defects in cheap cells

  This is the downside of the “500 Wh for €13” deal.
  At that price point, you don’t get telecom-grade cells with industrial QC.
  It’s a compromise.
  As it stands, this is a structural limitation of the LoRaTube concept.

  II Protecting the PCB/electronics in case of leakage

  The mechanical design answers most concerns:

  • the PCB is above,

  • the battery pack is below,

  • and the two volumes are physically separated by:

    • the 50 mm “coffee-cup” internal support, screwed into the 40 mm tube,

    • plus the piece that provides the positive terminal contact for the last cell.

  The electronics compartment and the battery compartment are mechanically isolated.
  If a cell leaks, the electrolyte cannot reach the PCB.
  And if the cells become impossible to remove, the entire tube section can simply be discarded (a 2-meter PVC tube costs around €2).

  III/ Toward a more resilient battery architecture

  The comments are valid: if we’re aiming for extreme robustness, having the whole system fail because of one leaking cell or one failed cell is not ideal.

  I’m considering a new architecture:

  • instead of one long 18S1 string,

  • use three parallel packs of 7 cells in series each → 7SP3 configuration.

  This gives an input voltage between ~7 V and ~12 V depending on the state of charge.
  The buck converter runs more efficiently and with lower losses in that range.

  The obvious risk with parallel packs is cross-charging, which would destroy the weaker packs quickly.

  Low-tech fix: Schottky diodes (passive ORing)

  The simplest and most reliable solution is to place a Schottky diode in series with each 7-cell string:

  • each 7S pack has its own diode,

  • the three diodes meet at the input rail of the buck converter.

  Expected behavior

  Example:

  • Pack A: 10.5 V

  • Pack B: 10.2 V

  • Pack C: 10.0 V

  • Schottky drop ≈ 0.3 V

  Effective voltages seen at the bus:

  • A → ~10.2 V

  • B → ~9.9 V

  • C → ~9.7 V

  Result:

  • Only Pack A supplies current initially (it has the highest voltage).

  • As it discharges, its voltage drops.

  • Once it falls below Pack B (diode-included), Pack B automatically takes over.

  • Then Pack C, etc.

  This gives a very primitive form of current balancing, with zero active electronics.

  Benefits

  • The system keeps running even if one pack fails, or even two packs.

  • Leakage or a broken contact in one 7-cell string no longer kills the entire node.

  • You move from a single point of failure (18S1)
    to a system with graceful degradation (7S3 + diodes).

  This matches the project philosophy:
  long lifetime outdoors with simple, low-cost, repairable technology.

  We could even consider 3, 4 or 5 parallel packs depending on:

  • outdoor mechanical constraints,

  • budget,

  • desired level of redundancy,

  • available space inside the tube.

• Separation between D pack and PCB

  Bertrand Selva • 12/04/2025 at 19:44 • 0 comments

  I will complete the log later with the elements I was able to collect from the article on hackaday.com about the LoRaTube. There were a lot of comments about the long-term behavior of D cells. You’re right, I do have a modification to address this issue.

  In the meantime, here is, through this diagram, the answer to one of the issues that was raised: there is indeed a clear separation between the electronics (which are in any case above the batteries) and the batteries, via the part that holds the 50 mm tube and looks like a coffee cup.

  
  

• Bring-up of LoRaTube PCB V4

  Bertrand Selva • 11/30/2025 at 13:59 • 0 comments

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

  Read more »

• V4 PCB received

  Bertrand Selva • 11/27/2025 at 10:23 • 0 comments

  I received the assembled V4 PCB today, along with five unassembled boards. Many thanks to PCBWay. I’m short on time and have a lot to catch up on right now, but I’ll get to the bring-up soon.
  
  
  

• Part Failure and Structural Reinforcement

  Bertrand Selva • 11/26/2025 at 13:27 • 0 comments

  Four Months Outdoors

  After four months outside and the first cold spells, here’s a status update on the mechanical side.
  I dropped the LoRaTube and broke the part at the end of the tube (the piece that’s glued to the PVC pipe).

  In addition, the end piece of the assembly,  the one bearing the weight of the whole battery stack and the contact pressure from the springs, had been printed too “light” and had slowly deformed under load. I redesigned it as a beefier part, matching the diameter of the new glued sleeves, and printed it with higher density (40% infill + gyroid pattern).
  
  
  

  
  New Design

  In hindsight, I had printed it too thin and not dense enough. I reworked the cap as well as the glued end-piece of the PVC tube, increasing the wall thicknesses and printing at 40% infill with a gyroid pattern.

  I should also mention that I changed printers, moving from my old Ender 3 V2 to a Bambu Lab machine (huge upgrade). The part, even though it is still PLA, comes out noticeably denser. Under-extrusion on the Ender? Slicer differences? Whatever the cause, the whole assembly feels much more solid now.
  
  Here is the new end piece of the assembly, which both closes the tube and holds the batteries in place.
  
  Here are the new end caps for the PVC tube.
  
  
  And here is the new mounting bracket that holds the 50 mm PVC tube (the tube that carries the electronics).
  
  And the end part of the tube : 
  
  
  I also changed the part that holds the 50 mm tube. It’s thicker, I increased its diameter, and I printed it with 40% gyroid infill as well. It’s the green part in the photos below.
  

  Resilience

  In any case, it’s by iterating that I’ll converge towards a system that’s robust in all conditions (Soyuz technique!).
  The length of the 40 mm-diameter PVC tube to cut is 115.8 mm. By cutting it to the correct length, I was able to remove the crescent-shaped spacer I had added earlier.

  In the last photo, you can see the device responsible for making contact with the positive terminal of the last cell.
  It consists of two parts that can move relative to each other. Contact pressure is provided by three compression springs. The travel is about 15 mm. The system looks robust and works well so far…

  I’ll leave the device assembled over the coming months. I’ll only bring it back into the lab when I receive the V4 PCB, if it looks OK for an outdoor test.
  
  
  
  
  
  
  
  

• Pictures of the Assembled PCB for the LoRaTube V4

  Bertrand Selva • 11/17/2025 at 09:53 • 0 comments

  Here are a few photos I received this morning of the fully assembled PCB, manufactured by PCBWay.
  This is Revision V4.

  The build quality is excellent ; clean soldering, crisp edges, and a layout that finally looks exactly as intended.

  Once the board is in my hands, I will publish a detailed bring-up report for this V4 revision as for the V3 revision: power-on tests, rail validation, firmware loading, radio checks, and early measurements.

  More to come.

  
  

  
  
  
  
  
  
  
  
  
  
  
  
  
  

• V4 IN PRODUCTION

  Bertrand Selva • 11/04/2025 at 09:20 • 0 comments

  The Gerbers and BOM have been sent to production : the V4 is now in production.
  This revision marks, I hope, the closure of the hardware development phase and the beginning of firmware optimization.
  
  

  Next phase: 

  • bring-up of the V4 in few weeks 

  • firmware (il everything is OK) : Focus will shift to thefinite-state control, FRAM ring buffer, and the orchestration of wake/sleep cycles with deterministic timing and energy budgets.

  Many thanks again to PCBWay for their continuous support in this next iteration.
  
  

• FRAM Data Logging Specification

  Bertrand Selva • 11/02/2025 at 22:56 • 0 comments

  Purpose and Memory Technology

  Logs are critical for monitoring LoRaTube, confirming real-world performance over time, and, if necessary, identifying failures or design flaws.

  This document records the reasoning and choices that led to the selected memory technology. The aim is to ensure reliable long-term logging with minimal power consumption and maximum resilience.

  SD cards, though common in consumer projects, were ruled out. Their fragility is well known: rapid cell wear, poor reliability over long periods without activity, unpredictable wear-leveling, and a tendency to become corrupted or unwritable after power loss. Random corruption, freezes, access slowness, and inrush current are all deal-breakers for an ultra-low-power, resilient system.

  Serial EEPROMs were also considered. They are inexpensive and widely available. However, their endurance is limited (typically one million write cycles per cell, much less in harsh temperature conditions), and write operations are page-based, which is not well-suited for the intended logging patterns. Write times can be significant, increasing the risk of data corruption during resets or brownouts. Data retention is often not guaranteed beyond a few years, especially with wide temperature variations.

  SPI Flash offers large storage but shares many drawbacks: limited endurance, mandatory page erase before writing, complex software wear-leveling, and a real risk of “bricking” the chip if power is lost during write operations. Frequent updates to a few bytes always force a compromise between wear and software complexity. Additionally, available pin count on the C3 is limited, with no other active SPI devices in the design.

  FRAM (Ferroelectric RAM) emerged as the solution. Key features:

  • Very fast access (read/write in a few microseconds)
  • No write latency
  • Virtually unlimited endurance (ideal for frequently updated counters)
  • Very low operating power

  FRAM requires no pre-erasure or software wear-leveling, never blocks on sudden power loss, and provides full-speed access regardless of the frequency or distribution of writes. Data can be written or read byte by byte. It is also known for its resistance to EMI, and data retention exceeds ten years, making it well suited for embedded data loggers requiring high reliability.

  There are two minor trade-offs: the chosen device (one of the few available on Aliexpress) draws about 9 µA in idle. While this is low, it is not entirely negligible over several years. 

  
  

  The FRAM is mounted on a large breakout board and is installed via female headers, allowing easy extraction for content analysis without soldering.

  
  

  Daily Log Format (16 bytes, little-endian)

  Available storage is 32 kB, so a daily log format with counters was selected. Counters are stored directly in FRAM to take advantage of its resilience to repeated writes and absence of paging.

  Assuming a five-year lifespan:

  32 kB / (5 years × 365 days/year) ≈ 17 bytes per day.

  The chosen log format is 16 bytes per day:

  Field	Bytes	Description
  timestamp	4	Unix UTC (seconds)
  midnight_temp	1	Temperature at midnight (−15…+35 °C normal, −50…+70 °C if TEMP_EXT=1)
  midnight_voltage	1	Main voltage (Vbat/Text, 10–32 V, LSB ≈ 86 mV)
  noon_temp	1	Temperature at noon (RTC or nearest sample)
  noon_voltage	1	Voltage at noon (same rule)
  wake_rx	2	Number of radio wake-ups, saturates at 0xFFFF
  ratio_rxtrue_per_wake_q8	1	Q8 ratio: (REVEIL_RADIO == 0) ? 0 : clamp(round(255 × TRUE_RX / REVEIL_RADIO))
  ratio_tx_per_rxtrue_q8	1	Q8 ratio: (TRUE_RX == 0) ? 0 : clamp(round(255 × TX / TRUE_RX))
  flags	1	See below
  noise_min_dbm	1	Min radio noise, −130…0 dBm (LSB ≈ 0.51 dB)
  noise_max_dbm	1	Max radio noise
  crc8	1	CRC-8 with first 15 bytes

  Ratio Calculation (bytes 7 & 8)...

  Read more »

• GERBER FILES FOR V4

  Bertrand Selva • 11/01/2025 at 15:12 • 0 comments

  You will find the Gerber files, the component placement file, the BOM, the schematic, and the EasyEDA JSON edit file for V4 in the project files.

  The PCB will go into production for this V4, once again thanks to PCBWay. Their ongoing support makes this project possible.

  Bring-up is scheduled in a few weeks.

View all 19 project logs