Kestrel 8852C passive noise floor: physts measurement bring-up + bare-physts report#307
Merged
Merged
Conversation
…-physts report The C8852C emitted empty physts reports (is_valid=0, all-zero content), so it had no per-frame RSSI/SNR and a null passive noise floor, while the C8852B worked. Root cause was the 8852C physts measurement bring-up, not the parse: - kestrel_halbb_rx_bringup (8852C branch): devourer ran only halbb_init_reg, skipping the vendor halbb_dm_init_per_phy measurement inits. The 8852C needs halbb_ic_hw_setting_init_8852c (BB evm/measurement report-enable 0xa10[0]) + halbb_cr_cfg_physts_init + halbb_physts_parsing_init to snapshot RSSI/SNR/EVM into the report. Call the chip fn directly (the wrapper drags in halbb functions not compiled in this config). - HalKestrel::bb_reset_all R_AX_PPDU_STAT (0xCE40) 8852C 0x0B00020F -> 0x0B000201: drop APP_MAC_INFO/RX_CNT/PLCP_HDR (bits 1/2/3). Those prepend blocks and push the physts_hdr_info out of place; cleared, the report is the bare physts, bit-identical to the 8852B (is_valid + rssi_avg_td + IE_01). The existing PPDU handler hand-parse then works for both dies unchanged. On-air ch36: 8852C passive floor -94.8 dBm / SNR 21.5 dB, cross-matching the 8852B -93.6 within 1 dB. 8852B RX/TX unregressed; ctest green. The frame-free NHM absolute floor stays 8852B-only: on the 8852C the NHM nhm_pwr reads ~23 dB high (its raw HW gain reference, not the SW path nor the front-end gain, which are correct), a deeper RF-cal item with no vendor 8852C offset. The 8852C's absolute floor is met by the passive rssi-snr floor. tests/kestrel_physts_floor_onair.sh validates both dies. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This was referenced Jul 19, 2026
josephnef
added a commit
that referenced
this pull request
Jul 19, 2026
## What The active/frame-free NHM absolute noise floor (`DEVOURER_RX_NOISE_FLOOR` → `RxEnergy.abs_noise_floor_dbm`) was 8852B-only. This enables it for the **8852C on 2.4 GHz**, where on-air characterization shows it is correct and stable. ## Why band-gated I characterized the 8852C NHM across 2.4 + 5 GHz (per-window time series vs the passive floor and the 8852B NHM): - **2.4 GHz**: the 8852C NHM reads correctly and stably (cross-matches its own passive floor within ~2 dB). → **enabled.** - **5 GHz**: the NHM reads correctly for ~1.5 s after a channel tune, then the AGC drifts and **locks** it ~24 dB high — a *bimodal gain-state lock*, not a fixed offset. It's not a halbb SW issue (the env-monitor treats the 8852C identically to the 8852B) nor a front-end-gain issue (the physts RSSI is correct). Only a full `set_channel` re-tune resets it, and RX traffic re-drives it. → **stays gated**, the 8852C uses the passive rssi−snr floor on 5 GHz. The 8852B NHM is correct on both bands (unchanged). ## Validation (on-air) | die | 2.4 GHz (ch6) | 5 GHz (ch36) | |-----|--------------|--------------| | C8852C | **-90 dBm** (was null) | null → passive floor | | C8852B | -83 dBm | -93 dBm (unchanged) | Plausibility guard (-60..-105) retained. Build clean, `ctest` 28/28. New harness: `tests/kestrel_nhm_2g_onair.sh`. Follows up the physts passive-floor work (#307); the 5 GHz NHM gain-lock is the remaining NHM half of #306. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 (1M context) <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.
What
Brings the per-frame passive noise floor (rssi−snr →
RxQuality.noise_floor_dbm+ LinkHealth) to the RTL8852CU/8832CU (C8852C), which previously reported it null while the C8852B worked.Root cause (not a parse issue)
The C8852C emitted empty physts reports (
is_valid=0, all-zero content), so there was no per-frame RSSI/SNR to build a floor from. Two gaps in the 8852C physts measurement bring-up:halbb_init_reg, skipping the vendor'shalbb_dm_init_per_phymeasurement inits. The 8852B fills physts anyway (its table covers it); the 8852C needshalbb_ic_hw_setting_init_8852c(BB evm/measurement report-enable0xa10[0]) +halbb_cr_cfg_physts_init+halbb_physts_parsing_initbefore the engine snapshots RSSI/SNR/EVM. (The chip fn is called directly — the wrapper drags in halbb functions not compiled in this config.)R_AX_PPDU_STAT(0xCE40) hadAPP_MAC_INFO/RX_CNT/PLCP_HDRset, which prepend blocks and push thephysts_hdr_infoout of place (is_valid=0). Clearing them (0x0B00020F → 0x0B000201) makes the report the bare physts, bit-identical to the 8852B (is_valid+rssi_avg_td+ IE_01), so the existing PPDU-handler hand-parse works for both dies unchanged — no parser refactor.Both changes are 8852C-gated; the 8852B path is untouched.
Validation (on-air, both dies plugged)
Cross-die passive-floor delta 1 dB; both cross-match the 8852B's frame-free NHM. 8852B RX/TX unregressed; 8852C TX fine (1170 submitted);
ctest28/28. New harness:tests/kestrel_physts_floor_onair.sh.Scope note (the NHM gap in #306 remains)
The frame-free NHM absolute floor stays 8852B-only: on the 8852C its
nhm_pwrreads ~23 dB high (its raw HW gain reference — not the SW path, which treats the 8852C identically, nor the front-end gain, which is correct since the physts RSSI matches). No vendor 8852C NHM offset exists; it's a deeper RF-cal item. The 8852C's absolute-floor need is met by the now-working passive floor, so this addresses the physts-SNR half of #306; the NHM-reference half is documented in-code as a follow-up.🤖 Generated with Claude Code