rvCSI hardens the runtime that turns WiFi CSI into typed events

What rvCSI is

Channel state information is the raw material of WiFi sensing, and getting at it is miserable: every chipset formats it differently, drivers are unstable, and most pipelines are a chain of scripts nobody can rerun.

rvCSI normalises CSI from Nexmon, ESP32, Intel, Atheros, files and replay into validated, typed, confidence scored events, from Rust, TypeScript or the command line.

What changed

Commit 2ef4fd1 is correctness work: implicit unwraps removed, dead code deleted, and rough edges closed across the workspace. For a runtime that other projects build on, that matters more than a feature.

Earlier in the series, commit 1ba7c98 exposed the live capture API through CaptureRuntime, and a CI commit set up npm publishing of @ruv/rvcsi through OIDC trusted publishing.

Get started

A Rust toolchain, or Node 18 or newer. For the CLI:

cargo install rvcsi-cli

Expected result: an rvcsi binary on your path.

For TypeScript:

npm install @ruv/rvcsi

Inspect a capture file without any radio hardware connected:

import { inspectCaptureFile, eventsFromCaptureFile } from "@ruv/rvcsi";

console.log(inspectCaptureFile("session.rvcsi"));
for (const ev of eventsFromCaptureFile("session.rvcsi"))
  console.log(ev.kind, ev.confidence, ev.timestampNs);

Expected result: frame count, channels and quality, then a stream of typed events with confidence scores.

The workspace includes rvcsi-mcp, an MCP tool server, alongside the daemon and the ESP32 adapter.

Use it today

Practical case: a sensing experiment you need to be able to repeat. Input is a recorded .rvcsi capture. Workflow is inspect, then run the DSP cleaned frames through the runtime, then read events. Output is a reproducible event stream from a fixed file.

Acceptance test: run cargo test --workspace in a checkout and confirm the suite passes before you attach any radio.

Push it further

Experimental commentary. Because rvCSI abstracts the chipset, a single sensing model can in principle be trained on one radio and deployed on another. That is the promise; treat it as untested for your hardware pair.

Limitation: normalisation does not erase physical differences between radios. Falsifiable test: record the same scene on two chipsets, run both through the runtime, and compare the event streams.