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 _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
