Here is what terminating impedance does to a fast signal: http://www.ko4bb.com/Test_Equipment/CoaxCableMatching.php
Didier KO4BB > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Mark Sims > > Sent: Thursday, June 19, 2008 12:01 PM > > To: [email protected] > > 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 -- [email protected] To unsubscribe, go to > > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > and follow the instructions there. > > > _______________________________________________ > 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. _______________________________________________ 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.
