[time-nuts] Thunderbolt performance vs temperature sensor

Magnus Danielson magnus at rubidium.dyndns.org
Sun Mar 8 12:02:53 EDT 2009


Tom Van Baak skrev:
> See: http://www.leapsecond.com/pages/tbolt-temp/
> 
> Hi Mark,
> 
> This is very interesting work that you're doing with Thunderbolt
> DS1620 temperature sensors. I hope you stick with it. I agree
> with Said about the double bind idea.
> 
> I worry too that your TBolts are remembering something of the
> past in spite of the hardware changes you make for each new
> run. Do you do a full factory reset each time? And then let the
> unit "re-learn" for several hours, or maybe several days? Do
> we really know how or what it is learning and how that affects
> the response to temperature?
> 
> 
> Having tried tempco measurements in the past I have several
> concerns about mythology. It's really hard to get this right and
> even harder when you don't know what "smart" algorithms are
> inside the box you're trying to test.

The theory here is that we do have a smart algorithm. Under the 
assumption that we have a smart algorithm comes that we want to give 
that algorithm a decent chance by using the higher resolution variant of 
the DS1620.

This also makes testing more troublesome.

> In this situation, it seems to me the main thing about temperature
> is not temperature at all, but the *rate* at which the temperature
> changes.
> 
> In that case, even careful cycling of room temperature every day
> or cycling temperature inside a special chamber every hour will
> not give you the real story -- because in both cases the focus is
> on varying the temperature; not the rate at which the temperature
> is changing.
> 
> Compounding the problem is that different components in the
> system will react to temperature at different rates. The DS1620
> is plastic and may react quickly. The OCXO is metal and will
> react slowly. Who knows what additional component's tempco
> are relevant to the final 10 MHz output. Some may overreact
> at first and then settle down.

True... but.

Consider that the OCXO and the temperature sensor has time-constants to 
them. You can now model their heat response-time through equalent RC 
links (in reality you have many of these lumped up, this is a thought 
model). As long as the temperature risetime is much slower than the OCXO 
and tempsensors time-constants, the risetime is dominated by the 
incident wave. A classic formula for this is:
                _________________
              /  2         2     |
t      = \  /  t       + t
  total    \/    signal    input

for t_signal >> t_input this becomes

t      = t
  total    signal

Signal in this case is heatchanges due to our main heater 8 lighmin away.

Another thing I want to point out is that metal is a very good heat 
conductor where as plastic is a very poor heat conductor. One has to be 
carefull to confuse that with heat capacitivity, the ability to keep 
heat. We use metal flanges to remove heat from components, not plastic 
ones. The high conductivity of metal will make any temperature change 
move fairly fast throughout. This is why it is hard to solder on ground 
planes or metal-chassis, the heat at the solderpoint distributes quickly 
where as soldering on some local point on a PCB is not that hard as the 
plastic of the PCB is a relatively poor heat conductor.

So, you can expect that the metal can of the OCXO reacts fairly quickly 
and the temperature sensor is a thad slow. This also matches exercises 
we have done by using a fan to do forced air convection tests on OCXO 
and tempsensor. Putting a *plastic* hood over it significantly lowered 
the risetime and the consequence is that the lower risetime allowed the 
tempsensor inside the OCXO to sense the change and react to it. This 
introduces a third time constant, the time-constant of the OCXO control.
The effect of using a hood or not was significant. The change of 
frequency shape was distinct and for the measurement interval we looked 
at the phase drift was about 1/3 for this simple addition.

Lessons learned:

* Temperature transients may expose OCXO time constants

* Passive isolation may aid in reducing gradient time constants

The OCXO Oven control really just helps with slow-rate changes and may 
span a high temperature range, but not quickly. Passive isolation helps 
smoothing out transients. For transients will heat capacitivity be an 
issue and multilayer isolation/capacitivity will acts as higher order 
filters.

> I guess in the ideal world you'd want to do a "sweep" where you
> go through several cycles of temperature extreme at rates varying
> from, say, one cycle per minute all the way up one cycle per day.
> 
> It seems to me you'd end up with some kind of spectrum, in which
> tempco is a function of temp-cycle-rate. Has anyone seen analysis
> like this?

To some degree yes... see above.

> For example, I'd guess that most GPSDO have low sensitivity to wild
> temperature cycles every second -- because of its own thermal mass.

Actually, if they sit in a forced air environment, they will change 
temperature pretty quick because their metal cover will conduct away the 
heat quite efficiently. Thermal mass is not a great measure unless you 
also consider the thermal conductivity, they together will describe the 
heat time constant.

If you put your GPSDO in a "heat pocket" and not put it flush to some 
metal surface but rather use plastic spacers you will be in a much 
better place from transients and the turbolence of convection (forced or 
not).

> And I bet most GPSDO have low sensitivity to wild temperature swings
> every few hours -- because the OCXO easily handles slow changes
> like this well. It's for time scales in between those two that you either
> hit sweet spots or get very confused and react just opposite of what
> you should.

You just don't react quick enough. Building OCXOs that would have a 
balance for it would turn up rather large. Our OSA 8600/8607 uses a 
Dewar flask embedded in foam inside the metal chassi and then has a 
metal chassi inside of that. The outer shell is not temperature 
controlled but becomes notably warm anyway.

Your wine-cooler 8607 should have a foam frapping and not stand 
metal-onto-metal to become more efficient.

Regardless. Temperature transients is best handled through isolation 
filters. Temperature gradients is reduces as well if done properly.

Unless an external temperature probe is thermally well connected to the 
OCXO it is not as useful and it can certainly not aid in anything but 
slow rate changes. This would become a TOCXO construct.

A thermally well tied temperature probe could be used for transient 
suppression if thinking about it, as the speed of compensation through 
the EFC input is very high. For it to work one has to model the 
transient response properly. Basically one has to process the signal 
through a model filter. This could be done in analogue or digital.

> I'm thinking another testing approach is to varying the temperature
> somewhat randomly; with random temperature *amplitude* along
> with random temperature *rate*. Using this temperature input, and
> measured GPSDO phase or frequency output, you might be able
> to do some fancy math and come up with a transfer function that
> tells the whole story; correlation; gain and lag as a function of rate,
> or something like that. I'll do some reading on this, or perhaps
> someone on the list can fill in the details?

This can be done using MLS sequences and the cross-correlation would 
produce the impulse response of the heat-transfer mechanism.

The actual heat difference used does not have to be that large actually, 
as you aim to establish the impulse response at this stage. With a 
detailed enough impulse response you can then locate the poles and zeros 
of the filter.

You can use a transistor and a resistor (say a 2N3055 with some suitable 
resistance) to be modulated by the MLS sequence and then do frequency or 
phase measurements synchronously with the MLS sequence. The rate of the 
MLS sequence will through Nyqvist theorem put an upper limit to the 
highest rate you can measure. Here is a golden case where "smart" 
frequency measurements should be avoided as their filtering would become 
included in the transient response. It could be compensated naturally, 
but would only confuse the issue.

The amplitude of temperature-shifts will of course become a frequency 
resolution factor. However, a short measurement period at high 
temperature shifts could work, but running over longer times natural 
temperature changes as well as aging needs to be suppressed and then you 
need to average over longer times and running at slightly less amplitude 
on modulation could be tolerated.
Temperature changes and drift could be cancled from the measurement 
sequence prior to cross-correlation to reduce impact. This can be done 
through normal frequency and drift predicting and removal.

Use of MLS sequences to characterize impulse responses is a well 
established technique. The two major limitations is usually too low 
modulation rate and too short MLS sequence besides the obvious one of 
dynamic. Calibration of output and input stages can remove their impact.

> I say all of this -- because of an accident in my lab today. Have a
> careful look at these preliminary plots and tell me what you think.
> It shows anything but a nice one-to-one positive linear relationship
> between ambient temperature and GPSDO output.
> 
> http://www.leapsecond.com/pages/tbolt-temp/

It looks kind of typical.

The OCXO performs a non-perfect diffrential task in the heat scale, its 
limited gain will make the long-term uncompensated. Look at the second 
plot. As the temperature rises drastically the phase dips dramatically.
The oscillations display similar risetimes and thus is let through.

For me this is somewhat of an expected impulse response. The GPSDO 
attempts to steer it into action, so that why it does not look as the 
full integrated frequency response as one would expect from an OCXO 
free-wheeling.

Cheers,
Magnus




More information about the time-nuts mailing list