Summary
On Heltec WiFi LoRa 32 V4, the WiFi/TCP link is stable when the node is idle but degrades badly under real transport load — i.e. when a Reticulum TCP peer is connected to the node and the node relays announces over LoRa. Under load, ICMP packet loss to the node rises to 30–55 % with RTT spikes up to ~900 ms, and the node's TCP link to the backbone/hub drops to DOWN. With no TCP peer attached and minimal LoRa traffic, the same node holds 0 % loss indefinitely.
This initially looked like a hardware fault on one board, but an A/B with a second, freshly-flashed board reproduced it identically (in fact worse), ruling out board-specific hardware.
Environment
- Board: Heltec WiFi LoRa 32 V4 (ESP32-S3), 2× units
- Firmware: v1.0.48 — reproduced on the stock release and on a local build with
WiFi.setSleep(false) added
- LoRa: 868.950 MHz, BW 125 kHz, SF10, CR 4/5, TX 17 dBm
- WiFi: 2.4 GHz STA to a home AP. Node runs the Local TCP Server on 4242; a Reticulum transport instance (
rnsd, TCPClientInterface) connects in to the node and relays backbone announces.
Reproduction / measurements
Same board, same AP, same config — only the load differs:
| Condition |
ICMP loss (5 min) |
Node TCP link |
| Idle (no TCP peer, minimal LoRa) |
0 % (300/300) |
— |
| Under load (TCP peer connected + relaying announces over LoRa SF10) |
32–55 % |
drops to DOWN |
Two independent boards, both full-erased + reflashed, identical config → both flap under load (32 % and 55 %), both perfectly stable when idle. The RTT spikes (up to ~900 ms) line up with LoRa TX windows.
Hypothesis
The synchronous/blocking LoRa TX path (an SF10 announce of ~167 B is ~0.6–2 s of airtime) appears to stall the main loop long enough to starve WiFi/TCP servicing, causing association hiccups, dropped ICMP, and TCP timeouts. Under transport load the node relays many announces over LoRa, multiplying the effect; an idle node transmits rarely and stays stable.
Suggestions
- Make LoRa TX non-blocking (DIO1 TxDone IRQ + state machine), or explicitly keep the WiFi/TCP stack serviced (yield) during TX.
- Optionally cap/space announce cadence while a TCP backbone / local-server peer is attached.
Minor, separate
Adding WiFi.setSleep(false) right after WiFi.begin() in wifi_remote_start_sta() gave a marginal improvement (turned a hard hang into recoverable flapping) but does not resolve the load-dependent loss. Happy to open a small PR for that if it's useful.
Thanks for the firmware — otherwise it's been great to work with.
Summary
On Heltec WiFi LoRa 32 V4, the WiFi/TCP link is stable when the node is idle but degrades badly under real transport load — i.e. when a Reticulum TCP peer is connected to the node and the node relays announces over LoRa. Under load, ICMP packet loss to the node rises to 30–55 % with RTT spikes up to ~900 ms, and the node's TCP link to the backbone/hub drops to DOWN. With no TCP peer attached and minimal LoRa traffic, the same node holds 0 % loss indefinitely.
This initially looked like a hardware fault on one board, but an A/B with a second, freshly-flashed board reproduced it identically (in fact worse), ruling out board-specific hardware.
Environment
WiFi.setSleep(false)addedrnsd,TCPClientInterface) connects in to the node and relays backbone announces.Reproduction / measurements
Same board, same AP, same config — only the load differs:
Two independent boards, both full-erased + reflashed, identical config → both flap under load (32 % and 55 %), both perfectly stable when idle. The RTT spikes (up to ~900 ms) line up with LoRa TX windows.
Hypothesis
The synchronous/blocking LoRa TX path (an SF10 announce of ~167 B is ~0.6–2 s of airtime) appears to stall the main loop long enough to starve WiFi/TCP servicing, causing association hiccups, dropped ICMP, and TCP timeouts. Under transport load the node relays many announces over LoRa, multiplying the effect; an idle node transmits rarely and stays stable.
Suggestions
Minor, separate
Adding
WiFi.setSleep(false)right afterWiFi.begin()inwifi_remote_start_sta()gave a marginal improvement (turned a hard hang into recoverable flapping) but does not resolve the load-dependent loss. Happy to open a small PR for that if it's useful.Thanks for the firmware — otherwise it's been great to work with.