Standard-driver FHSS experiment 4/5: A/B dwell-1 injection over MCC/FCS

[josephnef]

Summary

Use the proven two-context MCC/FCS scheduler from #271 to transmit and receive one frame opportunity per A/B slot ("dwell-1"), with deterministic queue ownership and on-air validation. This tests whether firmware channel time-slicing can become a real hopping data plane rather than merely alternating idle channel contexts.

Experiment 4 of 5; blocked by #271's timing, parity, and recovery gate.

Define dwell-1 precisely

For this experiment, one dwell contains exactly one Devourer data-frame opportunity plus any explicitly budgeted sync/control frame. It does not mean "request the smallest firmware dwell and hope one packet happens to fit." Slot duration must cover measured retune/settle, queue release, frame airtime at the configured rate/size, ACK/TxReport if enabled, and guard.

Step-by-step

• Choose a conservative fixed PHY profile and payload size; calculate airtime and derive the initial slot budget from Standard-driver FHSS experiment 3/5: two-channel Realtek MCC/FCS bring-up #271 p99 transition/first-decode measurements.
• Establish two explicit per-context TX queues (or the actual firmware-supported equivalent). Prove frames queued for A never air on B and vice versa using distinct sequence/channel tags plus wideband capture.
• Define the enqueue deadline relative to firmware slot time/TSF. Instrument enqueue, DMA/H2C completion, context activation, RF energy start, frame decode, ACK/TxReport, and slot end.
• Implement bounded admission: a late frame is deferred/dropped with a structured reason, never transmitted in the wrong context.
• Send A/B dwell-1 traffic for ≥100,000 slots, initially unidirectional. Record empty, wrong-channel, duplicate, late, truncated, and undecodable opportunities.
• Add RX tracking: deliver channel/context/slot metadata with each frame, quantify first-decode loss after each switch, and ensure stale bulk-IN data cannot be attributed to the next context.
• Add lockstep peer operation. Start with shared absolute schedule and explicit markers; test initial acquisition, phase correction, missed marker, three-slot loss, and peer restart.
• Add bidirectional/control opportunities only after unidirectional stability. Budget turnaround, ACK responder state, and USB RX blindness explicitly.
• Compare delivery, goodput, transition overhead, USB utilization, and CPU load against current Devourer host-driven FastRetune using the same hop pair and traffic.

Implementation details to settle

• Whether queue selection is encoded in the TX descriptor, MAC ID/interface, reserved-page schedule, or host release timing.
• Whether firmware autonomously drains a context queue or needs one H2C/USB kick per slot; the latter may erase the jitter advantage.
• How sequence numbers, retry state, aggregation, ACK/BlockAck, rate control, TX power, and TxReport map across contexts.
• Whether RX descriptors expose the active channel/context; if not, attribution must use a synchronized switch event plus a guarded drain and must be tested against delayed URBs.
• How keyed round order and Devourer sync markers map onto a two-context A/B schedule without mutable peer RNG state.
• How stop/restart invalidates queued frames and schedule epochs.

Fault injection

• Delay host enqueue across its deadline.
• Saturate USB and one context queue independently.
• Drop a switch completion/C2H event.
• Restart one peer mid-round.
• Force an ordinary set-channel/scan request while MCC runs; it must reject or transition through the defined owner handoff.
• Stop with frames queued in both contexts and prove no stale transmission after restart.

Acceptance criteria

• ≥100,000 A/B slots with zero wrong-channel frames and quantified missed/late opportunity rate.
• On-air capture proves one admitted data opportunity per context slot and measures actual guard/settling cost.
• A single hopping receiver acquires and tracks the schedule through loss and restart without persistent phase inversion.
• Late/overload/error behavior is deterministic and observable.
• Comparison against FastRetune shows whether firmware scheduling improves jitter, goodput, or host load enough to justify experiment 5.