Wi-Fi CSI chain selection: 8-chain health and missing-chain audit

By Wu Jun · Updated 2026-11-02 · Wi-Fi CSI, chain selection, GL-MT6000, MT7986, data quality · 6 min read

A reported 2 Tx x 4 Rx capture is often described as eight CSI chains. That does not mean the receiver behaves like eight equal, independent sensors. Chains may be missing, groups may be incomplete, and amplitude or temporal variability may differ. A parser that assumes eight valid records per group can silently mix missing data, duplicate chains or unintended fallbacks into an experiment.

This audit asks a narrow question using two public GL-MT6000 captures, a 10-minute primary capture and a 60-second comparison: are all eight tx/rx chains equally present, can RSSI/SNR select one, and can amplitude or temporal variance prove which chain is best? Both captures, the analysis script, CSVs, SVG figure and checksums are public ^{[1] [2]}.

1. Results

Three conclusions follow:

1. Eight-chain mode does not mean every measurement has eight chains. About 11.8% of closed groups contain only four.
2. RSSI/SNR cannot rank individual chains in this capture. Both fields are identical across chains inside every group and describe the shared reception context.
3. Low amplitude or low variance does not prove a better chain. Without a noise-only baseline, known motion and task ground truth, a quiet chain may be stable, insensitive or heavily attenuated.
4. A chain ranking does not carry across sessions. The 60-second capture contains eight chains in all 347 groups, but its amplitude ranking is negatively correlated with the 10-minute capture; both the strongest-amplitude and lowest-CV chain change.

2. Presence and temporal variability

The left panel below shows each chain's presence across 7,609 closed groups. The right panel plots median group mean amplitude against temporal coefficient of variation. It is a diagnostic view, not a "best chain" leaderboard.

Figure 1: Chain presence and temporal variability. Colour distinguishes always-present and intermittent chains. The figure does not claim that a low-variance chain is the physically best one.

tx0/rx1 has the lowest temporal CV and tx1/rx0 the highest, a difference of roughly six times. That is not evidence that one is six times better. Motion can raise variance, while nulls and small denominators can inflate CV. Amplitude also depends on automatic gain control, the RF path and the firmware's CSI extraction.

3. A second session rejects a fixed "best chain"

The project also publishes a 60-second de-identified demo capture with SHA-256 41c35d9d23e5c03ddd34ae97617e772fecdb55e8545156181828b060605a87a6. The same script gives:

This is not a small rank change. tx1/rx0 moves from amplitude rank 8 in the 10-minute capture to rank 2 in the 60-second capture. Median RSSI also changes from -31 dBm to -39 dBm. Two captures from the same router and home are enough to reject a permanent "best chain" rule.

A more defensible workflow is:

1. run a short independent calibration for every deployment or new session;
2. store chain completeness, RSSI/SNR context, amplitude distribution and temporal CV as session metadata;
3. apply a fixed-chain choice only within its calibration session and revalidate it on a new session;
4. choose a chain by downstream task metrics, not amplitude or CV alone.

4. Reproduction

The analysis uses only Python's standard library and NumPy. It does not require SciPy or Matplotlib.

1. Walk the outer container: <float64 ts><uint16 len><payload>.
2. Read the 24-byte CSI header and preserve tx, rx, rssi, snr, subcarrier_count and chain_info.
3. Close a measurement group only when bit 15 of chain_info is set.
4. Accept only 256-subcarrier pairs with non-zero I/Q.
5. Compute sqrt(I^2 + Q^2) per subcarrier, then the mean across the record.
6. Compute temporal CV as standard deviation / mean of group mean amplitude for each chain.
7. Save presence, amplitude distribution and temporal variability per tx/rx pair.

Run:

python3 analyze_csi_chain_health.py csi-10m.anon.bin \
  --summary summary.json \
  --csv chain_metrics.csv \
  --img csi-chain-health.svg

Downloads:

• Analysis script
• Chain metrics CSV
• Cross-session comparison CSV
• Machine-readable summary
• README and limits
• SHA-256 checksums

The source capture SHA-256 is 527466ceb8b5f835e55ff348f02808736b947db39e7baac1f34e375de146a440.

5. A chain gate that does not silently change identity

A practical system should use an explicit gate rather than a hidden fixed chain:

for each closed group:
    verify expected chain records are unique
    reject incomplete 256-subcarrier records
    preserve raw chain IDs
    compute per-chain health metrics on a calibration window
    if task requires a fixed chain:
        select it from calibration, not from the test window
    else:
        expose chain-specific features and missingness
    if no chain passes the gate:
        return unavailable

The calibration and test windows must remain separate. Selecting the most stable-looking chain on the test capture and then reporting accuracy on that same capture leaks information. Use empty-room, still-person or known-motion sessions for calibration, then evaluate on unseen sessions.

Keeping only complete eight-chain groups would discard 895 of 7,609 closed groups in this capture. Do not silently fill a missing tx1 chain with tx0/rx0. Either label eight-chain and four-chain groups explicitly or expose chain missingness as a downstream feature.

6. Why RSSI/SNR did not help

In this capture, RSSI and SNR are identical across all chains within each closed group. They can describe the overall reception context but cannot answer which of the eight chains is cleaner. That need not hold for every vendor or firmware, so a replicator must verify field semantics rather than assume each row contains a per-chain RSSI.

The same caution applies to selecting a chain from CSV columns that look correlated. First establish whether the field changes with chain identity; then discuss statistical selection.

7. What these captures cannot prove

• It cannot prove that tx0/rx1 is the physically or experimentally best chain.
• It cannot treat temporal CV as a noise floor without a controlled empty-room baseline.
• It cannot map tx0/tx1 or rx0 to rx3 directly to physical antenna positions.
• It cannot transfer this device's ordering to another firmware, room, client or new session.
• It cannot establish respiration, fall, occupancy or identity accuracy.

A useful chain-selection result must report completeness, missingness patterns, calibration, cross-session stability and downstream task metrics. Without that evidence, the defensible conclusion is "the chains are not equivalent and need explicit gating", not "chain X is best".

8. Next measurements

The next study needs three repeatable conditions: a noise-only empty-room baseline, a known sinusoidal or mechanical control, and human sessions across postures and distances. Hold channel, bandwidth, client, offered load and firmware fixed, and retain raw chain identity. Only then can chain selection become a measured experimental decision rather than a heuristic.