/ gps

Beaglebone Black NTP/GPS Server, Temperature Compensation part 2

See the Part 1 of Temperature Compensation or the hardware setup

Overview

In part 1, I did a trial run of chrony's temperature compensation and got a pretty good result. In this part, I collected more data on how temperature affected my system's clock.

The data

Letting the system run for a few days and collecting the temperature and local clock frequency every 60 seconds, I get a pretty good relationship between the two using a quadratic forumla fit (0.117 ppm root mean squared error):

Frequency vs Temperature, above 21C

The problem is, that isn't all the data. That's only data above 21C. My system has a wierd kink in the data at 21C:

Frequency vs Temperature, all

I've found an equation that somewhat fits the data: f(x) = -abs(a * (x - 20.88)) + b * ((x - 20.88)**2) + c * ((x - 20.88)**3). But it isn't a very satisfying fit, as it looks like it'll add more errors as the temperatures go down even further.

All the information I can find online about the expected relationship between temperature and crystal oscillators show what looks like a three degree polynomial graph. This data doesn't fit that expectation very well.

Additional data

These are the latest graphs for this system. This graph is the system behavior over time.

Temp vs Clock freq

Two things to notice: First is the right-hand axis is flipped to make it easier to see the relationship. Second is the wierd spike up in frequency every time the temperature goes down cools below 21C and the spike down when it warms above 21C.

Next graph is the average, minimum and maximum frequency at each temperature measurement.

avg, min, max per temp

To go along with this, a graph showing the the difference between maximum and minimum frequencies at each temperature.

max-min per temp

Using the assumption that the best I'll be able to do for a holdover clock with this hardware is 1/2 the error from min to max frequency, that's a worst case of 700 ppb. That's 2.5ms/hr which is ok but not great.

Future plans

It's looking more like additional hardware will be needed for more accuracy. It looks like the hardware support is there for an external clock. The BBB's TCLKIN pin is available (which should be able to handle up to ~25mhz) and I've already put the PPS pin on Timer4's capture pin. Right now, it looks like the Linux kernel doesn't have support for the timer capture hardware in the PPS infrastructure or the ability to use TCLKIN, but the hardware support is there.