Finds both halves of the filter problem. Points the CPU fix the wrong way.
Muse Spark 1.3 Contributor names both halves of the analog chain, as only Grok 4.6 does among the clean-room audits: the inherited 0x34=0x3C that leaves HR-C6000 de-emphasis on, and the AT1846S voice filters. Its fix turns de-emphasis off while keeping the widest low-pass, the safe register change. It also puts the microphone question first, finds the ±10% gate against the ±1% timing clamp, and keeps CPU on the list as unmeasured, with the sharp observation that an overrun would look like poor RF sensitivity.
Its CPU advice runs the wrong way: raise the clock, trim the filter, “only then touch the decoder”, when emulated counts put mbelib at 11–16 times the 72 MHz CPU and the filter under one. It trusts instruments that don’t work, misses the manual’s 8 kHz rule and dismisses the one-layer route. 22 of 30 claims hold. That puts it at C−, between Grok 4.6 and DeepSeek V4.1 Flash on the same clean-room protocol.
Claims that check out
22 / 30
6 overstated or doubtful · 2 wrong
Decode-critical issues found
2 of 4
CPU flagged, not found; misses the 8 kHz rule
Voice frames with de-emphasis on
0 / 180
the 0x34 setting it names, in my model
CPU the vocoder needs
11–16×
of 72 MHz; 168 MHz adds 2.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.
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
7422.2 pts
22 of 30 claims hold, and the few line citations it gives are exact (0x34=0x3C, the gate and clamp, the TDMA rejection). Two are wrong, one of them misdirecting: it would raise the clock and trim the FIR before touching the 11–16× vocoder.
Coverage of decode problems25% of the grade
5413.5 pts
Finds both halves of the analog chain (0x34 de-emphasis and the AT1846S filters), as only Grok 4.6 also does, as well as the microphone route, the gate/clamp mismatch and the M17 tap, and it flags CPU as unmeasured. It misses the 8 kHz rule, dismisses one-layer mode, and trusts the capture, the parser, pcm_starve and fail-closed muting.
Root cause & prioritisation15% of the grade
7210.8 pts
Puts the microphone question and the flattened analog path first, and keeps CPU on the list as unmeasured rather than clearing it. Held back by a CPU fix order that points away from the vocoder and by dismissing the one-layer route.
Fix plan & acceptance gates15% of the grade
7110.7 pts
Ordered steps with measurable checks: carrier-keyed captures, a four-level histogram, a transfer function, real recordings as regression vectors, and 0x34 changed without narrowing the low-pass. It starts with a capture that stages the wrong samples and would steer the resampler from a quantised rate estimate.
Originality & attribution10% of the grade
707.0 pts
Adds the 0x34 de-emphasis and AT1846S register culprits, the gate/clamp arithmetic, a FIR cost estimate and the overrun-as-poor-sensitivity diagnosis, and credits the stock report, bring-up notes and Stage-4 note throughout. The M17 tap, simulcast scope and band limits restate the repository.
Clarity & calibration5% of the grade
804.0 pts
Concise and well calibrated: blocker, bug, qualification gap and unmeasured are kept apart, and scope limits are marked “do not mistake for bugs”. A few overreaches remain: “cannot be made to”, “no 3 kHz brick wall”, “all cross-checked against independent reference encoders”.
Weighted total 68, 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 finds both halves of the analog chain
Analog mode runs HRC6000SetFMRx, which writes 0x34=0x3C: de-emphasis on with a 3 kHz low-pass, never cleared by the monitor. The AT1846S FM table adds its own high- and low-pass filters, which the DMR table switches off. It names both. Its fix is the careful one: de-emphasis off, compressor off, widest low-pass, AT1846S filters bypassed, then measure the transfer function. In my model de-emphasis alone leaves 0 of 180 frames, while the 3 kHz low-pass costs none.
It leans on the stock analysis to say the I2S stream most likely carries the microphone, and makes the carrier-keyed test the first step, with the M17 tap as the fallback. It finds the ±10% decode gate against a ±1% timing clamp. On CPU it doesn’t clear anything: it estimates about 4 million filter multiply-adds per second, says the real budget is unmeasured, and notes that an overrun resets the stream, so a CPU shortfall would look like poor RF sensitivity. That last point is exactly right.
If CPU is tight, it says: raise the clock toward 168 MHz, shrink the filter, and “only then touch the decoder”. Emulated instruction counts put the filter, timing search and level fit at 39–58% of the 72 MHz CPU, and mbelib’s IMBE synthesis at 11–16 times the whole CPU. 168 MHz buys 2.3×, and trimming the filter saves less than one CPU. The decoder, with its unwrapped harmonic phase driving newlib’s slow cosf path, is the part that has to change first.
MUSESPARK13_REVIEW.md P1-5 · mbelib.c:306 · model: Unicorn emulation of the firmware’s own build
Major gap
It trusts instruments that don’t work
Its first step is the capture acceptance procedure, but the capture stages the first 80 interleaved halfwords rather than the decoder’s samples (158 of 160 positions differ), and the parser certifies streams missing their first or last chunk. It expects pcm_starve to reveal audio underruns; that counter is never incremented. And it calls fail-closed muting an asset, though one failed signalling decode mutes a clear call for up to 9 frames.
It rejects the HR-C6000’s one-layer BER-test mode because the frames are DMR-structured and “the samples never reach the MCU as a continuous symbol stream”. The DMR framing is a real risk. But the manual documents continuous one-layer reception, and 36 bytes every 30 ms is exactly 4,800 symbols per second. Whether the mode needs DMR sync is untested, and it is the cheapest experiment on the chip.
It cites the manual’s I2S and LRCK divider formulas but not the sentence beside them: the I2S frame clock “must be 8KHz”, against the monitor’s 24 kHz. It also says C4FM needs a flat response to about 6 kHz with “no 3 kHz brick wall”, though C4FM sits below 2.88 kHz. And it lists trellis and CRC among the codes “cross-checked against independent reference encoders”; the trellis test re-implements the production table.
The audits track 4 issues that stop this radio decoding P25. This review: CPU flagged, not found; misses the 8 kHz rule. How the review treated each, from the provenance table: