Proves the real capture bug. Invents a second one.
GLM 5.3 does the thing this project needs: it tests its own claims. It proves that the c capture exports L/R-interleaved samples rather than the left-channel stream the decoder reads, shows the header and host parser then read that as mono, and explains exactly why three rounds of capture tests missed it — they drive the module directly and never the call site. It also keeps the sample source as the top blocker, with the microphone evidence laid out from the manual, the stock disassembly and the driver comments, and it finds two smaller defects nobody else reported.
Its second “PROVEN BUG” is not one. It reads p25_golay_decode’s failure path as returning check bits, and reports a reproduction. Compiling the real file shows the opposite: the wire word carries the received data in its top 12 bits, so the fallback returns exactly what the code’s comment claims, and the fix it proposes would corrupt a correct path. With the vocoder left as an open measurement rather than the 11–16× CPU wall it is, 25 of 31 claims hold and it lands at C−.
Claims that check out
25 / 31
4 overstated or doubtful · 2 wrong
Decode-critical issues found
2 of 4
CPU left open; misses the 8 kHz rule
Golay fallback, rechecked
0 bugs
its second “proven bug” doesn’t reproduce
CPU the vocoder needs
11–16×
of 72 MHz; it calls this unmeasured
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 graded2 h 57 min · 143 agent steps · 169 tool calls · 512K output tokens · Alibaba Cloud Token Plan · interactive
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
6820.4 pts
25 of 31 claims hold, and the capture defect it proves is real and precisely described. But one of its two executed reproductions is an artifact: the Golay failure path returns the received data, not check bits, and the fix it derives from that would break a working decoder.
Coverage of decode problems25% of the grade
5213.0 pts
Finds the capture bug with the reason the tests missed it, the microphone evidence, de-emphasis, the dead starvation counter, a stale PCM snapshot, the unverified clock writes and a full Phase 2 inventory. It misses the 8 kHz rule, the parser, capture epochs and the gate/clamp mismatch, and leaves the vocoder as an open measurement.
Root cause & prioritisation15% of the grade
7411.1 pts
A strong ordering: the unproven sample source first, then the instrument that would settle it, with a branch to a hardware tap if the answer is the microphone. It spends its third slot on a defect that isn’t one and never names the vocoder wall.
Fix plan & acceptance gates15% of the grade
6810.2 pts
Small, test-first steps in a sensible order, each host-checkable before hardware. Step four would change correct Golay code, nothing sets the receive path flat before the capture test, and the vocoder appears only as “measure it”.
Originality & attribution10% of the grade
707.0 pts
Two genuinely new findings, the stale d snapshot and the unverified clock writes, plus the clearest account of why the capture tests could not catch the defect. Much of the rest restates the bring-up log and stock report, with credit.
Clarity & calibration5% of the grade
723.6 pts
Well organised and specific, with a verification appendix and honest scope. It labels both defects “PROVEN BUG”, and one of them isn’t, which is the kind of confidence that moves fixes.
Weighted total 65, 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
It proves the capture bug, and why the tests missed it
The capture stages the raw interleaved row while the decoder reads the left channel at [i*2], so the export is L0, R0, L1, R1… GLM 5.3 reproduces it against the real staging code, then points out that the header and tools/p25_capture.py read that as mono at the nominal rate, so the RF-versus-microphone contrast runs on the wrong signal. Its explanation of why three rounds of capture tests passed is exactly right: they feed the module contiguous arrays and never exercise the call site in p25mon.c.
It keeps the source question first, with the evidence
The manual gives the built-in codec to microphone and line out and specifies I2S for an external codec, the stock disassembly puts 0xE0=0xC9 in the speaker path with no discriminator route, and the driver’s bit meanings are community reverse-engineering. So the clock and DMA evidence proves plumbing, not content. Its branch is right too: if the capture tracks the microphone, stop working on the I2S path and take the M17 discriminator tap.
The d PCM snapshot copies the first 16 samples of every 32-sample chunk into a static buffer, so the console shows a prefix rather than recent audio. And p25monApplyClockCfg() writes the clock registers through the plain SPI helper that fails silently under contention, while the periodic refresh uses the verified one, so a console clock change can report success without landing. It also flags the FM-audio path as a latent hazard and asks for a guard when 0x10 reads back 0x80.
It reports that p25_golay_decode returns check bits as data when a word is uncorrectable, “injecting garbage into the outer RS codeword”, and prints a reproduction. Compiled against the real p25_fec.c, the opposite holds: the wire word carries the received systematic data in its top 12 bits, so word >> 12 is the data for every value. Four errors in the check half return the clean data; errors in the data half return the received data, which is what the comment and DSD both describe. Its proposed fix, re-reversing those bits, would corrupt a path that works today.
It notes that mbelib synthesis runs inline in the 1 ms super-loop and that real-time behaviour is instrumented but never measured, then leaves it at step six of seven. Emulated, that synthesis needs 11–16 times the radio’s 72 MHz CPU: 134–458 ms for one voiced 20 ms frame. It is a blocker, not a measurement gap, and no front-end fix moves it.
“C4FM energy extends past ±4 kHz” is why it calls 24 kHz the first safe rate. C4FM at 4800 baud occupies under 2.88 kHz of baseband; 8 kHz fails because it gives 1.67 samples per symbol. And its Phase 2 table puts π/4-DQPSK at 4800 symbols per second, where Phase 2 runs at 6,000, which is the actual reason the chip’s modem can’t track it. It also calls one-layer mode “not a P25 symbol source”, which holds for Phase 2 but not for Phase 1, where the mode’s 36 bytes per 30 ms is exactly 4,800 symbols per second.
The audits track 4 issues that stop this radio decoding P25. This review: CPU left open; misses the 8 kHz rule. How the review treated each, from the provenance table: