[time-nuts] Tbolt temperature sensor
SAIDJACK at aol.com
SAIDJACK at aol.com
Thu Feb 5 00:56:54 UTC 2009
from my experience even a resolution of 0.25C is several orders of magnitude
too low for use in holdover temperature compensation on an OCXO.
This would result in fairly massive EFC changes on the Thunderbolt ovens,
especially if they are single ovens with significant thermal sensitivity. The
average error for a typical single oven OCXO due to this would be ~1.25E-010,
To make this work somewhat smoothly, one would need at least 0.001C or
better 0.0001C resolution.
I can't get into too much detail, but our units allow for down to ~0.000025C
resolution by using a 24 bit ADC for the temperature sensing. Keep in mind
that for temperature compensation the absolute temperature is not of interest,
but rather the change of temperature over time. This kind of resolution is
not possible with I2C based absolute temp sensors, one needs analog circuitry
feeding high-resolution Delta-Sigma ADC's. These circuits are not accurate on
the absolute temperature, but they do have very high resolution for relative
A resolution of 0.25C would give you only 40 individual DAC settings for a
10C change as could be expected on a typical diurnal temperature change on a
lab bench. This would make the frequency jump around and really sink the ADEV
performance of the unit during holdover.
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!
The math looks better for double oven OCXO's, but not much.
I am pretty sure the Dallas chip is only used for environmental monitoring
of the absolute temperature, and not for compensation anywhere inside the PLL
Any Thunderbolt designers on this list??
In a message dated 2/4/2009 12:45:51 Pacific Standard Time,
holrum at hotmail.com writes:
My bet is Dallas Semi changed their chip in a way that is not compatible
with the Tbolt firmware. If Trimble changed their firmware to not do the high
resolution read cycle, they would not have done the first steps of the high
res read cycle (mask off the LSB, subtract 0.25C) which actually reduces
the temperature resolution from nine bits to eight bits.
Trimble could have easily missed the problem if they did not plot the
temperature curves. The unit reports a proper temperature, it just does not have
the fine resolution of the earlier units... which could easily affect
More information about the time-nuts