[time-nuts] Strange temperature peak

[Tom Van Baak]

The problem is actually with all three parts: the 1620 sensor, TBolt
firmware, and with Heather. Let me explain.

1) While the root cause is an anomaly in the DS1620 chip, Dallas
identified (not solved) it and described a work-around after Weather
Station users noticed glitches in the late 90's.

2) The next problem is Trimble did not implement the recommended
software fix in their TBolt firmware. Worse yet, Trimble computes a
running average temperature and returns this as "the temperature"
instead of the actual instantaneous 1620 reading. Further they use
24-bit floating point precision in the TSIP packet. Side effects:
a) the returned temperature is biased and late due to the LPF,
b) users can mistake filtered floating point for mK or uK resolution,
c) any 1620 glitches are "smoothed" instead of handled as Dallas
suggested, and d) internal disciplining algorithms may use the bad
temperature values as input.

3) The final issue is that LH displays the filtered TSIP temperature
rather than the actual 1620 temperature reading. Thus you often
see exponential curves in temperature plots instead of true steps.
And glitches too.

Anyway, since we can't change the 1620 design; and we can't
change the TBolt firmware, the solution for Alberto (and anyone
else) is for LH to report the correct temperature.

Mark -- the trick is to recreate the raw quantized 1620 temperature
from the TSIP averaged temperature readings and then implement
the 1620 glitch fix per the Dallas memo. This way the readings are
on-time, reflect the actual ~1/140th C quantization of the chip, and
have no glitches. The difference is dramatic.

To de-average see at unavg.c in www.leapsecond/tools/

To de-glitch see the Dallas memo 2000-ds1820-report.pdf under
www.leapsecond.com/pages/tbolt-1620/

/tvb