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.

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@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.

Ok, I hadn't considered rate of change. 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@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@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. >

Hi > On Nov 1, 2014, at 5:09 PM, Dan Drown <dan-timenuts@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@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@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.

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@n1k.org> wrote: > Hi > > > On Nov 1, 2014, at 5:09 PM, Dan Drown <dan-timenuts@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@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@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

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@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@n1k.org> wrote: > >> Hi >> >> > On Nov 1, 2014, at 5:09 PM, Dan Drown <dan-timenuts@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@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@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. >