ESP32-C6 stops sending CSI while staying configured, reachable and responsive

ESP32-C6 stops sending CSI while staying configured, reachable and responsive

Repo: ruvnet/RuView (firmware) · Severity: High · Measured: 2026-09-15, node 12

Symptom

A node stops delivering CSI to the server while remaining healthy on every other axis:

server /api/v1/nodes   node 12 absent entirely (total drops 4 -> 3)
USB                    enumerated, /dev/cu.usbmodem21301
LAN                    reachable, ping 3/3, 0% loss, 4 ms
serial HELLO           RUVIEW_HELLO_OK_V1 node_id=12 version=0.8.12
                       target_ip=<server-ip> target_port=5005 configured=1
console                silent

So it is powered, associated, correctly configured for the right server and port, and
answering its own onboarding protocol — and sending nothing.

Frequency

Three occurrences on 2026-09-15, same board, firmware 0.8.12:

1. Found silent after a server restart.
2. Recovered by esptool --after hard_reset — rejoined within 10 s.
3. Died again ~13 minutes later, mid-capture.

Recovery is reliable via hard reset; it does not self-heal.

Impact

Beyond the lost node, it breaks captures. In occurrence 3 the node died during an
empty-room calibration. The server was unaffected (observed_source_node_ids is
cumulative, so missing_source_node_ids stayed [] and finalize would have succeeded) but
the app stopped being able to finalize — see the companion issue on client-side finalize.
The capture ran 889 s with no way to complete from the UI.

Relationship to the 2026-09-02 report

2026-09-02-ruview-c6-ap-reboot-nonrejoin.md recorded nodes that "exhaust Wi-Fi retries
during AP reboot and require a device reset", on firmware 0.8.8. This is the same
signature on 0.8.12, but without an observed AP event — so either the trigger is
broader than an AP reboot, or the retry exhaustion has another cause.

Suggested next step

Capture the console across the transition. The console is silent once it has happened, so
it needs to be attached before the failure — a long serial capture on a board left
running is the cheapest way to catch the moment it stops.

Start with a long serial-console capture attached before reproducing the failure on firmware 0.8.12, while checking the node’s LAN reachability and CSI delivery. Compare the console transition with the 2026-09-02 AP-reboot report and the hard-reset recovery. Done means identifying the trigger or failure state and documenting a reproducible path toward preventing CSI from stopping or enabling self-recovery.