Nine audits before this one argued from reading. This one built something. It compiled the firmware’s own DSP sources natively, timed the three stages of the receive chain, and reported that the vocoder is 87% of the cost — then refused to convert x86 time into a Cortex-M4 budget, and asked for the on-target counter instead. I rebuilt its benchmark: the numbers reproduce within 3%, and on the target the vocoder’s share is higher still. It also found what nobody else did in the register tables: the monitor never writes 0x34, so de-emphasis and a 3 kHz filter stay in the path all session — and the boot table sets the same bit again.
Where it bets wrong is the one thing it cannot check: it assumes the codec is carrying radio audio at all, when the repository’s own analysis says the stream is more likely the microphone. Its plan tests that first, which is the right instinct, through a capture export that is broken in a way it never looked for. 24 of 30 claims hold and none is wrong — one of four audits to reach zero — which puts it at C+, the best of the audits published up to it.
Claims that check out
24 / 30
6 overstated, mislabelled or unverified · 0 wrong
Decode-critical issues found
2 of 4
with partial credit on the other two
Wrong claims
0 of 30
one of four audits to reach zero
Its benchmark, rerun here
87%
the vocoder’s share, reproduced within 3%
ConditionsClean room: a fresh copy of the repository (46eebda with its uncommitted changes, its own docs and the HR-C6000 manual) with no earlier reviews, reviewed by one model through an isolated agent harness with no network, skills or memory.
The run, not graded15 min · 40 agent steps · 62 tool calls · 27K output tokens · OpenRouter API · one-shot
Read the full review audit
Every claim, every rerun and the modelling behind this grade, as published.
Weights reflect the question asked: find what stops P25 decoding and say how to fix it. Accuracy carries the most weight because a wrong review does harm; coverage and root cause together outweigh it because an accurate review of the wrong things does not help.
Where the points went
The 100-point grade split into the rubric’s weighted slots: filled is earned, empty is lost, with the other models on this task for scale.
1Accuracy2Coverage3Root cause4Fix plan56
GPT-6 Astra
89/ 100
GPT-5.6 Sol
84/ 100
HY4 Preview
77/ 100
GPT-5.6 Luna
75/ 100
UNIONALPHA
74/ 100
Grok 4.6
70/ 100
Muse Spark 1.3 Contributor
68/ 100
DeepSeek V4.1 Flash
66/ 100
GLM 5.3
65/ 100
Gemini 3.8 Flash
64/ 100
Qwen3.8 Max
63/ 100
Qwen3.8 Flash
59/ 100
GLM 5.3 Flash
56/ 100
DeepSeek V4 Pro
53/ 100
1Accuracy & evidence30 pts
2Coverage of decode problems25 pts
3Root cause & prioritisation15 pts
4Fix plan & acceptance gates15 pts
5Originality & attribution10 pts
6Clarity & calibration5 pts
Accuracy & evidence30% of the grade
8525.5 pts
Thirty claims checked, none wrong: 47 citations, 31 with line numbers, and every one I opened landed, down to the boot table’s 35th byte. Six are qualified, and the notable one is a Cortex-M4 instruction count it appears to have derived by halving a byte count.
Coverage of decode problems25% of the grade
5614.0 pts
The best decode-critical coverage of the audits up to it — the de-emphasis register, the manual’s 8 kHz rule, the vocoder’s share, the circular test oracle. It finds no tooling defect at all, and no fault in the muting, the health gate or the call state.
Root cause & prioritisation15% of the grade
8012.0 pts
It separates the signal problem from the work already done: the clock, the gating and the eco cycling were real fixes to a path carrying the wrong signal. The gap is that it ranks the filtering above the routing, when the routing decides whether the filtering matters.
Fix plan & acceptance gates15% of the grade
8412.6 pts
Three gates with stop conditions, measurement before modification, and a named fallback — the only plan on this task that tells you when to abandon it. It leans on the capture tooling without checking it.
Originality & attribution10% of the grade
828.2 pts
It wrote and ran a benchmark, sized the hot function by cross-compiling, and turned the manual’s 8 kHz rule into a prediction — sample triplication — that no audit or document had made. No new defect in the code itself.
Clarity & calibration5% of the grade
884.4 pts
Ranked findings with severities, a traced signal path, and two sections most reviews leave out: what it verified by running, and what it could not verify. Its uncertainty is marked where it belongs.
Weighted total 77, grade C+. Grade scale: A ≥ 90 · B 80–89 · C+ 75–79 · C 70–74 · C− 65–69 · D 50–64 · F < 50
Headline findings
Six things to know about this review
Holds up
The register the monitor never writes, found twice
The monitor’s codec refresh writes eight registers and not 0x34, so HRC6000SetFMRx’s 0x34 = 0x3C — “Compressor off, de-Emph on 3KHz Audio Filter” — stays in force for the session. The manual backs it: an audio filter and an optional de-emphasis module sit in the FM receive chain, 0x34[5] enables −6 dB/oct from 300 Hz to 3 kHz, and the low-pass choices are 2.55 and 3 kHz. Then it goes further than any other audit and checks the boot table: spi_init_values_7 is written to page 0x04 from register 0x11, and its 35th byte — the one that lands on 0x34 — is 0xE0, bit 5 set again. I verified that by index.
It turns the manual’s 8 kHz rule into an experiment
Two audits found the constraint that the I2S frame clock must be 8KHz. This one asks the next question: if the codec is specified for an 8 kHz voice channel, does raising LRCK to 24 kHz widen the decimation filter, or just the frame rate? Its prediction is that the capture would show each sample three times, or an 8 kHz image — 24 kS/s carrying 4 kHz of real bandwidth. Nothing in the repository or the nine reviews before it had asked this, and one later audit reached the same question independently. It can be settled from a capture the project can already take.
manual 1127, 1218 · p25mon.c:82–85
Validated
It benchmarked the chain, and the numbers reproduce
It compiled the firmware’s own sources natively with vectorisation off and timed them: resample ~1%, demodulator ~13%, mbelib IMBE ~87%, the vocoder about 7× everything else combined. I rebuilt it: 0.0001 s, 0.0019 s and 0.0131 s per second of audio. Within 3%. It then declines to turn x86 time into a Cortex-M4 budget and points at the DWT counter already wired into the firmware. That caution is right, and it is also the reason it never finds the size of the gap: emulated, mbelib needs 11–16× the 72 MHz budget.
Its whole first finding is that the decoder is fed de-emphasised, filtered radio audio. The repository’s own analysis reaches the opposite conclusion: 0xE0 = 0xC9 selects LineIn1, the manual frames I2S as external-codec plumbing, stock firmware never routes the discriminator to I2S, and the bring-up camped on carriers without a sync. It lists the routing as unverified and puts a carrier-versus-microphone capture first in its plan, which is the right experiment. But if the samples are the microphone, the register it calls the highest-value fix changes nothing.
Its measurements run through instruments it never checked
Gate 0 says: capture on a keyed carrier, measure the RF→PCM transfer function, sweep 0x34, re-measure. Every step of that goes through the capture export and tools/p25_capture.py. The export stages the contiguous first 80 halfwords of each row while the decoder reads [j][i*2], so 158 of 160 positions differ from what was decoded, and the parser certifies captures with missing chunks. The transfer function it would measure is of the wrong samples. No tooling defect appears anywhere in the review.
It rules Phase 2 out because H-CPM is quadrature and this path is scalar. A monitor receives the outbound channel, which is H-DQPSK; H-CPM is the inbound modulation, and being constant-envelope it is one a discriminator handles poorly rather than not at all. The conclusion survives on the signal it did not name. It also dismisses the chip’s one-layer mode as demodulated DMR frames, not raw symbols. The manual says 36 bytes per frame — 4,800 symbols per second, P25’s own rate. Whether the framing carries them is untested, not settled.
manual 2555–2560 · p25mon.c:415–416, 443
Claim check
30 claims, checked one by one
24 hold, 6 overstated, mislabelled or unverified, 0 wrong. Each claim was checked at the lines it cites.
The audits track 4 issues that stop this radio decoding P25. This review: partial credit on the source and the CPU wall. How the review treated each, from the provenance table: