mike@octel.UUCP (Michael D. Crawford) (09/22/89)
We have a problem with crosstalk between the Send Data and Recieve Data
of many of our serial lines. What happens is that a character sent will
be garbled and recieved on the same port.
We use our ports for terminals, and for downloading software produced by
cross-compilers on our Sun servers. The downloading protocol gets garbage
where it expects acknowledgements. The getty's on the terminal port cause
the system to crash through a bizarre feedback effect:
getty displays "Octel Communications Sun UNIX 4.0.1"
getty recieves something like "mkkoummu{;pkwww", then execs "login
mkkoummu{;pkwww". Here a ps -aux will occasionally spot the login process
using 50% or more of the CPU time. This is when I am lucky enough to catch
it and unplug the terminal. Otherwise, I suppose, login is repeatedly
prompting for the password, recieving "p}wwuo" or some such, printing
"Login incorrect" and prompting for the user name. It must really get
going as it echoes the characters it recieves for the username! When I am
lucky, I can abort the system, disconnect all the serial cables, and then
continue it, but if I am not, I must reboot.
I have found there is a simple algorithm to determine how the data is
garbled! The coupling is capacitive; when there is a 1 to 0 transition on
the send, there will be a 0 bit on the recieve. A 0 to 1 generates a 1.
Repeated runs of 1's or 0's don't generate anything, but seem to be
interpreted as 0's.
Our present wiring is a single twisted pair of telephone wire. The Send
and Recieve Data leads are twisted around each other. There is no ground.
Don't blame me. It was this way when I started here.
I replaced most of our downloads with Belden 9729. This has two
"Datalene" insulated twisted pairs, with an uninsulated drain wire for
each pair, and each such triplet is wrapped with "Beldfoil", aluminum
foil with a plastic coating on the outside. Following advice in
Nemeth, Snyder, and Seebass' "Unix System Administration Handbook", [p.
147], I tied on member of each pair to Signal Ground at both ends, used
the other members for Send and Recieve, and tied the drain wires in
each pair to Frame ground at the Sun end.
Examination with an oscilloscope shows there is still some crosstalk on this
cable. It seems small enough that it should not be a problem. Our
downloads work fine now. The Belden data sheet recommends this cable for
EIA RS-422, which I understand is a balanced pair signal, and is different
from RS-232. I just used up my first $300, 1000 foot spool. Before I
order another, I would like advice on what other cable you might recommend,
how to connect it, etc.
The 9729 is kind of hard to crimp and insert properly, as the insulation is
very thick, but at least it is soft. I suppose it has to be thick to space
the wires far apart to reduce their capacitance.
(I thought the crashes were do to many other things, which have been
eliminated over time. I had the intuitition that we needed better cable
for the downloading, but I was not sure what was going on at the time. I
am much relieved it is working now.)
--
Michael David Crawford Consulting for:
Oddball Enterprises Octel Communications Corp
694 Nobel Drive 890 Tasman Drive
Santa Cruz, CA 95060 Milpitas CA 95035
uunet!apple!vsi1!octel!mike
CI$ 72377,623edward@ucbarpa.Berkeley.EDU (Edward Wang) (09/23/89)
In article <43@octel.UUCP> mike@octel.UUCP (Michael D. Crawford) writes: >getty displays "Octel Communications Sun UNIX 4.0.1" >getty recieves something like "mkkoummu{;pkwww", then execs "login >mkkoummu{;pkwww". . . . That's the reason for the one second delay in the Version 7 getty. When fixing the wiring is beyond your control, add pf#1 to your gettytab. Things are much worse once somebody logs in (and unplugs the terminal, or switches the line away from it, which people do all too often here), echo is turned on and the line starts to bounce characters back and forth at full baud rate. What fun! Anyway, this is my pet peeve. TTY drivers should have input limiting when echo is on.
jst@cca.ucsf.edu (Joe Stong) (09/23/89)
I have found in the past that some RS-232 ports are just too high impedance; loading them on the receive side with some resistor in the 1-10K range will make them less sensitive to noise, and will keep the voltage levels down (electrostatic coupling). I tend to run transmit and receive in separate twisted pairs each with either a ground, or a robust signal that doesn't change much or respond quickly (like DTR or CD). I suspect that twisted pair phone wire would be cheap and effective used this way. (Beware: 4 wire "quad wire" is not twisted pairs.)