Skip to content

Releases: jrl290/RTNode-HeltecV4

v1.0.30 — Heltec V4 boot reliability (DIO image header)

01 May 21:22

Choose a tag to compare

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.inirtnode_heltec_v4 env: flash_mode = dio, arduino.memory_type = dio_qspi (PSRAM stays QSPI). V3 env: explanatory comment only.
  • flash.py — V4 board profile flash_mode qio→dio, so esptool merge_bin doesn'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

28 Apr 21:40

Choose a tag to compare

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_v4 binary 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 V4
  • rtnode_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)

28 Apr 18:14

Choose a tag to compare

v1.0.28 — Fix LoRa routing

Restores packet routing between LoRa and local TCP clients.

What's fixed

  • LoRa interface was MODE_ACCESS_POINT which 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_FULL so announces propagate freely between LoRa, local TCP clients, and the backbone — matching standard Reticulum transport node behaviour.
  • The boundary firewall (BOUNDARY_MODE inbound 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 V4
  • rtnode_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

27 Apr 03:27

Choose a tag to compare

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 V4
  • rtnode_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

27 Apr 02:46

Choose a tag to compare

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_v4 binary 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 V4
  • rtnode_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

27 Apr 01:22

Choose a tag to compare

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

21 Mar 03:08

Choose a tag to compare

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

14 Mar 16:19

Choose a tag to compare

v1.0.22 — SF5 option in config portal

12 Mar 01:43

Choose a tag to compare

  • Added SF5 as a selectable spreading factor in the configuration portal

v1.0.21 — Screen blank 5 min default, SF=5 option

12 Mar 01:36

Choose a tag to compare

  • Screen blanking default set to 5 minutes (was 10 minutes)
  • Added SF=5 as a supported spreading factor option