m monad-knowledge FIIT STU · open research vault
dataset

csi-wifi-human-detection

Also known as: CSI Dataset for WiFi Based Human Detection, WiFi Based Human Detection CSI, Zaman human detection CSI

What it is

Real WiFi-CSI occupancy / human-detection dataset (Zaman, Ahmad, Salman, Khan — 2025) captured on Raspberry-Pi + Nexmon commodity hardware. Its hardware line matches the project's own Pi5+AX210 collection effort (IP-112), so it is a useful real-hardware cross-check for presence detection. Labels are predominantly binary occupancy, with a small explicit two-person subset.

Verified specs

(from direct inspection of the delivered files, 2026-07-11 — not the upstream README)

  • Hardware: Raspberry Pi 4 Model B, Broadcom BCM43455c0, Nexmon-CSI toolchain.
  • Band / bandwidth: 2.4 GHz, 20 MHz, channels 1 / 6 / 11.
  • Scale: 1,126 files — 909 .csv (preprocessed CSI) + 217 .pcap (raw Nexmon captures).
  • Three collection sites: LAB_Final Year Project (200 files), room4_iqbal (252), room6_liaqat (674).
  • CSI CSV format: headerless; each row = one packet, each cell a complex string like -663-640i; 49 columns (subcarriers, after null/guard removal). Packet-count per file varies widely (~55 to ~20,000 rows). .pcap raw captures exist only for the two room6_liaqat static collections.
  • Labels / scenarios: static (empty / occupied) and dynamic (moving) captures. Person count is encoded only in some scenario-folder names — explicit 0 (empty, 20 files), 1 (170), 2 (62); the remaining ~874 files are single-actor lab captures without a count in the path. All facets are enumerated per-file in _manifest.json (site / scenario / motion / persons / channel / ext).

Acquisition & storage

  • Status: acquired — full payload mirrored to project S3 (s3://monad-knowledge/datasets/csi-wifi-human-detection/, ~4.06 GB, DOI 10.21227/smn7-jb67). The upstream CSV Files/ wrapper is stripped; the three site folders sit directly under the prefix.
  • Load pattern: read _manifest.json, filter files[] to the site/scenario/motion/persons/channel subset you need, then fetch only those objects via boto3 — do not sync the whole prefix. CSV cells parse with complex(cell.replace("i","j")). See the datasets skill (.claude/skills/datasets/) and its s3_dataset_loader.py (get_bytes + parse_complex_csv).
  • Regime caveat: 2.4 GHz is the presence-only band per the WiMANS deep-dive (occupancy-csi-variance); expect strong empty-vs-occupied separation but weak graded count, even on the small 2-person subset.

Empirical findings (2026-07-11) — NOT usable for a graded-occupancy claim

(reduction: monad_knowledge/notebooks/python/csi_realdata_occupancy_mechanism.py) The only site with graded counts is room4_iqbal (0 / 1 / 2 persons), but the labels are confounded with recording session, day, and Wi-Fi channel, which makes any occupancy result unidentifiable:

  • persons=0: 20 files = ONE ~10-min session (2024-12-04, 02:06–02:17), channel 11.
  • persons=1: 170 files spanning 2024-12-03 night → 2024-12-04, channel 11.
  • persons=2: 62 files = ONE ~35-min session (2024-12-03 noon), channel 1 (≠ the 0/1 channel).

Consequences, measured:

  • A file-level classifier separates 0-vs-1-person at AUC = 1.000 for every feature family (static amplitude, temporal variance, Doppler shape) — this is the classic session-fingerprint leakage artifact (each occupancy class ≈ one continuous recording, so its static channel is a perfect give-away), not an occupancy result.
  • The mechanism-relevant scalar — mean per-subcarrier temporal STD — does not differ between 0 and 1 person (Mann–Whitney p = 0.83, rank-biserial +0.03). So occupancy-csi-variance does not reproduce here at the 0→1 transition. Mean amplitude level shifts (p = 4e-6) but is itself session/AGC-confounded, so not attributable to occupancy.
  • The persons=2 class cannot be compared to 0/1 without confounding occupancy with channel (ch1 vs ch11).

Verdict: fine as a presence / empty-vs-occupied and pcap→CSI-toolchain reference; not a valid source for graded people-counting or the variance/Doppler mechanism — those need multi-session, channel-matched capture (the case for first-party IP-112 collection).

Why it matters here

Real Pi/Nexmon presence data on the exact chipset family the lab is deploying — a hardware-matched external check for the presence-detection claim and a candidate fixture for the IP-112 measurement protocol once first-party capture is online. The raw .pcap captures additionally let the IP-112 toolchain be validated end-to-end (pcap → CSI extraction) against a known-good reference.