How to make it working on ESP32-Wroom-32

[ChinmayLale]

Hi RuView team,

I'm interested in running RuView on the original ESP32-WROOM-32 (ESP32-D0WD-V3) instead of an ESP32-S3.

My board information:

Chip: ESP32-D0WD-V3 (revision v3.1)
Wi-Fi + Bluetooth
240 MHz Dual Core
4 MB Flash

Detected with:

python -m esptool --port COM5 chip-id

Chip type: ESP32-D0WD-V3 (revision v3.1)
Features: Wi-Fi, BT, Dual Core, 240MHz
Crystal frequency: 40MHz

I understand that the current firmware targets the ESP32-S3, but after reading the firmware architecture it seems that most functionality is modular.

My goal is not to run every feature on the ESP32. I'm happy to move heavy processing (edge DSP, WASM, AI, etc.) to the host and use the ESP32 only for:

• Wi-Fi CSI capture
• CSI packet serialization
• UDP streaming to the Rust sensing server

Before starting a port, I wanted to ask:

1. Is there any hardware limitation that prevents the original ESP32 from acting as a CSI node?
2. Which firmware modules are strictly dependent on ESP32-S3 hardware?
3. Does the Rust sensing server require raw CSI frames, or does it expect features already computed by the firmware?
4. Would maintainers be interested in supporting or reviewing a community port for the original ESP32 if it becomes functional?

Thank you for building such an interesting project!

[micorreo079-cpu]

it doesnt work, is just marketing.
the firmware has bugs, and he never tested with real data. Even claude (the co-creator) tells you that all the time

[thehaiderx]

1. Hardware limitation — original ESP32 as CSI node?

Official stance in project docs is that original ESP32 is not officially supported. The user-guide FAQ directly addresses this (in context of ESP8266, but the same page separately states the minimum bar): the ESP32-S3 is the minimum supported CSI capture device, and a separate tutorial explicitly says ESP32 (original) and ESP32-C3 not supported — single-core, insufficient for CSI DSP.

That said — thoda nuance hai. Original ESP32-D0WD-V3 (jo tum use kar rahe ho) is actually dual-core at 240 MHz — the "single-core" reasoning in that quote applies cleanly to ESP32-C3 (which really is single-core RISC-V), but doesn't literally apply to your chip. ESP-IDF's WiFi CSI API (esp_wifi_set_csi_config, esp_wifi_set_csi_rx_cb) was actually introduced on the original ESP32 before S3 existed, so raw CSI capture at the hardware/API level is not blocked. The real risk is more about RAM/flash headroom and timing margins under load — the firmware's Tier 1 pipeline uses a lock-free SPSC ring buffer moving data from Core 0 to Core 1, which your chip can support architecturally.

So: no hard silicon blocker for Tier-1-only (capture → serialize → UDP), but maintainers haven't validated or supported it, and 4 MB flash is on the tighter end (S3 boards ship 4–8 MB too, so that part's comparable).

2. Which modules are strictly S3-dependent?

Based on what's documented, the S3-specific dependencies are mostly around the heavier tiers, not Tier 1:

• Tier 3 WASM VM (RVF containers, Ed25519-signed modules) — needs more flash/RAM headroom; binary size alone is already 820 KB with only ~80 KB headroom before hitting the 900 KB gate on S3.
• Tier 2 edge DSP (presence/vitals/fall detection, phase unwrap, Welford stats, top-K subcarrier selection) — CPU/RAM-bound, not S3-exclusive per se, but tuned/tested against S3's extra RAM.
• Display/touch peripherals on the devkit boards (SH8601 AMOLED, FT3168 touch) — irrelevant to your headless plan anyway.

Since your plan is exactly "CSI capture + serialization + UDP, everything else moves to host" — you'd essentially be targeting Tier 1 only, which is the part with the least S3-specific coupling.

3. Does the Rust sensing server need raw CSI, or precomputed features?

Raw. The ADR-018 binary format contains raw sensor data, sent as CSI packets with magic 0xC5110001 — this is the base packet type regardless of tier. Precomputed features only show up in the separate vitals packet (magic 0xC5110002, Tier 2), which is optional and only emitted if edge DSP is enabled on the node. So a Tier-1-only firmware sending nothing but raw CSI frames is a fully valid, first-class input to the server — you're not missing anything by skipping edge processing.

4. Would maintainers support/review a community port?

Can't confirm this from docs — that's a call the maintainers would need to make directly. Best move: open a GitHub Discussion or Issue on ruvnet/RuView proposing exactly what you told me (scope-limited Tier 1 port, no edge DSP), and reference that Rust server already just wants raw CSI over UDP regardless of source chip. Given the project already treats the aggregator/server as chip-agnostic at the protocol level, a PR that's additive (new sdkconfig target, no changes to existing S3 path) has a reasonable shot — but only maintainers can confirm review bandwidth.