Standard-driver FHSS experiment 3/5: two-channel Realtek MCC/FCS bring-up

[josephnef]

Summary

Bring up the smallest useful Realtek MCC/FCS configuration—two fixed same-band channel contexts—and determine whether firmware can switch them with stable, sub-Devourer-slot timing while maintaining monitor RX/injection and correct per-context PHY state.

Experiment 3 of 5; depends on #269 and the firmware-path findings in #270. "FCS" here means Realtek fast channel switch, not frame check sequence.

Goal

Produce a measured A/B/A/B radio schedule controlled by firmware. This experiment does not yet require per-packet dwell or arbitrary N-channel hopping.

Step-by-step

• Map CONFIG_MCC_MODE, hal/hal_mcc.c, H2C_FCS_RSVDPAGE, H2C_FCS_INFO, reserved-page layout, C2H status, and is_fcs_mode_enable into a concise state diagram.
• Identify target chips/firmware with MCC enabled or enable-able; record conflicts such as concurrent-mode, Bluetooth coexistence, TDLS, power save, and interface-role requirements.
• Decode context contents: channel/BW/offset, RF/BB register cache, IQK/calibration data, MAC/BSSID/MAC-ID, TSF, beacon, TX queue/page allocation, dwell and guard time.
• Bring up the vendor-intended two-interface MCC case first (e.g. STA/AP or STA/P2P as supported) and verify A/B presence with a wideband SDR or two receivers.
• Instrument schedule upload, FCS switch interrupt/C2H, context save/restore, queue stop/start, slot boundaries, missed slots, and firmware reset/recovery.
• Add a research-only two-context monitor configuration without weakening the known-good vendor case. Explicitly define which context owns injected frames and RX delivery.
• Sweep firmware-accepted dwell/guard values downward. For every value, run ≥10,000 transitions and measure actual on-air dwell, transition gap, jitter, missed/extended slots, and first-decode delay.
• Compare RF/BB canaries after repeated A/B cycles with full-set end states on A and B. Verify channel-specific power, AGC bucket, spur/notch, bandwidth, and IQK state.
• Stop/abort MCC at every phase (before upload, armed, running, one context removed, USB error) and prove restoration to a known single-channel state.

Required test cases

• 36↔40 at 20 MHz (primary candidate).
• A same-band pair crossing any relevant AGC/sub-band bucket.
• Same primary channels at 40 MHz with fixed offsets.
• RX-only, TX-only, and bidirectional traffic.
• Loaded TX queues and idle queues.
• Cold start, firmware restart, unplug/replug, and command timeout.
• Cross-band only as a safe negative/control; do not fast-enable it by assumption.

Safety and architecture constraints

• Use legal non-DFS channels; MCC does not satisfy CAC or continuous radar-monitoring requirements by itself.
• Do not mutate vendor firmware blobs. Keep initial work to driver/H2C data structures and capability-advertised commands.
• Maintain a single owner for RF state; ordinary set-channel, scan, ROC, TDLS, and power-management operations must reject or stop MCC cleanly.
• Never report programmed dwell as achieved dwell without on-air measurements.

Decision gate

Advance to dwell-1 injection only if the minimum stable setting has p99 transition gap below 5 ms (preferably below current ~1.5 ms), no drift or missed slot in 10,000 transitions, correct destination decode, and recoverable stop/error paths. Otherwise document MCC as a slow slot-hopping option or reject it.

Acceptance criteria

• Two fixed contexts alternate on air with decoded traffic on both.
• Schedule format, timing unit/reference, context contents, and firmware support matrix are documented.
• Dwell/transition distributions and ≥10,000-transition reliability results are committed.
• Per-context register/calibration parity is checked, not inferred.
• Abort/error testing returns the adapter to a usable, known channel without reload where possible.