Skip to content
Fresnel
Sign inRequest access

Wi-Fi sensing · end to end

From CSI capture to a deployed model, without leaving one pipeline

Collect Channel State Information on ESP hardware, let a reference sensor label it for you, train on it, and deploy where the model belongs. The parsing scripts, the phase alignment, the label spreadsheet — all of it is the platform's job, not yours.

Request beta accessExplore the open stackRead the field guide

We onboard by use case, from your intake answers.

Already have an account? Sign in.

Recorded capture4-node array · 500 Hz
amplitudesubcarriers · time
  • Receiver 1 (reference)
  • Receiver 2
  • Receiver 3
  • Receiver 4

phase

phase · aligned

Nodes
4
Rate
500 Hz
Frames
89
Node align
pseudo-sync

The beta is open — for researchers and for product teams.

Tell us what you're sensing, what hardware you have, and how much data you expect to collect. We onboard by use case, and we're still shaping the platform around what the first cohort actually needs.

Apply for the beta

The pipeline

Five stages. One system.

Today each stage is a different repo, a different notebook and a different afternoon. Fresnel makes them one continuous path from radio to running model.

  1. 01

    Data collection

    Shipping

    Flash the firmware, start a session, stream CSI frames off one board or a distributed array — locally or over the network from a site you aren't standing in. Every frame carries the metadata that makes it re-usable later: radio settings, antenna, node identity and timestamp.

  2. 02

    Analysis and sanitization

    Shipping

    Inspect amplitude and phase per receiver in the browser as it arrives. Remove the artifacts that make raw CSI unusable — phase offset, dropped frames, subcarrier nulls — with the corrections applied consistently across the whole dataset rather than per notebook.

  3. 03

    Model building

    In beta

    Start from CSI-native architectures for presence, activity and counting, or plug in your own through the SDK — anything ONNX-compatible. Feature extraction and windowing are configured against your capture, not re-derived from a paper's appendix.

  4. 04

    Training

    In beta

    Train hosted, or take the pipeline offline and train on your own machines. Either way you compare runs across environments and see where a model stops generalizing before it reaches a room it has never been in.

  5. 05

    Deployment

    In beta

    Some models belong on the node; some belong in your cloud. Deploy either way — back to the ESP hardware the data came from, or to infrastructure you run — and keep collecting from the deployed fleet so the next model is trained on the field, not the lab.

Why this is hard today

CSI work stalls before the model

  • Labeling is manual
    Someone stands with a stopwatch, performs the activity, and reconciles timestamps afterwards. Datasets stay small because collection is bound to a human in the room.
  • One room, one model
    A model trained in one room learns that room. Move the furniture and accuracy falls off — and most published CSI datasets are captured in a single environment, so the failure surfaces after you deploy rather than while you are still evaluating.
    Computer Communications, 2026 — a survey on CSI dataset reproducibility
  • Every rig is bespoke
    A parser per chipset, a fork per project, phase handled differently in each. The result is work that is hard to reproduce and harder to hand to a colleague.

What you get that you can't assemble yourself

The parts that were the hard part

  • Pseudo phase synchronization across nodes
    Patent pending
    Commodity radios don't share a clock, so every packet arrives against its own arbitrary phase reference and a multi-node capture is really several unaligned ones. Pseudo phase synchronization recovers the gauge-invariant relative phase between receivers — the part that does not depend on any packet's own reference — so a distributed array reads as one instrument instead of node by node.
  • Time-synchronized auto-labeling
    Point a camera running a people-counting model at the space, and its count becomes the label on the CSI arriving at that instant. Any reference sensor works — microphone, camera, IMU — aligned to the CSI clock. An hour of collection produces an hour of labeled data, unattended.
  • Remote and unattended collection
    Start, monitor and stop captures on nodes deployed anywhere on the network. Combined with auto-labeling, collecting a second and third environment stops being a week of fieldwork.
  • Bring your own model
    SDK
    Plug any ONNX-compatible model into the pipeline and keep the collection, labeling, training and deployment path around it. Your research stays yours; the plumbing stops being your problem.
  • Agent automation over MCP
    Planned
    Expose captures, datasets and training runs as tools an agent can drive — so sweeping a parameter across twenty sessions is a request, not twenty clicks.
  • Runs on hardware you can buy today
    ESP first
    Commodity ESP32 radios you can order today — not an SDR rack, and not a card discontinued in 2008 that you have to find second-hand. The pipeline is built to go chipset-agnostic; ESP is where it starts.

Open source

The capture path is open

The firmware and transport layers are Rust crates under the csi-rs organisation — read them, build them, run them without an account. The platform sits on top of them.

Explore the ecosystem
Core / Protocol Layer
Core and protocol crates the rest of the stack builds on.
esp-csi-rs
On-Device Interfaces
Interfaces that run on the ESP board itself.
esp-csi-cli-rsesp-csi-litetui-rsesp-csi-litegui-rs
Host-Side Applications
Tools that run on a computer and talk to the board.
csi-webserver
Browser Client
Browser client for the host webserver.
csi-webclient
  1. 01
    CaptureCollect CSI frames on the board.esp-csi-rs
  2. 02
    SessionStart a capture and forward the stream.esp-csi-cli-rs
  3. 03
    BridgeMove frames from the board to a client.csi-webserver
  4. 04
    ReadPlot amplitude and phase live.csi-webclient

Apply for the beta

A few questions about what you're trying to sense, the hardware you have, and your timeline. We read every one and onboard by use case — the beta is how we find out which parts of this matter most.

Request beta accessRead the docs