TX: NitroQAM (256-QAM VHT on 2.4 GHz) — expose, on-air validate, document (already reachable, band-agnostic path)

[josephnef]

Summary

Expose and validate 256-QAM VHT on the 2.4 GHz band ("NitroQAM" / "TurboQAM") as a first-class, documented TX mode. This is the proprietary Realtek/Broadcom extension that runs an 802.11ac VHT PPDU with a 256-QAM constellation in the 2.4 GHz band — 2×2 VHT MCS9 @ 40 MHz/SGI = 400 Mbps PHY, vs the 300 Mbps ceiling of standards-only 802.11n (MCS15, 64-QAM). It is what "AC1300"-class adapters (e.g. the RTL8822BU CF-924AC, INVENTORY slot #15) advertise on 2.4 GHz.

Motivation

• Closes the last modulation gap on 2.4 GHz — a ~33% PHY-rate headroom for close-range, high-SNR links (bench throughput demos, short-range ground-station uplink).
• Costs almost nothing: the transmit path already supports it (see below); this is a validation + power-shaping + docs task, not new plumbing.

Current state — it is already reachable, not gated

The TX path is band-agnostic end to end. DEVOURER_TX_RATE=VHT2SS_MCS9/40 (or a radiotap VHT field, MCS=9 / NSS=2) on a 2.4 GHz channel already resolves to MGN_VHT2SS_MCS9 → DESC_RATEVHTSS2MCS9 (0x3F), rate_id=9, bw_desc=1, and is written into the 8822B TX descriptor without ever reading the channel/band:

• src/Radiotap.c / src/jaguar2/RtlJaguar2Device.cpp (fill_descriptor) — VHT MCS/NSS decoded, no band check; 40 MHz on 2.4 GHz reachable via DEVOURER_BW=40.
• Shared MRateToHwRate maps MGN_VHT2SS_MCS9 → DESC_RATEVHTSS2MCS9 for Jaguar1/2/3 alike.
• Vendor drivers confirm: the injection lever (fix_rate → USE_RATE=1, rtl8812au_xmit.c, ioctl_linux.c) has zero band validation; DESC_RATE* is one flat band-agnostic enum.

Band is special-cased in only two places, neither a transmit gate:

1. Association-time registry knob vht_24g_enable / REGSTY_IS_11AC_24G_ENABLE (rtw_cmd.c) — only controls whether the VHT IE is advertised at assoc. Irrelevant to injection.
2. The regulatory TX-power-limit table skips the VHT section on 2.4 GHz (hal_com_phycfg.c, band == BAND_ON_2_4G && tlrs == TXPWR_LMT_RS_VHT → continue), so 2.4G-VHT inherits the OFDM/HT power base uncapped. A power-shaping quirk, not a block.

Prior evidence it airs: VHT frames have been chip-validated on a real RTL8812AU over the B210 at ch1/2412 (2.4 GHz) and decoded by a software receiver.

Proposed work

1. On-air waterfall validation. Inject VHT2SS_MCS9/40 (and MCS8) vs MCS15/40/SGI (11n 64-QAM baseline) on ch6 from an 8822BU/8812AU; measure delivery on a NitroQAM-aware peer + SDR duty (tests/bench_onair.py, tests/sdr_duty.py). Confirm the baseband emits a clean 256-QAM VHT PPDU on 2.4 GHz and locate the SNR crossing vs 64-QAM. Add a tests/nitroqam_waterfall.sh in the style of tests/ldpc_waterfall.sh.
2. Power fold. Because the reg-limit table skips 2.4G-VHT, the applied per-rate power for MCS8/9 is extrapolated/uncapped — verify with a register dump and, if mis-driven, shape it via the per-rate diff lever (see the companion SetTxPowerRateDiffs generalization issue).
3. Docs + capability. Document NitroQAM under DEVOURER_TX_RATE in DeviceConfig.h and CLAUDE.md; note the peer-decode requirement (a standards-only 11n RX sees noise) and the ~+4–5 dB SNR premium over 64-QAM. Optionally surface a nitroqam_ok bench-derived flag in AdapterCaps (in the spirit of the ldpc_rx_* truth table), set only for the chips validated on air.

Scope / caveats

• 256-QAM is a close-range throughput play — the opposite of the low-rate/narrowband direction wanted for long-range FPV. This is a strong-link mode, documented as such.
• Validate per chip before advertising: 8822BU/8822CU/8822EU/8812AU are the candidates; the flag should reflect on-air truth, not a spec claim.
• No source change is required to select the rate — if validation is clean, the deliverable is a test script, a power-fold check, docs, and (optionally) a caps flag.

Non-goals

• Association / capability negotiation (vht_24g_enable) — devourer is injection-only.
• 2.4 GHz VHT reception robustness (the 8822B-only SOML DSP) — a separate, optional follow-up.

---

🤖 Filed with Claude Code after a code + vendor-reference investigation.