[time-nuts] Tbolt temperature sensor

[Magnus Danielson]

Tom Van Baak skrev:
>> 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?
> 
> 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.

Recall that a typical thunderbolt is a fairly closed up box. The case is 
a great heat-conductor so gradients and changes caused from external 
sources is damped by the relatively high heat conductivity in the shell 
as compared to the head conductivity into the box and especially the 
oscillator. Inside the box there are some local heat sources dispersed 
throughout, but the OCXO heats up pretty good by itself. There is not 
much self convection in there.

One also must recall that an OCXO oven has a damping of temperature 
swing. This gain of the oven is of interest here. While we surely could 
have use for more bits, an OCXO ambient temperature of 0-70 C may become 
say a 0,07 degree shift, a gain of 0,01. A 0,25 C shift will become 
0,0025 C shift at the crystal. Is the resolution usefull? Yes, but it is 
has limits. The important thing being, which limits was it intended to 
solve?

While I agree that absolute temperature is not necessary, high 
resolution can be spoiled by other sources of temperature, such as 
enabling another dump source, shift of sats etc. all causing shift in 
power usage and changing the gradients inside the box. To get any real 
performance one has to keep the temperature sensor tightly tied to the 
OCXO while well isolate from the other stuff. For the Thunderbolt target 
application I think it would be severly overkill.

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

Actually, any CHANGE in temperature gradients will do that. If you have 
a static temperature gradient you will not really notice. Gradients have 
however a tendency to change... as power burn changes in different 
places etc.

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

Even a very passive filter making convection onto the OCXO case 
basically none causes a very dramatic change and the response curve is 
quite different. The most important thing is that the oven actually can 
track along fast enought.

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

Except that temperature changes may be fairly quick... I have detuned 
OCXOs just by walking by them... pushing colder air onto them as I come 
walking. The OCXO needs to do up-front compensation, but the EFC path 
may do after the fact compensation if propper dynamic models exist and 
is fairly valid.

I don't think 0,25 C resolution is worthless, but it can still do good work.

> 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?

There are many interesting aspects to such thermal dynamic tests.

> Again, given this is time-nuts, some real data would be nice.

As always.

Cheers,
Magnus