5/10 MHz narrowband on the RTL8814AU — completing the series#221
Merged
Conversation
The last chip in the series. The 8814A's phy_SetBwRegAdc only pokes 0x8ac[1:0] (a 20/40/80 mode selector with no sub-20 value), so the divider looked absent — and the 8812AU divide (writing [9:8]/[21:20]) narrows nothing on it. But the vendor's own field comment documents the full 0x8ac set as [28, 21:20, 16, 9:6, 1:0]: the 8814 shares the *8822B* layout, where the ADC clock is [9:8]+[16] and the DAC clock is [21:20]+[28] — the [16]/[28] high bits dominate. Clearing them and writing the 8821C/8822B divide codes verbatim (10 MHz 3/3, 5 MHz 2/2, small-BW 2/1) narrows the 8814 exactly as it does an 8822B. Bench-verified (RTL8814AU 4T4R, host-pushed TX via the 3081 MCU): - SDR occupied bandwidth: 20M=16.4, 10M=8.2, 5M=4.1 MHz - 8814AU 10M TX -> Jaguar3 RX 8800; J3 10M TX -> 8814AU RX 7800 - 8814AU 5M TX @2.4G -> J3 RX 8800; 20M regression 8700; ctest 13/13 - caps: RTL8814A narrowband=1 bw=[5,10,20,40,80] (8812A same; 8821A correctly stays narrowband=0 / [20,40,80]) Narrowband now spans every supported Jaguar1 chip except the 8821A (DAC-clock divide starves its 1T1R TX path). Docs/README/CLAUDE updated; the narrowband doc's "walls" now records the per-die encoding trap (same fields, different sub-field) instead of calling the 8814 unported. 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.
What
5/10 MHz narrowband on the RTL8814AU (4T4R) — the last chip in the series that hadn't been cracked, and the one whose bandwidth register genuinely doesn't look like it has a narrowband path. This completes narrowband across every supported chip and generation.
The trap it was hiding
The 8814's
phy_SetBwRegAdc_8814Aonly pokes0x8ac[1:0]— a 20/40/80 mode selector with no sub-20 value — so the divider looks absent. Worse: the 8812AU divide (which writes[9:8]/[21:20]) narrows nothing on the 8814 (first attempt: all three widths read 16.4 MHz on the SDR).The crack was in the vendor's own field comment, not its code:
0x8ac[28, 21:20, 16, 9:6, 1:0]. That's the 8822B layout — the ADC clock is[9:8]+[16]and the DAC clock is[21:20]+[28], with the[16]/[28]high bits dominating (which the executed code never writes). Clear those high bits and write the 8821C/8822B divide codes verbatim (10 MHz 3/3, 5 MHz 2/2, small-BW 2/1) and the 8814 narrows exactly like an 8822B.Result (bench, RTL8814AU 4T4R, host-pushed TX via the 3081 MCU)
RTL8814A→narrowband=1,bw=[5,10,20,40,80](8812A same; the 8821A correctly staysnarrowband=0/[20,40,80])The full picture
Narrowband now spans every supported chip — Jaguar1 (8812AU/8811AU/8814AU), Jaguar2 (8822B/8821C), Jaguar3 (8822C/8822E) — with one characterized exclusion, the 8821A (its 1T1R clock tree starves TX when the DAC clock is divided).
docs/narrowband.md's "walls" section now records the per-die encoding trap — the same register block can carry the same fields under a different value encoding per die; a divide that reads dead may just be landing in the wrong sub-field, so read the vendor's field comments, not just the code it executes — in place of the old "8814 is unported" note. README and CLAUDE.md updated to match.🤖 Generated with Claude Code