Asking the fleet what it is doing…
monad-knowledge Wi-Fi sensing lab · FIIT STU
Campaign session

01KY0CYKXEV4XXZ3RCSYRHBAKJ

finished 2026-07-20 18:34:57.838654+00:00 → 2026-07-20 18:45:27.877267+00:00 · 5 runs · supervisor: react-agent

“BLE arm (#4): 5 coupled seeds with ble.enabled emit ble_links.parquet (rssi_dbm) alongside CSI. A/B (same 5 runs reduced twice): BLE RSSI carries counting information (mean per-mount MI 0.212, slightly ABOVE CSI's 0.172) BUT is far flatter across mounts (spread 0.103 vs CSI 0.251) and far less seed-stable (rank rho 0.186 vs 0.593). The BLE-optimal placement {0,5,7,10,11} diverges from CSI-optimal {3,4,5,6,7} (Jaccard 0.25; per-mount MI rank corr only 0.248). Conclusion: BLE RSSI is a coarse, seed-noisy locator — NOT a substitute for CSI in placement; CSI's mean-amplitude discriminates good vs bad mounts much more sharply. This empirically supports the thesis framing of BLE as calibration/presence and CSI as fine-grained counting. CAVEAT: BLE is modelled at the 5.2 GHz CSI carrier (not true 2.4 GHz BLE) and is a single-scalar RSSI anchor — a BLE-like proxy, not real BLE; a real AX210/Pi5 + BLE anchor is needed to confirm.”

Archive snapshot, as of 8 h ago — the run corpus is rebuilt once a day, so this page is not a live reading. The fleet panel is the live one; it refreshes every 30 s.

Success criteria

CriterionResolved
STAGE 0-1: crowd valid, H(C)>0 (occupancy [1,31] std 8.45) yes
BLE modality: ble.enabled emits ble_links.parquet (rssi_dbm) per candidate yes
Per-candidate measured I(C;Φ) for BOTH CSI (mean_amp_db) and BLE (rssi_dbm) with multi-seed CI yes
A/B: CSI-optimal vs BLE-optimal placement compared (divergence quantified) yes
FRAMING: BLE-like scalar anchor at 5.2 GHz (not true 2.4 GHz BLE), sim-only until hardware yes

Synthesis

BLE arm — is a BLE anchor a second counting modality, or a calibration aid?

Campaign: c-mall-archcad · Session: 01KY0CYKXEV4XXZ3RCSYRHBAKJ · Runs: 5 coupled walk→ray-traced seeds with the BLE modality enabled, on mall-archcad-floor-0 (14-candidate grid)

Executive summary

The thesis is about BLE-calibrated CSI crowd counting, so the natural question is: does a BLE signal actually help you count — could you place access points by BLE, or fuse BLE with CSI? We enabled a BLE link alongside the Wi-Fi CSI on the same five simulated crowds and asked which ceiling mounts each modality says are informative about the crowd. The answer: BLE does carry counting information — on average about as much as CSI — but it is blurry. Every mount looks about equally (un)informative to BLE, and BLE's verdict wobbles a lot from one crowd to the next, whereas CSI sharply and stably separates the good mounting spots from the bad ones. So BLE is not a stand-in for CSI when deciding where to put sensors; it behaves like a coarse presence/calibration signal, with CSI doing the fine-grained counting — exactly the division of labour the thesis assumes. (Caveat up front: the simulator models BLE at the Wi-Fi carrier, not the real 2.4 GHz BLE band, so treat the specific BLE numbers as a proxy.)

Why this ran

Every prior mall result placed APs by CSI mutual information. If a BLE anchor were an equally good — or complementary — counting modality, the counting-optimal placement should look similar under BLE, or a fused CSI+BLE signal should beat CSI alone. Testing that is the on-thesis step: it tells us whether BLE earns a counting role or a calibration role.

What we measured

On the identical five runs we computed, per candidate mount, the mutual information I(C;Φ) between occupancy count C and (a) the CSI mean amplitude and (b) the BLE RSSI — each a single scalar per mount per frame-window, multi-seed mean + t-CI. We then compared the counting-optimal AP set under each modality (Jaccard overlap) and the agreement of their per-mount informativeness rankings (Spearman).

Results

BLE carries counting signal, but a blurry one. Mean per-mount BLE MI is 0.212 nats — marginally above CSI's 0.172 — so BLE is not uninformative. But the spread across mounts is 0.103 nats for BLE versus 0.251 for CSI: BLE assigns nearly every mount a similar value, while CSI strongly distinguishes hubs (top CSI mount 0.344 nats) from dead spots. And BLE's ranking is unstable across crowds — seed-rank Spearman ρ = 0.186 for BLE versus 0.593 for CSI. A modality that can't reproduce its own ranking across seeds can't be trusted to choose mounting points.

The two modalities pick different placements. BLE-optimal {0, 5, 7, 10, 11} vs CSI-optimal {3, 4, 5, 6, 7} share only {5, 7} — Jaccard 0.25 — and their per-mount informativeness rankings barely agree (Spearman 0.248). BLE would send you to different mounts than CSI, but because BLE's own ranking is noise-dominated (ρ=0.186), that divergence is not a better placement, just an unreliable one.

What it means

BLE, as a single-scalar RSSI anchor, is a poor instrument for where to place counting sensors: it is spatially blurry and seed-noisy compared with CSI. This is consistent with — and empirically motivates — the thesis's architecture, where BLE serves calibration and presence (a coarse, cheap "someone is here" / drift reference) and CSI does the fine-grained counting and placement. It argues against treating BLE as a co-equal counting modality, and for using it the way the thesis proposes: to periodically re-anchor the CSI counter, not to replace it. A CSI+BLE fusion for counting is still worth testing, but on this evidence BLE's contribution to placement is small.

Confidence & caveats

Not real BLE. The simulator models the BLE link at the 5.2 GHz CSI carrier, not the 2.4 GHz BLE band — different propagation and wall/body interaction — so the specific BLE magnitudes are a proxy, not a BLE measurement. Both features compared are scalars, which understates CSI's true advantage (its full 52-subcarrier vector carries more than the mean). Single floor, seed is the unit (n=5), sim-only. The clean next step is a real 2.4 GHz BLE beacon + AX210/Pi5 CSI floor (IP-106/IP-112) to confirm the calibration-vs-counting division of labour on hardware.

Figure: fig_placement_oracle_mall-archcad-floor-0_ble (BLE-informativeness panel), with rec_ble.json + rec_csi.json at the session artefacts prefix for the full A/B.

Criticism adversarial review

Written by the campaign-critic subagent against the brief's success criteria — read it as the counter-position to the synthesis above.

Criticism — BLE arm 01KY0CYKXEV4XXZ3RCSYRHBAKJ

🔴 The load-bearing caveat

This is not real BLE. The runner models the BLE link at the CSI carrier (5.2 GHz, channel_hz=5.2e9), not the 2.4 GHz ISM band where real BLE advertises. 2.4 GHz propagation, wall penetration, and body-shadow are materially different, so the specific BLE numbers (flat MI, low ρ) are a property of this 5.2 GHz scalar-RSSI proxy, not a measurement of BLE. The qualitative claim (a single scalar RSSI discriminates mounts less sharply than CSI mean-amplitude) is plausible and on-thesis, but must be labelled a proxy result.

⚠️ Fair-comparison notes

  • Both features are scalars (CSI mean_amp_db = mean over 52 subcarriers; BLE rssi_dbm), so this compares two aggregate features, not CSI's full subcarrier vector vs BLE. CSI's real discriminative edge (per-subcarrier structure) is understated here — a full-CSI feature would likely beat BLE by more.
  • The CSI arm here differs from the sealed 14-grid CSI session (count-opt {3,4,5,6,7} vs {3,4,7,11,13}) — run-instance + bootstrap variability at moderate ρ. The A/B is valid because CSI and BLE are reduced from the same 5 runs; do not cross-compare BLE-arm CSI against the other session's CSI.
  • BLE ρ=0.186 is low enough that the BLE-optimal set is barely reproducible — its divergence from CSI is real, but its own identity is noise.

Solid

BLE modality emits and reduces cleanly; the flat-and-noisy BLE MI vs sharp-and-stable CSI MI is a consistent, interpretable contrast that lands squarely on the BLE-calibrated-CSI thesis.

Verdict

seal. Keep the 5.2 GHz-proxy caveat front and centre; the finding motivates real 2.4 GHz BLE + AX210/Pi5 hardware (IP-106/IP-112) as the next step.

Attached runs

Run Gate Purpose Replay
80637BVS replay
C15SVKQR replay
FA7ZHNX8 replay
0225YD9H replay
5D2GDBR1 replay