Standard-driver FHSS experiment 5/5: N-channel hopping via inactive MCC context rewrite

[josephnef]

Summary

Determine whether a two-context Realtek MCC/FCS engine can produce an arbitrary N-channel hop sequence by rewriting the inactive context while the active context carries traffic ("ping-pong contexts"), without stopping the firmware scheduler or transmitting with partially updated state.

Experiment 5 of 5; blocked by #272. This is an optimization/reuse experiment, not permission to patch firmware or bypass regulatory state.

Proposed model

slot k:   context 0 active on ch[i]   | rewrite context 1 → ch[i+1]
boundary: atomic firmware switch      |
slot k+1: context 1 active on ch[i+1] | rewrite context 0 → ch[i+2]

The core unknown is whether a context is a firmware-owned mutable record with an atomic commit, or a collection of live RF/BB/reserved-page state that cannot safely change while MCC runs.

Step-by-step

• Enumerate every per-context object and its ownership: firmware RAM/reserved page, RF/BB cache, IQK/calibration slot, channel/BW, TX power, AGC/spur state, MAC ID/interface, TSF/beacon, queue, and host shadow state.
• Trace all writes used to configure/update a context. Identify explicit version/valid/commit fields, firmware acknowledgements, DMA lifetime rules, and whether firmware may read the record at any time.
• Build a no-traffic A/B control that repeatedly rewrites only the inactive context A→B→C→D while logging firmware events and observing RF. Start with channels in one AGC/sub-band bucket.
• Add a two-phase update if supported: prepare complete inactive state, receive firmware-ready acknowledgement, then atomically arm it for the next boundary. Never edit a live reserved page in place.
• Measure the update deadline: latest safe submit time before boundary, H2C/USB p99, firmware apply time, and behavior when the deadline is missed. A missed update must repeat/skip a slot or stop safely, never expose mixed state.
• Add dwell-1 traffic from Standard-driver FHSS experiment 4/5: A/B dwell-1 injection over MCC/FCS #272 and verify ≥100,000 slots across 3- and 4-channel sequential schedules with wideband capture.
• Add Devourer's stateless keyed schedule. Derive the next target early enough to meet the update deadline; preserve absolute-slot acquisition and schedule markers.
• Cross AGC/sub-band buckets and then widths only after adjacent 20 MHz hopping passes. Compare context register parity against a full set for every target.
• Inject torn/late/missing update, C2H loss, USB congestion, firmware reset, and host restart. Define epoch/version rollover and stale-context rejection.

Alternative branches to evaluate

1. Inactive-context rewrite works atomically: implement the ping-pong scheduler behind an experimental capability flag.
2. Rewrite requires stopping MCC: measure stop/reprogram/start; retain only if it still beats FastRetune and does not lose synchronization.
3. Firmware supports more than two native contexts/table entries: prefer uploading the whole bounded hop table once.
4. Only channel register changes safely: keep two complete context templates but apply a minimal firmware channel delta, with parity validation.
5. No safe mutation: close with evidence and keep fixed A/B MCC; do not emulate atomicity through timing luck.

Correctness invariants

• Active context is immutable.
• A target becomes eligible only after complete firmware acknowledgement/version match.
• Channel, bandwidth, calibration, TX power, queue identity, and host shadow state change as one logical generation.
• The frame admitted for slot s either airs on schedule(s) or is observably dropped/deferred.
• Failed updates cannot silently collapse the keyed sequence into a predictable stale A/B loop; peers receive an epoch/status indication and reacquire.
• Cross-band remains on the full safe path unless complete RFE/calibration context restoration is proven.

Regulatory constraints

Use permitted non-DFS channels for development. Context caching or prior brief visits do not establish DFS availability. Any future DFS hopset requires a separate regulatory design for CAC, radar monitoring, channel availability, evacuation, and non-occupancy; this issue must not disable those controls.

Acceptance criteria

• An on-air verified 3- and 4-channel schedule runs for ≥100,000 dwell-1 slots with zero wrong-channel/mixed-context frames.
• The inactive-context update protocol, ownership, deadline distribution, and failure behavior are documented.
• Full-path register parity is checked per target channel, including bucket crossings attempted.
• Keyed schedules remain deterministic by absolute slot and recover after missed updates/restarts.
• A benchmark compares ping-pong MCC, fixed A/B MCC, and current FastRetune for transition gap, jitter, delivery, goodput, USB traffic, and CPU.
• If atomic safe mutation is unavailable, the issue records a defensible no-go result rather than shipping a race.