Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!linus!philabs!micomvax!musocs!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP
Newsgroups: comp.unix.questions
Subject: Re: RS232 cables and DSR/RTS/etc
Message-ID: <880@mcgill-vision.UUCP>
Date: Sun, 6-Sep-87 02:53:13 EDT
Article-I.D.: mcgill-v.880
Posted: Sun Sep  6 02:53:13 1987
Date-Received: Sat, 19-Sep-87 05:40:22 EDT
References: <8998@brl-adm.ARPA> <650@ora.UUCP>
Organization: McGill University, Montreal
Lines: 55

In article <650@ora.UUCP>, tim@ora.UUCP (Tim O'Reilly) writes:
> In article <8998@brl-adm.ARPA>, art@acc.arpa writes:
>> For asynch RS-232 cables,  I recommend the following:
>> 	SD   2 -------------\/----------------- 2   SD
>> 	RD   3 -------------/\----------------- 3   RD
>> 	RTS  4 --+			    +-- 4   RTS
>> 	CTS  5 --+			    +-- 5   CTS
>> 	DSR  6 ------+			+------ 6   DSR
>> 	SG   7 ------|------------------|------ 7   SG
>> 	DCD  8 ------o------\/----------o------ 8   DCD
>> 	DTR 20 -------------/\----------------- 20  DTR

> Note that the cable shown here is a null modem cable for connecting
> two DTE (Data Terminal Equipment) interfaces.  DTE-DCE (i.e. terminal
> to modem) connections would not cross lines 2 and 3, and 8 and 20.

In practice, the distinction between DTE and DCE seems to have all but
disappeared.  The only reliable way I know of to tell which some
equipment behaves as is to hook it up, and if it doesn't work, try
inserting a null modem cable and see if it cures it.  (Of course, for a
permanent connection, make or get a cable wired the right way (that is,
whichever way works)!)

> [However,] I do want to point out one drawback of the cable shown
> here, which has nothing to do with DSR/DCD/DTR:

> A cable with CTS and RTS jumpered together will work fine for normal
> terminal operation (people don't type all that fast)  but if you try
> to upload text from a PC using a cable like this, the receiving
> system will tend to lose characters.  [Further explanation of RTS and
> CTS.]  If there is any chance your cable will have to carry data from
> the terminal to the host at computer speeds rather than at human
> speeds, you should be sure to include RTS and CTS.  [Null-modem
> cables should cross the lines, other cables straight through.]

Or make sure you have either a hardware/firmware silo on the interface
or a machine fast enough to keep up with full-speed input.

One reason RTS/CTS/DCD/DTR/DSR signals are little-understood is, I
expect, because many terminal cables are made with four-conductor wire
just because it is what is on hand.  Such cables must of course use two
conductors for pins 2 and 3 (crossed or not).  This leaves only two
wires, one of which must be taken for some sort of ground (1 or 7 [*]),
leaving just one wire.  But just one wire isn't enough for a signal in
each direction.  Fortunately, such cables tend to be for real
terminals, not computer-to-computer links.  (To be sure, we use them
that way, but we are aware of the potential problems and make sure the
machines can take it....)

[*] I notice the original cable didn't have pin 1, Protective Ground,
connected.  Fie for shame.

					der Mouse

				(mouse@mcgill-vision.uucp)