ESPectre
The future of Wi-Fi sensing
IEEE 802.11bf adds explicit WLAN sensing mechanisms to the Wi-Fi standard. ESPectre does not implement the amendment, but its work with current ESP32 CSI provides a practical way to study some of the same sensing problems today.
Why IEEE 802.11bf matters to ESPectre
Wi-Fi radios already estimate how a signal changes between transmitter and receiver so they can communicate reliably. IEEE 802.11bf adds procedures that let devices coordinate those measurements for sensing.
ESPectre explores motion sensing with the CSI exposed by supported ESP32 devices. This makes it possible to study algorithms, runtime behavior, and product integration before embedded 802.11bf hardware and developer APIs are widely available.
From communication to sensing
A Wi-Fi receiver does not observe only the data sent by a router. It also observes the radio channel through which that data arrived. Walls, furniture, people, and movement alter the paths taken by the signal. Channel State Information, or CSI, captures part of that channel response across the Wi-Fi subcarriers.
Most Wi-Fi systems use channel measurements internally to communicate reliably. Sensing asks a different question: what can changes in those measurements reveal about range, velocity, angle, motion, or other properties of objects in an area of interest?
That is the conceptual shift behind WLAN sensing. The network is no longer only carrying an application’s information; the behavior of the radio channel can become an input to the application.
What IEEE 802.11bf changes
IEEE 802.11bf-2025, published in September 2025 as Amendment 4 to the IEEE 802.11 standard, adds enhancements for WLAN sensing. It modifies the MAC and selected PHY service interfaces for sensing in license-exempt bands between 1 GHz and 7.125 GHz, and above 45 GHz.
The main practical change is coordination. According to the IEEE 802.11 WLAN Sensing Task Group, the standard provides mechanisms that let stations:
- Advertise their WLAN sensing capabilities.
- Request and set up transmissions used to obtain sensing measurements.
- Exchange sensing feedback and information.
These mechanisms let Wi-Fi devices schedule sensing exchanges and report the resulting measurements. Current ESP32 CSI sensing instead depends on ordinary network traffic and the diagnostic data exposed by the chipset.
A standard for measurements, not meaning
IEEE 802.11bf does not define a universal motion detector, presence detector, activity classifier, or room model. It standardizes mechanisms that help devices arrange and report sensing measurements. Turning those measurements into a trustworthy application result remains a separate signal-processing, machine-learning, and validation problem.
It also does not guarantee that every future Wi-Fi device will support sensing, that every chipset will expose the same developer API, or that an application can reuse today’s CSI algorithms unchanged. Implementations will still differ in antennas, bandwidth, timing, feedback format, calibration, and access policy.
Interoperable measurement procedures are only one layer of a sensing product. Useful results still depend on the radio, driver, data model, detector, product integration, and validation in representative environments.
ESPectre today and a possible future backend
| Layer | ESPectre today | Standards-backed direction |
|---|---|---|
| Measurements | CSI exposed by supported ESP32 devices from ordinary Wi-Fi traffic | Measurements obtained through deliberate sensing procedures and feedback |
| Platform boundary | ESP-IDF CSI capture APIs and current ESP32 radio behavior | A practical chipset and driver API exposing 802.11bf, or equivalent documented sensing data |
| Sensing logic | ESPectre features, detectors, readiness, calibration, and events | The same product contracts where measurement semantics permit, with algorithms revalidated or adapted as needed |
| Status | Implemented and tested on supported hardware | Exploratory, with no delivery date until suitable embedded hardware exists |
ESPectre separates its detector core and runtime from the ESP-IDF capture backend and product frontends. If suitable embedded hardware exposes documented sensing APIs, the project could add another measurement backend while retaining compatible runtime events and frontend integrations.
That is a design direction, not a compatibility claim. A real backend would require documented hardware access, a precise mapping of measurement semantics, new datasets, detector validation, resource measurements, and parity checks before it could be called supported.
What has to happen next
Hardware must implement useful sensing capabilities
The standard has been published, but embedded chipsets, radios, and firmware still have to turn it into practical products.
Drivers must expose stable measurement APIs
A capability hidden inside closed firmware cannot become an open sensing backend. Developers need documented access, timing, metadata, and failure behavior.
Algorithms must be validated against the new measurements
Better coordination may improve consistency, but it does not automatically preserve the statistics of current CSI features or the quality of existing detectors.
Products must make sensing visible and proportionate
Wi-Fi sensing avoids images and audio, but presence and movement data can still reveal routines. Standards, products, and deployments all need clear authorization, transparency, and security boundaries.
What ESPectre can do now
Current ESP32 hardware is enough to develop open algorithms, run reproducible tests, and integrate local motion events into existing products. This work also exposes the limits of traffic-dependent CSI, vendor-specific capture APIs, and measurements that were not designed as a sensing interface.
Standards-backed measurements could support more repeatable research and better coordination between devices, but those benefits must be tested on real implementations. For now, ESPectre focuses on validating the measurements available today and keeping the software boundaries ready for another radio backend.
The ESPectre roadmap therefore treats IEEE 802.11bf support as hardware-triggered. Work begins only when a suitable embedded platform provides documented access to the required measurements.