[time-nuts] Tbolt temperature sensor

[SAIDJACK at aol.com]

Hi Tom,
 
trying to send this message, but attachment is too big. John has to  approve 
the attached image:
 
   
Hi Tom,
 
> To make this work somewhat smoothly, one would need at least 0.001C  or  
> better 0.0001C resolution.

>Hi Said,
>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
>or GPSDO.


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.
 
bye,
Said