[time-nuts] Tbolt temperature sensor
Tom Van Baak
tvb at LeapSecond.com
Thu Feb 5 05:57:33 UTC 2009
Cool. Thanks for the plots.
I can see the oven current change (temp), as well as the
EFC changing to counteract it.
As far as I can tell the three GPSDO in the photo are GPS
locked. Is that correct? I mean, they stay within a couple
of 10 ns over the span of 70+ hours, so it's not likely in
In that case, how do you distinguish in the plots between
the GPS phase locking reaction to the OCXO starting to
go off-frequency and software temperature compensation?
How much of the correction in the plots is due to normal
phase locking against GPS and how much is due to your
temperature sensing and compensation?
The plots look like what any GPSDO would do. Temp goes
down; OCXO changes rate; GPS TIC detects divergence;
and DAC changes EFC to compensate for everything.
----- Original Message -----
From: SAIDJACK at aol.com
To: tvb at leapsecond.com ; time-nuts at febo.com
Sent: Wednesday, February 04, 2009 8:58 PM
Subject: Re: [time-nuts] Tbolt temperature sensor
> To make this work somewhat smoothly, one would need at least 0.001C or
> better 0.0001C resolution.
>Can you provide some real data, to help me believe this claim?
Please remember I talked about resolution, not accuracy. This type of resolution is easy to achieve with a 24 bit ADC and a thermistor; keeping in mind that 24 bits of resolution are 16 million steps. Again, this doesn't mean we will have accuracy nearing this type of resolution.
See attached image, these are three single-oven FireFly-II GPSDO's running in our garage, exposed to at least 20 degrees C of temperature change. You can see a significant amount of EFC change on all units (about 4mV pk to pk on each unit), and this is mostly done through the temperature compensation (red trace is EFC, blue trace is temperature/OCXO-current).
You can see this by the fact that the red EFC trace almost perfectly follows the blue temperature trace in inverse, and the units are well locked throughout the ordeal so compensation is working really well. If it wasn't, then the UTC phase would have to have a larger error on it to create this kind of EFC range.
When doing the math, this comes out to about 25 micro Degrees per ADC LSB. Again this is resolution, and I would not be surprised if the noise level of the temp sensor is 10x or 100x higher than this, but as you said we can do averaging on these numbers to get rid of noise. This also doesn't mean the thermistor can generate accuracy to this level, it may have higher hysterisis etc, but again the resolution comes for free with a 24 bit ADC.
>When you get below 1C or 0.1C resolution it starts to matter
>from which direction the temperature gradient is headed, or
>from which angle air is flowing. Or which side is up. Or what
>the humidity is, etc.
Yes, but we don't mind about that if the temperature sensor sits right on the crystal inside the OCXO well shielded and insulated from the outside world as it would be for most OCXO's.
>This, because temperature gradients break any steady state
>model you have based on a point source (e.g., temp sensor)
>or average temperature measurement (e.g., oven current).
>Then there is the matter of the rate at which temperature changes;
>slow temp changes and rapid temp changes affect an OCXO
>quite differently. This, due to different thermal time constants of
>all the metal and insulation materials in and around the OCXO
Absolutely. Fast changing transients are deadly for any OCXO. But if a GPSDO is hermetically sealed in an enclosure such as the Thunderbolt, then the unit will low-pass filter any thermal change. As long as the thermal change is slower than the heater's natural loop time constant then this should not be a problem since the heater can track the change. We are in trouble if the PID cannot follow the thermal gradient.
> To give you an example: a typical single-oven OCXO has about 1ppb per degree
> C change. This would mean the unit could only be adjusted by 2.5E-010 steps
> with the Dallas Temp sensor as a reference. So the average error would be
> 1.25E-010, which results in a massive 12.5 microseconds average drift error in
> 1000s intervals due to the temperature quantization error!
>Are you assuming a design where one takes a Dallas reading
>each second and stuffs it into the EFC every second? No one
>would actually do that.
My point exactly. But I think this is what Mike said about the Thunderbolt in his question. My point was that this is not done, and he should not be worried about the change to a lower resolution temp sensor affecting the signal quality from his Thunderbolt.
>Instead if one averages the temperature
>sensor over 10, 100 or more seconds you avoid large EFC steps.
>Everything else in a GPSDO is all about slow averaging; there's
>no reason temperature adaptation cannot be treated the same.
Respectfully I do not agree :) This will only work if the temp sensor jumps back and forth between two LSB's due to noise (PWM, dithering). If it only changes 0.25C every 10 minutes, then you would see a 2.5E-010 change in the frequency when this jump happens. It's just too coarse, even if it is low-pass filtered. A typical GPSDO has 5E-013 DAC LSB resolution, so reducing this to 2.5E-010 would be detrimental.
>I suppose I should add a random temperature cycle hold-over
>test to the abuse I inflict on each GPSDO here. Are you saying
>the Fury would do much better than others in this regard?
No, I am saying that other vendors also don't use I2C temp sensors for their temperature compensation because their resolution is not enough, and one could only measure temperature at one particular point on the PCB, not the crystal itself. I would think most GPSDO's use the same method as Fury.
>Again, given this is time-nuts, some real data would be nice.
See the attached image, it would be good to see how the competitors units' correlate OCXO EFC to temperature. I am sure they have very high resolution as well. I would think that the resolution would be at least as good as 1 to 5 EFC LSB steps per temperature sensor step to avoid quantization errors due to temp sensor resolution.
More information about the time-nuts