Suggested new system variable, xo_nominal_frequency

[ms-jdow]

I have noticed conflicts between programs which use "xo_correction" to mitigate the crystal oscillator errors and programs which do it themselves in their DSP software. SDR Console is an example of the latter; and sdrangel is an example of the former.

I also note that sdrangel, and perhaps others, presume that the oscillator will always be 40 MHz. This may not always be ideal. There is at least one GPSDO which includes a synthesizer on its output. It can be used as 40MHz and say 25 MHz references if desired. This is useful when using existing LNBs to access 10.0 to 10.5 GHz. However, I also have instruments which require a 10 MHz reference. Since it appears Pluto works nicely with a 10 MHz reference it would be nice to change it appropriately.

However, some may wish to use a frequency that makes LNB's work nicely with Pluto and be done with it. That frequency may not be a nice even frequency. And it would be hard for a program that sees an xo_correction value of 23.7533356 MHz to figure out that the intended frequency of an external crystal oscillator rather than GPSDO was nominally 23.753333MHz.

Finally I note that one correspondent has suggested a circuit for automatically switching between the onboard clock and a GPSDO input. These may not both be 40 MHz, either.

Putting this all together I am suggesting creating an xo_nominal_frequency system variable to store the nominal clock frequency and possibly make xo_correction be an ephemeral value. Then programs can pick up what is the intended clock frequency and store corrections as parts per million so they can do the right thing.

{^_^} Joanne DOw

[rgetz]

Hi.

xo_correction is not a function of the PLUTO, but a function of the AD9363 in kernel Linux driver. https://wiki.analog.com/resources/tools-software/linux-drivers/iio-transceiver/ad9361#xo_correction

Since the kernel uses all integer math, it's better to represent things in Hz values, since it allows sub 1 ppm offset management (1Hz in 40MHz is 0.025 ppm), and it's all integer - floating point is not allowed.

Nominal value of the reference clock is managed in the device tree - it's not mean to be a run time parameter, so putting a switch there will cause things to fail at lots of levels until the driver is re-written to support that...

If people are not using the driver correctly - they should fix things. :)

[mhennerich]

XO correction only works in a small window. The range a correction can be applied is set by the clock-accuracy property. By default for pluto this is 200ppm. https://github.com/analogdevicesinc/linux/blob/master/arch/arm/boot/dts/zynq-pluto-sdr.dtsi#L26

If you need a different reference clock you need to change the clock-frequency attribute. Like Robin said this requires a changing the device tree.

-Michael

[ms-jdow]

Nonetheless a nominal frequency value should be developed so that various programs do not argue with each other over calibration settings. {^_^}

[mhennerich]

The nominal frequency is the center of:

cat xo_correction_available

[39992000 1 40008000]

cat name

ad9361-phy

Syntax of the available range attribute is [min step max].

-Michael

[ms-jdow]

OK, thank you for the better understanding. {^_^}