BLE-Assisted CSI Ground Truth Collection
Current assessment (2026-09-15)
Superseded design retained for provenance, reviewed September 15, 2026. No primary data are attributed to this card. BLE device counts require independent validation before serving as person labels. The current listener is the fleet Broadcom controller; the original ESP32/FeitCSI hardware plan is historical.
BLE device counts require independent validation before serving as person labels. The current listener is the fleet Broadcom controller; the original ESP32/FeitCSI hardware plan is historical.
Next evidence needed: Use EXP-F1 for the current protocol and evidence. The earlier plan below is not an instruction to reopen this experiment.
Basis: Thesis Narrative, the September 10 synthesis, and the September 15 register review. See the review record for evidence sources and outstanding checks.
Earlier protocol and dated results
The methods and observations below retain their original scope. Read their readiness statements and proposed next steps as historical. The current assessment above records what has changed; frozen thresholds have not been retrospectively revised.
The problem, in plain words
Think of teaching a child to guess how many people are in a room by listening to how muffled the music sounds through the wall. To teach them, you need to tell them the right answer many times: "muffled like this = 5 people." Wi-Fi crowd counting works the same way — the Wi-Fi channel gets disturbed by bodies, and a model learns "this pattern of disturbance ≈ 5 people." But to learn it, the model needs thousands of labelled examples, and each label is a real headcount at a real instant.
Getting those headcounts by hand is the bottleneck. It caps how much data you can collect, and it makes long, natural, day-after-day recordings basically impossible. Device-free Wi-Fi counting is well studied — from smart-building occupancy (zou2018_1590 ↗) to deep-learning counters (zhou2020_6173 ↗) to commodity-ESP32 systems (choi2022_17c2 ↗) — and all of them pay the manual-labelling tax. Meanwhile BLE beacons are already known to sense occupancy cheaply (demrozi2021_bf55 ↗; koksal2025_426c ↗), and combining Wi-Fi and BLE packet capture already estimates occupancy accurately (longo2019_b72f ↗). The bet of EXP-001 is: let the cheap BLE channel label the expensive CSI channel, automatically.
What we are trying to prove
- Hypothesis (falsifiable): a per-second BLE advertisement count from participants' phones matches a human headcount within ±1 person for more than 90% of time windows, across a controlled ramp (0→10 people), several days of natural occupancy, and deliberate stress cases (simultaneous entry/exit, partial app coverage, BLE interference). If it holds, BLE is a trustworthy automated label source and downstream experiments (the old EXP-002…005 line) can train on it.
- What a null means: if agreement falls below that bar — because phones in pockets/bags attenuate below the listener's floor, participants share or forget devices, MAC/identifier rotation and mobile-OS background limits suppress advertisements, or one person carries two phones — then BLE device-count is a biased proxy, not ground truth. The whole labelling pipeline it was meant to justify inherits that bias, and every model trained on it is fit to BLE's errors, not to reality. This is exactly why the successor card reframes BLE as an anchor to be measured against, not a truth source.
How the experiment works (plain method)
- Deploy the radios. Two-to-four CSI TX/RX links (ESP32-C5 pairs, or Raspberry Pi 5 + Intel AX210 via FeitCSI) span the room diagonally and horizontally at ~100 Hz packet rate, with occupants kept outside the first Fresnel zone of each link so bodies perturb rather than block the path. One or two Raspberry Pi BLE sniffers scan continuously, counting only advertisements carrying the app's service UUID.
- Instrument the people. Each participant runs a phone app that broadcasts a unique BLE identifier every second and heartbeats to a collection server over TCP/UDP. The BLE listener turns "distinct UUIDs heard in the last window" into an automatic occupancy timeline.
- Three phases. (A) Controlled validation — empty-room baseline, then add one person every five minutes to ten, manual count at every transition. (B) Natural occupancy — deploy in a real meeting/study room for 3–5 days during working hours; people come and go carrying phones; spot-check by hand three times a day. (C) Stress testing — rapid simultaneous entry/exit, deliberately partial app coverage (3 of 5 carry it), competing BLE devices (smartwatches, earbuds), and a person standing in a line-of-sight path.
- Line up the clocks. All devices NTP/PTP-synced to <100 ms so a CSI packet and a BLE count refer to the same instant. Outputs: raw CSI (amplitude + phase, all subcarriers), BLE scan logs (identifier, RSSI, timestamp), and the manual-vs-BLE count logs used to score agreement.
The plan (status: designed, not executed)
Because no data exists yet, the falsifiable claim above is untested. The concrete, still-open success gates from the design are:
- BLE-derived count within ±1 person of manual count for >90% of windows (the core claim).
- CSI capture health: >95% packet rate, no hardware dropouts, >8 h unattended.
- Cross-source time sync <500 ms end-to-end.
What changed since: the design was split so the two hard, separable risks get their own cards — can the hardware even capture clean CSI for hours (EXP-P1) and is the BLE anchor good enough, and how do we measure its own error (EXP-F1). Read this card as the shared motivation and the panel below as a pre-mortem on the design.
Key references
- longo2019_b72f ↗ — the closest prior art: fusing Wi-Fi + BLE packet capture for occupancy; the multimodal-anchor premise.
- demrozi2021_bf55 ↗ — BLE occupancy/counting basis, and honest that device-count needs a correction model.
- koksal2025_426c ↗ — a fielded BLE-beacon occupancy system; the deployment-reliability contrast.
- zou2018_1590 ↗, zhou2020_6173 ↗, choi2022_17c2 ↗ — the device-free CSI counting baselines this pipeline is meant to label.
- ficara2024_f89b ↗ — MAC/identifier randomization; why stable device-counting degrades in the wild.
- guarino2026_e72c ↗, meneghello2023_0a93 ↗, zhang2026_ccac ↗ — the reproducibility/dataset-schema bar the SWE voice invokes.
- simoni2023_f197 ↗, zhang2024_1d32 ↗ — privacy-first presence monitoring; the ethics basis.
- huang2025_060d ↗ — a public real-CSI benchmark for the red-team's external cross-check.