RuView firmware fixes: ESP32-C6 onboarding restored and a leaner 4 MB build

What this is about

RuView turns ordinary WiFi signals into presence and room sensing, with no cameras. Small ESP32 boards act as sensing nodes: they listen to WiFi channel state information (CSI) and stream it to a server. How well that works depends on firmware that fits the board's flash and can be set up without fuss.

Two firmware fixes merged this week address exactly that. One is about fitting the firmware to 4 MB and 8 MB boards. The other repairs the USB path the macOS app uses to add an ESP32-C6 node. This story covers both because they touch the same firmware and the same boards.

A note on the release tags

v2828 and v2872 are automated server releases produced by the CI pipeline on each merge. PR #1904 itself documents that automated vNNNN releases are not firmware releases, and that firmware archives are meant to be published on dedicated vX.Y.Z-esp32 releases. When this story was checked, no such esp32 firmware release was listed yet. The news here is the merged fixes and the physical verification recorded for one of them, not the tags.

What changed

PR #1890, merged September 26 (commit 65247129, carried in v2828):

• The on-device logger writes to a FAT partition named storage, but only the 16 MB layout had one. The 8 MB layout stopped at 6 MB and left 2 MB unaddressed; a storage partition now fills it, so logging works on 8 MB boards.
• 4 MB layouts genuinely have no room, so the logger is compiled out there. The FAT and wear-levelling libraries drop out of the image.
• The PR measured an ESP32-S3 4 MB image going from 955,504 to 912,832 bytes (42,672 bytes recovered) with the same build method as CI.
• The v2828 release notes record verification on a physical ESP32-C6 (4 MB, ESP-IDF v5.4): the app image went from 1,085,424 to 1,042,368 bytes, 43,056 bytes smaller; the Failed to find FATFS partition storage error seen on every 4 MB C6 boot is gone; WiFi join, CSI start-up and CSI delivery to the host were confirmed; CI 35 of 35 green.
• Flashing note from the PR: the 8 MB partition table changes, so an existing 8 MB device needs a full erase rather than an over-the-air update.

PR #1904, merged September 27 (commit 5ef001b4, carried in v2872):

• USB Serial/JTAG becomes the primary ESP32-C6 console, so the onboarding hello message from the Mac app actually reaches the firmware. An ineffective secondary-console reader was removed, because secondary consoles in ESP-IDF are output only.
• The tracked C6 onboarding bundle now identifies itself as firmware 0.8.12; before, it embedded 0.8.11.
• A static delivery-contract check was added to the host test gate. The PR records that make host_tests passed and a local ESP-IDF 6.0.2 C6 build produced the expected console settings.
• Honest limit: the PR states that physical hello-and-configure verification on hardware remains an explicit post-build gate. No physical result for #1904 is published, so none is claimed here.

This follows the earlier RuView USB onboarding story from September 11. That release introduced the onboarding flow; #1904 repairs its delivery on the C6.

Get started

Prerequisites: an ESP32-S3 or ESP32-C6 board, a USB cable, Docker or ESP-IDF, and Python with esptool for flashing. There is no npm package, MCP server or npx skills package for the firmware, and no hosted demo.

The firmware README documents Docker as the reliable build method. Its documented build, run from the repository root, targets the ESP32-S3:

MSYS_NO_PATHCONV=1 docker run --rm \
  -v "$(pwd)/firmware/esp32-csi-node:/project" -w /project \
  espressif/idf:v5.4 bash -c \
  "rm -rf build sdkconfig && idf.py set-target esp32s3 && idf.py build"

For the C6, the README documents builds for the XIAO ESP32-C6 with an explicit antenna overlay, for example:

idf.py -D SDKCONFIG_DEFAULTS="sdkconfig.defaults;sdkconfig.defaults.esp32c6;sdkconfig.defaults.xiao-internal" \
  set-target esp32c6
idf.py build

Expected result: a build directory with the firmware image. The README says the boot log must report the intended antenna path before a measurement is labelled. For fresh installs it lists per-chip flash bundles, each with a short flashing guide, and warns never to flash an S3 bundle onto a C6. Boards on 0.8.8 or earlier need one full flash before onboarding will work.

Commands here were read from the release notes and repository documentation at the pinned reference; they were not executed as part of writing this article.

Use it today

Practical case: you are adding a 4 MB ESP32-C6 node to a room. Input is a fresh board and a WiFi network. The workflow is build or download the matching C6 image, flash it once, then add it through the macOS Add Sensor flow. The output is a node streaming CSI to your server, without a storage error on every boot.

Reader acceptance test: on a 4 MB C6 flashed with a build that includes #1890, the boot log should no longer print Failed to find FATFS partition storage, and the image should be roughly 43 KB smaller than the previous build. After #1904, the C6 should answer the onboarding hello over native USB; if it stays silent, check that the console is USB Serial/JTAG.

Push it further

Experimental commentary. Treating the partition table as a budget, and removing a feature where the flash cannot fit it rather than letting it fail at boot, is a pattern worth copying across edge firmware. The recovered space also gives the 4 MB layout more room for sensing features.

Limitation: the 4 MB builds now have no on-device log, and 8 MB boards need a full erase to pick up the new table. #1904 has not yet published a physical verification. Falsifiable test: flash the C6 bundle identifying as 0.8.12 and run the Mac onboarding. If the Mac app never sees the node as fresh, the delivery fix has not held on hardware.