Live status · Read the latest
monad-knowledge Wi-Fi sensing lab · FIIT STU
open EXP-F1 field

Validating participant observations as headcount references

In plain words

When can participant phone observations serve as a calibrated reference for people counting?

phone phone phone BLE listener Wi-Fi recording+ device eventscount needs checking
A listener records participating devices. Relating those observations to people requires independent counts, device-carriage checks and time alignment. Schematic of the design, not a measurement.
Why it matters
A phone observes devices and a participant's actions. A person count needs a separately checked relation between those observations and the people present.
How it is done
Compare phone and on-node BLE observations with independently timed headcounts and observed task completion. Measure missing phones, multiple devices and uncertain zone membership.
Where it stands
Collection is under way. The BLE scanner now tells devices from the static background, but four labels cannot say how many addresses one person brings, so the reference-to-headcount acceptance test remains open.

Asks, formallyParticipant phone observations and the fleet's on-node BLE scans can estimate independently observed headcount within ±1 person in at least 90% of one-minute windows, provided device carriage, zone assignment and time alignment are validated. A task schedule is an intended treatment; independently timed observations establish the evaluation reference.

FoundThe September 15 register contains 229 usable primary sessions, including ambient recordings through September 12.

StandingStatus not declared · last activity 2026-10-18

RoomSingle meeting / seminar room (target: FIIT meeting room, ~5–15 capacity) once the room polygonization lands in PostGIS. Falls back to the library floor's largest cell ([[fiit-library-polygonized-9]] et al.) if the meeting-room floorplan is delayed.

Validating participant observations as headcount references

Current assessment (2026-09-28)

The continuous on-node BLE scanner (since 14 September) now supports a label-free background model, but not a people count. The reference acceptance test is still open, because the independently timed headcounts it needs do not exist beyond OL-001 to OL-004 (two and three people, one visit).

Finding Number Source
The static BLE background is the public addresses 4,523 of 4,532 addresses heard in ≥ 90 % of night minutes are public (99.8 %) diary 2026-09-23
Four labels cannot fix how many addresses one person brings v0 posterior 0.57 / 2.00 / 10.69 addresses per person (5 / 50 / 95 %) same
On the labelled visit, about 2 to 4 addresses per person above background literature: 0.33–0.5 devices per person (longo2019_b72f) diary 2026-09-25
A bystander phone can be placed, not tracked median error 2.23 m [1.62, 3.10] on the 2026-08-28 walk; committed moves +1.3 points [−0.8, +2.8] over static devices diary 2026-09-27
Address rotation bounds any path non-resolvable RPAs rotate at 10 min, resolvable RPAs just under 15 min; re-identification recall 0.63 same

So a BLE address count is a device count with an unmeasured people ratio. It can teach the CSI where and roughly how busy, and it cannot serve as the headcount reference this card was built to validate.

Next evidence needed: independently timed people counts (IP-162 Counting, CR-101) on busy weekday hours, so the address-to-people ratio and its day-to-day variation can be measured.

Results and assessment (2026-09-15)

The September 15 register contains 229 usable primary sessions, including ambient recordings through September 12. These are not 229 independently labelled reference tests. The fleet BLE listener is the on-node Broadcom controller; the earlier ESP32 requirement is historical. The September pilot covers four selected episodes and two positive headcounts on one day, with detector-selected boundaries.

Limits of the reference evidence

A prescribed schedule records intent, and a QR scan records an event; neither guarantees continuous occupancy. BLE RSSI presence results and counting unique app devices are different estimands. Validate the device-to-person and zone-assignment mappings before using either as a label. The claim that synthetic transfer never ran is also stale: the September 4 comparison reported a null at the shipped impairment prior, and its realistic-impairment, scarce-capture extension reopened September 9.

The archive audit also finds receiver sessions without a paired injector claim. Their source attribution is unverified in this register. An ambient profile name does not establish which transmitter produced a record.

Next evidence needed: Run the reference acceptance analysis against independently timed counts, carrying clock and location uncertainty. Separate training labels from evaluation labels. Inherit participant instrumentation gates from EXP-P1 and EXP-P3.

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.

Original hypothesis (before this review): Counting unique BLE advertisements from the gamification mobile app, observed via ESP32-C6 listeners, matches a prescribed walk-task schedule and a spot-check manual count within ± 1 person across 90 %+ of 1-minute windows — establishing the BLE-anchored ground-truth pipeline that EXP-F2 and EXP-F3 will rely on without manual labelling.

The problem, in plain words

Think about how you'd grade a thermometer. You need a reference you already trust — a known-good thermometer, or a glass of ice water at exactly 0 °C. Without a reference you can't tell whether your device is right or just confident. Wireless crowd counting has no cheap reference. The "glass of ice water" for a room is the true number of people in it, minute by minute — and getting that by hand is the expensive, boring part that quietly limits every study in the field.

EXP-F1's idea is to manufacture the reference on purpose. Instead of passively watching an uncontrolled crowd and hand-labelling it, we hand each participant a phone that tells them where to walk and when. Now the room's occupancy is not something we have to measure — it is something we scheduled. The BLE listeners then just have to agree with the schedule. This is the same trick vehicle-counting researchers use when they anchor Bluetooth counts against a trusted secondary count to learn the mapping (tayeb2023_cc87 ↗) — here the "trusted secondary" is a script the phones obey.

The catch, and it is the whole experiment: BLE has to actually count people to be a ground truth. If BLE can only tell you someone is there but not how many, then it is a presence sensor wearing a counter's costume — and the simulation already warns us this is the likely failure mode.

What we are trying to prove

  • Hypothesis (falsifiable): BLE-derived counts (unique app advertisements per window, seen by ESP32-C6 listeners) match the app's prescribed walk-task schedule within ± 1 person across ≥ 90 % of 1-minute windows, and match a manual spot-check within ± 1 person across ≥ 90 % of spot-checks. If BLE saturates — reads "occupied" but not "how many" — the hypothesis fails, and the BLE anchor is demoted from ground truth to presence gate (still useful, but not what EXP-F2/F3 assume).
  • A designed-in null: scenario F1.C deliberately disables BLE advertising on 3 of 5 phones mid-session. The correct result is a count that undercounts by exactly 3 — proving the failure mode is known and bounded, not silent. A silent, unpredictable miscount here is worse than a large but predictable one.
  • What a null means for the programme: if BLE cannot carry graded count in a real room, the whole "BLE-anchored, manual-labelling-free" chain collapses, and EXP-F2/F3 must fall back to manual counting or a different anchor (camera, turnstile). That is why EXP-F1 is a gate, not a formality.

How the experiment works (plain method)

  1. Register the room in PostGIS and place 8 devices via gis_place_device: 4 Pi 5 + AX210 nodes as 2 Wi-Fi 6 CSI TX/RX pairs (5 GHz, FeitCSI), 2 ESP32-C6 BLE listeners in opposite corners, 2 ESP32-C5 for supplementary 2.4 GHz CSI.
  2. Baseline — 10 minutes of empty-room recording to fix the noise floor.
  3. Run four scripted sub-scenarios: F1.A controlled entry/exit (1→10→1), F1.B steady state (5 fixed, 30 min), F1.C penetration drop (3 of 5 disable BLE adv), F1.D BLE noise (add smartwatches / headphones). The app issues walk-tasks over TCP; the BLE listener counts unique advertisements per 1-second window; the collection server compares against the schedule and the spot-check.
  4. Synchronisation gate — every device's first data row within 100 ms (PTP), because the whole premise is that CSI and BLE describe the same moment.
  5. Stop on first hardware dropout — a single device dropout breaks co-registration and invalidates the session.

The two simulation campaigns pre-test the physics of step 3 before any hardware is deployed: c-ble-csi-coregistration synthesises BLE-RSSI and CSI from the same ray-traced channel (co-registered by construction), and c-sim2real-count-transfer was meant to build a synthetic-impaired corpus to pretrain the CSI counter — the arm that would let EXP-F2/F3 lean on simulation.

What we've found so far (honest)

This is simulation motivation, not field evidence. The hardware experiment has not run.

c-ble-csi-coregistration — REAL results (30 runs, 1 figure) — a split verdict

Session 01KVX0WCD5… executed all 30 planned runs on the static through-wall rig (a seated-crowd proxy) at 2.4 GHz. Criteria resolved: [✅ pass, ❌ fail, ✅ pass].

What was tested Result Reading
Both channels from one solved CFR (criterion 1) ✅ all 30 runs emit csi.hdf5 + ble_links.parquet, no NaN/Inf Co-registration works — CSI and BLE describe the same moment.
Mean RSSI monotone-decreasing with N, ρ ≤ −0.6 per seed (criterion 2) ❌ ρ = −0.83 / −0.66 / −0.09 (seed0/1/2) Two of three seeds pass; seed2 broken by one unlucky placement. Shape is a step then plateau, not a graded slope.
Resolvable ΔN sensitivity table + noise degradation (criterion 3) ✅ produced Presence (empty→occupied) d = 2.3–3.7; graded ΔN=2 within occupied d = 0.4–0.8 (not resolvable).

The honest headline (from the session's own synthesis): in the seated/static regime where the temporal CSI counting feature provably collapses, a co-registered BLE anchor still tells you the room is occupied — robustly, and it holds even at 6 dB event noise (presence d drops 2.32 → 1.81 → 1.54 as noise goes 2 → 4 → 6 dB). But it does not encode graded headcount in this multiroom geometry. The supervisor verdict: "coarse presence yes, graded headcount no… motivation only, not proof." The living hypothesis ble-ground-truth-sufficiency was not bumped on this synthetic evidence.

Directly relevant to EXP-F1: the sim is warning that a corner-placed BLE anchor may saturate exactly as EXP-F1's field hypothesis requires it not to. The field design's answer — the app counts unique advertisements per phone, not blockage-induced RSSI drop — is a fundamentally different (and more count-linear) mechanism, which is precisely why EXP-F1 must still run: the sim tests the blockage-anchor physics, not the advert-counting physics.

c-sim2real-count-transfer — PHANTOM (0 runs, 0 figures, 0 budget)

Both sessions of this campaign are hollow. The latest, 01KXBWYQH2…, is state: finished but has run_ids: [], figures: [], and budget_used all zero. Its criteria are [false, false, false]. What actually happened: a preflight unblocked the dependency chain and validated the corpus recipe on one probe cell (n_agents=3, seed=0), then the supervisor exhausted its token budget before generating the 24-cell corpus. The Phase 2b transfer test — the entire point, "does synthetic-impaired pretraining beat real-only at a small real budget?" — was never executed. No transfer result exists. Any downstream claim that "simulation pretraining helps EXP-F1's counter" is, today, unsupported. This is exactly the class of hollow session the 2026-07-15 integrity audit flagged, and it is recorded here so no reader mistakes a validated recipe for a validated result.

How to read the figures

Only one real figure exists in this experiment's evidence: fig_csi_ble_coregistration.png (session 01KVX0WCD5…).

  • Left/main panel — pooled, baseline-normalised ΔRSSI against occupancy N. Read the shape, not individual points: a clear drop from N=0 to the first occupants, then a flat plateau for N=6 vs N=12 (within ~0.2 dB). That plateau is the saturation finding — it is why the anchor reads presence, not count.
  • Right panel — the per-event spread (σ ≈ 6–12 dB). This is dominated by cross-link path-loss and placement variance, not the self-authored measurement noise, and it is the budget the occupancy signal has to clear. When you see the occupancy step (1–2 dB) sitting inside a 6–12 dB spread, you understand instantly why graded counting is hard and presence is easy.

The sim-to-real transfer campaign has no figures to read — because it never ran (see above).

Key references

  • demrozi2021_bf55 ↗ — BLE occupancy/counting basis; the presence-vs-count divide the sim reproduced.
  • iannizzotto2025_b55c ↗ — recent BLE people-counting, the mechanism EXP-F1's advert-counting competes with.
  • tayeb2023_cc87 ↗ — anchoring Bluetooth counts to a trusted secondary count; EXP-F1's schedule-as-truth analogue.
  • longo2019_b72f ↗ — nominal-vs-effective penetration; frames the F1.C designed-null.
  • zou2018_1590 ↗, choi2022_17c2 ↗, zhou2020_6173 ↗ — CSI crowd-counting baselines the ground truth serves.
  • huang2025_060d ↗ — the real labelled-count anchor for the transfer arm and the red-team's cross-check demand.
  • chen2023_5cbd ↗, wang2026_2758 ↗, khan2023_b7c5 ↗ — the sim-to-real / transfer context for the (unexecuted) c-sim2real arm.
  • zhang2026_ccac ↗, guarino2026_e72c ↗ — the reproducibility bar the SWE voice invokes against the phantom session.
  • zhang2024_1d32 ↗, simoni2023_f197 ↗ — privacy basis for the ethics voice.
  • xiong2023_e6c6 ↗ — sensing/estimation trade-off framing for the mathematician's identifiability argument.

Design appendix — hardware, protocol, criteria (preserved from the original card)

Hardware deployment

Role Device Count Placement
CSI TX/RX (5 GHz Wi-Fi 6) Pi 5 + AX210 (FeitCSI) 4 (= 2 pairs) Diagonal + horizontal links per choi2022_17c2 ↗ geometry
BLE listener ESP32-C6 2 Opposite corners of the room
Supplementary 2.4 GHz CSI ESP32-C5 2 Co-located with BLE listeners
Ground-truth source Mobile app ≤ 15 phones One per participant
Collection server laptop / Pi 5 1 LAN-attached

Sub-scenarios

Scenario Participants App BLE-adv Manual count interval
F1.A: Controlled entry-exit 1 → 10 → 1 100 % every entry transition
F1.B: Steady state 5 fixed for 30 min 100 % every 5 min
F1.C: Penetration drop 5 fixed 60 % (3/5 disable adv mid-session) every 5 min
F1.D: BLE noise 5 fixed 100 %, +smartwatches / headphones every 5 min

Success criteria

  • BLE-derived count matches task-schedule count within ± 1 person across ≥ 95 % of 1-s windows in F1.A and F1.B.
  • BLE-derived count matches manual spot-check within ± 1 person across ≥ 90 % of spot-checks in F1.A → F1.D.
  • CSI packet capture rate ≥ 95 % per Pi-5 node across all scenarios.
  • Session runs ≥ 1 h continuous with zero device dropouts.
  • PTP sync stays sub-100 µs across all nodes.

Dependencies

  • EXP-P1 — Phase D dress rehearsal passed; provides the hardware platform + mobile app.
  • gis_place_device registrations for the deployment room.
  • 5–15 participants for the gamification session.

Cross-experiment links

  • EXP-F2 — inherits the ground-truth chain.
  • EXP-F3 — inherits the per-link feature pipeline.

Notes

EXP-F1 is the foundation. If it fails, every downstream field claim is anchored on a chain that can't be trusted. The gamification loop is the structural advance that makes validation affordable — 1 h of scripted scenarios replaces multi-day continuous manual counting. The simulation evidence to date argues the blockage anchor sees presence but not count; the field run exists precisely to test whether the advert-counting anchor does better.

See it run

Trajectory replay of run 4B1H5N0V — press play, scrub the timeline, toggle agent trails and footfall.

Loading replay…

Open the run workbench →

Simulation runs the 20 most recent, newest first
Run Date Gate Campaign Replay
4B1H5N0V 2026-10-18 ✓ c-sim2real-count-transfer replay →
YHY0A9T4 2026-10-18 ✓ c-sim2real-count-transfer replay →
1R3NXN30 2026-09-04 ✓ c-sim2real-count-transfer replay →
10J69YZ5 2026-09-04 ✓ c-sim2real-count-transfer replay →
DW41VCZ6 2026-09-04 ✓ c-sim2real-count-transfer replay →
79GZ1PVT 2026-09-04 ✓ c-sim2real-count-transfer replay →
PPRQD19A 2026-09-04 ✓ c-sim2real-count-transfer replay →
HYGAP8NY 2026-09-04 ✓ c-sim2real-count-transfer replay →
NBBQZAVR 2026-09-04 ✓ c-sim2real-count-transfer replay →
QWBNANGJ 2026-09-04 ✓ c-sim2real-count-transfer replay →
GC6NETV7 2026-09-04 ✓ c-sim2real-count-transfer replay →
KHDX8MER 2026-09-04 ✓ c-sim2real-count-transfer replay →
65DV2HZB 2026-09-04 ✓ c-sim2real-count-transfer replay →
GQZP8M3H 2026-09-04 ✓ c-sim2real-count-transfer replay →
PD8Q2PAT 2026-09-04 ✓ c-sim2real-count-transfer replay →
1RAA9YS0 2026-09-04 ✓ c-sim2real-count-transfer replay →
7MKN1ABX 2026-09-04 ✓ c-sim2real-count-transfer replay →
GMQRCD7G 2026-09-04 ✓ c-sim2real-count-transfer replay →
9MGH7BP0 2026-09-04 ✓ c-sim2real-count-transfer replay →
TYA2HE72 2026-09-04 ✓ c-sim2real-count-transfer replay →

All exp-csi-crowd runs in the workbench →

Provenance

—
not recorded

Data types

  • csi-amplitude
  • csi-phase
  • ble-advertisement-log
  • ble-rssi
  • ground-truth-occupancy
  • mobile-app-task-log