[time-nuts] Tbolt temperature sensor
SAIDJACK at aol.com
SAIDJACK at aol.com
Thu Feb 5 05:06:43 UTC 2009
trying to send this message, but attachment is too big. John has to approve
the attached image:
> 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
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
> C change. This would mean the unit could only be adjusted by 2.5E-010
> 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
> 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