Releases: jrl290/RTNode-HeltecV4
v1.0.30 — Heltec V4 boot reliability (DIO image header)
Fixes a bootloop affecting some Heltec V4 boards (reported on V4.3) caused by the v1.0.29 V4 binary having its image header marked QIO. The ESP32-S3 ROM bootloader trusts that header byte and configures the SPI controller for QIO before any of our code runs; if the flash chip / board strapping doesn't actually support QIO, the bootloader hangs in flash init and TG0 watchdog resets (rst:0x7 TG0WDT_SYS_RST, Saved PC inside ROM).
Fix: image header is now built as DIO (universally safe). The IDF 2nd-stage bootloader still runs bootloader_enable_qio_mode() which probes the flash chip's SFDP / Quad Enable bits at runtime and upgrades the SPI controller to QIO when the chip genuinely supports it. Steady-state flash throughput is unchanged on capable parts; cold boot adds ~50 ms for the probe.
Changes
platformio.ini—rtnode_heltec_v4env:flash_mode = dio,arduino.memory_type = dio_qspi(PSRAM stays QSPI). V3 env: explanatory comment only.flash.py— V4 board profileflash_modeqio→dio, soesptool merge_bindoesn't rewrite the header byte and undo the fix when packaging releases.docs/index.html(web flasher) — Detect step now logs chip Variant (getChipDescription) and Flash ID (JEDEC mfg/dev) alongside Chip / Features / Flash size, so future bug reports include enough info to identify chip package and flash chip without guessing.
Notes for users
- Web flasher: open https://jrl290.github.io/RTNode-HeltecV4/, click Detect, then Full install (since the bootloader image is being replaced).
- CLI:
python flash.py --board v4 --full. - Existing V3 boards: no functional change. Same binary behavior; refreshed image only because it's part of the same build.
v1.0.29 — Heltec V4.3 boot/RX fix
v1.0.29 — Heltec V4.3 boot/RX fix
Mirrors the V4.3 (KCT8103L FEM) support from upstream markqvist/RNode_Firmware 1.86. Addresses reports of V4.3 boards entering a USB reconnect loop with no display after flashing v1.0.26–v1.0.28.
Likely root causes addressed
OCP_TUNED 0x18 → 0x28— over-current protection limit was too low for the V4.3 PA path, causing the radio to brown out the 3V3 rail during boot.- SX1262 errata 15.4 — IQ polarity register bit was being reset to the wrong value on every
SetPacketParams, causing silent RX failure (TX still worked). - SX1262 errata 15.1 — modem sensitivity register now correctly toggled for the active LoRa bandwidth.
- FEM detection — settle time bumped 1 ms → 5 ms before reading CSD pull level.
- Per-FEM LNA gain & PA gain table — KCT8103L now uses LNA gain 21 (vs 17 for GC1109) and a different PA gain table for accurate TX power calibration.
Compatibility
- A single
rtnode_heltec_v4binary continues to work on both V4.2 (GC1109) and V4.3 (KCT8103L) — FEM model is auto-detected at boot. - V3 binaries unchanged in behaviour (rebuilt for tag consistency).
Files
rtnode_heltec_v4.bin— V4.2 / V4.3 update (16 MB, qio, 80 MHz)rtnode_heltec_v4_merged.bin— full flash image for V4rtnode_heltec_v3.bin— V3 update (8 MB, dio, 80 MHz)rtnode_heltec_v3_merged.bin— full flash image for V3
Web flasher: https://jrl290.github.io/RTNode-HeltecV4/
v1.0.28 — Fix LoRa routing (MODE_FULL)
v1.0.28 — Fix LoRa routing
Restores packet routing between LoRa and local TCP clients.
What's fixed
- LoRa interface was
MODE_ACCESS_POINTwhich blocks all outbound announce broadcasts. LoRa devices could not learn backbone paths and local TCP clients could not learn LoRa paths, breaking routing in both directions. - Switch LoRa to
MODE_FULLso announces propagate freely between LoRa, local TCP clients, and the backbone — matching standard Reticulum transport node behaviour. - The boundary firewall (
BOUNDARY_MODEinbound filter) is independent of interface modes and continues to gate all backbone (WAN) traffic using the local/mentioned address whitelists. LAN devices (LoRa + local TCP) retain free reign; WAN traffic is filtered as before. - Update local TCP server log message and portal description to reflect it uses
MODE_GATEWAY(already correct in code, now correct in strings too).
Files
rtnode_heltec_v4.bin— V4.2 / V4.3 update (16MB, qio, 80MHz)rtnode_heltec_v4_merged.bin— full flash image for V4rtnode_heltec_v3.bin— V3 update (8MB, dio, 80MHz)rtnode_heltec_v3_merged.bin— full flash image for V3
v1.0.27 — Configurable LoRa airtime limits
v1.0.27 — Configurable LoRa airtime (duty-cycle) limits
Adds two new fields to the LoRa section of the WiFi config portal:
- 15s limit (%) — short-term airtime cap (rolling ~15 second window)
- 1hr limit (%) — long-term airtime cap (rolling ~1 hour window)
When the measured LoRa airtime exceeds either threshold, TX is paused
until the rolling window drops back below the limit. Range 0–25 %
with 0.1 % resolution. 0 = disabled (default).
Useful for self-imposed regional duty-cycle budgets — e.g. EU868 users
can set 1.0 on the 1hr limit.
Settings are persisted to EEPROM and survive reboots.
Files
rtnode_heltec_v4.bin— V4.2 / V4.3 update (16 MB, qio, 80 MHz)rtnode_heltec_v4_merged.bin— full flash image for V4rtnode_heltec_v3.bin— V3 update (8 MB, dio, 80 MHz)rtnode_heltec_v3_merged.bin— full flash image for V3
Web flasher: https://jrl290.github.io/RTNode-HeltecV4/
v1.0.26 — Heltec V4.3 support
v1.0.26 — Heltec V4.3 support
Adds runtime support for the Heltec WiFi LoRa V4.3 board revision alongside the existing V4.2.
What's new
- KCT8103L FEM auto-detect: V4.3 boards swap the GC1109 PA for a KCT8103L. The driver now detects the FEM type at boot from the default CSD pull level and drives the appropriate control pins (CTX vs CPS) for both TX and RX paths.
- A single
rtnode_heltec_v4binary works on both V4.2 and V4.3 revisions — no separate build required. - Sleep path also pulls CTX low on KCT8103L boards for proper low-power state.
Hardware reference
| Board | PA | Control |
|---|---|---|
| V4.2 | GC1109 | CSD + CPS (CTX driven by DIO2) |
| V4.3 | KCT8103L | CSD + CTX (CPS driven by DIO2) |
Files
rtnode_heltec_v4.bin— V4.2 / V4.3 update (16MB, qio, 80MHz)rtnode_heltec_v4_merged.bin— full flash image for V4rtnode_heltec_v3.bin— V3 update (8MB, dio, 80MHz)rtnode_heltec_v3_merged.bin— full flash image for V3
Web flasher: https://jrl290.github.io/RTNode-HeltecV4/
v1.0.25 — RTNode naming, web flasher, V4 16MB only
What's new
- RTNode naming: PIO envs and binaries renamed to
rtnode_heltec_v3/rtnode_heltec_v4 - Web flasher: Browser-based installer at https://jrl290.github.io/RTNode-HeltecV4/ (no software install required, Chrome/Edge only)
- V4 16MB only: V4 8MB variant removed; only the 16MB PSRAM variant is supported
- PSRAM: V4 always has PSRAM (compile-time); V3 detects at runtime via
ESP.getPsramSize()
Firmware files
| File | Board |
|---|---|
rtnode_heltec_v3_merged.bin |
Heltec WiFi LoRa 32 V3 (8MB, ESP32-S3) |
rtnode_heltec_v4_merged.bin |
Heltec WiFi LoRa 32 V4 (16MB, ESP32-S3, PSRAM) |
Both files are merged binaries (bootloader + partitions + app) suitable for first install or full reflash.
v1.0.24: Node hash in WiFi config portal
What's new
WiFi Config Portal: Node Hash display
The captive-portal setup page now shows the device's Reticulum destination hash at the top, making it easy to identify the node without opening a terminal.
- Hash is cached in RTC memory after the first normal boot and survives software reboots into config mode
- Displays a friendly placeholder on first-ever boot (before RNS has started for the first time)
Firmware binaries
| File | Board |
|---|---|
rnode_firmware_heltec32v3.bin |
Heltec WiFi LoRa 32 V3 (boundary mode) |
rnode_firmware_heltec32v4_boundary.bin |
Heltec WiFi LoRa 32 V4 (boundary mode) |
Flash with flash.py from this repo.
v1.0.23 — display orientation, DHCP recovery, transport mode note
v1.0.22 — SF5 option in config portal
- Added SF5 as a selectable spreading factor in the configuration portal
v1.0.21 — Screen blank 5 min default, SF=5 option
- Screen blanking default set to 5 minutes (was 10 minutes)
- Added SF=5 as a supported spreading factor option