|
|
|
|
— |
precision_timing:thunderbolt_temperature_sensor [2013/01/08 19:00] (current)
|
| | ====== 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). |
| | |
| | |
| |
