You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ESP32 Wi-Fi-CSI sensing meshes — the RF-and-architecture guide: verified answers to the antenna, crystal/phase-coherence, band/chip, and survey questions, with the numbers, the papers, and the corrections to our own prior write-up
You want to build a mesh of cheap ESP32 nodes that sense a room from Wi-Fi Channel State Information (CSI) — presence, motion, breathing — and you have hit the questions the datasheets half-answer and the forums answer wrong:
Are PCB antennas "too noisy" for sensing? (guide Section 1)
Can you skip custom co-crystal boards by syncing phase from a central laptop? (Section 2)
Is 5 GHz worth it, and what does the ESP32 actually hand you for CSI? (Section 3)
How fast can a per-room survey really be? (Section 4)
This guide adjudicates each one against primary sources, separates the measured facts from the labeled opinions, and tells you which questions only a bench can answer.
Provenance: a verification-heavy pass (2026-07-12).
Roughly 176 labeled claims across five topic reports.
Each load-bearing claim traced to a primary source (peer-reviewed papers, IEEE 802.11 clauses, chip datasheets/TRMs, Espressif code and issue trackers).
Each claim subjected to a one-line refutation attempt.
Where a source failed, the claim moved to a "Refuted — do not re-import" list rather than being softened — including three claims from our own prior gist refuted outright (see the callout below).
Everything the literature could not settle is declared a numbered bench experiment on hardware we own.
Corrections to the prior guide (read this first)
The prior gist (linked at the bottom) was written before this verification pass. Three of its claims did not survive primary-source checking and must not be carried forward:
"Phase sensing effectively requires co-crystal hardware" — too strong.
Holds instead: single-node phase-based sensing (respiration, Doppler, detrended-phase features) on independent-crystal TX/RX pairs is standard and proven — [preprint]FarSense (arXiv:1907.03994), [peer-reviewed]Widar2.0 (Qian et al., MobiSys 2018), delay-domain methods. The co-crystal requirement is real but scoped to multi-chain / multi-node coherent processing (per-node AoA, a distributed coherent aperture, absolute ToF).
So (for the MVP): you do not need co-crystal boards. (Full adjudication: guide Section 2.)
"The ESP32-C5 does Wi-Fi 6 at 40 MHz" — false.
Holds instead: on the C5, HE (11ax) and VHT (11ac) CSI are 20 MHz-only; 40 MHz exists only as 11n HT40, and there is no 80/160 MHz CSI anywhere in the ESP32 family — datasheet + Espressif engineer, [vendor]esp-idf #18493.
So (for the MVP): expect 20 MHz CSI, HT40 only via 11n — never 80/160 MHz. (Guide Section 3.)
"C6 subcarrier table" — undocumented, do not cite ours as fact.
Holds instead: no ESP-IDF version publishes a CSI subcarrier/buffer table for the ESP32-C6 (the doc section is empty in latest and stable); the numbers floating around are community-reported only. The documented C5 counts are 57/56 usable at HT20 and 117/114 at HT40 (not the "56 / 128" figures seen elsewhere — 128 is a zero-padded buffer size).
So (for the MVP): treat C6 subcarrier counts as unverified; use the documented C5 counts. (Guide Section 3; bench item 10.)
Confidence labels (the ladder used throughout)
Label
Meaning
[peer-reviewed]
published, venue-reviewed paper
[preprint]
arXiv / not-yet-in-venue (e.g. the 2024–2026 ISAC surveys)
arithmetic from cited numbers (labeled so you can strip it)
[lead]
fetched but not adversarially verified — read it yourself before relying on it
Facts (the first six) are kept visibly separate from [derived] inferences and from clearly-labeled recommendations, so a reader can strip the opinions and the facts still stand. Every [peer-reviewed]/[preprint] claim names its paper in-line (title + first author + venue/year + link) — no bare labels. Goal: you finish able to make and defend a different choice than we would, not copy a recommendation.
The main guide, four sections: 1. Antennas & ground planes (what actually degrades CSI vs what's just a static baseline shift; the detune tradeoff quantified). 2. Cross-node phase coherence (the crystal question: fails-as-stated for coherent phase, holds-reinterpreted as per-packet sanitization + central feature fusion; the CFO/SFO/CPO/PDD error budget). 3. Bands & what the ESP32 exposes for CSI (2.4 vs 5 GHz; the per-chip S3/C5/C6 CSI matrix; the 20 MHz-only limit; the lltf_bit_mode trap; Wi-Fi 6/7 sounding "in the protocol, not app-accessible"; no software beam-steering). 4. Survey automation (annotated walk-throughs + transfer learning; the phone-orientation-survey idea = no prior art but composes proven pieces). Each section carries its own "Refuted — do not re-import" block.
Every "unstudied / no-prior-art / needs-experiment" gap turned into a numbered experiment on our bench (NanoVNA / tinySA / PPK2 / S3-C5-C6 boards): antenna-type CSI noise floor, metal-proximity detune curve, detune-vs-CSI-information, vibration & PSU screens, inter-node CFO stability, PDD jitter per chip, static-path anchoring, C5 5 GHz CSI + the lltf_bit_mode trap, and the phone-orientation survey. Each: hypothesis · setup · measurement · what the result means.
Underlying evidence (not published here): the five topic reports with per-claim source registers live in the project vault at docs/.research/csi-rf/topic-*.md.
ESP32-CSI bench-experiment plan — every "the literature can't settle this" gap, turned into a measurement on hardware we own
The research pass (2026-07-12) was honest about its limits: where no primary source could settle a question, it declared a gap and routed it here. This is that list, as numbered experiments on the bench we bought.
The bench:
ESP32-S3 / C5 / C6 dev boards
NanoVNA (≤3 GHz, ~4.4 GHz in harmonics mode)
tinySA
Nordic PPK2
the antennas and the 60 GHz MR60BHA2
Each experiment states a hypothesis (what the literature predicts, with its citation), a setup, a measurement, and what the result means for the design.
Run order. Do them roughly in numeric order — the antenna-filter and phase experiments (1–7) are foundational; the C5 5 GHz and survey experiments (8–11) depend on firmware that is further out. The full roster:
Experiment
Group
Depends on
Order
1. Antenna-type CSI-noise floor
1 — Antennas & static-filter
Bench hardware (foundational)
1
2. Metal-proximity detune curve
1 — Antennas & static-filter
Bench hardware (foundational)
2
3. Detune-vs-CSI-information
1 — Antennas & static-filter
Bench hardware (foundational)
3
4. Antenna/cable vibration sensitivity
1 — Antennas & static-filter
Bench hardware (foundational)
4
5. PSU noise screen
1 — Antennas & static-filter
Bench hardware (foundational)
5
6. (stretch) Amplitude-SAR taste test
1 — Antennas & static-filter
Bench hardware (foundational)
6
7. Inter-node CFO stability
2 — Phase coherence
Bench hardware (foundational)
7
8. PDD-jitter distribution per chip
2 — Phase coherence
Firmware (further out)
8
9. Static-path anchoring viability
2 — Phase coherence
Firmware (further out)
9
10. C5 5 GHz CSI characterization
3 — C5 5 GHz & protocol edges
Firmware (further out)
10
11. Phone-orientation-labeled survey
4 — Survey automation
Firmware (further out)
11
Reading order note. These map onto the guide's four sections; the "why it's a gap" for each traces to a topic report (docs/.research/csi-rf/topic-*.md). Nothing here re-derives literature — these are only the questions the literature genuinely left open for our exact hardware.
Group 1 — Antennas & the static-filter model (Section 1)
1. Antenna-type CSI-noise floor
Gap: no paper measures raw CSI variance vs antenna type — [preprint]Strohmayer & Kampel 2024 compared downstream HAR accuracy, not the noise floor.
Hypothesis: once RSSI is equalized, built-in PIFA ≈ external whip ≈ whip-with-ground-plane-change — because the antenna is a static linear filter, not a noise source [derived, Section 1].
A difference at equal RSSI would falsify the static-filter model.
Setup:
Set up a static room with a tripod-mounted S3 TX/RX pair.
Stream 100 Hz ESP-NOW CSI.
Record 10 min each for three antenna conditions:
(a) built-in PIFA
(b) external whip on U.FL
(c) whip + module on/off a 10×10 cm copper sheet
Measurement:
per-subcarrier amplitude σ/μ
Allan deviation
Equalize mean RSSI across conditions — pad with an inline attenuator, not TX power.
What the result means:
if σ/μ matches across antennas at equal RSSI → the "static baseline, not noise" model holds → you can use PCB antennas and calibrate rather than match hardware across the fleet.
if it differs at equal RSSI → the static-filter argument breaks.
2. Metal-proximity detune curve
Gap: no open S11-vs-distance-to-metal curve exists — the [lead] SiLabs whitepaper's data is behind a form (read it yourself).
Espressif's 15 mm clearance rule [datasheet] is unquantified on our antennas.
Hypothesis: a conductive plane's effect on S11 changes with distance [derived, Section 1]:
inside ~λ/4 (≈30 mm at 2.44 GHz) → S11 degrades smoothly as the plane approaches.
at λ/8 (~15 mm) → it acts as a reflector (gain + nulls).
closer than that → it loads/mismatches the antenna.
Setup:
Connect the NanoVNA to the whip via U.FL.
Sweep S11 2.3–2.6 GHz at 0/5/10/15/20/30/50 mm from an aluminum sheet.
Repeat the sweep inside an aluminum corner.
Measurement:
S11 VSWR vs distance
resonant-frequency shift vs distance
Note the distance where VSWR crosses 2.
What the result means:
produces the detune-vs-distance curve the app notes only allude to.
if the curve matches the 15 mm rule → it validates the rule for our enclosures; if not → it corrects it.
the curve tells you how close an aluminum corner may sit before it stops being a usable reflector.
3. Detune-vs-CSI-information (the engineer's core question)
Gap: no literature on deliberately detuned antennas for sensing — the whole "70 % loss OK, 99 % not" question is unstudied [Section 1, A3].
Hypothesis: a static detune costs link budget, not calibratability — sensing SNR (dynamic multipath, tens of dB below LOS — [peer-reviewed]FarSense premise (arXiv:1907.03994)) runs out long before comms SNR.
−5 dB detune → tolerable.
−20 dB detune → destroys sensing at room scale.
Setup:
Insert a known mismatch (NanoVNA-measured): nominal / −5 / −10 / −20 dB, via a detuning sleeve or ground-plane butchery.
Add an inline attenuator as a clean control — changes level without changing the pattern.
For each condition, record:
RSSI
per-subcarrier CSI SNR
a fixed sensing task: person walks a marked path; breathing at 2 m.
Measurement:
the "dB of degradation vs sensing accuracy" curve
Compare detune vs equivalent-attenuator to separate mismatch-loss from pattern-distortion effects.
What the result means:
turns the engineer's 70 %/99 % intuition into an actual spec → how much antenna degradation the design can absorb before breathing-at-range fails.
4. Antenna/cable vibration sensitivity
Gap: unquantified — no paper measures antenna-vibration-induced CSI noise on ESP32 [Section 1, A1/A4].
Hypothesis:time-varying antenna behavior (a swaying cable, a tapped mount) injects CSI variance comparable to real motion.
This is the actual noise mechanism, unlike the static ground-plane effect.
Setup:
Establish a static link.
Tap/fan-buffet each of these separately: the antenna mount, the coax, the enclosure.
Measurement:
induced CSI variance vs that of a person walking at 3 m (the reference "real signal")
What the result means:
sets the mechanical-mounting spec.
if vibration-induced variance rivals real motion → "rigid mounting is a sensing requirement" is a real constraint.
if it does not → that requirement is over-caution.
5. PSU noise screen
Gap: "PSU quality matters" is folklore.
The real in-band path is conducted supply ripple, not radiated 2.4 GHz (Espressif troubleshooting [datasheet], Section 1).
Hypothesis: cheap wall-warts differ mainly by 3V3-rail ripple.
battery (or the PPK2 as a clean source) is the quiet ground truth.
Setup:
For each candidate wall-wart, probe with the tinySA at the 3V3 rail (conducted, via probe).
Probe near the antenna (radiated, 2.4–2.5 GHz).
Measure the CSI noise floor on battery vs that PSU (the PPK2 doubles as the clean reference supply).
Measurement:
rail ripple spectrum per PSU
CSI noise floor per PSU, vs battery
What the result means:
yields a per-PSU-model go/no-go screen.
confirms which coupling path (conducted vs radiated) actually matters.
6. (stretch) Amplitude-SAR taste test
Gap: feasibility of the "moving chip images a static scene" idea (Section 1, A5) on our hardware.
Hypothesis: a moving node produces a repeatable spatial CSI-magnitude signature of a large static metal object, even without phase coherence.
Setup:
Mount an S3 RX on a manually indexed 1 m rail (5 cm steps), with a static TX.
Run the static room with and without a large metal object.
Image via simple back-projection on CSI magnitude.
Measurement:
any repeatable object signature above the empty-room baseline
What the result means:
if a repeatable signature appears → the moving-chip static-sensing idea earns real investment (motorized rail + encoder + phase handling).
if not → it stays a curiosity.
Group 2 — Phase coherence on our exact fleet (Section 2)
7. Inter-node CFO stability
Gap: no literature value for ESP32-specific CFO drift.
it decides recalibration/tracking rates (Section 2, B).
Hypothesis: the residual CFO between two stock nodes drifts on a ms timescale and wanders further with temperature.
consistent with [peer-reviewed]MegaMIMO's "100 Hz → π rad in 20 ms".
consistent with [peer-reviewed]ESPARGOS's measured PLL phase randomness.
Setup:
Have two stock S3/C6/C5 nodes receive the same beacon stream from one TX.
Log per-packet CFO (esp-csirx_ctrl fields, or phase slope between HT-LTFs) for ≥30 min.
Include a temperature step (hairdryer/heatsink) during the log.
Measurement:
relative-CFO time series
Allan-deviation-style plot → how long a frequency estimate stays within, e.g., 10 Hz
What the result means:
if the answer is "milliseconds" → it nails shut the "calibrate offsets once to a central clock" idea for coherent phase.
if the answer is "milliseconds" → it confirms the per-packet-sanitization architecture.
either way → it sets any real tracking loop's rate.
8. PDD-jitter distribution per chip
Gap: the literature gives the mechanism ([peer-reviewed]Splicer (MobiCom 2015)), not ESP32 numbers (Section 2).
Hypothesis: the per-packet linear-slope term (packet-detection delay) is random every packet, ±integer-sample class (~50 ns at 20 MHz ≈ π across the band per sample).
it may differ between S3, C6, and C5.
Setup:
Hold the channel static.
Per chip model, histogram the per-packet linear-slope term after a linear fit.
Measurement:
PDD-slope distribution per chip (S3 vs C6 vs C5)
What the result means:
quantifies how much per-packet phase sanitization each chip needs.
shows whether any chip is meaningfully cleaner → an input to chip choice for phase-quality tasks.
9. Static-path anchoring viability at ESP32 bandwidths
Gap: the main open question for phase-quality sensing on stock 1×1 modules.
50/25 ns delay resolution (20/40 MHz) may not resolve a static reference path from the target path indoors (Section 2, delay-domain method of [preprint]Wu et al. (arXiv:2402.09048)).
Hypothesis: delay-domain static-reference anchoring works on a single antenna if a static path is resolvable from the dynamic path at ESP32 bandwidth.
it collapses when they merge into one tap.
Setup:
Use a single node with a static strong reflector present.
Attempt delay-domain referencing at HT20 (20 MHz) and HT40 (40 MHz).
Vary target distance so the target/reference delay separation crosses the resolution limit.
Measurement:
whether sanitized phase quality holds as target-reference separation shrinks below one delay bin
What the result means:
if phase quality holds → respiration/phase sensing is achievable on stock 1×1 modules.
if it collapses → it forces 2-RX (co-crystal / ESPARGOS) hardware.
Group 3 — C5 5 GHz CSI and the protocol edges (Section 3)
10. C5 5 GHz CSI characterization (and the lltf_bit_mode trap)
Gap: no third-party characterization of C5 CSI at 5 GHz exists.
mechanism — a phone walked through the room, TXing packets the fleet captures CSI from while streaming ARCore/ARKit 6-DoF pose, gives every CSI sample a transmitter-pose label.
outcome — this collapses the per-room survey to one walk.
accuracy — retention in the 80–95 % band (the level the transfer-learning family shows).
Setup:
A phone app streams 6-DoF pose and emits a steady packet stream.
The fleet logs CSI time-synced (ms-class, which is all data alignment needs — Section 2) to the pose stream.
Walk the room once.
Measurement:
does TX-pose labeling measurably speed convergence of a room baseline / model vs an unlabeled walk?
the orientation-dependent confounder — the phone's own antenna pattern + surveyor body-shadowing — which is both the signal's value and its hazard.
What the result means:
if it works → it closes the one novel gap in the whole survey story with high leverage (per-room survey in minutes).
if the body-shadowing confounder dominates → the pose label needs the phone body-mounted/gimballed rather than hand-held.
Hardware-limit note (what the bench cannot do without a purchase)
Limit
Fallback
5 GHz S11 verification needs a ≥6 GHz VNA. The NanoVNA tops out ~3 GHz (~4.4 GHz harmonics), below the 5.15–5.85 GHz band entirely, so experiments 2–3 cover 2.4 GHz only.
Use a LiteVNA 64 / NanoVNA-F V3-class instrument, or fall back to an S21/RSSI proxy sweep using two C5 nodes and per-channel RSSI (Section 3, gap 1).
Coherent-aperture / per-node AoA experiments need co-crystal hardware (esp-crab-style C5 pair or an ESPARGOS board) — out of scope for the stock-module bench.
Only pursue if a feature genuinely needs it (Section 2 verdict).
ESP32 Wi-Fi-CSI sensing meshes — the RF-and-architecture guide: what actually degrades your channel measurement, whether a central clock can replace co-crystal hardware, which band and which chip expose what, and how to survey a room fast — with the numbers, the papers, and the corrections to our own prior write-up
You are building a mesh of cheap ESP32 nodes that sense a room from Wi-Fi Channel State Information (CSI) — presence, motion, breathing — and you have a pile of design questions the datasheets half-answer and the forums answer wrong.
This guide adjudicates the specific ones our engineer raised:
are PCB antennas "too noisy" for sensing;
can you skip custom co-crystal boards by syncing phase from a central laptop;
is 5 GHz worth it, and what does the ESP32 actually hand you for CSI;
and how fast can a per-room survey really be.
Each answer is grounded in a primary source cited in the sentence that makes the claim, with the contrary evidence set beside it.
Provenance. This is the output of a verification-heavy research pass (2026-07-12):
176 labeled claims (roughly), across five topic reports.
Each load-bearing claim traced to a primary source — peer-reviewed papers, IEEE 802.11 clauses, chip datasheets/TRMs, Espressif code and issue trackers.
Each subjected to a one-line refutation attempt.
Where a source failed, the claim moved to a "Refuted — do not re-import" list rather than being softened.
Three claims from our own prior gist were refuted outright — see the callout in the README.
Everything the literature could not settle is declared as a bench experiment on hardware we own (see bench-experiment-plan.md).
[lead] — fetched, not adversarially verified; read it yourself before you rely on it
Facts carry the first six labels; recommendations are called out as a separate, take-it-or-leave-it layer.
Every [peer-reviewed]/[preprint] names its paper in-line — no bare labels.
Goal. You should finish able to make and defend a different choice than we would, not copy a recommendation. The facts are separable from the opinions on purpose.
1. Antennas and ground planes — what actually degrades CSI, and what doesn't
You have two antenna choices per node — the module's built-in PCB antenna or an external whip/directional — and a folk belief that the PCB one is "too noisy for sensing."
Is the built-in PCB antenna "too noisy for sensing"?
Verdict: No — not for room-scale. It's outclassed only through multiple walls.
Why the "too noisy" belief is half-wrong — and the wrong half is the one that matters:
Ground-plane dependence is real: a PCB antenna's efficiency and pattern shift with the copper/metal around it.
But that effect is static — it changes a node's baseline, not the frame-to-frame variance CSI reads.
A static baseline shift is a calibration problem, not a noise problem.
Their own reading: the biquad's spectrograms look far more pronounced, but once you are comfortably above the noise floor the activity pattern is identical and the model gains nothing.
Antenna gain buys SNR and range, not new information.
Contrary evidence, stated:
It is one paper, one environment, amplitude-only, CNN-based.
The LOS gap (0.8 pp) sits inside the standard deviation — read it as "no difference in LOS," not "PIFA better."
Nothing in it measures raw CSI variance vs antenna type (that is bench item A-1).
So: PCB is fine for room-scale; reach for external only through multiple walls.
Why static ground-plane effects don't corrupt CSI
The antenna plus its ground plane, enclosure, and nearby fixed metal is a linear, time-invariant filter in front of the radio [derived]: per subcarrier it multiplies the true channel by a fixed complex gain.
Efficiency loss, pattern reshaping, and detune ripple across the channel shift a node's baseline and per-subcarrier gain profile — they do not add time-varying noise.
Any pipeline that looks at CSI changes, normalizes per subcarrier, or per-node calibrates absorbs them entirely.
What does corrupt CSI is anything that makes the transfer function time-varying:
a loose or vibrating antenna/pigtail;
a power cable swaying in the near field;
a flexing enclosure.
That modulates every path and looks exactly like motion.
Rule for the fleet: rigid mounting of antenna, coax, and cable dress is a sensing requirement, not cosmetics [derived] (no paper quantifies antenna-vibration CSI noise on ESP32 — bench item A-4).
The one caveat where "static" leaks: a narrow-band antenna parked on a resonance skirt turns slow temperature/humidity drift into slow CSI drift, which lands in the breathing band (0.1–0.5 Hz) — separable by filtering, but worth knowing.
Metal enclosures, aluminum corners, and cables
Espressif's own [datasheet]Hardware Design Guidelines — PCB Layout Design require ≥15 mm clearance around a PCB antenna inside the housing and then tell you to test throughput and range per product — i.e. they treat enclosure effects as empirically verified, not predictable.
A conductive plane at λ/8–λ/4 (≈15–30 mm at 2.44 GHz) is a reflector:
which is literally how Strohmayer's plane-reflector and biquad systems are built — [peer-reviewed]Strohmayer & Kampel 2024;
closer than that it loads and detunes the antenna and shadows half the sphere.
So an aluminum corner is not inherently bad for sensing — it is an uncontrolled corner reflector: expect a few dB of forward gain, deep nulls behind/sideways, and some detune, all static and calibratable, at the cost of where the node can see.
On the cables the engineer asked about, separate three mechanisms because they behave differently [derived, standard EMC reasoning]:
50 Hz mains is ~8 orders of magnitude below 2.4 GHz — not an RF interferer, no in-band path.
SMPS switching noise lives at kHz–hundreds-of-MHz harmonics, so its realistic in-band path is conducted supply ripple into the PA/LNA — Espressif's troubleshooting guidance lists supply ripple as a TX-performance factor and prescribes CLC filtering on the RF supply, so judge a wall-wart by its ripple at the 3V3 pin and a tinySA sweep near 2.4 GHz, not by its mains side (cheap USB warts vary wildly → per-PSU bench screen, item A-5).
The cable as a parasitic radiator — any wire in the near field re-radiates and detunes (why Espressif pushes USB/UART away from the antenna, and why TI notes that plugging a dongle into a PC changes its performance), static if fixed, a CSI-noise source the moment it sways.
The detune tradeoff, quantified
The engineer's instinct — a −5 dB detune is fine, a −20 dB detune is not — is directionally right, and the numbers back it, but not for the reason of the comms link.
So budget antenna degradation against the dynamic-path SNR: if that path is ~30–40 dB below the direct path, a 10 m node has only ~0–15 dB of true sensing margin at MCS7.
A −5 dB detune measurably erodes it and a −20 dB detune destroys it, exactly the engineer's instinct.
Dropping to a low MCS or 802.11b rate buys ~20 dB of sensitivity floor back on the same subcarriers.
No literature exists on deliberately detuned antennas for sensing (multiple query phrasings) → this is bench item A-3, the one that turns the 70 %/99 % intuition into a measured spec.
Directional vs omni, and "static CSI"
For a mesh of criss-crossing TX-RX pairs the literature's sweet spot is moderate-gain wide beams (2–6 dBi, or Strohmayer's ~70° biquad chosen deliberately to cover a room like a camera FOV — [peer-reviewed]Strohmayer & Kampel 2024); reserve high gain for through-wall/long-hall links. Directionality also buys clutter rejection, used as interference control in Hernandez & Bulut's one-sided arrangement[peer-reviewed].
On the engineer's "static CSI is possible if the chip moves or the TX steers the beam" — supported by demonstrated systems, but each imports a requirement a bare ESP32 lacks:
The illumination moves (steered beam / RIS):[peer-reviewed]"Human Activity Recognition with a 6.5 GHz RIS for Wi-Fi 6E" lifts gesture classification above 90 % by reconfiguring the medium — but no ESP32 (S3/C5/C6) has a beam-steering TX (single RF chain [datasheet]), so this needs external hardware.
Refuted — do not re-import (Section 1):
"PCB antennas are too noisy for CSI sensing" — contradicted in LOS by the only head-to-head, Strohmayer & Kampel 2024.
"a detune that loses power distorts the sensing signal" — a static mismatch is a static filter; it costs link budget, not calibratability. What distorts is time-varying antenna behavior (vibration, swaying cable).
any paper measuring deliberately-detuned antennas for sensing — none exists (bench A-3); open S11-vs-metal-distance curves — behind a SiLabs form (bench A-2); any enclosure-vs-sensing-accuracy study — none found.
2. Cross-node phase coherence — can a central clock replace co-crystal hardware?
"Phase-information accuracy is lost across different crystals. If chips are synced from a central laptop/phone and transmit locally-derived phase + offsets calibrated to a common clock, that limitation may be bypassed."
Verdict: fails for cross-node coherent phase; holds when reinterpreted as per-packet self-sanitization + central feature fusion.
So: keeping the two halves apart is the whole point — and this is what decides whether the mesh needs custom co-crystal PCBs or can be stock modules plus software.
Why it fails as stated — for the precision class it implicitly targets (cross-node coherent phase: a distributed AoA/ToF aperture, absolute ranging):
The gap is ~5–6 orders of magnitude.
The scheme delivers time synchronization of the data (µs-class: when things were measured, plus a frequency-offset ledger).
Coherence needs phase lock of the local oscillator at the instant of each measurement (ps-class).
One carrier period at 2.437 GHz is 410 ps; a 10° alignment budget is ≈11 ps[derived].
And a frequency ledger decays: a calibration table is phase-useless tens of milliseconds after you write it.
independent crystals differ by up to ~40 ppm for two 802.11-compliant radios (≈97 kHz at 2.437 GHz); Espressif requires the Wi-Fi crystal within ±10 ppm[datasheet], so two in-spec stock modules can legitimately sit ~20 ppm ≈ 49 kHz apart and wander with temperature
the residual after per-packet correction re-randomizes every packet (the MegaMIMO number above)
ledgers the mean offset only — the residual is not fixed (a table is phase-useless within tens of ms)
CPO (PLL initial phase)
measured on the ESP32 specifically: [peer-reviewed]ESPARGOS (Euchner et al. 2025) (Sec. II-A) found the ESP32's LO PLL initial phase changes after every chip reset and every channel change even when all chips share a daisy-chained reference clock
RX PLL locks to a random phase every packet / every re-lock, uniform across subcarriers
nothing — "reference clock distribution is insufficient for achieving phase coherence"; a frequency ledger carries zero information about this
PDD (packet-detection delay)
the correlator that finds packet start has ±sample jitter; one 50 ns sample at 20 MHz is ≈π across the band [peer-reviewed/derived] (Splicer Sec. 3.1)
adds a random-per-packet phase slope
nothing — no clock sync touches it
Evidence — nobody has done it in software. No published system achieves multi-receiver Wi-Fi phase coherence from a central time reference plus a software offset ledger. Every one that achieved multi-device coherence used continuous over-the-air re-tracking or dedicated hardware:
[peer-reviewed]MegaMIMO re-measures phase against the lead's sync header every joint transmission and explicitly rejects offset-times-elapsed-time prediction.
[peer-reviewed]AirSync tracks the carrier continuously via the OFDM cyclic prefix.
[peer-reviewed]RFClock (Sarkar et al., MobiCom 2021) decomposes the problem into three distinct ones — time ≠ frequency ≠ phase — and needs custom follower boards.
[peer-reviewed]ESPARGOS distributes a wired Wi-Fi phase-reference to every chip in addition to a shared clock.
Espressif's own esp-crab[vendor] puts two ESP32-C5 on a common crystal precisely "to eliminate the relative frequency offset caused by clock asynchrony."
Why it holds reinterpreted. Change "offsets calibrated to a central clock" to: each node self-sanitizes phase per packet against its own reference, then nodes ship sanitized per-link features to a central fusion point.
That is exactly what the multi-node sensing literature does — Widar3.0, WiPose, CARM and the rest fuse per-link sanitized Doppler/velocity profiles, never raw cross-node phase ([preprint]"A Primer on ISAC-izing Commodity Wi-Fi", Sec. V).
The established sanitization tricks all cancel errors within one receiver:
conjugate multiplication or the FarSense CSI-ratio cancels all common-mode terms across two antennas of one radio;
static-reference-path anchoring in the delay domain lets a single antenna use a resolvable static path as its own anchor — [preprint]Wu, Pegoraro, Meneghello et al., Sec. III-B.
Each cleans relative phase; none creates a shared absolute reference between two independent radios.
Evidence — what that means per sensing task on stock modules:
Yes, with a caveat — CSI-ratio needs 2 RX antennas on one radio (not on 1×1 stock modules); use static-path anchoring or conjugate-across-time instead (FarSense; delay-domain Wu et al.) [peer-reviewed/preprint]
Yes — per-link Doppler fused centrally; no cross-node phase needed ([preprint]ISAC primer, arXiv:2601.12980, Sec. V)
Per-node AoA
No on 1×1 modules — needs ≥2 coherent RX chains → co-crystal/dual-chip board or a multi-antenna chip
Cross-node coherent aperture, absolute ToF
No in software — needs shared clock plus phase-reference distribution (ESPARGOS) or a monostatic/full-duplex trick
So (recommendation — take or leave):
Don't build co-crystal PCBs for the MVP.
Design the mesh as N independent bistatic links + central non-coherent feature fusion (the published architecture), each node doing per-packet self-sanitization.
Keep the co-crystal option (esp-crab-style, or an ESPARGOS board as a lab reference instrument) in reserve for features that genuinely need per-node AoA or a coherent aperture.
The laptop/phone "central clock" is still useful — for data alignment (ms-class: which packet is which), just not for phase.
Refuted — do not re-import (Section 2):
"phase-mode sensing effectively requires co-crystal hardware" (blanket) — too strong: single-node phase-based sensing (respiration, Doppler, detrended-phase features) on independent-crystal TX/RX pairs is standard and proven (FarSense, Widar2.0, delay-domain methods). The co-crystal requirement is real but scoped to multi-chain / multi-node coherent processing.
"software sanitization is unproven for distributed nodes" — imprecise: it is proven for per-node sanitization + feature-level fusion across nodes, and proven-impossible-so-far for cross-node phase coherence. Different claims, different verdicts.
3. Bands, and what the ESP32 actually exposes for CSI
2.4 vs 5 GHz
The CSI corpus clusters at 2.4 GHz mostly from tool history, not physics:
And directly on the engineer's comment (3) — "2.4 vs 5 GHz antennas have different geometry; does that matter for synchronized nodes?"
Verdict: No, it doesn't.
Why:
The fleet fuses per-link features non-coherently (Section 2), not a coherent cross-node aperture.
So per-link calibration absorbs differences in antenna geometry, gain, and even band.
Nodes need not carry identical or band-matched antennas[derived from Section 2's non-coherent-fusion result].
Antenna geometry is a per-node link-budget and pattern choice, not a fleet-wide matching constraint.
The catch for our fleet: the usual "5 GHz gives you 80/160 MHz" bandwidth argument does not apply — the ESP32-C5 is 20 MHz-only on 11ax and only reaches 40 MHz via 11n [datasheet] (ESP32-C5-WROOM-1 datasheet v1.1). So 5 GHz on the C5 buys shorter wavelength and quieter spectrum, not more bandwidth.
On the 5 GHz antenna-match ("S11 gap") worry — half right, and the right half mostly doesn't matter for CSI. The 5.15–5.85 GHz span is 12.7 % fractional bandwidth:
VSWR peaks ~4.6 inside the band, 28 % average efficiency
hard — "covers it on paper, optimal nowhere"
But an imperfect match is a static complex filter on CSI:
calibrated away like cables and LNAs by any baseline-referenced pipeline ([peer-reviewed]CSUR 2019, denoising/calibration section);
the only uncalibratable cost is SNR loss (mismatch loss −10·log₁₀(1−|Γ|²): ~0.5 dB at VSWR 2, ~2.3 dB at VSWR 4.6 [derived], plus efficiency delta), which you spend on range, not accuracy.
"Software-steering the match" (aperture/impedance tuners):
Absent on ESP32-class hardware — the C5 block diagram is fixed matching + diplexer + one PCB antenna, the only reconfigurability being a 2-way antenna-diversity switch [datasheet].
The real lever you have is channel selection/hopping — the same trick [peer-reviewed]Chronos (Vasisht et al., NSDI 2016) used to stitch hops into a wideband measurement.
mmWave radar is a different modality, not a band swap. Your 60 GHz MR60BHA2 and 24 GHz modules are active FMCW radar:
chirp-based, giving absolute cm-range and per-target micro-Doppler (range resolution c/2B ≈ 2.7 cm on a ~5 GHz sweep [derived]; TI FMCW training [vendor, standard-grade]);
whereas Wi-Fi CSI passively reads the channel you were transmitting on anyway.
They are complementary and fusing them is a documented pattern (multi-modal datasets [peer-reviewed]MM-Fi (NeurIPS 2023) and XRF55 carry synchronized CSI + mmWave). Don't believe "radar sees through walls" — Seeed's own [datasheet]MR60BHA2 guide disclaims detection through glass/thin wood; through-wall belongs to the 2.4 GHz CSI column.
The per-chip CSI matrix (Espressif primary sources only)
This is the decisive, factual part — verified against ESP-IDF docs, ESP-IDF headers, Kconfig.soc_caps, datasheets, and the esp-csi issue tracker, not blogs:
Capability
ESP32 / S3
ESP32-C6
ESP32-C5
Band
2.4 GHz [datasheet]
2.4 GHz [datasheet]
2.4 + 5 GHz[datasheet]
11n HT20 CSI
56 total / 52 usable sc [ESP-IDF doc]
undocumented — section empty [gap]
57 total / 56 usable [ESP-IDF doc]
11n HT40 CSI
114 total / 108 usable [ESP-IDF doc]
undocumented [gap]
117 total / 114 usable[ESP-IDF doc]
11ax HE20 CSI
— (no 11ax)
yes per struct (acquire_csi_su/mu/dcm/beamformed) [code]; users report 512 B buffers [lead]
Fact: HE and VHT are 20 MHz-only on C5/C6; 40 MHz exists only as 11n HT40; there is no 80/160 MHz CSI anywhere on the family [datasheet + esp-idf #18493].
Consequence: the C5's real bandwidth ceiling for delay resolution is therefore HT40 (117 tones over 40 MHz beats 245 tones over 20 MHz for range) — an Espressif engineer framed exactly this 20 MHz/12-bit vs 40 MHz/8-bit trade without picking a winner [vendor, esp-idf #18493].
Denser sampling ≠ finer resolution: Wi-Fi 6's 245-tone HE20 gives 4.3× denser frequency sampling in the same 20 MHz, which improves unambiguous delay range and per-tone SNR/redundancy, not delay resolution (bandwidth is unchanged) [derived from OFDM sampling theory — flag for the engineer to sanity-check].
The lltf_bit_mode landmine (C5, 5 GHz).
Symptom: on ESP-IDF v5.5 the C5's CSI buffer was frozen — identical I/Q every frame on every 5 GHz channel while metadata updated normally.
Scope: field exists only on the C5 (MAC v3); if you evaluate C5 5 GHz CSI and see a dead-constant buffer, this is why (bench item 4).
Wi-Fi 6/7 sounding is in the protocol, not app-accessible.
What the protocol does: since 802.11ac a beamformer can transmit an NDP Announcement + Null Data Packet on demand and solicit compressed beamforming feedback (Givens-rotation angles, not raw CSI); 11ax adds AP-scheduled multi-STA (trigger-based) sounding [standard/spec, 802.11ax-2021 Clause 26.7].
What's lost: the transmit steering matrix is implementation-private, and the feedback is lossy (per-tone amplitude and global phase gone).
What ESP32 exposes:no API exposes any of it — C5/C6 are 11ax beamformees only, they transmit feedback they cannot read [code] + esp-csi #183.
802.11bf status:802.11bf (WLAN Sensing) was published 2025-09-26[standard/spec] and standardizes exactly the missing piece (sensing-initiated sounding + CSI reporting; overview [peer-reviewed]Du et al. 2024, "An Overview on IEEE 802.11bf: WLAN Sensing" (IEEE COMST)) — but no shipping consumer chipset was found exposing it, and certainly not the ESP32.
No software beam-steering on ESP32, period. Every chip is 1T1R single-antenna; TX beamforming needs ≥2 coherent TX chains; "antenna diversity" is a switch, not a phased array [datasheet + code].
Refuted — do not re-import (Section 3):
"ESP32-C5 supports Wi-Fi 6 at 40 MHz" (any variant) — false: HE and VHT are 20 MHz-only; 40 MHz is 11n only [datasheet + esp-idf #18493].
~~"HT20 gives ~56 / HT40 gives ~128 subcarriers on C5"~~ — 57/56 and 117/114 on the C5 doc table; 128 is the zero-padded example-buffer size. The C6 subcarrier table does not exist in any ESP-IDF version (community-reported only — bench item).
"the first-word-invalid quirk is ESP32-classic-only" — the flag and doc note appear for the C5 too; treat it as a runtime flag on all chips [ESP-IDF doc + code].
"11n CSI feedback frames are a usable sensing source" — 11n-era feedback is undeployed; the cleartext-BFI sensing literature is 11ac/11ax MU-MIMO.
4. Survey automation — how fast can a per-room survey be?
"Every deployment room needs its own survey — true; how fast can we make a survey (software-steered beam? a phone that transmits its orientation?)."
Verdict: The fast-survey lever is not beam steering — it is annotated walk-throughs plus transfer learning. On-node beam steering is a dead end on our hardware; the phone-orientation idea has no direct prior art but composes proven pieces (a bench candidate).
Why — walk-throughs collapse the survey to walking time:
PDR/SLAM-labeled crowdsourcing collapses the survey to walking time (minutes per room) at near-parity accuracy.
The modern form auto-labels with AR pose — [peer-reviewed; IPIN 2022 venue = lead]VI-SLAM2tag uses ARCore visual-inertial SLAM to tag fingerprint collection with 6-DoF pose.
Contrary evidence, stated: these are all RSS device-localization systems (the phone is what's being located) and Zee still needs a floor plan plus a map-convergence period — porting the annotation idea to device-free CSI sensing is the open piece (D3, below).
Why — transfer learning turns per-room cost into a one-time cost:
Scope caveats, stated (paper Sec. 4.4): it needs the person's location+orientation from a passive-tracking front end and multiple links with known geometry — zero survey per new room, but not zero geometry, and the ~10-point cross-orientation drop is real.
The honest accuracy-retention band across this family is 80–95 % of in-domain[derived across the cited papers].
Evidence — software-steered beam to speed the survey: NO on our hardware[derived from datasheets]:
1T1R chips can't TX-beamform;
the C6 is a Wi-Fi 6 beamformee only (target of an AP's steered beam, never the steerer, [datasheet]);
and ESPARGOS is a RECEIVE array, not TX steering — an engineer-verify item, confirmed: its eight ESP32-S2 chips share a wired phase-reference to make phase-coherent receivers, and nothing in the paper claims transmit coherence — [peer-reviewed]ESPARGOS / companion;
RIS steered illumination helps sensing coverage but is bespoke lab hardware and was never used to speed a survey.
The fleet's honest substitutes for steering are channel hopping/splicing (Splicer-style), many spatially-distributed TX nodes (discrete illumination geometries — the multi-link diversity Widar3.0's BVP is built on), and moving the receiver.
A phone that transmits its orientation — no direct prior art, but it composes proven pieces → a bench candidate.
No published system was found in which a phone is the CSI transmitter streaming its IMU orientation so device-free receivers can calibrate/label a survey (searches across "smartphone transmitter known orientation IMU CSI calibration", AR-pose + radio-map, and the crowdsourcing literature surfaced only phone-as-located-device, phone-as-label, and phone-as-beacon systems). Declared gap.
But the idea is well-grounded as the composition of two proven pieces [derived]: VI-SLAM2tag's "phone pose auto-labels the radio measurement" + Widar3.0's Sec. 4.4 prerequisite "the system needs the moving thing's location and orientation to normalize CSI."
A phone walked through the room, TXing packets the nodes capture CSI from while streaming its ARCore/ARKit 6-DoF pose, gives every CSI sample a transmitter-pose label — a per-room survey in one walk.
Caveat worth labeling in the data: the phone's own antenna pattern and the surveyor's body shadowing are orientation-dependent confounders — which is exactly what makes the orientation label valuable and hazardous if ignored (bench item 5).
So (recommendation — take or leave):
Adopt the walk-through pattern (phone as roving TX + AR pose + fleet capturing CSI).
Design for transfer (train on domain-independent velocity/Doppler-space or ratio-style features so rooms cost adaptation-minutes, not survey-hours).
Forget on-node beam steering — spend that ambition on channel hopping, node-placement diversity, and (only if receive-side coherence ever becomes load-bearing) an ESPARGOS-style board, which is a hardware project, not firmware.
Refuted — do not re-import (Section 4):
"Widar3.0 needs zero infrastructure/effort in a new room" — it needs multiple links with known geometry AND the subject's location+orientation from a tracking front end; "zero-effort" is scoped to no data collection / no retraining.
"ESPARGOS shows ESP32s can beam-steer" — it is a phase-coherent receive channel sounder; no transmit coherence claimed.
"a commodity AP's beamforming can be software-pointed for a survey sweep" — 802.11 TxBF direction is chosen by the sounding protocol toward the associated STA; no steer-to-angle API exists.
"FarSense-style fingerprint-free sensing ports directly to our nodes" — CSI-ratio needs two coherent RX antennas on one radio; stock ESP32s have one.
Open questions named above are routed to bench-experiment-plan.md. Every load-bearing claim traces to a primary source in the five topic reports' source registers (docs/.research/csi-rf/topic-*.md); the prior gist is treated as hypothesis, never authority.
