| Re: [chrony-dev] Frequency synchronization without phase |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
Quoting Dan Drown <dan-ntp@xxxxxxxxx>:
Another direction I'm considering is measuring the host's frequency
using PWM output on the host (~1PPS) and measuring that with the
microcontroller's timer. That should give me a more precise
measurement, and it isn't affected by interrupt latency.
I've gone through a few redesigns and now I have something that is
starting to look pretty good.
First redesign: I setup the Linux computer to output 50Hz PWM, and
hooked that to a timer channel on my microcontroller.
I then divided down the PWM to 1Hz in software to measure the length
of 1 second to compare the two
clocks - Linux system vs microcontroller's TCXO.
That looks like this (green=Linux system's clock, purple=TCXO's
measurement of Linux system's clock).
https://dan.drown.org/odroid/run7/tcxo-acc-1024.png
I've adjusted the starting offset to be within 50ppb, but the TCXO
drifts off and the difference widens to over 300ppb after 3 days.
Second redesign: I experimented with reducing the tempcomp factor by
50% so that the TCXO's drift has less of an impact, but it still does
some temperature correction.
That looks like this (blue=Linux system's clock, purple=TCXO tempcomp
reduced by 50%, green=TCXO tempcomp reduced by 70%)
https://dan.drown.org/odroid/run8/tcxo-acc-1024.png
Again I adjusted the starting point to be within 50ppb, and after 7
days it's drifted 3ppm (50%) / 5ppm (70%).
Third redesign: To reduce the number of variables, I wanted to get the
frequency from the GPS into the stm32. I added another timing channel
on the stm32 and hooked it up to the same GPS PPS that chrony is using.
The GPS channel (frequency difference between TCXO and GPS, 64s average):
https://dan.drown.org/odroid/latest/chan2.png
The Linux system frequency is measured relative to the GPS channel.
This reduces the TCXO error to a very small amount.
Purple=stm32's measurement, Green=Linux system's measurement
https://dan.drown.org/odroid/latest/tcxo-acc-full.png
That's a little hard to see with them being so close together.
Here's how tempcomp.log vs tracking.log looks:
https://dan.drown.org/odroid/latest/tempcomp.png
The frequency reported in tracking.log is -20.464ppm to -20.466ppm.
Tempcomp is taking care of all (well, over 99%) of the frequency
changes. So if I find a better local frequency source, this should be
a good design.
For fun, I added a third timing channel with a RTC (DS3231 "+/-
2.5ppm") that outputs 1PPS. It has an internal temperature sensor to
adjust the capacitive load on the built-in crystal every 64s to stay
on frequency. You can see those jumps in this graph (frequency is
relative to the GPS PPS). I set its aging register to +0.2ppm before
starting the measurement.
https://dan.drown.org/odroid/latest/chan3.png
Lastly, an adev plot of the three channels. Channels 1&3 are relative
to the GPS (channel 2). The GPS is relative to the TCXO. The timer
hardware's resolution is 2e-8 (48MHz) at 1 second.
https://dan.drown.org/odroid/latest/adev-input-capture-channels.png
Code for both the microcontroller and Linux client is here -
https://github.com/ddrown/stm32-input-capture
For my next redesign, I'm going to try a better class TCXO. The
current one is branded as "2.5ppm", and I think I'll try a "200ppb"
Unrelated to tempcomp, I'm also trying out the new asymmetry code
because I'm on a recent git version. I assume the offset value in
statistics.log is corrected for asymmetry while the offset value in
measurements.log is not. I've added the two offsets to my graphs:
https://dan.drown.org/odroid/run9/remote-statistics.96.126.122.39.png
https://dan.drown.org/odroid/run9/remote-statistics.216.239.35.0.png
https://dan.drown.org/odroid/run9/remote-statistics.216.239.35.4.png
Those servers average an asymmetry value of -0.46. It seems to be an
improvement.
--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.