Thanks to Jim Lux for a detailed explanation of one of the most complex
cases. It seems to me that most of these cases can be abstracted, without
loss of precision, into an integer plus a rational fraction (integer
divided by integer). If you allow "improper fractions", for which the
numerator is greater than the denominator, then this result can be
presented as a single rational fraction.

Some complex synth chains (like DSN) may require a sum of several rational
fractions. But you can always add two fractions by multiplying their
denominators. Some synth chains (like DSN again) may require multiplying an
intermediate rational fraction by another rational fraction, but again, the
arithmetic is straightforward. The actual numbers may grow large, but
64-bit math should be able to handle that.

So, an API return set that consists of a 64-bit integer numerator and a
64-bit integer denominator, forming a fraction to be multiplied by the
reference frequency, seems like a fairly generic API return which could be
standardized. The reference frequency might be available from another API
call, or not, depending on the system.

Can anyone think of a synthesis example which doesn't fit this model of a
sum of rational fractions?

As far as I can tell, this works because all synth hardware fundamentally
uses integer math, as well as mixers which produce sums and differences, so
that sums of rational fractions are the most complex result possible.

To give yet another example of the same general phenomenon, the API for the
AD9361 transceiver chip will set its synthesizer to the requested
frequency, within 1 or 2 Hz. Then it will back-calculate the actual
achieved frequency from the synth parameters, round that to the nearest
even 1 Hz, and report that as the achieved frequency.  If your desired
frequency includes a fraction of a Hz, this can be confusing and
misleading, and you can often get closer to your desired nominal frequency
by ignoring the API and setting the frequency "by hand".

If you ask it correctly, the API will report the integer and numerator (or
its components) of the fractional divisor. However, it takes a deep dive
into the chip spec sheet to discover that the denominator of that fraction
is 65533. No, not 65536, or even 65535. This makes it extremely difficult
to set the LO on an exact Hz frequency using a round-number reference like
10 MHz, even though the API reports back to the caller the nice exact
frequency (the actual frequency rounded to the nearest Hz).  This caused us
considerable frustration, once upon a time.

Cheers!
--Stu

Ooh. I'm not sure..

A typical simple PLL might have a rational fraction (N/R), where N is itself a something like B*P+A.  (that's the ADF4108, since I have the datasheet open).  And I think most dual modulus dividers can fit into that form.

A casual look at some SiLabs parts looks like they too are in that form - some algebraic combination of numbers as rational fractions.

There are a host of synthesized sources, though, that aren't single frequency - and this is where a simple API concept starts to break. For instance, an FSK radio will have two or more discrete frequencies. OK, API call to set "frequency #N" and API call to return "synth ratios for frequency #N"

And there are plenty of "chirped" sources, where one specifies a start and a ramp rate, or even with exponential frequency vs time (constant fractional rate of current frequency). I think those are sort of outliers.

When you look at modern waveform generators (like the Keysight 33600 series) it gets even weirder because their output signal is made up of chunks of either internally generated waveforms or playback of stored waveforms. 

But, yeah, in the case of a single fixed frequency, one could probably return a canonical "rational fraction times reference frequency".

I think though, that use cases like "what's the current transmit frequency" are tough when the transmit frequency depends on the instantaneous (or historical) receive frequency, as in a coherent transponder.  On X-band, in theory, the Ftransmit is 880/749 * Freceive.   So while I could return some ratios (like 880/749), I'm not sure I could break it out into all the components (offset registers, etc.) in a "generalized" way.

So for any given synthesizer architecture, one could define an API for that synthesizer that works.  But it's the "generic" return that's challenging. 

I will confess, I can't think of any synthesizers that use irrational numbers somehow.   I have seen some interesting designs based on linear feedback shift registers, but I think those are all still able to boil down to rational numbers.   A cordic synthesizer sort of backhandedly uses sin/cos and pi, but ultimately, the actual implementation is just multiplies and adds, and is going to generate something that is a rational fraction of the clock rate.

On Thu, 12 Dec 2024 11:33:11 -0500, Stewart Cobb via time-nuts time-nuts@lists.febo.com wrote:

Thanks to Jim Lux for a detailed explanation of one of the most complex
cases. It seems to me that most of these cases can be abstracted, without
loss of precision, into an integer plus a rational fraction (integer
divided by integer). If you allow "improper fractions", for which the
numerator is greater than the denominator, then this result can be
presented as a single rational fraction.

Some complex synth chains (like DSN) may require a sum of several rational
fractions. But you can always add two fractions by multiplying their
denominators. Some synth chains (like DSN again) may require multiplying an
intermediate rational fraction by another rational fraction, but again, the
arithmetic is straightforward. The actual numbers may grow large, but
64-bit math should be able to handle that.

So, an API return set that consists of a 64-bit integer numerator and a
64-bit integer denominator, forming a fraction to be multiplied by the
reference frequency, seems like a fairly generic API return which could be
standardized. The reference frequency might be available from another API
call, or not, depending on the system.

Can anyone think of a synthesis example which doesn't fit this model of a
sum of rational fractions?

As far as I can tell, this works because all synth hardware fundamentally
uses integer math, as well as mixers which produce sums and differences, so
that sums of rational fractions are the most complex result possible.

To give yet another example of the same general phenomenon, the API for the
AD9361 transceiver chip will set its synthesizer to the requested
frequency, within 1 or 2 Hz. Then it will back-calculate the actual
achieved frequency from the synth parameters, round that to the nearest
even 1 Hz, and report that as the achieved frequency. If your desired
frequency includes a fraction of a Hz, this can be confusing and
misleading, and you can often get closer to your desired nominal frequency
by ignoring the API and setting the frequency "by hand".

If you ask it correctly, the API will report the integer and numerator (or
its components) of the fractional divisor. However, it takes a deep dive
into the chip spec sheet to discover that the denominator of that fraction
is 65533. No, not 65536, or even 65535. This makes it extremely difficult
to set the LO on an exact Hz frequency using a round-number reference like
10 MHz, even though the API reports back to the caller the nice exact
frequency (the actual frequency rounded to the nearest Hz). This caused us
considerable frustration, once upon a time.

Cheers!
--Stu

time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com