tests: default matrix --channel to 6 (2.4GHz); surface band asymmetry

[josephnef]

Summary

tests/regress.py --channel defaulted to 36 (5GHz UNII-1), and every matrix invocation in README.md + CLAUDE.md examples used --channel 100 (5GHz UNII-2-extended). This hid a long-standing fact: devourer's 5GHz code path has broken cells for 8814 RX, 8821 TX, and 8821 RX that all pass at 2.4GHz. The "RTL8814AU... RX solid" line in CLAUDE.md was correct AT 2.4GHz but appeared to contradict matrix output captured at 5GHz — which is why PR bodies #34, #42, and #49 all record "8814 RX devourer still broken" but those cells work fine at ch6.

What this changes

• tests/regress.py — default --channel → 6. Help text spells out that 5GHz has known broken cells.
• tests/README.md — example invocations drop the explicit --channel 100. Added a "Channel / band asymmetry" entry to Known Limitations.
• CLAUDE.md — regress.py examples drop --channel 100. Adds a paragraph explaining the band asymmetry.

What this does NOT change

• The actual 5GHz code-path issues — separate investigation (follow-up PR will tackle 8814 RX at 5G, 8821 TX/RX at 5G).
• The persistent 8814AU TX gate — 0 hits at both bands; unchanged.
• The 8812AU code paths, which work at both bands.

Empirical evidence — single-pair matrix at both bands, master 9e5287e post-PR-57

VM mode (devourer-testrig + aircrack-ng/88XXau), 12s per cell, --no-baseline-abort.

TX=8812, RX=8814

cell	ch100	ch6
kernel TX → kernel RX (baseline)	292 ✓	339 ✓
devourer TX → kernel RX	4839 ✓	5279 ✓
kernel TX → devourer RX	0 ✗	300 ✓
devourer TX → devourer RX	0 ✗	5500 ✓

TX=8821, RX=8812

cell	ch100	ch6
kernel TX → kernel RX (baseline)	108 ✓	336 ✓
devourer TX → kernel RX	0 ✗	5544 ✓
kernel TX → devourer RX	100 ✓	300 ✓
devourer TX → devourer RX	0 ✗ (105 fail)	5500 ✓

TX=8812, RX=8821

cell	ch100 (extrapolated from full-matrix)	ch6
kernel TX → kernel RX (baseline)	348 ✓	345 ✓
devourer TX → kernel RX	5517 ✓	5279 ✓
kernel TX → devourer RX	0 ✗	300 ✓
devourer TX → devourer RX	0 ✗	5200 ✓

TX=8814, RX=anything (8814 TX gate — broken on both bands)

0 hits at both ch100 and ch6 for every cell where devourer TX is on 8814AU. Pre-existing gate, not addressed here. See kaeru cite RTL8814AU libusb-userspace bulk-OUT does not produce on-air TX.

Why ch6 as default

• The OpenIPC long-range-video use case typically runs at 2.4GHz.
• Out-of-the-box matrix runs should pass for the chips that work — otherwise contributors get false-failure noise.
• The 5GHz issues are real but separate; the new help text + Known Limitations entry tell users how to surface them deliberately.

Test plan

• python3 -c 'import tests.regress' clean import
• python3 tests/regress.py --help renders the new help text
• Single-pair matrix at --channel 6 runs end-to-end and passes for 8812/8821 chip combos (table above)
• Single-pair matrix at --channel 100 reproduces the historical 5GHz broken cells (table above)
• --full-matrix --channel 100 matches prior PR bodies' tables (confirms the change doesn't alter 5GHz behavior — it only flips the default)

Follow-up

Separate PR will investigate why devourer's 5GHz path is broken for 8814 RX / 8821 TX / 8821 RX. Probably a band-switch register sequence missing somewhere in RadioManagementModule::PHY_SwitchWirelessBand8812 or the per-channel BB setup. Saved as kaeru cite devourer 5GHz vs 2.4GHz cell asymmetry — matrix --channel 100 default hides working 2.4G state for the next session.

🤖 Generated with Claude Code