NTP vs GPSDO

[sq6emm]

I was just wondering... tezuka_fw include ntp...
Can we somehow use NTP instead of external referency to "semi-lock" the reference freq of the board?:)

[F5OEO]

Wow...what nice idea..Completely forget that I already did that in rpitx project !

[F5OEO]

Seems that chrony does a good job. Should adjust automatically xo correction at 0.5ppm.

chronyc tracking

Reference ID : 52437EF2 (free.saclay.org)
Stratum : 2
Ref time (UTC) : Thu Feb 13 11:48:19 2025
System time : 0.000165481 seconds fast of NTP time
Last offset : +0.000024224 seconds
RMS offset : 0.000192790 seconds
Frequency : 0.888 ppm fast
Residual freq : +0.006 ppm
Skew : 0.413 ppm
Root delay : 0.010170583 seconds
Root dispersion : 0.001970754 seconds
Update interval : 260.4 seconds
Leap status : Normal

[sq6emm]

Just one thing I do not understand, the clock of the CPU (system) is the same as clock of ADC/DAC?

[F5OEO]

XTAL -> AD9363 -> Zynq
So ADC/DAC and CPU frequencies are related.

So if we can measure cpu frequency drift (by chrony) we can calculate ppm of cpu and thus ppm of xtal :
Script adj_chrony.sh with (should have a good ntp source, and be patient to have a godd precision)
High accurate ppm = 0.611 +/- 0.225 slow
Correct 39999976

Right niw, I can achieve 10Hz precision at 2.4Ghz, which is not bad for common usage. Hope that it could be replicate on other.

[sq6emm]

Great! Thanks for explanation, I would say precision is not the main issue, stability is.

[sq6emm]

Its working!.. At least adjustment. Will measure with GPSDO next days;)

[sq6emm]

Just a fast fun with maia and 1296.800 gpsdo locked CW signal...

For sure adjustment works... but... I am not sure if adjustment is correct... for me it seems like it moved wrong direction - but it might be connected with low horizontal resolution of maia...

[F5OEO]

You can maybe replace "fast" by "slow" to get the opposite

tezuka_fw/board/pluto/overlay_maia/root/adj_chrony.sh

Line 12 in 545adc9

if [ "$sign_correction" = "fast" ] ; then

[sq6emm]

I need to do something like ppm=ppm+16 to get close to the frequency.
Are there two different clocks? CPU and AD? Maybe we need to take into account some clock factor?

[Notupus]

I just read this after making a PR about this, the script assumes xo_correction takes the same sign as the ppm correction when it wants the absolute clock frequency according to https://ez.analog.com/linux-software-drivers/f/q-a/539037/ad9363-xo_correction-precision/399563.

Another consideration is configurable ntp servers that persist, to make it more accurate since I suppose the network topology isnt always optimized to France.

[F5OEO]

This is a work in progress test to know if it could work. If it is good enough, user could set the ntp server he wants. I also try to get usb gps to geta more reliable ntp server. I see also result with 15ppm. Need to investigate.

[Notupus]

It works and for me it's 2ppm slow and the accuracy is 120ppb. What I would think about is the update rate which goes higher with better accuracy to about 20mins per update which means it might drift in between due to temp depending on use so forcing an update rate of 10seconds or something like that that's less than a minute could help track single hz drifting .

[sq6emm]

This is change between slow (signal on the left) and fast (signal on the right).
While signal is 1296805000Hz (so even more left ~+16.28 ppm)

[sq6emm]

With +16.28 I get very close:

[sq6emm]

to be precise what I mean;)

[Notupus]

Gave it good ntp servers and got a 0.067 thats 67ppb

[sq6emm]

Do you guys have a reference signal that you can compare? Koz as said before it does not correct the frequency towards the reference. It is changing but not what is expected.

[Notupus]

PPS_GPS seems to be a different type input, maybe it expects sine wave pps not square thus the issues, maybe setting whatever it is to 2? https://github.com/Notupus/tezuka_fw/blob/4b1ba37903b364fa31bd7b1497cf9496c347dbb7/board/libre/patches/linux/04fbdbb433faae8ffb3a5b24b7435509b11334cb/0005-ad5660.patch#L74