Kestrel FastRetune: drop the per-hop synth relock + DDV writes (25 → 9 ms)#327
Merged
Conversation
… 9 ms) Two more levers on top of the compose-cache, both on-air + soak validated (and both contradicting my earlier "that would deafen the radio" guess — tested, not assumed): - The synth PLL relock (halrf_set_s0_arfc18's ~13 ms LCK poll) was ~60% of the hop. For a SAME-sub-band hop the VCO moves little and settles during the caller's admission window, so a plain RF18 write holds channel accuracy; the full relock + LCK verify (the only path with MMD-reset lock recovery) is kept for a sub-band crossing (a bigger jump). Gated on the gain-bucket change that already drives the gain re-apply. - The DDV (d-die 0x10018) writes are unpopulated on the single-die 8852B — dropping them costs no channel accuracy. Same-sub-band hops land at ~9 ms, cross-sub-band ~13 ms, both zero wrong-channel (adjacent 36/40/44 delivery 98.5%; cross 36/44/149 wrong=0; aggressive-config soak 2000 hops zero wrong-channel, ~97% delivery). Net from the ~44 ms unoptimized hop: ~5x. A SetMonitorChannel still always relocks, so the fast hop's dropped guarantee is bounded to the intra-sub-band case. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #326's compose-cache — the two remaining levers, both measured and soak-validated (and both contradicting my earlier "that would deafen the radio" guess; I tested rather than assumed this time).
Per-stage profiling of the ~25 ms compose-cache hop showed the split: synth relock 10–18 ms (~60%), path-B write ~3 ms, DDV ~3 ms.
Lever 1 — relock only on a sub-band crossing (the big one)
The path-A channel write runs a full synth PLL relock (
halrf_set_s0_arfc18:0xd3hold + RF18 write + a ~13 ms0xb7LCK poll) +fast_lck_check(MMD-reset recovery). For a same-sub-band hop the VCO moves only a little and settles on its own during the caller's admission window, so the LCK poll is pure blocking — a plain RF18 write holds channel accuracy. The full relock (the only path with lock-failure recovery) is kept for a sub-band crossing (a bigger VCO jump), gated on the samegain_bucketchange that already drives the gain re-apply.Lever 2 — drop the DDV writes
The d-die
0x10018window is not populated on the single-die 8852B, so its two SI writes + two0xcftoggles cost no channel accuracy.Results (8852B DUT, host oracles)
Net from the ~44 ms unoptimized hop: ~5× (44 → 9 ms), putting Kestrel FHSS within reach of the 11ac chips (~50 ms dwell-1 slot → ~30 ms). A
SetMonitorChannelstill always relocks, so the fast hop's dropped lock-verify guarantee is bounded to the intra-sub-band case where it's empirically safe.Docs: updated Kestrel row + explanation in
docs/frequency-hopping.mdand the FastRetune section insrc/kestrel/CLAUDE.md. ctest 36/36.🤖 Generated with Claude Code