yield=0pps on ESP32-S3-DevKitC-1-N8R8 (no display): MGMT-only filter starves CSI callback — pre-built binary fix needed

[dolle-ship-it]

We set up 6x ESP32-S3-DevKitC-1-N8R8 nodes (8MB Flash N8R8, no display) with a TP-Link EAP225 access point on channel 1 and Ubuntu 22.04 running sensing-server v0.3.1. All nodes connect to WiFi successfully — Got IP confirmed, RSSI around -50 dBm — but yield stays permanently at 0pps and no CSI cb messages ever appear in the serial output.

After investigation we found the root cause: the release_bins pre-built binaries are compiled with MGMT-only promiscuous filter as the RuView#396 workaround. This was designed to prevent SPI flash cache crashes on boards with QSPI displays. The ESP32-S3-DevKitC-1 has no display at all, so the crash risk simply does not apply to our hardware — but the MGMT-only filter starves the CSI callback (RuView#521) and yield collapses to zero permanently.

We fixed this by recompiling the firmware from source using Docker with espressif/idf:v5.4, changing the promiscuous filter to MGMT+DATA. The existing 50Hz rate gate in wifi_csi_callback (CSI_MIN_PROCESS_INTERVAL_US = 20ms) prevents the SPI flash cache crash on our hardware. After recompilation yield immediately jumped to 15-21 pps on all 6 nodes.

We would like to request a separate pre-built binary for display-less boards like the DevKitC-1. Many users will have exactly this board and hit the same issue without knowing why.

[ruvnet]

Your root cause analysis is correct — this is the same issue as #866. The MGMT-only promiscuous filter in the pre-built release binaries restricts CSI callbacks to management frames only, which starves the pipeline on DevKitC-1-N8R8 boards (and other variants) that don't generate enough management frame traffic to sustain a usable yield.

The absence of "CSI cb" log lines at all (vs. #897 where they appear every ~18s) suggests the filter may be even more restrictive on the N8R8 variant, possibly because its radio enters a lower beacon-listen rate when associated.

Until a fixed binary ships: building from source with the DATA promiscuous filter is the reliable workaround. The TP-Link EAP225 at -50 dBm RSSI rules out signal level as a factor — this is purely the filter.

---

Generated by Claude Code

[ruvnet]

Fixed — and hardware-verified. You nailed the root cause: the pre-built binaries set a MGMT-only promiscuous filter (the #396 workaround for the SPI-flash-cache crash on display boards), which only fires the CSI callback on sparse management frames — so on display-less boards (DevKitC-1, T7-S3, N8R8) yield collapses to 0 pps under real traffic.

Fix (merged to main, PR #906): after the boot-time display probe, boards with no AMOLED panel upgrade the filter to MGMT | DATA (csi_collector_enable_data_capture() gated on !display_is_active()). Display boards keep MGMT-only, preserving the #396 crash protection. No boot reorder.

Verified on real hardware (ESP32-C6, display-less):

• yield 0–5 pps → ~27 pps (≈6×)
• presence/motion detection came alive (flat-zero before)
• no ESP32-S3 CSI crash: SPI flash cache race in wDev_ProcessFiq during promiscuous mode #396 wDev_ProcessFiq crash over a sustained run
• log: Promiscuous mode enabled (MGMT-only, RuView#396) → CSI filter upgraded to MGMT+DATA (no display, RuView#893)

Pre-built binaries refreshed to v0.6.7 in #908 (S3 8MB/4MB, C6, S3-ADR-110). To get it now: build from main, or flash the refreshed release_bins once #908 lands (a tagged v0.6.7-esp32 release will follow). Thanks for the precise diagnosis.