Enhancements to clock synthesis - use continued fraction algorithm for selecting Si5351 multisynth register values

[fventuri]

As discussed here #125 (comment) there are a few improvements that could be made to the Si5351 clock synthesis for the RX-888.

One of them is replacing the current algorithm use to select the multisynth settings with a best rational approximation algorithm (based on continued fraction) that can find the optimal a + b/c values for the Si5351 multisynth.

This approach has a couple of advantages:

• it can synthesize most commonly used frequencies exactly
• it achieves the best approximation (i.e. the closest value) that is synthesizable by the Si5351 multisynth in the other cases

Before writing any new code, we need to think about this issue: the best rational approximation algorithm allows for arbitrary frequencies, even frequencies that have a fractional value of Hz. This can be useful for accurate adjustments of the reference clock, using ppm (or ppb).

Unfortunately the STARTADC command accepts an integer (uint32_t) value, that can't be used to represent floating point values.
In order not to break existing applications the STARTADC command should probably be kept the way it is now, and a new command, called say STARTADCFP should be implemented; this new command would expect a double precision (float64_t) frequency value, and can be used to select an arbitrary frequency (possibly non integer).
The old STARTADC command could then be changed to just convert its integer argument to double precision and pass it to the function that implements STARTADCFP.

As suggested by David in the other thread, the tests that need to be implemented should follow these guidelines:

the tests needs to be updated with a small set of additions to fx3_cmd and fw_test. No control features go in without tests that also get added into, typically, fw_test, fx3_cmd. A simple test for this would be going through a set of random frequencies and running it for X seconds and generally getting the number of samples you expected - there is an existing STREAMING TEST as well as ADC setting tests, though they need to be extended to determine if the code always comes up with a solution.

The FX3 code implementing the best rational approximation algorithm for the Si5351 multisynth can be found here: https://github.com/fventuri/DFC-transceiver/blob/main/fx3-firmware/si5351.c

Franco

[ringof]

Review of current clock synthesis and a proposed path to resolve

I audited the current implementation against this request. Findings and a concrete plan below.

Current state (what we have today)

In SDDC_FX3/driver/Si5351.c:

• si5351aSetFrequencyA(UINT32 freq) (line ~189) and its CLK2 twin si5351aSetFrequencyB(UINT32 freq2) (line ~265) both take a UINT32 (integer Hz) argument.
• The algorithm picks an even integer feedback divider targeting a 900 MHz PLL, then sets the PLL multiplier as mult + num/denom with denom hard-coded to 1048575 and num computed by truncating division (lines ~227–231).
• The multisynth output divider is integer-only: SetupMultisynth() forces P2 = 0, P3 = 1 (lines ~119–121). So the Si5351's fractional output stage is currently unused, and the only fractional resolution comes from the fixed-denom PLL term.

Net effect: many target frequencies land on the nearest synthesizable value with avoidable error, and there is no path to express sub-Hz / ppb reference adjustments. That matches the motivation in the issue.

STARTADC = 0xB2 is defined in SDDC_FX3/protocol.h (line 22) and handled in SDDC_FX3/USBHandler.c (~line 206), where it reads a 4-byte little-endian frequency via memcpy(&freq, glEp0Buffer, 4) and calls si5351aSetFrequencyA(freq). Host side: tests/fx3_cmd.c sends it via cmd_u32/ctrl_write_u32 (4-byte LE), and docs/api.md documents it as a 4-byte command.

Proposed plan

1. Add a best-rational-approximation core (continued fraction).
Port the approach from the referenced fventuri/DFC-transceiver si5351.c: a helper that, given a target ratio, returns the optimal a + b/c with b,c <= 2^20 - 1 (1048575) honoring the Si5351 constraints (PLL VCO 600–900 MHz, multisynth divider bounds, even-integer requirement where applicable, R-divider for sub-1 MHz). This should drive both the PLL and the multisynth fractional terms, which requires generalizing SetupMultisynth() to accept num/denom instead of forcing integer-only.

2. Make the core take double, keep the integer path as a thin wrapper.

• Introduce si5351aSetFrequencyFP(double freq) (and a CLK2 equivalent) holding the new algorithm.
• Reduce si5351aSetFrequencyA(UINT32 freq) to return si5351aSetFrequencyFP((double)freq); so existing behavior/callers are preserved with improved accuracy.

3. Add a new STARTADCFP vendor command.

• Pick an unused opcode (e.g. 0xB4 or 0xB5, currently free per protocol.h).
• Payload: 8-byte IEEE-754 little-endian double. FX3 is little-endian ARM, so memcpy(&d, glEp0Buffer, 8) is fine, but we should document the wire format explicitly and bump wLength handling to 8.
• Update the debug name tables (FX3CommandName, FX3_CMD_COUNT in protocol.h/DebugConsole.c) accordingly.
• Keep STARTADC (0xB2) unchanged for backward compatibility, as the issue requests.

4. Host tooling + docs.

• Add ctrl_write_f64/cmd_f64 + a do_adc_fp() wrapper in tests/fx3_cmd.c.
• Document STARTADCFP in docs/api.md (8-byte LE double) and note the accuracy improvement to STARTADC.

5. Tests (gating requirement per the thread).

• Extend the ADC-setting tests in tests/fw_test.sh and tests/fx3_cmd.c to sweep a set of random frequencies (integer via STARTADC and fractional via STARTADCFP) and assert that the algorithm always returns a solution within the supported range (~2 MHz–129.6 MHz) and that PLL lock is achieved.
• Extend the streaming test to run for X seconds at several of those frequencies and confirm the expected sample count.
• Add a unit-level check (host-buildable) of the rational-approximation function against known-exact frequencies and known worst-case approximations, so the math is validated without hardware.

Open questions before coding

1. Opcode choice for STARTADCFP (proposing 0xB4) — any preference?
2. Failure semantics when a requested frequency is out of range or unsynthesizable — clamp, nearest, or return an error status to the host?
3. Should si5351aSetFrequencyB (CLK2) get the same treatment now, or stay integer for this change?
4. Confirm the supported frequency window to validate against (docs mention ~2 MHz–129.6 MHz).

---

Generated by Claude Code

[ringof]

Picking up the two points you raised, after re-reading docs/api.md, docs/vendor-protocol-plan.md, and docs/ka9q-compat-audit.md. They mostly reinforce your instincts, but they also correct one thing I said earlier and reshape the "new command" mechanics.

1. "Old commands should quietly work better" — agreed, unconditionally

This is the right call and it's also already the documented design intent. docs/vendor-protocol-plan.md Principle 1 classifies STARTADC as configuration whose goal is "unchanged on the wire; clearer in docs." Improving the math behind STARTADC doesn't touch the wire format at all — the 4-byte LE integer Hz argument stays exactly as documented in api.md. Existing hosts (ExtIO, rx888_stream, ka9q) get sub-Hz accuracy for free with zero coordination.

Concretely: si5351aSetFrequencyA(UINT32) becomes a thin wrapper that casts to double and calls the new continued-fraction core. The PR (#134) already proves the win quantitatively — at the common rates the new algorithm is exact where the current integer path is off by up to ~2.86 Hz (100 MHz). So: no reason to gate the improvement behind a new opcode. The old command just gets better.

2. Separating "set the clock" from "start" — the direction is already in the docs, but the mechanic needs adjusting

Your instinct matches vendor-protocol-plan.md Principle 1 almost verbatim:

"STARTADC reads as a state transition ('start the ADC') but is actually Si5351 configuration. STARTFX3 is the real state transition."

So the separation you want largely already exists in the firmware — it's just badly named. Two consequences worth surfacing before we design anything:

• There is no separate "enable the ADC" step to expose. The LTC2208 free-runs off the Si5351 clock; capture begins at STARTFX3, and (since Commit 1, v0.1.0) STARTFX3's preflight reads CLK0/PLL state directly from the chip. So a "no-arg STARTADC that starts the ADC" would either duplicate STARTFX3 or just be a rename — it wouldn't correspond to a distinct hardware action. I'd avoid adding it.
• 0xB4/0xB5 are taken. I floated those for STARTADCFP earlier — please disregard that. Per ka9q-compat-audit.md §matrix and the Commit 4 deprecation list, 0xB4 = TUNERINIT and 0xB5 = TUNERTUNE are deprecated-but-reserved (they STALL, and ka9q's enum still defines them). Reusing them would collide with that contract.

The clean, docs-aligned shape is therefore a typed clock setter in the reserved range. vendor-protocol-plan.md already carves out 0xD0–0xDF for typed configuration setters and literally names SET_SAMPRATE as the example. That's exactly this. Proposed:

Opcode	Name	Payload	Role
0xD0 (range-aligned)	SETCLOCK / SET_SAMPRATE	8-byte IEEE-754 LE double Hz	Configuration — well-named, sub-Hz/ppb-capable clock setter (the FP frequency the continued-fraction algorithm needs)
0xB2	STARTADC (unchanged)	4-byte LE uint32 Hz	kept forever for compat; now delegates to the same FP core
0xAA	STARTFX3 (unchanged)	—	remains the actual start

This gives you the whole thing: configuration (SETCLOCK) cleanly separated from control (STARTFX3), the quiet upgrade to STARTADC, and no redundant command — all without a wire break.

On "REPLACE the direct Si5351 fiddling ka9q does"

We can't unilaterally replace it — that's ka9q's rx888_set_samprate() programming the Si5351 over raw I2CWFX3, and it intentionally bypasses firmware clock logic (ka9q-compat-audit.md §8). What we can do is make SETCLOCK good enough (the same continued-fraction math, sub-Hz) that poking registers host-side offers no accuracy advantage, advertise it in GETCAPABILITIES (the commands feature-detection list from Commit 3) so a host can detect and prefer it, and document it as the recommended path. Then ka9q/librx888 can choose to drop their host-side Si5351 math — but that's an upstream decision. The project's documented stance (ka9q-compat-audit.md §1–§2, "minimize upstream asks") and the recoverability invariant mean I2CWFX3 direct programming must keep working regardless. So SETCLOCK is additive, not a replacement we impose.

Open decisions for discussion

1. Opcode: take 0xD0 from the reserved typed-setter range (my recommendation), or a one-off byte from 0xB7–0xB9/0xBD–0xCD? The plan says pull one-offs from the latter and reserve 0xD0–0xDF for exactly this kind of setter — which is why I lean 0xD0.
2. Name: SETCLOCK vs SET_SAMPRATE. The plan's example is SET_SAMPRATE, but "clock" is more honest since it sets the Si5351 output, not strictly the sample rate after any divider. Slight preference for SETCLOCK.
3. Out-of-range / unsynthesizable: clamp to nearest, or STALL with a clear failure? The recoverability invariant (Principle 2) wants a clean STALL over silent wrong behavior; I lean STALL + leave state untouched.
4. CLK2 (si5351aSetFrequencyB): refactor onto the same core now, or leave integer for this pass?
5. Should SETCLOCK land before or alongside GETCAPABILITIES (Commit 3)? It really wants to be in the commands list to be feature-detectable; otherwise hosts can only probe-and-watch-for-STALL.

If this shape looks right, I'll fold it into a PLAN.md (per CLAUDE.md) with the per-file changes and the test additions, and the host-side math validation in #134 becomes the regression oracle for the firmware port.

---

Generated by Claude Code

[ringof]

Empirical results from the host-side math harness (PR #134)

Before touching firmware, I built a standalone, hardware-free test harness (tests/si5351_math_test.c, in PR #134) that ports the continued-fraction rational_approximation() from the fventuri/DFC-transceiver reference, packs the result into the real Si5351 P1/P2/P3 register fields and decodes them back (so register packing is exercised, not just the math), and reconstructs the synthesized frequency. It runs the current integer algorithm from SDDC_FX3/driver/Si5351.c side-by-side for comparison. Reference = 27 MHz. Here's what it produced:

Common ADC rates

The new algorithm hits 0 Hz error on every one; the current integer algorithm is off by up to ~2.86 Hz:

Rate	new error	current error
16 MHz	0.000 Hz	−0.255 Hz
32 MHz	0.000 Hz	−0.511 Hz
64 MHz	0.000 Hz	−1.022 Hz
100 MHz	0.000 Hz	−2.861 Hz
128 MHz	0.000 Hz	−1.431 Hz

Exactly-synthesizable rates

Constructed as ref·N/ms (integer feedback, even output divider): the new algorithm is exact to 1e-9 Hz.

Fractional / ppb targets

Things the integer STARTADC command literally cannot express:

• 64000000.5 Hz → resolved to 1e-6 Hz
• 64000000.064 Hz (a 1 ppb offset) → resolved to ~4 mHz

This is the concrete case for the FP clock-setter discussed above — sub-Hz / ppb reference adjustment.

Random sweep — 20,000 frequencies across 2–129.6 MHz (fixed seed, deterministic)

Algorithm	Solved	mean |err|	worst |err|
new	20000/20000	0.00002 ppm	0.212 ppm
current	—	0.019 ppm	0.237 ppm

The "solved 20000/20000" is the "always comes up with a solution" guarantee David asked for in the thread — every frequency in the supported window produced a valid register set within the Si5351 constraints, and the new algorithm beats the current one on both mean and worst-case error.

Reproduce

make -C tests check-math      # expect: 1..31, "# 31/31 passed", exit 0

The harness doubles as the regression oracle for the firmware port (it already validates the exact P1/P2/P3 packing the firmware will emit).

---

Generated by Claude Code

[fventuri]

Wow, you're fast David!

I don't really have any strong (or even weak) opinions on the name and the opcode for this new command.

And I completely forgot about the second clock used for the VHF tuner LO.
If I remember correctly the Si5351 register values for the two synthesizers are nearly identical, except that they are written to different registers, so I would avoid a duplication of 99% of the code, and instead add an additional argument to the function (that can be 0 or 1) to configure and start the first or second synthesizer.

Regarding values out of range, I agree that STALL with a clear failure would be preferable.

Another useful feature would be to have a user readable register (similar to the ones you already have for the counts) that contains the error between the selected frequency and the actual synthesized frequency, so the user could read it and know if the frequency was synthesized exactly or off by a few mHz, and if so, by how much it is off.

It's getting late here, so I'll check your progress tomorrow morning.

Franco

[ringof]

Monte-Carlo error characterization (10 kHz – 135 MHz) + algorithm-vs-hardware capability

Following up on the request to characterize the error distribution across the band and to separate algorithm quality from hardware capability. New harness tests/si5351_mc.c (committed on the #134 branch; plots via make -C tests mc-plot). Reference = 27 MHz, the MS5351M crystal on the RX888mk2 (Si5351.c:32).

Error vs frequency

Red = current integer algorithm (clustered ~0.005–0.04 ppm across the whole band). Blue = new continued-fraction algorithm, Gray = brute-force hardware optimum — both pinned at the plot floor (≤1e-6 ppm). Blue sits directly on top of gray.

Error distribution (CDF, 60,000 random frequencies)

	mean |err|	median	p99	worst
new	~0 ppm	0	0	0.000142 ppm
current	0.0156 ppm	0.0155	0.0332	0.0381 ppm

46% of random frequencies (27,439 / 60,000) synthesize with literally zero error under the new algorithm (vs 3 for current). In the CDF, new is the near-vertical blue line jammed against the left edge; current's mass sits at 0.01–0.04 ppm.

Algorithm vs. hardware capability — the important part

To answer "how well can the algorithm do vs. what the chip is even capable of," the harness includes a brute-force oracle that exhaustively searches every feedback denominator c ∈ [1, 2²⁰−1] and reports the smallest achievable error — the hardware floor.

• Across all 1,500 swept frequencies, the continued-fraction result is bit-identical to the brute-force optimum (gap = 0). So for generic frequencies the algorithm is optimal; the residual error you see is the MS5351M's fractional-N resolution limit, not the algorithm's.
• What sets the hardware floor: the 20-bit feedback denominator (c ≤ 1,048,575) together with the 27 MHz reference. Realizable grid spacing ≈ reference / (output_ms · c), i.e. sub-Hz everywhere in band — which is exactly what makes ppb-level reference correction (the FP command's purpose) physically meaningful.
• One place the algorithm underperforms the hardware: the reference routine's epsilon = 1e-5 early-exit. For targets whose feedback ratio lands just above an integer, it bails early and leaves up to ~0.4 ppm on the table where the chip could hit 0 (worst case found: 112.500045 MHz → new 0.398 ppm vs optimum 0.000 ppm). This is a tunable software limit, not a hardware one — tightening epsilon (e.g. 1e-9) or dropping the early-out closes it. I'd fold that into the firmware port and add a regression test pinning the near-integer-feedback band.

MS5351M datasheet bounds to confirm before finalizing

Everything above assumes Si5351-spec limits; the MS5351M is register-compatible but worth verifying its datasheet for: VCO range (Si5351 = 600–900 MHz; we target 900 max), integer feedback 15–90, 20-bit num/denom, and even output divider 4–900 (Si5351 allows up to 1800). The VCO minimum and the denominator width are the two numbers that bound the whole result.

Reproduce

make -C tests mc-plot     # builds si5351_mc, runs it, emits scatter + CDF PNGs

---

Generated by Claude Code

[ringof]

Reframing: precision reference + AN619 spectral purity

Two corrections/elevations to my earlier "the crystal washes it out" note, both of which strengthen the case for this work.

1. The milliHertz use case presumes a precision reference — and that flips the binding constraint

My earlier caveat (stock 27 MHz crystal error ≈ tens of ppm dwarfs the ~0.04 ppm algorithm quantization) only applies to the stock-crystal case. Anyone adjusting at milliHertz/ppb is not running the stock crystal — they're feeding a TCXO or, more typically, a GPSDO such as the Leo Bodnar LBE-1420 (GPS-disciplined; when locked, frequency accuracy on the order of ~1×10⁻¹¹, i.e. ~1×10⁻⁵ ppm — treat as approximate pending the datasheet, which I couldn't fetch from here).

With a reference like that, the error budget inverts:

Reference	Reference error	Binding limit on output placement
Stock 27 MHz crystal	~tens of ppm	the crystal (algorithm is invisible)
TCXO	~0.1–1 ppm	mixed
GPSDO (LBE-1420)	~1×10⁻⁵ ppm	the chip's fractional-N resolution + the synthesis algorithm

So in exactly the regime where someone cares about mHz, the reference is no longer the floor — the algorithm and the 20-bit-denominator hardware grid become the binding constraint. That is precisely where the continued-fraction algorithm (and the FP command needed to express a non-integer Hz target) earns its keep, and where the current integer command's ~0.04 ppm quantization and its inability to take fractional Hz become the actual limitation. This is the case Franco flagged in the opener ("accurate adjustments of the reference clock, using ppm or ppb"). The feature is justified by correctability under a precision reference, not by raw accuracy under the stock crystal.

2. AN619 spectral-purity compliance is a first-class requirement, not a footnote

RX888 users care a great deal about ADC-clock spectral purity (clock spurs/jitter set the achievable SDR dynamic range), so the implementation must demonstrably follow AN619's low-jitter/low-spur recommendations — and these become acceptance criteria, not incidental behavior:

• Output MultiSynth stays integer and even, with all fractionality pushed into the PLL feedback. AN619's lowest-jitter configuration. The current firmware already does this (SetupMultisynth() forces P2=0, P3=1) and the continued-fraction change operates only inside the PLL feedback term — so there is no spectral regression. Must be preserved and asserted in tests.
• Output integer-mode bit (MS0_INT) is set. The current CLK0_CONTROL = 0x4F has bit 6 = 1, i.e. integer mode on the output MultiSynth — already AN619-correct. Preserve.
• VCO kept high (~900 MHz). Higher VCO divides down output phase noise; the algorithm targets 900 MHz max. Preserve.
• DIVBY4 special case (output divider = 4, per AN619): the reference algorithm handles it (output_ms == 4 ? 0xc : 0x0); the current firmware does not (SetupMultisynth just computes P1 = 128*divider - 512). It's unreachable at our ≤135 MHz ceiling (output_ms ≥ 6), but the port should carry it for correctness/range headroom.
• New spectral opportunity the algorithm unlocks: when the best rational approximation is an integer feedback (b == 0) — ~46% of frequencies in the sweep — the PLL can be put in integer mode (FBA_INT) for the lowest spurs. The current code always writes denom = 1048575 and so can never use integer-PLL mode even when the target is exactly an integer ratio. The new algorithm makes integer-PLL operation detectable and selectable. (Exact register/bit for FBA_INT to be confirmed against AN619 §register map during implementation — I don't want to assert it from memory.)

Implications for the port / tests

1. Justify the feature in docs as ppb correctability under a precision reference + clean API, explicitly not as a stock-crystal accuracy gain.
2. Add explicit test/inspection assertions that the emitted registers keep the integer even output MultiSynth + MS0_INT + high VCO invariants (AN619 compliance is regression-tested, not assumed).
3. Evaluate setting FBA_INT when b == 0 to take the integer-PLL spectral win on the ~46% of exactly-synthesizable rates.
4. Carry the DIVBY4 handling from the reference.

Net: the change is spectrally neutral-to-positive (never worse, potentially better via integer-PLL mode), and the resolution gain is meaningful exactly for the precision-reference users who need it.

---

Generated by Claude Code

[ringof]

Algorithmic comparison with ka9q-radio's src/si5351.c solver

I compared ka9q-radio's current src/si5351.c solver against the simpler reference algorithm, and extended the #134 harness to measure them head-to-head. Same fundamental method — continued-fraction best rational approximation of the PLL feedback ratio, denominator ≤ 1,048,575, identical P1/P2/P3 packing, integer output MultiSynth with the fractional part in the PLL feedback, VCO 600–900 MHz. ka9q's is a more refined formulation, and the differences map onto exactly the open items in this thread.

Where ka9q's solver is more sophisticated

1. Exact integer/rational arithmetic with semiconvergents — no floating point in the approximation. This is the textbook-optimal best-rational-approximation under a denominator bound.
2. Spur-aware candidate scoring — it scores by (absolute error, then a spectral preference rank) that favors integer MultiSynth and small denominators. This bakes the AN619 spectral-purity bias into the selection.
3. Integer-mode packing when the feedback is integer (b == 0).
4. Full search over R dividers (1..128), output divider D (integer {4,6,8} first, then fractional 8..2048), and several VCO targets, with legality checks.

Head-to-head measurements (extended harness, 27 MHz reference, 10 kHz–135 MHz)

Accuracy distribution (60,000 random integer rates): the exact-rational and float-CF methods are indistinguishable for typical frequencies — both ~0 ppm mean/median, worst ≈ 0.000142 ppm — and both massively beat the current integer algorithm (~0.016 ppm mean).

The epsilon corner (where exactness actually matters): I drove the fractional part of the feedback ratio from 1e-8 to 1e-2 and compared each method to the exhaustive optimum:

	worst gap vs hardware optimum
float continued-fraction (epsilon = 1e-5 early-out)	~0.29 ppm
exact integer/rational + semiconvergent	0.000 ppm

In the band where the feedback fractional part is ~1e-6…1e-5, an exact fraction exists (denominator ≤ the 2²⁰−1 limit), so the exact method nails it — but the float routine's epsilon = 1e-5 early-out bails before finding it and leaves up to ~0.3 ppm on the table. This is the one place the exact formulation is materially better, and it's the corner I flagged earlier from the float reference. Eliminating it just requires the exact integer/rational + semiconvergent formulation (or a much smaller epsilon).

Spur preference — a tempering result. I also measured the chosen feedback denominator c for a single-divider selection vs. a spur-aware divider search:

• Integer-PLL (b == 0) is ~0% for arbitrary rates with the 27 MHz reference and our divider range — exact integer feedback ratios essentially never occur for random frequencies.
• Spur-aware divider search trims the median denominator only modestly (~500,000 → ~450,000; p90 ~967k → ~935k).
• The dominant spectral lever — integer, even output MultiSynth — is already used by every variant here regardless.

So for arbitrary frequencies the spur-aware search buys little; its value concentrates on "nice" rates where a low-denominator or integer-feedback solution exists at some divider. The big spectral-purity guarantee comes from the output-divider topology (already in place), not from the feedback-approximation cleverness.

Algorithmic takeaway

• For accuracy, both methods reach the hardware optimum except in the epsilon corner; the meaningful differentiator is exactness (integer/rational + semiconvergents) eliminating that corner.
• For spectral purity, the integer even output divider is what matters and is already standard; spur-aware feedback-denominator minimization is a minor refinement for arbitrary rates given a fixed reference.
• Net: an exact integer/rational formulation is the part worth adopting; the elaborate multi-divider spur search yields diminishing returns for the RX888's typical rate set on a 27 MHz reference.

Plots (epsilon probe + denominator distribution) are produced by make -C tests mc-plot in the harness.

---

Generated by Claude Code

[ringof]

Figures for the head-to-head measurements above.

Feedback approximation error vs. the fractional part of the feedback ratio — float continued-fraction (epsilon = 1e-5) vs. exact integer/rational vs. hardware optimum. Below ~1e-6 no exact fraction exists and all three track together; in the 1e-6…1e-5 band the exact solver drops to zero while the float routine leaves up to ~0.3 ppm.

Chosen feedback denominator c distribution (60,000 random frequencies) — single divider vs. spur-aware divider search. The spur-aware search shifts the distribution only modestly toward smaller denominators; large denominators dominate either way for arbitrary rates.

Both reproducible via make -C tests mc-plot.

---

Generated by Claude Code