release_bins 0.6.7 yields 0 pps CSI on ESP32-S3-DevKitC-1 (RuView#893 fix verified on C6 only)

Summary

Flashing the pre-built firmware/esp32-csi-node/release_bins/ binaries (v0.6.7) to a stock ESP32-S3-DevKitC-1 gives sustained yield=0pps - no CSI ever reaches the host. Rebuilding from source with the sdkconfig.defaults.devkitc overlay on the same board gives 29-38 pps.

release_bins/version.txt records this as fixed:

note: RuView#893 - display-less boards capture DATA frames (CSI yield 0pps fix);
      hardware-verified on ESP32-C6 (0->27 pps)

The verification appears to have covered the C6 but not the S3 DevKitC-1, where the failure still reproduces.

Observed

Two boards, both stock ESP32-S3-DevKitC-1 class, 8 MB flash, no display attached:

• 58:e6:c5:67:84:ec
• 14:c1:9f:db:8b:38

Flashed from release_bins/ per the README Quick Start step 0. Both associate to WiFi normally and report healthy RSSI, but:

I (1510061) adaptive_ctrl: medium tick: state=8 yield=0pps motion=0.00 presence=0.00 rssi=-53
I (1511061) adaptive_ctrl: medium tick: state=8 yield=0pps motion=0.00 presence=0.00 rssi=-54

sustained indefinitely (observed to ~25 min uptime). No csi_collector: CSI cb #N lines appear at any point. Note state=8.

After rebuilding from source with the overlay documented in the header of sdkconfig.defaults.devkitc:

idf.py -DSDKCONFIG_DEFAULTS='sdkconfig.defaults;sdkconfig.defaults.devkitc' set-target esp32s3
idf.py -DSDKCONFIG_DEFAULTS='sdkconfig.defaults;sdkconfig.defaults.devkitc' build

the same board, same room, same AP:

I (23318) csi_collector: CSI cb #600: len=384 rssi=-61 ch=1
I (23488) adaptive_ctrl: medium tick: state=5 yield=35pps motion=0.00 presence=0.00 rssi=-61

Note state=5 rather than state=8.

Likely cause

sdkconfig.defaults.devkitc documents precisely this failure mode:

The stock ESP32-S3-DevKitC-1 has no AMOLED panel, but the ADR-045 runtime probe false-positives on it: with no TCA9554 and floating QSPI pins, the SH8601 init sequence reports success, display_is_active() returns true, and main.c skips the RuView#893 MGMT+DATA promiscuous upgrade - CSI yield collapses to 0 pps (the exact symptom #893 fixed).

That is consistent with the C6 passing verification: it does not present the same floating-QSPI probe false-positive, so the runtime path there is not affected.

Caveat on the evidence: two variables changed between the failing and working runs (prebuilt -> source, and no-overlay -> overlay), so this is not a strict A/B isolating the overlay alone. I did not build a no-overlay binary from source to complete the matrix. The symptom does match the documented mechanism exactly.

Impact

README Quick Start step 0 directs new users to these binaries to skip the build, and the firmware README's Hardware Requirements table lists ESP32-S3-DevKitC-1 as a recommended board. The combination is a device that boots, joins WiFi, logs healthy RSSI, and streams nothing - with no error anywhere to indicate why. Docker is required to build from source, so the prebuilt path is the one most first-time users will take.

Suggested fix

Either build release_bins/ with the devkitc overlay, or ship a second set (e.g. release_bins/devkitc/) with the distinction called out in the Quick Start.

Minor, separate

The firmware README Quick Start heading reads "Pre-built binaries (v0.6.5 - skip the build step)" while release_bins/version.txt says 0.6.7.

Start with firmware/esp32-csi-node/sdkconfig.defaults.devkitc, release_bins/version.txt, and the firmware README Quick Start. Compare the prebuilt configuration with the documented devkitc overlay, then reproduce on an ESP32-S3-DevKitC-1 using the release binaries and source-build commands. Done means the prebuilt path produces CSI callbacks and nonzero yield, and the README/version labeling clearly identifies the supported binary.