Quoting Dan Drown <dan-...@drown.org>:
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-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Reply via email to