Project Logs

Collapse

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

• PCB V4

  Bertrand Selva • 10/30/2025 at 11:46 • 0 comments

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

  Read more »

• LoRaTube V3 Hardware Bring-Up : Power Rail Debug & Path to V4

  Bertrand Selva • 10/26/2025 at 16:13 • 0 comments

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

  Read more »

• Updated files LoRaTube V3

  Bertrand Selva • 10/05/2025 at 06:57 • 0 comments

  The latest files for V3 — the version currently in production with PCBWay  — have been uploaded (in the files project).

  The archive includes the schematic, Gerber files, Pick and Place data of the V3.
  
  

• Pictures of the Assembled PCB for the LoRaTube V3

  Bertrand Selva • 09/29/2025 at 10:03 • 2 comments

  Here are some photos I received this morning of the assembled PCB, manufactured by PCBWay.
  
  This is version V3. All related files are available in the project repository.

  It’s a cool moment to see the physical board assembled. The result looks very nice.

  I’ll post a more detailed log with first debugs/tests as soon as I receive the board in hand.
  
  I don't no why but I can't put new photos on my log. So, please find the following links : https://github.com/Bertrand-selvasystems/pictures_PCB_loratube/blob/main/
  

  
  

• PCB sent for assembly & production (LoRaTube V3)

  Bertrand Selva • 09/12/2025 at 12:35 • 0 comments

  The PCB order (including component assembly) has been sent to production today.
  Thanks to PCBWay for supporting the project and for reviewing/validating the BOM.

  I’ve updated the Gerbers and other related files in the project (V3).

  Once I receive the board, I’ll share the debugging and testing process in a new log, along with a YouTube video.

  The next update should come in about thirty days...

• Schematic description (LoRaTube V2)

  Bertrand Selva • 09/05/2025 at 12:35 • 0 comments

  
  
  

  First of all, thanks to Christoph Tack for the extensive reviewing and the valuable feedback on the schematic. One major change came from his advice: the new architecture drops the Pi Pico and runs instead on an ESP32-C3 MINI, which is much more suited for ultra-low-power profiles.

  The power path starts from a 20–30 V pack of alkaline batteries. The input is protected against reverse polarity and surges by an LM74610 ideal diode and a TVS diode (SMAJ36AH). A MAX16956 buck converter then provides a regulated 5 V rail, always on.

  On this 5 V line sits a TPS2553 current limiter, set to about 250 mA (R_ILIM ≈ 118 kΩ). This limiter is mandatory because the supercapacitors are placed after it, directly on the 5 V bus.
  During LoRa TX bursts, the E22-400T33D can draw up to 1.3 A. Thanks to their low ESR, the supercaps deliver this current. But when they recharge, the limiter ensures the source current stays below 250 mA (~70 mA on the battery side).
  This low recharge current is critical: it is compatible with end-of-life alkaline packs or very cold conditions, and it even improves autonomy—lower current means more usable energy can be extracted from the cells.

  The supercap charging is supervised by a TLV6700 comparator (previously a MAX8212 in V1). It cuts charging at 4.90 V and re-enables it below 4.75 V, stabilizing the bus around 4.8 V. This is high enough for reliable E22 operation but low enough to minimize supercap leakage, which increases with voltage and temperature.

  From this 5 V rail, a TPS62840 ultra-low Iq buck generates the permanent 3.3 V rail. This powers the ESP32-C3, the TPL5010 watchdog, the PCF8523 RTC, and the FRAM memory.

  • The RTC is always powered, mainly to use its alarm output, wired together with the TPL5010 WAKE through an open-drain buffer.

  • The FRAM (≈ 27 µA continuous consumption) is physically disconnected when not logging, using MOSFET switches to avoid phantom powering through the I²C bus.

  Two high-impedance resistor dividers allow monitoring of both the input (30 V) and the 5 V bus. The high-voltage divider is switched by a P-MOS/NPN combo for ESP32 safety.

  The LoRa E22 module runs directly from the supercap 5 V bus. The ESP32 supervises the radio: if the module becomes unresponsive, a hard reset circuit can force recovery (still pending in this version).

  The watchdog (TPL5010) resets the ESP32 if it fails to toggle DONE within 10 s. The firmware kicks it every 8 s, and the DONE line also drives a small green LED, flashing 100 ms every cycle—visible but still energy-friendly.

  Protections are layered:

  • SMAJ36AH TVS for surge,

  • Polyfuse 2016L050MR set at 500 mA for the input,

  • LM74610QDGKRQ1 ideal diode for reverse polarity and blocking back-feed to the cells,

  • 2 A fuse on the supercap path.

  Finally, a USB-C connector allows ESP32 programming and log extraction. Two tactile switches let you force BOOT mode or reset, just like on a standard devkit.
  
  PCB

  
  The board is designed to slide into a 50 mm PVC tube. Target outline is 45 mm wide × 125 mm long to leave insertion clearance.

  • Assembly: all components are placed on the front side; the supercapacitors are mounted on the back side.

  • Minimum trace width: 0.256 mm (~10.1 mil).

  • Keep-out & fit: maintain a small edge clearance for the tube wall; avoid tall parts near the edges to prevent friction during insertion.

  
  Next steps

  For the next steps, I’ll wait until September 20 to launch fabrication — just enough time to add the missing power switch on the E22 line and double-check everything.
  The build will go through PCBWay — thanks for supporting this project! They’ve been awesome.

  I also scattered debug pads all over the board to make troubleshooting easier.

  And hopefully, I’ll be able to run new field tests out during this winter!
  
  PS : I put new gerber files on the projet

View all 13 project logs