80 MHz vs 40 MHz for Wi-Fi CSI: resolution, snapshot rate and a real compatibility trap

By Wu Jun · Updated 2026-10-29 · 4 min read

Channel bandwidth is one of the most consequential choices in a Wi-Fi CSI setup. It controls how much frequency information each measurement contains. It can also expose a practical failure: a legacy 40 MHz client inside an 80 MHz BSS may make the AP's transmit rate periodically collapse to VHT-MCS0 1SS.

This page separates three issues: bandwidth resolution, the independent snapshot rate, and the wide-BSS client problem reproduced on our GL-MT6000.

1. What bandwidth actually buys you

This table describes the frequency dimension only. Subcarrier count changes with chip, width, firmware and reporting mode. Always count data_num in your own capture instead of inferring it from nominal bandwidth.

More bandwidth is not automatically better:

• the same transmit power spread over a wider band can lower SNR per subcarrier;
• DFS channels can see radar events and automatic channel changes;
• overlapping 80 MHz networks create more airtime contention;
• legacy and low-power clients may only support 20 or 40 MHz.

Maximum width is therefore a sensible starting point for a dedicated CSI radio, not a universal setting for every client in the house.

2. 95.5 records/s is not 95.5 independent snapshots/s

Our 10-minute capture contains 57,293 chain records over 599.924 seconds, or 95.5 records/s. One measurement can contain up to eight tx/rx chain records that share almost the same instant. Closing groups on chain_info bit 15 gives 7,609 measurements, so the independent snapshot rate is:

7,609 / 599.924 s ≈ 12.68 measurements/s

The full analysis also removes 25 zero-heavy groups, obtaining about 12.64 Hz. Time and Doppler processing must use this grouped timeline. Eight chains are not eight consecutive time samples.

Two limits follow:

1. Respiration: at 0.1-0.5 Hz, a 12.64 Hz snapshot rate still has ample Nyquist margin;
2. True walking micro-Doppler: at 5 GHz, radial motion at 1 m/s produces 2v / λ = 2 / 0.06 ≈ 33 Hz, well outside the ±6.32 Hz unambiguous range of a 12.64 Hz snapshot system, so it aliases.

The capture can therefore support slow motion envelopes, respiration and other low-frequency changes. It cannot support a claim that the full gait micro-Doppler spectrum has been recovered. That needs a higher independent snapshot rate, a dedicated radar waveform or different hardware. Counting chain records does not increase Nyquist.

Keep the dimensions separate:

• bandwidth improves range resolution and subcarrier count;
• Doppler/time resolution depends mainly on independent snapshot rate and observation time;
• multipath richness depends on environment and geometry, not bandwidth alone.

3. The legacy-client failure we reproduced

Our test client uses a 2013-era Broadcom NIC and negotiates 40 MHz only. Inside an 80 MHz BSS, the AP's transmit rate for that client periodically collapsed to VHT-MCS0 1SS: 13.5 Mbps PHY and about 7-10 Mbps achieved downlink, while upload remained normal.

The test held the client, room and channel fixed and changed only radio width. After 60 seconds idle, we ran six 6-second LAN downloads. These are grade E first-party results; the captures and scripts are public ^{[1] [2]}:

RSSI stayed near -40 dBm and the client reached 400 Mbps in its fast state, so this was not a weak-signal problem. It resembles a rate-control or airtime-processing failure for a narrow-band client inside a wide BSS. We did not instrument the firmware's internal rate state, so we report the reproducible phenomenon without inventing a specific register-level root cause.

4. Keeping CSI resolution and usable clients together

For a single-radio device, 40 MHz is often the conservative default unless frequency resolution is the dominant requirement. If 80 MHz is essential, isolate it on a dedicated interface and keep legacy clients off that BSS.

5. Reproduce the diagnosis

First check whether the client really collapses:

# tx bitrate = AP -> client, usually the failing direction
# rx bitrate = client -> AP, which may remain normal
iw dev <ap> station dump | grep -E "Station|tx bitrate|rx bitrate"

# inspect width, channel and associated stations
iwinfo <ap> info
iw dev <ap> station dump

Then run an A/B test with one variable at a time:

1. Fix client position, channel, transmit power and test file;
2. idle for 60 seconds between runs to avoid cache and burst scheduling effects;
3. alternate HE80 and HE40 for at least six runs each;
4. record PHY rate, achieved throughput, RSSI, retries and time;
5. do not use a public download as the only load; it adds server and ISP variables.

During our collapse, 12 seconds moved 12.4 MB while the AP transmitted 12.87 MB. There was almost no retransmission waste. The radio stayed at a very low rate and left most airtime idle. A single final speed-test number hides that distinction.

6. Conclusion

• 80 MHz provides roughly 256 subcarriers and finer range bins, but needs better SNR and spectrum;
• 95.5 records/s is not a 95.5 Hz timeline; the independent measurement rate is about 12.64 Hz;
• 12.64 Hz is suitable for low-frequency motion/respiration research, not full walking micro-Doppler;
• HE80 with legacy 40 MHz clients requires an explicit compatibility test, not just successful association;
• separate the sensing radio/AP from normal clients whenever both use cases matter.

Related: the MCS0 rate-control deep dive · OpenWrt Wi-Fi slow after idle · reproduction guide