[net.periphs] Definition of "null modem" cable

control@almsa-1 (William Martin) (08/29/85)

What is the exact definition of a "null modem" cable? Does the term
*only* mean that the connections to pins 2 and 3 on a DB25 RS232
connector on each end are interchanged, or does it also imply
connections of other pins or the shorting or cross-connecting of
certain pins (like 1, 7, 6, and 20)?

Or is it a general term with no exact definition, except that it implies
that the 2 & 3 connections are crossed?

Will Martin

ARPA/MILNET: wmartin@almsa-1.ARPA    UUCP/Usenet: seismo!brl-bmd!wmartin

saltiel@cdstar.UUCP (Jack Saltiel) (08/29/85)

In article <195@almsa-1>, control@almsa-1 (William Martin) writes:
> What is the exact definition of a "null modem" cable?
> 
> Or is it a general term with no exact definition, except that it implies
> that the 2 & 3 connections are crossed?
> 
That's exactly right. Depends upon what modem functions you are
trying to 'nullify' or imitate. The one that we use that usually
(99%+) succeeds in allowing data to flow is:

-----------------------
    f     2  -------------------\ /------------------  2    f
                                 X
    e     3  -------------------/ \------------------  3    e

    m     4  ----\				 /---  4    m
                 |                               |
    a     5  ----/                               \---  5    a

    l     6  ------\                          /------  6    l
                   |                          |
    e     7  ----------------------------------------  7    e
                   |                          |
	  8  ------+                          +------  8
                   |                          |
	 20  ------/                          \------  20

		  2 = TD Transmit Data
		  3 = RD Receive Data
		  4 = RTS Request to Send
		  5 = CTS Clear to Send
		  6 = DTR Data Terminal Ready
		  7 = Signal Ground
		  8 = CD Carrier Detect
		 20 = DSR Data Set Ready

	Alternate arrangements have 4 & 5 crossed between the two
	end to allow cooperating hardware perform a
	RTS/CTS handshake.

	Other have that and/or DTR on the left tied to DSR & CD on
	the right & visa versa. This allows another kind of
	handshake. If you don't need the handshake, use the one
	drawn above. It will almost always allow data to pass.

	(PS: I may have RD & TD, RTS & CTS, and DTR & DSR
	reversed--this is from memory(at home) but just check an
	EIA chart first. It only matters if you're doing any
	hardware handshaking.)

-- 
					Jack Saltiel
					Cambridge Digital Systems
					{wjh12,talcott}!cdstar!saltiel

	"Here's to plain speaking and clear understanding."
	"I like a man who likes to talk."

phil@amdcad.UUCP (Phil Ngai) (08/30/85)

In article <195@almsa-1> control@almsa-1 (William Martin) writes:
>What is the exact definition of a "null modem" cable? Does the term
>*only* mean

1) that the connections to pins 2 and 3 on a DB25 RS232
>connector on each end are interchanged,

2) or does it also imply
>connections of other pins or the shorting or cross-connecting of
>certain pins (like 1, 7, 6, and 20)?
>
3) Or is it a general term with no exact definition, except that it implies
>that the 2 & 3 connections are crossed?

The way I look at it, RS232 is not a standard, it is just a way of saying
you are going to try to make two devices talk together. With whatever
pins work. (ever try to hook up an NEC Spinwriter to a computer?)

But in answer to your question, 3) is certainly right, 1) works for many
DEC devices and 2) is sometimes needed. If you need 2), the most general
case is as follows:

2-----3
3-----2
7-----7
4-- --4
  | |
5-- --5
6-- --6
  | |
8-- --8
  | |
20- -20
-- 
 "What really knocks me out, is a book that, when you've done reading it, you
 wish the author that wrote it was a terrific friend of yours and you could
 call him up on the phone whenever you felt like it."

 Phil Ngai (408) 749-5720
 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil
 ARPA: amdcad!phil@decwrl.ARPA

hes@ecsvax.UUCP (Henry Schaffer) (08/30/85)

> What is the exact definition of a "null modem" cable?  ...
> 
> Will Martin
> 
  I don't believe that there is a standard wiring - but the standard
definition is that the "null modem" (also called a "crossover" or
sometimes a "modem eliminator") converts a DTE interface to a DCE
and vice-versa  (DTE-data terminal equipment, e.g. terminal.  DCE-data
communication equipment, e.g. modem.)
  To do this some pins are passed through, e.g. 1 and 7,; some are
"crossed over", e.g. 2 and 3, and some are just fed back at each
end, e.g.6 and 20 are connected together at each end and don't go
through.
  Then vendors differ as to exactly what else they do.  Glasgal
Communications also connects 4,5 and 8 at each end, while Black Box
Products connects 4 and 5 at each end and connects 8 to the 6 and 20
at each end.  Black Box also passes through 11 and 12 crossed over.
(This info is from their respective catalogs.)
  The one I use to connect a Model 100 to an IBM PC has the following
connections:    Male         Female
                 1            1
                 2            3
                 3            2
                 4            5
                 5            4
                 6,20         8
                 7            7
                 8            6,20
Someone elso made it for me, so I can't say whether this is the
minimum necessary wiring - but it does work.  Note it isn't 
exactly either one of the above vendor's schemes.  Also
note that the genders of the connectors are not standard (although
female-female is probably most common.)  You have to specify what you
want.
--henry schaffer

taylor@ecsvax.UUCP (Steven Taylor) (08/30/85)

The main difference between a "null modem cable" and a "modem 
eliminator" in common usage of the terms is that a "modem
eliminator" OFTEN also has the capability to provide a clock 
signal on pins 15 and 17.  This is commonly used to connect
two synchronous devices which require external clock (which would
normally be supplied by the modem, hence the "eliminator.")

Steven Taylor
Distributed Networking Associates
119 Doncaster Lane
Charlottesville, VA  22901
(804) 979-0656

gws@cbnap.UUCP (Gary W. Sanders (N8EMR)) (08/30/85)

In article <3209@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes:
>In article <195@almsa-1> control@almsa-1 (William Martin) writes:
>>What is the exact definition of a "null modem" cable? Does the term
>>*only* mean
>
>
>>The way I look at it, RS232 is not a standard, it is just a way of saying
>>you are going to try to make two devices talk together. With whatever
>>pins work. (ever try to hook up an NEC Spinwriter to a computer?)
>
>>But in answer to your question, 3) is certainly right, 1) works for many
>>DEC devices and 2) is sometimes needed. If you need 2), the most general
>>case is as follows:

	You can just cross pins 2 and 3, then pins 4 and 5 are connected
	togeter on each side of the connector. Pins 6,8 and 20 are connected
	together on each side of the connector. This way you get the null
	modem cable you need. However you loose a little also, first no
	hardware flow control, second if you used this cable with a modem
	the computer would never see someone hang up the phone and the
	process attached to that modem would never die. A "generic" better
	may is illistrated below. Keep in mind RS232/DB25 may be a standrd,
	but many companys dont fully implement it or they add the own extra
	features. 

	Generic NULL modem
	------------------

	2__________3
	3__________2
	4__________5
	        !__6
	5__________4
	6__!
	7__________7
	8__________20
	20_________8

	You may or not need the pin 5 to pin 6 strap, If you are using
	AT&T terminals to and AT&T datakit LAN you will need the strap.

	What connectors go on each side depends on your enviorment, Typicaly
	a female on each end works out great, In a DEC only world all you need
	is female to female null modem cables. In an AT&T env. you might
	want to have male to female null modems.
_______________________________________________________________________________ 
[                                                                             ]
[	Gary W. Sanders (N8EMR)						      ]
[	AT&T Bell Labs (Columbus,Ohio)					      ]
[	614-860-5965 (w)	614-457-4595 (h)			      ]
[	72277,1325 Compuserve.						      ]
[                                                                             ]
-------------------------------------------------------------------------------
-- 
test of sig file

hull@hao.UUCP (Howard Hull) (08/31/85)

I just perused the RS232 standard and the Application Notes and did not find
the words "null modem" anywhere.  I did find "DCE(modem)" mentioned once in
the Application notes.  So "null modem" must be trash slang.  A "full" null
modem can be quite complex.  Following is a description for one I have had
miscellaneous cable collection.

DEC		TERMINAL / COMPUTER RS-232 NULL-MODEM CABLE	10-MAR-82

Cable Type:	Belden 9504	4 pair overall shielded
Outside Dia.:	0.265 inches	(6.75 millimeters)
Connectors:	DB-25
Terminal								Computer
Pin #	Signal Name		Wire Color	Signal Name		Pin #

 1	Protective ground-------Shield Drain----Protective ground	 1
 2	Transmit Data---------> red ----------> Receive Data		 3
 3	Receive Data <--------- white <-------- Transmit Data		 2
 4	Request to Send--:----> violet -------> Carrier Detect		 8
 5	Clear to Send <--: 5 jumpered to 4
 6	Data Set Ready <-:-----	green <-------- Data Terminal Ready	20
22	Ring Indicator <-: 22 jumpered to 6
 7	Signal Ground--white's blk & red's blk--Signal Ground		 7
 8	Carrier Detect <--- violet's blk <--:---Request to Send		 4
			    5 jumpered to 4 :-> Clear to Send		 5
20	Data Terminal Ready -> green's blk -:-> Data Set Ready		 6
			   22 jumpered to 6 :-> Ring Indicator		22

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
[If yet unproven concepts are outlawed in the range of discussion...
                   ...Then only the deranged will discuss yet unproven concepts]
        {ucbvax!hplabs | allegra!nbires | harpo!seismo } !hao!hull

jeq@laidbak.UUCP (Jonathan E. Quist) (09/01/85)

In article <1734@hao.UUCP> hull@hao.UUCP (Howard Hull) writes:
>I just perused the RS232 standard and the Application Notes and did not find
>the words "null modem" anywhere.  I did find "DCE(modem)" mentioned once in
>the Application notes.  So "null modem" must be trash slang.  A "full" null
>modem can be quite complex.  Following is a description for one I have had
>miscellaneous cable collection.
>
>DEC		TERMINAL / COMPUTER RS-232 NULL-MODEM CABLE	10-MAR-82
>
>Cable Type:	Belden 9504	4 pair overall shielded
>Outside Dia.:	0.265 inches	(6.75 millimeters)
>Connectors:	DB-25
>Terminal								Computer
>Pin #	Signal Name		Wire Color	Signal Name		Pin #
>
> 1	Protective ground-------Shield Drain----Protective ground	 1
> 2	Transmit Data---------> red ----------> Receive Data		 3
> 3	Receive Data <--------- white <-------- Transmit Data		 2
> 4	Request to Send--:----> violet -------> Carrier Detect		 8
> 5	Clear to Send <--: 5 jumpered to 4
> 6	Data Set Ready <-:-----	green <-------- Data Terminal Ready	20
>22	Ring Indicator <-: 22 jumpered to 6
> 7	Signal Ground--white's blk & red's blk--Signal Ground		 7
> 8	Carrier Detect <--- violet's blk <--:---Request to Send		 4
>			    5 jumpered to 4 :-> Clear to Send		 5
>20	Data Terminal Ready -> green's blk -:-> Data Set Ready		 6
>			   22 jumpered to 6 :-> Ring Indicator		22
>
>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.)
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.  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.)
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.)

Jonathan E. Quist
ihnp4!laidbak!jeq
``I deny this is a disclaimer.''

peter@graffiti.UUCP (Peter da Silva) (09/03/85)

Here is the minimum null-modem cable I have ever used. Note that it's really
not suitable for anything but a hardwired terminal, short haul, but it's
perfectly good for connecting DEC terminals to non-DEC computers & vv.

		 2------------3
		 3------------2
		 4-+        +-5
		 5-+        +-4
		 7------------7
		 6-+        +-6
		 8-+        +-8
		20-+        +-20

Conscientious hackers will want to connect 1, 4 and 5:

		 1------------1
		 2------------3
		 3------------2
		 4------------5
		 5------------4
		 7------------7
		 6-+        +-6
		 8-+        +-8
		20-+        +-20

But for most cases 6, 8, and 20 are irrelevant. Of course if for some weird
fetishistic reason you want to look like a real pair of modems, leave 4 and 5
dangling & do something useful with 6, 8, and 20. The 3-wire cable at the top
will handle a good percentage of your cabling needs.

hull@hao.UUCP (Howard Hull) (09/20/85)

> >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