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.ch...@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 <kb...@n1k.org> wrote:
Hi
> On Nov 1, 2014, at 5:09 PM, Dan Drown <dan-timen...@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 <kb...@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-timen...@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@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@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@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@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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
