This shows you the differences between two versions of the page.
|
precision_timing:thunderbolt_temperature_sensor [2013/01/08 19:00] |
precision_timing:thunderbolt_temperature_sensor [2013/01/08 19:00] (current) |
||
|---|---|---|---|
| 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: | ||
| + | |||
| + | 1) Put the original temp sensor back into the unit, let it run one week, and | ||
| + | do the drift tests exactly the same as before. | ||
| + | |||
| + | 2) 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). | ||
| + | |||
| + | |||