[time-nuts] Digital temperature compensation

[Dan Drown]

I think you have a good point - any model is going to have a larger  
error than the data itself.  I'll be looking into this.

Quoting Chris Albertson <albertson.chris at gmail.com>:

> 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:
>
>> Hi
>>
>> > 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 ….
>>
>> Bob
>>
>> > 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
>> function:
>> >>>
>> >>> f(x) = -abs(a * (x - 20.88)) + b * ((x - 20.88)**2) + c * ((x -
>> 20.88)**3)
>> >>> 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.
>> >>>
>> <temp-clock-warmer.png><temp-clock.png>_______________________________________________
>> >>> time-nuts mailing list -- time-nuts at febo.com
>> >>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> >>> and follow the instructions there.
>> >>
>> >> _______________________________________________
>> >> time-nuts mailing list -- time-nuts at febo.com
>> >> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> >> and follow the instructions there.
>> >>
>> >
>> > <temp-vs-clock.png>_______________________________________________
>> > time-nuts mailing list -- time-nuts at febo.com
>> > To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> > and follow the instructions there.
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>
>
>
> --
>
> Chris Albertson
> Redondo Beach, California
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>