Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84; site hao.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!hao!hull
From: hull@hao.UUCP (Howard Hull)
Newsgroups: net.dcom,net.periphs
Subject: Re: Definition of "null modem" cable
Message-ID: <1768@hao.UUCP>
Date: Fri, 20-Sep-85 16:54:13 EDT
Article-I.D.: hao.1768
Posted: Fri Sep 20 16:54:13 1985
Date-Received: Sun, 22-Sep-85 06:39:51 EDT
References: <195@almsa-1> <1734@hao.UUCP> <195@laidbak.UUCP>
Distribution: net
Organization: High Altitude Obs./NCAR, Boulder CO
Lines: 151
Xref: watmath net.dcom:1315 net.periphs:863

> >Notes:	This cable is wired like a DEC H312 Null Modem Card.
> >
> >Judging by the above note, at least DEC seems to think it knows what a
> >"null modem" is.
> >								     Howard Hull

> DEC obviously hasn't used equipment that toggles Request to Send
> wired to a machine as above.  Most all the UNIX terminal drivers
> I've seen would have a fit if the state of Carrier Detect
> was constantly changing.  Wiring Data Terminal Ready on one end
> to Carrier Detect on the other end seems to nearly always work.
> (Data Set Ready can be substituted if equipment demands.)

The fact that it nearly always works is not an assurance that it
complies with the RS232 standard.  Will Martin was not trying to get
something to work, he was concerned about what the definition was.

I suppose that my submission of the DEC H312 Null Modem diagram is thus
out of context; the H312 is an article of diagnostic and test hardware,
and it is not used operationally.  (However, I am sure the description
of it was correct; there was a similar posting from Craig Bevins that
came all the way from Australia!)

I would like to resolve whether the either the software designers,
or the hardware designers, or both, or neither are following the
RS232 standard, and if not, what the violations are.  The following
is included for reference:

Pin #	Signal Name		Description	RS 232 Mnemonic

 1	Protective ground	(mutual)		AA
 2	Transmit Data		(from T to M)		BA
 3	Receive Data		(from M to T)		BB
 4	Request to Send		(from T to M)		CA
 5	Clear to Send		(from M to T)		CB
 6	Data Set Ready		(from M to T)		CC
 7	Signal Ground		(mutual)		AB
 8	Data Carrier Detect	(from M to T)		CF
20	Data Terminal Ready	(from T to M)		CD
22	Ring Indicator		(from M to T)		CE

Notes:	The "from" device asserts the signal.
	The "to" device reads the signal.
	Data Terminal "T" is the computer or a crt terminal.
	Data Set "M" is a modem, or a null-modem to a computer or crt terminal.
You say:

> Request to Send should go to Clear to Send on the other end,
> and vice verse.  If you're going to use it, it may as well
> be right.

The situation is complicated by the fact that the RS232 standard
covers both dedicated line use and switched network use of modems (DTE)
and terminals/host computers (DCE).  There are handshaking protocols
for each.  For the purposes of this discussion, I will assume the
switched telecommunication network is the use we are concerned about.
From the Application Notes (Bulletin No. 9) of the EIA, I quote:
---
3.1.4	Handshaking

A handshaking technique is used predominately on the switched
telecommunication network.  DCEs used on dedicated point-to-point
circuits with alternate voice capability may also use this
technique.  The DCEs transmit signals to each other and perform
certain timeouts to establish the data transmission channel and
provide circuit assurance prior to turning the channel over to
the DTE for data transmission.  Where the DCE includes the
handshaking function, it guarantees initial circuit assurance,
and circuit CB (Clear to Send) (106) circuit CF (Received Line
Signal Detector) (109) must mean exactly what the name implies.
Each DCE has communicated with the other end and of the
telecommunication channel and knows that it is ready to transmit
and receive data.  In the design of some DCEs this philosophy is
carried even further in that the DCE will turn Circuit CB
(Clear to Send) (106) OFF if the received line signal disappears
from the telecommunication channel.  This is based on the logical
deduction, "If I can't hear him, he probably can't hear me either.
Therefore, stop transmitting."
---

Add to this some comments from 
				Randolph Fritz
UUCPnet:			decvax!philabs!wu1!rf

   RANDOLPH FRITZ'S GUIDE TO RS-232 SIGNALS AND OTHER SICK JOKES.

Signal	DTE <-> DCE	Description
======	===========	===========

4 RTS		->	Request to send.  Turns on modem's transmit
			carrier.  CONNECT.

5 CTS	<-		Clear to send.  Indicates that modem's transmit
			carrier is on.  Some modems assert this all the
			time.  CONNECT.

			  Message-ID: <274@wu1.UUCP>
			  Date: Wed, 4-Apr-84 13:19:06 MST

                                 we then get a sequence in which as RTS
is asserted by station A, its carrier must come on.  That implies that
it *was off*.  The modem, having done this must then return the assurance
that it has indeed done what it was told to do; the modem thus asserts
CTS to the DCE it is connected to.  There is no statement right here,
expressed or implied, concerning what will happen at the other end of the
telecommunication line.  The two sources quoted above would indicate that
DEC is correct in their alignment of Pins 4, 5, and 8, and that you are
responding to a self-composed desire for a life that is simpler than the
one the standard considers.

It would appear that toggling RTS is only appropriate for dedicated lines,
or perhaps for switched networks that remember paths, then proceed to connect
and disconnect them with the abandon of a Tasmanian Devil in a field full
of baby Jack Rabbits.  Otherwise, one should either leave RTS alone or not
drop carrier in response to null RTS.

>	     If equipment on one end doesn't support it,
> jumper them on *that* end.  (A lot of equipment doesn't bother with
> them anyway; I've only seen it on printers that couldn't
> generate ^S/^Q (*gasp*) for flow control.)

I know how you feel.  I, too, would like the manufacturers to support
both hardware and software handshaking.

> Safety Ground (pin 1) should NOT be carried all the way through,
> lest you develop ground loops.  If you have shielded cable,
> by all means use the shield, though.  More often than not,
> the best ground will be at the computer end.  (This assumes
> a proper installation, all disks, power supplies, and
> cpu's grounding to a single point.)

Safety Ground isn't a safety ground unless it IS carried all the way
through, via a shield or conduit.  What do you care if there is 5 Amperes
of miscellaneous AC between two terminal frames, as long as the terminal
innards are not connected to it?  Deliberate execution of specified
performance requirements must not be allowed to carry unsafe operational
situations into the product system, even for wartime environments.

For a system contained all in one building, and on one power distribution
breaker branch, we would wire them as you do, with one end of the shield
open, and the other grounded at the central distribution point, i.e. the
computer.  However, we do not have many installations that are all on one
breaker branch.  In those remaining cases (the majority), we take it tough
and do it according to code.

> Jonathan E. Quist
> ihnp4!laidbak!jeq
> ``I deny this is a disclaimer.''
Shucks.  Me too.
								     Howard Hull
        {ucbvax!hplabs | allegra!nbires | harpo!seismo } !hao!hull