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

Didier Juges didier at cox.net
Thu Jun 19 23:21:33 UTC 2008


Here is what terminating impedance does to a fast signal:

http://www.ko4bb.com/Test_Equipment/CoaxCableMatching.php

Didier KO4BB 

> -----Original Message-----
> From: time-nuts-bounces at febo.com 
> [mailto:time-nuts-bounces at febo.com] On Behalf Of Didier Juges
> Sent: Thursday, June 19, 2008 6:11 PM
> To: 'Discussion of precise time and frequency measurement'
> Subject: Re: [time-nuts] Thunderbolt RS-232 and TSIP protocol.
> 
> 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.
> 
> 
> _______________________________________________
> 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.





More information about the Time-nuts_lists.febo.com mailing list