Can the firmware do CSI capture only on plain ESP32 (LX6)?

[udiNur]

I want to use an original ESP32 board as a dumb CSI source — capture
frames in the promiscuous callback, ship them off the chip over UDP
or serial, do all the DSP and pose work elsewhere. No on-device DSP,
no display, no mmWave, no WASM.

I know CLAUDE.md says original ESP32 isn't supported. But reading
the reasoning (DSP throughput, dual-core pinning, pose fusion), it
looks like it's about what the chip can't do on-device. If I strip
all that and only run the capture path, does the unsupported label
still apply?

Board is an ESP32-D0WD-V3 rev v3.1, dual-core LX6, 240 MHz, 4 MB
flash. PSRAM presence unconfirmed (esptool can't read external PSRAM
via efuse on classic ESP32). Host is macOS arm64.

What I checked locally before opening this:

• No S3-only APIs in firmware/esp32-csi-node/main/ — no esp_psram_*,
  no USB-JTAG, no LCD_CAM, no vector intrinsics.
• The CSI calls in csi_collector.c look chip-agnostic.
• partitions_4mb.csv has no S3 markers, fits my flash.

So the open questions:

1. Is the unsupported tag about WiFi MAC / CSI report format
   differences, or just about DSP headroom? If it's just headroom,
   capture-only sidesteps it.
2. Are the CSI fields (subcarrier count, phase format, antenna layout,
   secondary-channel behavior) the same coming off LX6 vs LX7? Anything
   in signal/ or ruvsense/ calibrated to S3 quirks that downstream
   code would have to compensate for?
3. The 50 Hz throttle in csi_collector.c:70-86 mitigates the
   wDev_ProcessFiq cache race — possibly related to ESP32-S3 CSI crash: SPI flash cache race in wDev_ProcessFiq during promiscuous mode #396. Does that
   race look the same on LX6 or worse?
4. Is there a Kconfig path to compile out edge_processing / display /
   mmWave / WASM, or is it source-level?
5. Does firmware/esp32-csi-node: IDF 6 build, HE CSI config, unicore DSP, provision chip detect #522's chip-detect handle plain ESP32, or only C6/S3?

#522 looks like the right base for this. Happy to take a stab at it
and open a draft PR if the answers above don't show a hard blocker.
Don't want to spend the time if there's something I'm missing.

Refs: #522, #524, #396, #560.

[ruvnet]

The original ESP32 (including D0WD-V3) is explicitly not supported by this project — see the hardware table in the README and CLAUDE.md:

Device	Role	Status
ESP32-S3 (8MB flash)	WiFi CSI sensing node	✅ Supported
ESP32-S3 SuperMini (4MB)	WiFi CSI (compact)	✅ Supported
ESP32 (original, LX6)	—	❌ Not supported
ESP32-C3	—	❌ Not supported

The primary reason is the CSI API and DSP pipeline compatibility, not just core count. The firmware and signal processing pipeline were designed and validated against the S3's Xtensa LX7 CSI interface and the esp_wifi_csi_cb implementation on IDF v5.4. The LX6-based original ESP32 uses a different, undocumented wDev_ProcessFiq hook for CSI that has known race conditions and format differences (different subcarrier layout, phase representation, and header structure) that would require substantial re-validation.

For the questions you raised:

• "Dumb capture-only" offloading: The firmware still relies on S3-specific CSI packet framing — the format isn't directly portable even for pure capture.
• firmware/esp32-csi-node: IDF 6 build, HE CSI config, unicore DSP, provision chip detect #522 chip-detect: That handles S3 vs S3-SuperMini (4MB vs 8MB flash) variants, not LX6 vs LX7.

Recommendation: ESP32-S3-based boards (the ~$6 SuperMini or ~$9 standard S3) are the supported and tested path. If board cost is a constraint, the SuperMini at ~$6 is the lowest-cost option that works out of the box.

---

Generated by Claude Code

[cyberfortress762]

I'm trying to run RuView on an ESP32-S3 (specifically the YD-ESP32-S3 2022 V1.3). I know the firmware is designed to filter and log only MGMT frames, but my board isn't capturing any frames at all.

I wanted to ask: is there any known incompatibility with this specific YD V1.3 model? Has anyone successfully used this exact board?

Any insights would be appreciated. Thanks!

[ruvnet]

@cyberfortress762 The YD-ESP32-S3 2022 V1.3 is an ESP32-S3 module and should be compatible — it's not on the known-incompatible list. "No frames captured" on a supported S3 board is almost always a provisioning or connectivity issue rather than hardware incompatibility.

Checklist to diagnose:

1. Serial monitor — flash the firmware, open a serial monitor at 115200 baud, and look for csi_collector: CSI cb #N: lines. If those are absent, CSI collection isn't starting (usually means WiFi hasn't associated yet or provisioning is incomplete).
2. Provisioning — run provision.py --port <COMx> --ssid <your-AP> --password <pw> --target-ip <aggregator-ip>. The board needs to know where to send UDP frames.
3. UDP listener — confirm sensing-server (or your aggregator) is listening on UDP port 5005 on the correct interface.
4. MGMT frame note — CSI frames from the firmware are sent as UDP packets to the aggregator, not logged as raw 802.11 MGMT frames. If you're using a packet sniffer expecting MGMT frames, that's a different layer.

The ESP32-S3 end-to-end setup tutorial (#34) and Known Issues & Troubleshooting guide (#301) cover the full bring-up checklist with expected serial output at each step.

---

Generated by Claude Code