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

[Didier Juges]

Mark,

Have you put a scope at the line to see what the signals look like at the
end of the 25 foot cable? What kind of distorsion do you see? You may be
able to improve things quite a bit with the proper termination. 

When using unknown cables to send relatively fast signals, yet not critical
enough to warrant using a coax cable, I use a series RC network across the
cable, with a small cap (100pF or so) and a series 1kohm potentiometer to
terminate the line (at the receiver end). I tweak the pot until the waveform
looks best on the scope. This is not as good as a constant impedance cable,
but it's a lot cheaper and easier, and has worked most of the time.

Didier 

> -----Original Message-----
> From: time-nuts-bounces at febo.com 
> [mailto:time-nuts-bounces at febo.com] On Behalf Of Mark Sims
> Sent: Thursday, June 19, 2008 12:01 PM
> To: time-nuts at febo.com
> Subject: [time-nuts] Thunderbolt RS-232 and TSIP protocol.
> 
> 
> 
> 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/c
rea=earncashback
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com To unsubscribe, 
> go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.