LoRaTube

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.

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:

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

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)

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

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.

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.

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/

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

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

LoRa Range Test from Mont Bessou (Corrèze, FR)

    “Here are the real-world propagation results from my repeater installed on Mont Bessou (alt. 976 m) in Corrèze - France.
    The node uses an Ebyte E22-400T22D LoRa transceiver running at 2400 baud and feeding a simple 2 dBi antenna (Retevis 5/8 lambda)

Test setup

Repeater on the summit at the GPS position LAT 45.568737,  LONG  2.212755 ; The receiver is the communicator with a 2 dBi antenna with the same LoRa module. 

The repeater was installed at the summit of Mont Bessou. The receiver was my handheld LoRa communicator, equipped with a small 2 dBi antenna.

I drove away from the repeater along accessible roads. Using GPS, I monitored the distance from the origin.

At each test point, I attempted to establish a link by sending a message from the communicator. If the message was successfully echoed by the repeater and displayed back on the communicator’s screen, I logged it as a successful transmission.

For each confirmed link, I recorded two values from the E22 module:

• the RSSI (Received Signal Strength Indicator)

• the ambient noise level
  (both values read from the module’s internal registers: 0×01 and 0×00, respectively)

    According to the E22 docs: dBm = –(256 – raw).
    Both RSSI and noise share this scale, so SNR [dB] = RSSI dBm – Noise dBm.

Plots
RSSI & noise vs distance and  SNR vs distance

Conclusions from the Propagation Graphs

The field test confirms that a LoRa repeater placed at a high point like Mont Bessou can sustain a long-distance link even with modest hardware and low RF power.

Key takeaways from the plots. The measurements confirm that even with a basic E22 module configured at 2400 baud and a small 2 dBi antenna, the repeater installed at the summit of Mont Bessou can maintain a reliable link up to 40 km — without a single lost message.

• The weakest signal observed (–88 dBm at 31 km) remains 49 dB above the declared sensitivity (–137 dBm), which means the link margin is extremely comfortable.

• The SNR stays positive across the entire distance. Even at the furthest point, with an SNR of +1 dB, there is still 13 to 16 dB of headroom before reaching the theoretical demodulation threshold (–12 dB to –15 dB for spreading factors SF9/SF10, which are likely used by the module — though Ebyte provides no clear details on this).

• The measured signal attenuation slope (about 6 dB per doubling of distance) closely matches that of a free-space propagation model. In ideal line-of-sight conditions, two additional doublings suggest a possible range of 60 to 80 km, or even up to 100 km on a clear ridge-to-ridge path.

These surprisingly good results are actually easy to explain: the transmission site is elevated, the 433 MHz band suffers less attenuation than 868 MHz, and the rural Corrèze region offers very low RF noise. Additionally, all test points were chosen to be free of nearby vegetation, clearly facing the repeater, and often positioned on elevated ground.

I didn’t push beyond 40 km for practical reasons: I was already quite far from the summit, and I wanted to keep the return drive reasonable (crossing the Dordogne valley is slow).
That said, the repeater should remain fully operational with negative link margins down to around –12 dB, which suggests significant additional range potential.

Not bad at all for such a simple setup.

Here are a few shots of the repeater fully assembled and installed in my garden.