[time-nuts] Thunderbolt RS-232 and TSIP protocol.
Didier Juges
didier at cox.net
Thu Jun 19 19:21:33 EDT 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
mailing list