Audits the memory to the byte. Misreads the receive path.
GLM 5.3 Flash’s strongest work is on memory. It reads the linker map and gets every figure right: 0 bytes of SRAM free, 1,160 bytes of CCM, which stock modules hold it, and about 22 KB of DMR-codec and satellite buffers a P25 build could reclaim. It also keeps the unverified sample source as the first blocker, says de-emphasis closes the 4-level eye, finds the hybrid 0x10=0x6E clock state and the ±10% gate against the ±1% timing clamp.
Its receive-path reasoning is weaker. It says the monitor never sets a bandwidth (it forces 25 kHz), puts the HR-C6000’s 0x34 on the AT1846S, leans towards RF on the microphone question, and would gate decoding at ±1% on a rate report quantised to ±0.67%. It never looks at CPU, where mbelib needs 11–16 times the 72 MHz core. 17 of 28 claims hold. That puts it at D, last of the four clean-room audits.
Claims that check out
17 / 28
7 overstated, mislabelled, miscounted or doubtful · 4 wrong
Decode-critical issues found
1 of 4
microphone question left open; misses CPU and the 8 kHz rule
SRAM free after the link
0 bytes
its map audit, exact to the byte
CPU the vocoder needs
11–16×
of 72 MHz; it calls the chain “in good shape”
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.
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
Grok 4.6
70/ 100
Muse Spark 1.3 Contributor
68/ 100
DeepSeek V4.1 Flash
66/ 100
GLM 5.3 Flash
56/ 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
6419.2 pts
17 of 28 claims hold, and its linker-map audit is exact to the byte. Four are wrong and they steer the fixes: the monitor “never asserts a bandwidth” (it forces 25 kHz), the rate report has “~0.004% resolution” (it is ±0.67%), mbelib has “no Phase 2 AMBE+2 decoder”, and a DMA stall the bring-up notes later resolved.
Coverage of decode problems25% of the grade
348.5 pts
Finds de-emphasis as an eye-closer, the hybrid 0x10 clock state, the gate/clamp mismatch, the M17 tap and a thorough memory picture, and keeps the microphone question open. It misses the vocoder CPU wall, the 8 kHz rule, one-layer mode, the test oracle, both muting policies and every tooling bug, and never names the AT1846S filter register.
Root cause & prioritisation15% of the grade
629.3 pts
Puts the unverified sample source first and analog conditioning second, both right, but leans towards RF on the microphone question and gives clock robustness and memory high priority while the vocoder that cannot run in real time goes unexamined.
Fix plan & acceptance gates15% of the grade
629.3 pts
The carrier-keyed test first, the M17 tap as fallback and concrete memory reclaims are sound. Its other fixes rest on wrong premises: forcing a 25 kHz bandwidth the code already sets, a ±1% gate on a ±0.67% rate report, and an inverse-emphasis filter instead of clearing 0x34 bit 5, with no vocoder or oracle work.
Originality & attribution10% of the grade
585.8 pts
Most of its case restates the stock report and bring-up notes, with credit. What it adds is the linker-map audit (CCM users, reclaimable buffers, discarded AMBE objects) and the gate/clamp mismatch.
Clarity & calibration5% of the grade
683.4 pts
Clearly structured, with severity labels and an honest “plausible, not proven” on the sample source, but confident about things that are wrong: “never asserts a bandwidth”, “~0.004% resolution, plenty”, “no Phase 2 AMBE+2 decoder”.
Weighted total 56, grade D. 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 audits the memory to the byte
From the linker map: SRAM .data 17,000 + .bss 112,532 + 1,540 bytes of heap and stack reservation fills all 131,072 bytes, and CCM has 1,160 bytes left. It names who holds CCM: uiNotification 38,400, sound 5,824, uiUtilities 4,608, SPI_Flash 4,096, voicePrompts 3,788, and the whole P25 monitor just 6,016. Its reclaim candidates check out too: about 10 KB of DMR codec buffers and 12 KB of satellite state, and the unused AMBE objects are already discarded by the linker.
The unverified sample source is its first blocker, with the stock analysis credited, the carrier-keyed capture test first and the M17 tap as fallback. It says de-emphasis closes the 4-level eye in a way the demodulator’s linear fit can’t undo, which my model confirms: 0 of 180 frames. It also gets the hybrid clock state right (0x10=0x6E keeps the codec clocking, 0x10=0x80 kills it), and finds the ±10% decode gate against a ±1% timing clamp.
It says the monitor “inherits whatever the current VFO channel happens to be” and “never asserts a bandwidth”, then proposes forcing 25 kHz. trxSetModeAndBandwidth(RADIO_MODE_ANALOG, true) already sets exactly that. It files the HR-C6000’s 0x34 under the AT1846S, never names 0x34=0x3C or the AT1846S 0x58 filters, and argues the stream is probably RF because mic audio “would not produce plausible 4-level carriers”, though no 4-level signal has ever been seen on it.
“The software decode chain … is in good shape.” Emulated instruction counts put mbelib’s IMBE synthesis at 11–16 times the radio’s 72 MHz CPU: one voiced 20 ms frame takes 134–458 ms, so the decoder falls behind on every voiced frame whatever the front end does. It also never mentions the manual’s rule that the I2S frame clock “must be 8KHz”, against the monitor’s 24 kHz.
It would gate decoding at ±1% or steer the resampler from the measured rate, which it says has “~0.004% resolution”. That report counts 160-sample DMA blocks, about ±0.67% at 24 kHz, so the gate would flap. It says “the DMA still stops every ~3–15 s”, quoting a build-21 note the same document later resolves. And it says the bundled mbelib has “no Phase 2 AMBE+2 decoder”: ambe3600x2450 is exactly that codec.
Its first step relies on the c capture and tools/p25_capture.py, but the capture stages the wrong halfwords (158 of 160 positions differ from what the decoder reads) and the parser certifies incomplete streams. pcm_starve never counts. It proposes validating fixes against the project’s channel model, which shares the receiver’s own RRC filter, and treats the per-frame radioSetAudioPath(false) writes as protection rather than two unverified SPI writes per frame.
The audits track 4 issues that stop this radio decoding P25. This review: microphone question left open; misses CPU and the 8 kHz rule. How the review treated each, from the provenance table: