No shipped ESP32-S3 binary produces CSI on a bare (display-less) S3 DevKit — two distinct causes; in-repo release_bins 4MB binary works

Summary

On a bare ESP32-S3-N16R8 DevKit (no AMOLED, no touch, chip rev v0.2), every downloadable S3 release binary yields yield=0pps permanently — including v0.7.1 with the #985 self-ping active. Two independent causes:

1. v0.7.x s3-8mb (display-enabled build): SH8601 display probe false-positives on bare boards → the yield=0pps on ESP32-S3-DevKitC-1-N8R8 (no display): MGMT-only filter starves CSI callback — pre-built binary fix needed #893 /fix(firmware): capture DATA frames on display-less boards — #893/#866/#897 (yield=0pps root cause) #906 MGMT+DATA filter upgrade is skipped → CSI starves at MGMT-only. The write-only QSPI panel init "succeeds" into the void (SH8601 panel init OK (368x448)), while the two probes that can detect absence (TCA9554 @0x20 and FT3168 touch, both I2C with readback) correctly fail — but don't influence display_is_active().
2. v0.6.7-esp32 release asset esp32-csi-node-s3-4mb.bin predates the fix: its boot banner says Compile time: May 23 2026 11:44:16, but fix(firmware): capture DATA frames on display-less boards — #893/#866/#897 (yield=0pps root cause) #906 merged June 2 (898c536e). The v0.6.7 tag source has no csi_collector_enable_data_capture() call in main.c. So the only display-less S3 release binary never contained the yield=0pps on ESP32-S3-DevKitC-1-N8R8 (no display): MGMT-only filter starves CSI callback — pre-built binary fix needed #893 fix it was advertised to carry (in the yield=0pps on ESP32-S3-DevKitC-1-N8R8 (no display): MGMT-only filter starves CSI callback — pre-built binary fix needed #893 /ESP32-S3 v0.6.5: CSI callbacks extremely sparse (3 callbacks in 70s under heavy WiFi traffic), yield stays 0pps #866 /state=8 yield=0pps constantly — board connected to WiFi but no CSI frames transmitted #897 close-out comments).

The in-repo firmware/esp32-csi-node/release_bins/esp32-csi-node-4mb.bin (refreshed by 786e834d, built 2026年06月02日, banner v0.7.0) works immediately: CSI filter upgraded to MGMT+DATA (no display, RuView#893) prints, and yield goes 0 → 27–30 pps.

This is the S3 re-test that was requested in #866 ("Please re-test on your S3 once #868 lands") and #893 — with the conclusion that the fix is correct but was never actually shipped for S3.

Environment

• Board: bare ESP32-S3-N16R8 DevKit (dual USB-C, CH343P UART bridge), efuse chip rev v0.2, boya 16MB flash
• AP: Orange Livebox (2.4 GHz, channel 1, WPA2-PSK, phy bgn, BW20), quiet residential RF, RSSI −56...−67
• Host: macOS (Apple Silicon), esptool v5.3.0, sensing-server built from main (2a307138)
• Association/IP/UDP path verified healthy: DHCP lease, OTA HTTP server reachable from LAN (TCP 8032 answers), <ba-add> block-ack established with the AP

Evidence

A) v0.7.1-esp32 release esp32-csi-node-s3-8mb.bin — yield=0pps despite self-ping

Boot (relevant lines):

I csi_collector: Promiscuous mode enabled (MGMT-only, RuView#396)
I csi_collector: CSI collection initialized (node_id=1, channel=1)
I csi_collector: self-ping started -> 192.168.1.1 @50Hz (CSI OFDM source, fix #521/#954)
I disp_hal: I2C bus init OK (SDA=15, SCL=14)
W disp_hal: TCA9554 not found at 0x20: ESP_FAIL
W disp_hal: TCA9554 not found — assuming display power is always-on (direct wiring)
I disp_hal: SH8601 panel init OK (368x448) <-- false positive on bare board
W disp_hal: FT3168 not found (ret=ESP_FAIL, id=0x00)

No CSI filter upgraded to MGMT+DATA line ever appears (display falsely active ⇒ upgrade skipped). Result over minutes of uptime:

I adaptive_ctrl: medium tick: state=8 yield=0pps motion=0.00 presence=0.00 rssi=-62

Controlled traffic test: 381 HTTP GETs to the node's own OTA endpoint in 20 s (each a full TCP exchange ⇒ guaranteed unicast OFDM HT data frames to the STA, AP had an active BA session) → yield stayed 0pps for the entire window. Note this also means the #954 expectation that gateway ping replies "drive the CSI engine regardless of promiscuous filter state" did not hold on this board (S3 rev v0.2): 50 Hz self-ping + heavy directed unicast produced zero CSI callbacks under MGMT-only. With MGMT+DATA (binary C below) the same traffic produces 27–30 pps, so the practical fix is the filter upgrade — but the #954 claim may deserve a footnote.

B) v0.6.7-esp32 release asset esp32-csi-node-s3-4mb.bin — predates the fix

I app_init: App version: 0.6.7
I app_init: Compile time: May 23 2026 11:44:16 <-- #906 merged 2026年06月02日
...
I csi_collector: Promiscuous mode enabled (MGMT-only, RuView#396)
(no MGMT+DATA upgrade line; yield=0pps; 261 HTTP GETs/15s → still 0pps)

git show v0.6.7-esp32:firmware/esp32-csi-node/main/main.c contains no enable_data_capture call — consistent.

C) In-repo release_bins/esp32-csi-node-4mb.bin (786e834, built 2026年06月02日) — works

I main: ESP32-S3 CSI Node (ADR-018 / ADR-110) — v0.7.0 — Node ID: 1
I csi_collector: Promiscuous mode enabled (MGMT-only, RuView#396)
I csi_collector: CSI filter upgraded to MGMT+DATA (no display, RuView#893)
I csi_collector: CSI cb #1: len=384 rssi=-61 ch=1
...
I adaptive_ctrl: medium tick: state=5 yield=27pps ... (3–5 pps ambient, 27–30 pps under traffic)

Server side: node registers in /api/v1/mesh, csi_fps_ema ≈ 35, end-to-end pipeline live.

Suggested fixes

1. Refresh the release assets with post-fix(firmware): capture DATA frames on display-less boards — #893/#866/#897 (yield=0pps root cause) #906 display-less S3 binaries (both 8 MB and 4 MB) — currently a bare-S3 user following the release page cannot get CSI at all, and the in-repo release_bins workaround is hard to discover.
2. Harden display_is_active(): gate it on the probes that can actually fail on bare hardware (TCA9554 / FT3168 I2C readback — both correctly returned ESP_FAIL here) instead of the write-only SH8601 QSPI init. On this board the existing logs already contain everything needed for a correct decision.
3. Optionally provide an NVS override (e.g. display=0/1 via provision.py) so field units can force the filter behavior without reflashing a different variant.

Happy to test candidate binaries on this N16R8 — it reliably reproduces both failure modes.

Filed with Claude Code on behalf of the board owner after a live debugging session; all logs above are from real hardware (no mocks).