[time-nuts] Digital temperature compensation
albertson.chris at gmail.com
Sat Nov 1 19:16:19 EDT 2014
If this is just for holdover then I don't think you even want a general
solution. Have the controller always keep the last few days of data for
temperature vs. EFC value. Then if GPS fails use the most recent data for
the current temperature. This makes for a self adapting system accounting
for aging too. Not just crystal aging but the aging of the resisters, the
temperature sensor itself and other components.
I don't think holdover should fall back onto a model that was created from
data that might be months or years old. Use hours or days old data.
This will give the desired response which is this: If the temperature is
constant when the GPS fails the EFC value as determined by your holdover
temperature modeling should give you the EXACT same EFC value as just
before the GPS failure. I don't think you can do that with a model. You'd
nee to use logged data.
On Sat, Nov 1, 2014 at 4:01 PM, Bob Camp <kb8tq at n1k.org> wrote:
> > On Nov 1, 2014, at 5:09 PM, Dan Drown <dan-timenuts at drown.org> wrote:
> > Ok, I hadn't considered rate of change.
> It’s one of the limits on this sort of thing in general. It’s even more of
> an issue with a coupled mode like the one you show. Since there are an
> enormous number of possible variables, it’s always tough to know exactly
> how much of an issue you will have.
> One common answer - run your profile runs at the temperature change rate
> you are most likely to see in practice.
> Another very common answer - don’t use that crystal, get one that does not
> have the problem. You can get parts with slopes <0.1 ppm / C over 10 to
> 50 C. You might have to spend some quality time sorting them out ….
> > This data is currently 3 day's worth and seems to repeat itself on both
> days at the same temperature point. Attached is a time based graph to show
> that. The ppm axis (on the right) is inverted to make it easier to see the
> relationship between the two.
> > Quoting Bob Camp <kb8tq at n1k.org>:
> >> Hi
> >> This sort of thing is normally done with a precisely controlled
> temperature chamber and multi day temperature ramp runs. Even then there is
> a bit of “wonder what that was, let’s try it again”.
> >> If you are looking at a crystal oscillator, what you have is a
> perturbation in the frequency / temperature curve. The response you get
> will be temperature rate of change dependent.
> >> Bob
> >>> On Nov 1, 2014, at 4:40 PM, Dan Drown <dan-timenuts at drown.org> wrote:
> >>> I'm experimenting with using a temperature sensor to estimate local
> oscillator frequency changes. My goal is to have a decent holdover clock
> for a NTP server with not so great GPS antenna placement.
> >>> I've been sampling temperature every minute, measured by a DS18B20.
> I've been measuring local clock frequency differences, using chronyd's logs
> from the GPS's PPS. At 28C through 21C, I get a pretty good result that
> fits a quadratic polynomial decently (0.117 ppm stddev). I've attached the
> graph of that as "temp-clock-warmer.png".
> >>> With the colder temperatures, there's a sudden drop off in frequency
> that I'm having a hard time finding a equation that fits as nicely. All
> the examples I can find on the web look like third degree polynomials,
> while my data doesn't seem to fit that exactly. The best result I've had
> so far (0.198 ppm stddev) is attached as "temp-clock.png" and uses the
> >>> f(x) = -abs(a * (x - 20.88)) + b * ((x - 20.88)**2) + c * ((x -
> >>> a = 0.888582
> >>> b = 0.113806
> >>> c = -0.00445763
> >>> Does anyone have any advice on how to better model this? Has anyone
> seen this behavior?
> >>> I can provide the raw data if that would help any.
> >>> time-nuts mailing list -- time-nuts at febo.com
> >>> To unsubscribe, go to
> >>> and follow the instructions there.
> >> _______________________________________________
> >> time-nuts mailing list -- time-nuts at febo.com
> >> To unsubscribe, go to
> >> and follow the instructions there.
> > <temp-vs-clock.png>_______________________________________________
> > time-nuts mailing list -- time-nuts at febo.com
> > To unsubscribe, go to
> > and follow the instructions there.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> and follow the instructions there.
Redondo Beach, California
More information about the time-nuts