Repository navigation
kestrel: park the EDCCA level on 5 GHz as on 6 GHz - #491
Merged
Merged
Conversation
With the BB table's EDCCA level the MAC energy-detect gate latches busy on the receiver's own floor (-65..-69 dBm as the BB measures it, no DIG) on 5 GHz too, and more the higher the channel: host injection from an 8832CU at a 20 ms gap reached an 8812CU witness at ~50% on ch6/36/44, 52% on ch52, 21% on ch60, 3% on ch64 and 0 of ~435 frames on ch100/149/157/161, with 0.0% SDR airtime on ch161 and the injector stalling on bulk-OUT timeouts. Clearing the EDCCA gate alone restored ch64-161 to the ch6 rate; clearing the primary gate alone restored nothing. Program the vendor's unlinked EDCCA_NORMAL_MODE level on 5 GHz as the 6 GHz path already does (the vendor's own level for an unassociated device, never busy); preamble carrier sense stays on. After the change, default configuration: ch6 / 44 / 100 / 161 all ~50% witnessed at the same rate. Deferral still holds on ch161: a max-duty injector sent 19063 frames on a quiet channel, 7327 under a co-channel max-duty MCS1 flood with the gates on, 15676 with DEVOURER_DIS_CCA=1. 2.4 GHz is untouched (floor -82 dBm, busy=0). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
PR Summary by QodoKestrel: park EDCCA on 5 GHz to restore host injection
AI Description
Diagram
High-Level Assessment
Files changed (4)
|
Code Review by Qodo
1.
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
Review point: the park rewrites the threshold CRs in place and a later 2.4 GHz tune left them parked. The glue now captures the table's five threshold CRs (level_p, level, ppdu, dwn, obss) before the first park and a 2.4 GHz tune after a parked band writes them back; the tune log carries the programmed level. Measured: a fresh ch6 tune logs level=66; a 161->6->161->6 hop session logs 249 on each 5 GHz tune and 66 on each return to ch6, with 440 of the ch6 dwell frames witnessed; ch161 and ch6 injection unchanged (222/435, 209/431). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
agustinglez
added a commit
to agustinglez/devourer
that referenced
this pull request
Oct 15, 2026
Some 8852C bring-ups armed the ACK responder, read the entry back, and answered no ACK for the whole session (OpenIPC#490). The chip built the ACK, but the TX path selection the MAC attached to it was garbage in those bring-ups: it enabled a path this 2T2R die does not have, or mapped path A off the signal, so no antenna sent it. The selection comes from MAC state nothing initialises, which is why it changed per bring-up. The halbb glue now follows the T-MAC path routing at bring-up with halbb_ctrl_tx_path_pmac_8852c(RF_PATH_AB): the BB takes the path enable and the path A/B maps from its own P-MAC registers (0x09a4 [4:2]), paths A+B with A on IFFT 0 and B on IFFT 1, plus the vendor's per-path TSSI reset pulse. 8852C only; the switch applies to every PPDU. - ack_responder_ok is true on the 8852C as well (still an explicit list of measured variants). - docs/kestrel-ack-responder.md: the dead-bring-up section now gives the cause, how it was found (the TX-info debug port, decoded with the BB's INTF_TXINFO layout), what was ruled out, and the fix's numbers. Measured (TX50UH responder, TX20U Nano soliciting, ch161, MCS1, 8 s per session): before, 3 of 12, 6 of 15 and 4 of 30 sessions dead (the last on master with OpenIPC#491); the map-A-1 selection died 10 of 10 times. After, 0 dead of 123 armed sessions across the register-level override and this vendor call (30 of them on this exact code), 15 of them with the bad selection, all 96.8-100%; solicitor across a live disarm 3791/3845 then 0/1602 and 3829/3843 then 0/1639; never armed 0/1591. Second bench: 0 of 20 on ch6 and ch161, both units. One-stream injection unchanged (MCS1 and 6M ~1900/2000 to the 8852B, ch6 and ch161 with carrier sense on). Two- stream injection from the 8852C does not decode with or without this, so its effect there is not measured.
josephnef
pushed a commit
that referenced
this pull request
Oct 16, 2026
Fixes the dead ACK bring-ups on the 8852C (item 1 of #490). ## In short Some 8852C bring-ups armed the hardware ACK responder and then answered no ACK for the whole session. The chip did build the ACK, but every frame also carries a selection of which transmit antenna paths to use, and the one the MAC attached to the ACK was garbage in those bring-ups: it enabled a path this 2T2R chip does not have, or wired path A to the wrong signal, so no antenna sent it. The selection comes from MAC state nothing initialises, which is why some bring-ups were fine and others were not. The fix makes the baseband take the path selection from its own registers instead of from the MAC, using the vendor's own function for it, right after the existing path routing at bring-up. 8852C only. ## The change - `kestrel_halbb_ctrl_tx_path` (halbb glue) calls `halbb_ctrl_tx_path_pmac_8852c(RF_PATH_AB)` after `halbb_ctrl_tx_path_tmac_8852c`: `0x09a4` [4:2] selects P-MAC as the source of the path enable and the path A/B maps, set to paths A+B with A on IFFT 0 and B on IFFT 1. - `ack_responder_ok` is true on the 8852C too, still as an explicit list of measured variants. - `docs/kestrel-ack-responder.md`: the dead-bring-up section now gives the cause, how it was found, what was ruled out, and the numbers. `AdapterCaps.h` and the `SetAckResponder` contract follow. ## Measured TX50UH responder, TX20U Nano soliciting, ch161, MCS1, 8 s per session: | | dead sessions | |---|---| | without the fix (three series, the last on master with #491) | 3 of 12, 6 of 15, 4 of 30 | | with the fix (register-level override and this vendor call; 30 on this exact commit) | **0 of 123**, all 96.8-100% | - The bad selection (path A mapped to 1) died 10 of 10 times without the fix and answered 15 of 15 times with it. - Live disarm with the solicitor running across it: 3791/3845 then 0/1602, and 3829/3843 then 0/1639. Never armed: 0/1591. - Your bench on 9efa6ac (the register-level version): 0 dead of 20, both units, ch6 and ch161. - One-stream injection from the 8852C to the 8852B is unchanged: MCS1 and 6M ~1900/2000 on ch6, and on ch161 with carrier sense on. - MSVC build, `ctest` 79/79 on Windows. ## Your two notes - **TSSI reset pulse.** Included: the change now calls the vendor function instead of writing the three registers by hand, so the per-path 0x58dc / 0x78dc pulse runs as in the vendor. The 30 sessions and the injection cells above were taken on this version. The function also sets halbb's `bb->tx_path` to RF_PATH_AB, as in the vendor driver. - **Scope.** The switch applies to every PPDU, and the measurements cover one stream only. Two-stream injection from the 8852C does not decode on master with or without this (MCS12 and VHT2SS_MCS1: 0/2000 at the 8852B, while the 8852B's own two-stream frames reach the 8852C), so what the change does to two-stream TX is not measured. ## Not in this PR - Where the MAC takes the response's path selection from is still not found (not the per-macid CMAC table, not the MAC TX power tables, not the firmware version). - The "response-abort gates are mandatory" note in the doc was measured before #491 parked the 5 GHz EDCCA level; it may no longer hold on 5 GHz, but it was not re-measured here. - The bus-9 TX50UH host-TX fault, the coex cleanup and the bench note stay in #490.
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.
The problem
Host injection from an 8832CU goes silent on the upper 5 GHz channels. With the BB table's EDCCA level the MAC energy-detect TX gate latches busy on the receiver's own floor (-65..-69 dBm as the BB measures it, no DIG), the mechanism the 6 GHz path already parks (
src/kestrel/CLAUDE.md). Measured on the bench (TX50UH injector, 20 ms gap, 8812CU witness, default configuration):SDR airtime on ch161 under a max-duty flood: 0.0% (ch44: +4% over idle); the injector stalls on bulk-OUT timeouts. The fixed TX-power knob (8 / 14 / 20 dBm) changes nothing.
DEVOURER_CCA_GATES=0,1(EDCCA gate alone cleared) restores ch64 / 100 / 161 to 220-226;1,0(primary alone) restores nothing. The tune log says it on every 5 GHz tune:EDCCA band1 pwdB fb=-67 ... busy=1.The change
kestrel_halbb_edcca_6gbecomeskestrel_halbb_edcca_park(band_type, bw)and the channel set calls it for 5 GHz as well as 6 GHz: the vendor's unlinkedEDCCA_NORMAL_MODElevel, its own level for an unassociated device, never busy. Preamble carrier sense stays on. 2.4 GHz is untouched (floor -82 dBm, busy=0). Comments and the Kestrel notes carry the measurements; the compliance consequence the 6 GHz note already states now covers 5 GHz.Measured after the change
Default configuration, same setup: ch6 196/423, ch44 215/434, ch100 227/440, ch161 224/437. Deferral still holds on ch161: a max-duty 6M injector sent 19063 frames in 8 s on a quiet channel, 7327 (7086 witnessed) under a co-channel max-duty MCS1 flood with the gates on, 15676 (10639) with
DEVOURER_DIS_CCA=1. Linux build +ctest83/83.One bench, one injecting unit (the second TX50UH on this bench does not host-inject at all, on any band, for an unrelated reason tracked in #490), near field.
Part of #490.
🤖 Generated with Claude Code