Differences

This shows you the differences between two versions of the page.

@@ Line 1: / Line 1: @@
+====== Thunderbolt Temperature Sensor ======
+//Re: [time-nuts] Thunderbolt performance vs temperature sensor//
+----
+Mark Sims
+Fri, 06 Mar 2009 09:57:39 -0800
+I did some testing on a Thunderbolt with the new revision E2 (low resolution,
+flat line) and old revision D1 (high resolution,  curvy line) DS1620
+temperature sensor chips.  The only thing that changed was the temperature
+sensor chip.
+Basically,  I put a unit that had the new revision E2 temperature sensor into
+manual holdover mode and ran Lady Heather over several 24 hour (approximately)
+periods with the log enabled.  Between each period,  I put the unit back into
+GPS discipline mode and let it recover.
+Next I swapped out the temperature sensor chip with an old revision D1 chip and
+let the unit run for a week so that it had a chance to relearn any filter
+coefficients.  Then I repeated the holdover log runs.
+I processed the logs to calculate the spread in the PPS error reading over 1
+hour intervals.  With the new revision E2, low res temp sensor the Thunderbolt
+averaged 1.73 uS of PPS change per hour.  With the old revision D1,  high res
+temp sensor the unit averaged 0.82 uS of PPS change per hour.
+So,  it appears that the Thunderbolt does indeed use the temperature sensor
+readings in its disciplining of the oscillator (which is also obvious from the
+plots of DAC voltage vs temperature) and that the units performance (at least
+the holdover performance) was adversely affected when the DS1620 temperature
+sensor chip was changed going from rev D to rev E.
+----
+Tom Van Baak
+Sat, 07 Mar 2009 20:16:16 -0800
+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.
+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.
+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?
+For example, I'd guess that most GPSDO have low sensitivity to wild
+temperature cycles every second -- because of its own thermal mass.
+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.
+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?
+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/
+/tvb
+----
+Magnus Danielson
+Sun, 08 Mar 2009 09:03:40 -0700
+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:
+{{:precision_timing:tvb-1.png|}}
+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
+----
+SAIDJACK
+Fri, 06 Mar 2009 14:18:26 -0800
+Hi,
+While this is good news for Trimble's competition and may open up the  avenue
+for an amateur mod, I think we would have to be fair to Trimble and do  the
+double-blind test:
+) Put the original temp sensor back into the unit, let it run one week,  and
+do the drift tests exactly the same as before.
+) remove the sensor completely from the board, and let it run without any
+sensor (if the unit works this way)
+You may have seen the performance difference due to measurement errors,
+aging of the crystal, ambient temperature changes (there was over 1 week
+difference between the two tests, so I am sure ambient temperature effects were
+different on the two runs), etc.
+To really get to the bottom of this, you would have to put the unit into a
+thermal chamber and cycle it from say -20C to +60C over an hour with say 10C
+steps and see the frequency change versus temperature.
+bye,
+Said
+----
+Mark Sims
+Fri, 06 Mar 2009 16:04:01 -0800
+Hello Said,
+The Tbolt that I used for the test was well aged (several months of operation)
+and stable prior to the tests.  It was only powered down for the 10 minutes or
+so that it took to swap out the old sensor.
+I tried to choose data sets that were fairly comparable temperature wise.  I
+also chose the basic measurement interval to be 1 hour so that temperature
+would not be changing much over the hour.  I am fairly confident that the
+results reflect changes due to the temperature sensor.
+I wanted to make the measurement PPS drift / degree C change / hour but the
+later model (low res) temp sensor chip would seldom produce a recordable change
+in temperature over a one hour period.
+----
+Mark Sims
+Sun, 08 Mar 2009 11:00:29 -0700
+The test that I did was meant to reflect how a typical user would be using a
+Thunderbolt...  sitting out in free air on a piece of poly foam,  covered by a
+cardboard box to provide a little isolation from environmental transients.
+Tbolt internal temperature changes were around 3 deg C per day and 0.3C per
+hour.  My chosen figure-of-merit for the tests was how much the PPS signal
+changed (as reported by the Thunderbolt message) over an hour.
+The unit had run continuously for several months.  Before I swapped the temp
+sensor chip,  I made several runs where at 11:00 AM I put it into manual
+holdover mode and started the log.  I recorded its self-measured data for
+around 23 hours,  stopped the log,  put it into normal operation mode for an
+hour.
+Next,  I shut it down and swapped the temp sensor chip.  This took about 10
+minutes.  I then restarted it,   let it stabilize for a day,   and did a
+factory reset.  I let it run for four days in GPS locked mode and four days
+with the 23 hour holdover mode cycles.  This (hopefully) gave it some time to
+learn about the new temp sensor.  Next I repeated the "official" 23 hour
+holdover test runs.
+The average of the 1 hour PPS holdover deviations with the newer low res temp
+sensor was 1.73 uS per hour.  The average of the 1 hour PPS deviations with the
+older high res sensor was 0.82 uS per hour.
+Yes,  it would be nice to put the unit into an environmental chamber and put it
+through its paces and discover all sorts of neat things about it.  I was more
+interested in how the change in the DS1620 temperature sensor chip affected the
+units in a way that I might actually see in the way that I use them.  I have
+already swapped the temp sensor chip three times in this unit (original E2
+chip,  another E2 chip,  and the D1 chip) and don't really want to risk
+damaging it with two more swaps (back to E2 and then D1).
+Tests on a single unit are hardly conclusive,  but it appears that you can
+double your holdover performance by using the older DS1620 chip.  Also,  by
+looking at the DAC and TEMP plots the temp sensor chip readings ARE used in
+generating the DAC voltage in GPS locked mode...  so I am assuming that the
+performance also would be improved in GPS locked mode (but by how much and how
+to test that have yet to be determined).

Differences

Except as noted, this entire site Copyright © 2002-2017. KO4BB All rights reserved.