[time-nuts] Thunderbolt RS-232 and TSIP protocol.

[Mark Sims]

I am writing a program that talks to the Thunderbolt.  The computer that I am on is in a different room and they are connected by a 25 foot RS-232 cable.  At 9600 baud I get occasional (mayby one in 1000 packets) glitches in the data stream.  The glitches do not show up with a 10 foot cable.  Two differently construced long cables had problems.  Interestingly the glitches almost always show up in the same place in the same two data packet types.

The TSIP protocol does not put checksums on the packets so you have no reliable way to tell that your data has been corrupted.  I only noticed the problem when I started logging temp, dac voltage,  pps, and osc offsets.  I was logging the min, average, and max values of each parameter over 10 second intervals.  The glitched packets  caused some values to be way off and they showed up in the min/max data.  Backtracking to the corrupted packets showed the bogus values.  Also usually the packets were two or three bytes short and this showed up as errors in the expected End-of-Packet and Start-of-Packet flags.

Moral of the story: Thunderbolts don't like to drive long data cables.   The TSIP protocol has serious data integrity issues.  When parsing TSIP packets,  if you don't see the ETX where expected,  discard that packet... it is definitely corrupted.

Enabling parity checking would probably help,  but many operating systems and drivers do not actually check parity and/or report parity errors.
_________________________________________________________________
Earn cashback on your purchases with Live Search - the search that pays you back!
http://search.live.com/cashback/?&pkw=form=MIJAAF/publ=HMTGL/crea=earncashback