kestrel: park the EDCCA level on 5 GHz as on 6 GHz

[josephnef]

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):

channel	witnessed of ~435
6 / 36 / 44	205 / 192 / 211
52 / 60 / 64	226 / 92 / 12
100 / 149 / 157 / 161	0

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_6g becomes kestrel_halbb_edcca_park(band_type, bw) and the channel set calls it for 5 GHz as well as 6 GHz: the vendor's unlinked EDCCA_NORMAL_MODE level, 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 + ctest 83/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

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Kestrel: park EDCCA on 5 GHz to restore host injection

🐞 Bug fix 📝 Documentation 🕐 20-40 Minutes

AI Description

• Park 5 GHz EDCCA at the existing unlinked level to prevent the receiver’s noise floor from
 blocking injection.
• Preserve preamble carrier sense and leave 2.4 GHz unchanged.
• Document bench results and the resulting 5 GHz regulatory energy-detect limitation.

Diagram

graph TD
  Tune["Channel tune"] --> BB["BB configuration"] --> Band{"Band selection"}
  Band -->|"5/6 GHz"| Park["EDCCA park"] --> Calc["Vendor threshold"] --> TX["Preamble deferral"]
  Band -->|"2.4 GHz"| Default["Table default"] --> TX

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Disable the EDCCA MAC gate on 5 GHz

• ➕ Bench isolation indicates this would restore injection.
• ➖ Bypasses the gate rather than using the existing vendor threshold path.
• ➖ Would still forgo regulatory energy-detect behavior.

2. Calibrate and enforce band-specific EDCCA thresholds

• ➕ Could retain energy-detect deferral where regulatory rules require it.
• ➖ Requires a reliable noise-floor calibration and broader hardware and regulatory validation.

Recommendation: Use the existing 6 GHz parking mechanism for this unassociated injection path: it directly addresses the measured false-busy condition without disabling preamble carrier sense. Treat regulatory-compliant energy detection as a separate requirement; this approach does not enforce it on either 5 or 6 GHz.

Files changed (4) +50 / -28

Bug fix (3) +31 / -18

kestrel_halbb_glue.cGeneralize EDCCA parking across 5 and 6 GHz +7/-5

Generalize EDCCA parking across 5 and 6 GHz

• Renames the 6 GHz helper and accepts a band type so the vendor threshold calculation uses the current band. Its existing one-time initialization and unlinked normal-mode threshold behavior remain intact; the comment now states the expanded regulatory consequence.

hal/halbb/g6/kestrel_halbb_glue.c

kestrel_halbb_glue.hExpose the band-aware EDCCA parking helper +2/-1

Expose the band-aware EDCCA parking helper

• Updates the public declaration to accept the band type alongside bandwidth. The adjacent comment still describes the helper as 6 GHz-only.

hal/halbb/g6/kestrel_halbb_glue.h

HalKestrel.cppPark EDCCA after 5 GHz channel configuration +22/-12

Park EDCCA after 5 GHz channel configuration

• Calls the generalized helper after BB configuration on both 5 and 6 GHz, while leaving 2.4 GHz unchanged. Updates the tune log annotation and records bench evidence for restored injection and continued carrier-sense deferral.

src/kestrel/HalKestrel.cpp

Documentation (1) +19 / -10

CLAUDE.mdDocument 5 GHz EDCCA failure and trade-off +19/-10

Document 5 GHz EDCCA failure and trade-off

• Adds the 5 GHz channel measurements, explains why parking restores injection, and records that preamble carrier sense still defers transmission. Extends the stated regulatory energy-detect limitation to 5 GHz.

src/kestrel/CLAUDE.md

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. A 5 GHz visit leaves 2.4 GHz detection off ✓ Resolved

Description

vnd_bb_ctrl_bw_ch() parks the EDCCA threshold on 5 GHz but skips any threshold update when the
next tune has band_type == 0. After a 5-to-2.4 GHz channel switch, the parked, never-busy
threshold remains in hardware because the channel-control and reset paths do not restore the 2.4 GHz
table value.

Code

src/kestrel/HalKestrel.cpp[R2316-2317]

+  if (band_type == 2 || band_type == 1)
+    kestrel_halbb_edcca_park(_halbb_ctx, band_type, hbw);

Evidence

The channel setter maps 2.4 GHz to band type 0 and calls the common BB tune path. The new guard
excludes that band; parking writes the unlinked EDCCA_MAX threshold to hardware, while the
per-channel BB path and BB reset do not rewrite those threshold registers. Thus the newly parked 5
GHz value persists across the switch.

src/kestrel/HalKestrel.cpp[2609-2612]
src/kestrel/HalKestrel.cpp[2680-2685]
src/kestrel/HalKestrel.cpp[2316-2317]
hal/halbb/g6/kestrel_halbb_glue.c[192-198]
hal/halbb/g6/vendor/halbb_edcca.c[157-176]
hal/halbb/g6/vendor/halbb_edcca.c[212-227]
hal/halbb/g6/vendor/halbb_8852c/halbb_8852c_api.c[1446-1519]
hal/halbb/g6/vendor/halbb_8852c/halbb_8852c_api.c[392-405]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A 5 GHz tune programs a never-busy EDCCA threshold that survives a later 2.4 GHz tune, despite the intended 2.4 GHz table default.
## Fix Focus Areas
- src/kestrel/HalKestrel.cpp[2312-2317]
- hal/halbb/g6/kestrel_halbb_glue.c[175-198]
## Recommended Fix
On a 2.4 GHz tune following a parked-band tune, explicitly restore the 2.4 GHz table EDCCA register values and update the HALBB channel descriptor. Preserve the existing 5/6 GHz parking behavior.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can hide the parts of a finding you never read, like the evidence or the agent prompt

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗