The short answer is yes: channel state information can carry repeatable changes caused by a gesture, and a classifier can learn those changes. The difficult part is not drawing a waveform. It is collecting enough representative packets, keeping the transmitter and receiver stable, defining labels that a person can repeat, and proving that the model recognizes the gesture rather than the room, the participant, or a particular capture session.
A useful first project has a narrow vocabulary such as swipe left, swipe right, push, pull, and idle. It records CSI with the same hardware and packet configuration, separates calibration from gesture windows, and evaluates a person or room that was not used during training. If the goal is only presence or generic movement, the existing WiFi presence and motion guides are a better fit; gesture recognition needs a more specific label and a stricter validation plan.
This article connects the practical capture path to research datasets such as WIDAR3 and SignFi, then explains where ESP32 CSI, Linux CSI tools, and an open-source model fit. The key idea is simple: every impressive prediction should be tied to a known signal source, a reproducible label, and a test split that measures the failure you actually care about.
What WiFi CSI gesture recognition actually recognizes
CSI describes how a wireless channel changes across subcarriers, antennas, packets, and time. A moving hand changes multipath and phase relationships in a way that may be repeatable for a particular setup. A model does not see a human-readable gesture; it sees a time window of measurements after packet filtering, calibration, normalization, and feature extraction. The final class is an inference about that window, not a direct image of the person.
Keep the target task narrower than the marketing language. A five-class wave gesture experiment, a sign-language vocabulary, and a room-level activity recognizer have different data needs. A model that separates gestures from one participant in one room may fail when the participant changes, the receiver moves, furniture is added, or the radio channel becomes busy. The page should report those boundaries instead of presenting a camera-free classifier as universal perception.
- Good first task: 3–6 deliberate gestures plus an idle or unknown class.
- Useful output: class, confidence, and an unknown state when the window is ambiguous.
- Do not assume a router exposes raw CSI just because it advertises WiFi sensing.
- Presence, motion, pose, identity, and gesture recognition are related but separate tasks.
The capture-to-class pipeline
A reproducible pipeline begins with a packet source, a CSI-capable receiver, fixed placement, and a documented channel configuration. The capture process should preserve timestamps and enough metadata to reconstruct which participant, gesture, distance, antenna arrangement, and room condition produced each window. Save raw or minimally processed data before experimenting with filters so that a promising result can be audited later.
Preprocessing is part of the model boundary. Remove corrupted packets, align or interpolate the time series only when justified, normalize amplitudes carefully, and separate training transformations from test data. If a filter uses information from the complete recording, it can leak the answer into the evaluation. Start with a transparent baseline before adding complex neural architectures.
| Stage | What to record | Common failure |
|---|---|---|
| Capture | CSI packets, timestamps, channel, antennas, room | A connectivity demo with no usable raw CSI |
| Cleaning | Packet quality, missing values, calibration choices | A filter that removes the gesture or leaks test information |
| Labeling | Gesture name, start/end, participant, repetition | Loose windows that include different movements |
| Training | Feature transform, split, seed, model version | Random windows from one session in both train and test |
| Evaluation | Unseen person, room, day, and unknown cases | Reporting only the easiest within-session accuracy |
Hardware: start with CSI access, not a marketing label
ESP32 CSI is a practical low-cost starting point when the board, firmware, ESP-IDF version, packet source, and antenna arrangement are documented. Espressif’s esp-csi examples are useful because they show the capture side, but an ESP32 board is not a finished gesture sensor. You still need a stable transmitter, a receiver callback or logger, a time window, labels, and an evaluation script.
A Linux laptop with a compatible network card can provide a different capture path, while a Raspberry Pi can host logging, inference, or a display without automatically becoming a CSI receiver. When comparing projects, classify them as capture tools, datasets, visualization demos, model code, or complete applications. That classification prevents a polished repository screenshot from being mistaken for a reproducible end-to-end system.
- Confirm that the exact board or NIC exposes CSI, not only RSSI or a vendor-level sensing feature.
- Record firmware, driver, channel width, sampling behavior, antenna path, and packet source.
- Keep transmitter and receiver placement fixed during the first baseline.
- Use the ESP32 CSI guide and open-source project guide when the hardware path is unclear.
Datasets and labels: WIDAR3, SignFi, and your own room
Public datasets help you compare preprocessing and model ideas before building a full capture rig. WIDAR3 is useful for studying WiFi-based gesture or activity representations across people and locations, while SignFi is associated with WiFi-based sign recognition. A benchmark can reveal whether your code runs, but its devices, sampling protocol, labels, and environment may not match your hardware. Treat published accuracy as a reference point, not a promise for your room.
Your own dataset is still necessary when the deployment environment matters. Define each gesture with a short instruction, collect multiple repetitions at different speeds, include idle and accidental movements, and preserve participant and session identifiers. Split by participant or session before windowing where possible. If adjacent windows from the same recording appear in both train and test, the score can measure memorization of a signal segment rather than generalization.
| Data route | Best use | Caution |
|---|---|---|
| Public gesture dataset | Reproduce a paper or test a preprocessing baseline | Hardware, room, labels, and sampling may differ |
| Small controlled capture | Check whether the chosen hardware responds at all | Easy to overestimate accuracy with one participant |
| Multi-session capture | Measure day, room, and participant drift | Requires metadata and stricter split rules |
| Deployment-like stream | Test latency, unknown gestures, and packet loss | A model score alone does not measure reliability |
Preprocessing and model training
Begin with a baseline that a reader can inspect: amplitude or phase features, a fixed-length window, a simple classifier, and a confusion matrix. Then compare more advanced choices such as convolutional layers, recurrent models, attention, or time-frequency representations. The useful comparison is not only which model wins on a single split; it is which representation remains understandable when the room or participant changes.
Avoid turning augmentation into a hidden claim about physics. Noise injection, time scaling, channel masking, and amplitude normalization can improve robustness, but they do not replace real variation. Keep a final holdout session untouched until the pipeline is locked. Report class balance, macro-F1 or per-class recall, latency, unknown handling, and the number of false triggers in an idle room.
- Use a session- or participant-level split before creating overlapping windows.
- Keep preprocessing parameters learned from training data only.
- Inspect confusion between visually similar gestures and the idle class.
- Log latency, packet loss, false triggers, and unknown predictions alongside accuracy.
How to validate across people and rooms
The most important test is usually not another random window from the same recording. Ask whether a new participant, a changed room, a moved receiver, another day, or ordinary background movement breaks the classifier. A strong validation plan names the intended deployment boundary and creates a test split that represents it. If the model is only intended for one person and one fixed room, say so and avoid general claims.
Use the same gesture instruction in every session, but do not force identical timing or posture. Add negative cases such as walking past the link, a fan, a door, a pet, and an empty room when they are plausible in the deployment. Compare per-class recall and false alarms, then inspect representative failures. A model that is slightly less accurate but fails visibly and can enter an unknown state may be safer than a model that makes confident guesses on every window.
- Within-session split: useful for debugging, weak evidence of deployment readiness.
- Unseen participant split: tests whether the model learned a person-specific motion style.
- Unseen room or day: tests multipath and environmental drift.
- Negative and unknown cases: tests whether the system can decline to classify.
Limits, privacy, and a sensible next step
CSI gesture recognition is sensitive to geometry, hardware, firmware, channel traffic, walls, furniture, and the behavior of the people being measured. The same gesture can create different traces in another room, and an unrelated movement can look similar to a trained class. It should not be described as camera replacement, identity recognition, or a medical or safety decision system without task-specific evidence and independent safeguards.
Radio sensing can still expose patterns of occupancy, movement, and routine even when no camera is stored. Explain what is collected, prefer local processing, keep raw CSI only as long as the experiment needs it, and let participants know when sensing is active. For a practical next step, start with the CSI hardware guide, choose one public dataset or a five-class local capture, and write the participant/room split before training the first model.
- Treat the gesture vocabulary, room, people, and hardware as part of the system specification.
- Do not infer identity, health status, or hidden activity from a gesture classifier.
- Keep a visible unknown state and an independent sensor for high-consequence actions.
- Link every reported score to a data split, session count, and failure definition.
Primary technical references
WiFi CSI gesture recognition FAQ
Is WiFi CSI gesture recognition the same as WiFi motion detection?
No. Motion detection asks whether a change occurred, while gesture recognition maps a time window to one of several defined classes. A motion detector can be a useful baseline, but it does not prove that a model can distinguish gestures.
Can an ESP32 recognize gestures by itself?
An ESP32 with a compatible CSI capture path can collect useful measurements, but recognition still needs a packet source, stable placement, preprocessing, labels, a model, and validation. The board is a capture component, not automatically a finished sensor.
How many gestures should a first dataset contain?
Start with three to six deliberate gestures plus idle or unknown. A small vocabulary makes labeling and failure analysis possible. Add gestures only after the model has been tested with new sessions and participants.
What is the best WiFi CSI gesture dataset?
There is no universal best dataset. Choose one whose hardware, gesture vocabulary, sampling protocol, and participant or room diversity match your question. Public datasets are useful for reproduction; a deployment still needs local data.
Why does a gesture model work in one room but fail in another?
CSI depends on multipath, antenna geometry, furniture, people, channel traffic, and device placement. If the training split does not include room or participant changes, the model may learn the recording environment instead of a portable gesture representation.
Can WiFi CSI gesture recognition identify a person or diagnose health?
A gesture classifier should not be treated as an identity or medical system. Those claims require separate tasks, evidence, consent, privacy controls, and independent validation. Keep the output limited to the tested gesture vocabulary and show an unknown state when the signal is ambiguous.