BLE-Assisted CSI Ground Truth Collection

Executive summary

Every Wi-Fi crowd-counting model needs a label: at each moment, how many people were actually in the room? Almost all published work gets that label by hand — a person watches and writes down the count, or the scene is scripted ("now 3 people walk in"). That is slow, expensive, and impossible to run for days. This experiment proposes a cheaper source of truth: give every participant a phone app that broadcasts a Bluetooth Low Energy (BLE) advertisement once a second; a small BLE listener counts how many distinct phones it hears; that count becomes the ground-truth occupancy, timestamped and automatic, running alongside the CSI capture.

Stated honestly: the idea is attractive but the card was never executed as written, and its central assumption is load-bearing and unproven — BLE device-count equals people-count only if everyone carries exactly one participating, actively-advertising phone. That assumption breaks in ordinary ways (phone in a bag attenuates the signal, someone forgets the app, iOS silences background advertising, two devices per person). So BLE here is not a truth oracle — it is a second imperfect sensor, and the honest framing (adopted by the successor EXP-F1) is to anchor CSI against it while measuring BLE's own error, not to treat it as gospel. This is a real-hardware design for a FIIT STU room; nothing here is simulated, and nothing here is measured yet.

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.

Review panel

Each voice is a prepared expert with a one-line stance and the literature it argues from. Because there are no results, every verdict is about the design and its assumptions.

+ 📐 Mathematician — *identifiability & the estimand*

Stance: what exactly is BLE-count an estimator of? It measures number of actively-advertising, in-range participating devices, and equals number of people only under an injective map: one person ⇔ one advertising phone. Ask: state that assumption as a formal condition and its violations — missing devices bias low, multi-device users bias high, and neither is zero-mean, so the error does not average out over a long recording; it is a systematic offset that your model will happily learn as signal. BLE occupancy work is honest that raw device-count needs a correction model to become people-count (demrozi2021_bf55 ↗; longo2019_b72f). Verdict: the estimand is a proxy, not the target; identifiability holds only under an assumption the design does not defend.

+ 📊 Statistician — *design, power, unit of replication*

Stance: I audit the measurement design, not the RF. The "±1 person for >90% of windows" gate is a good, concrete criterion — but it hides a replication trap. Ask: consecutive one-second windows are heavily autocorrelated (occupancy barely changes second-to-second), so thousands of "windows" are not thousands of independent trials; the effective sample size is the number of occupancy transitions and distinct sessions, which is small. Report agreement per transition and per day with clustered CIs, not per-window, or the 90% will be a confidently-quoted illusion. Also pre-register how you score the stress phase separately — pooling it with the easy ramp inflates the headline. Verdict: criterion is fine; fix the unit of replication before you trust any percentage it produces.

+ 🔴 Sim-to-Real Red-Team — *the professional sceptic*

Stance: assume the ground truth is wrong until proven otherwise — and here the "truth" is itself an unvalidated sensor, which is the worst case. Ask: you are proposing to bootstrap an entire thesis's labels from a device-count that (a) has never been measured, and (b) degrades under the exact conditions you care about — MAC/identifier randomization and RCM actively break stable device-counting in the wild (ficara2024_f89b ↗). If BLE undercounts in dense scenes, the CSI model learns to undercount and the error is invisible, because both sensors agree on the wrong answer. The only cure is an external check: hold out sessions with a genuine independent count (human video-tally, or cross-validate on a public real-CSI benchmark like huang2025_060d) before any label from this pipeline is trusted. Verdict: do not ship models trained on BLE-only labels as if the labels were truth; the successor EXP-F1's "anchor + measure its error" reframing is the correct retreat.

+ 🔧 Deployment Practitioner — *would this survive a real install?*

Stance: I mount the Pi5/AX210 and chase the phone that stopped advertising. Ask: two field killers the design under-weights. First, mobile-OS background limits — iOS heavily throttles or blocks background BLE advertising and rotates identifiers; an app that advertises fine in the foreground goes silent in a pocket, so your "one second advertisement" becomes best-effort. Second, compliance drift — over 3–5 days people forget to open the app, phones die, guests arrive with nothing. Fixed BLE-beacon door systems exist precisely because participant-carried tags are unreliable (koksal2025_426c; demrozi2021_bf55 ↗). Verdict: feasible for a supervised Phase-A ramp; the multi-day Phase-B "natural occupancy" is the part that breaks in the field — budget for a fallback reference and per-day compliance logging.

+ 🛡️ Responsible-Sensing / Ethics — *consent, privacy, dual-use* (experiment-specific voice)

Stance: this design puts a unique, continuously-broadcasting identifier on each participant and records RF that reveals presence and movement — that is people-sensing, and it needs a consent and data-handling story, not just a network diagram. Ask: who can hear the advertised UUIDs besides your listener (BLE is a public broadcast), how are identifiers rotated and unlinked after the session, and what is retained? The privacy literature for exactly this class of system is explicit — probe/beacon-based presence monitoring must be designed privacy-first, with hashing/federation, not bolted on (simoni2023_f197 ↗; zhang2024_1d32). Verdict: ethically runnable with informed consent and short-lived rotated IDs; document the DPIA before Phase B, since a days-long identifier broadcast in a shared building is the sensitive part.

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.

BLE-Assisted CSI Ground Truth Collection

Environment