husmann@uiucdcsb.UUCP (01/10/85)
I would like to build my own cable to interface my 9-pin serial port to my
modem's 25-pin RS-232C socket. I can buy one for $60 but I'm sure I can make
one for much less. What I need to know is the name of the pins on the 9-pin
serial port and which pin of the 25-pin plug I wire them to.
I think I saw a note on the net sometime ago which gave directions for this
little job but I can't find it now. Thanks in advance.
Harlan Husmann
Department of Computer Science
University of Illinois at Urbana-Champaign
usenet: {ihnp4,pur-ee}!uiucdcs!husmann
csnet: husmann@uiucdcs.Uiucad0@pucc-i (Andy Thomas) (01/15/85)
Here are the pin assignments of the 9 pin D connector on the
IBM PC/AT serial port.
Pin Description Signal Source
--- ----------- -------------
1 Carrier Detect modem
2 Receive Data modem
3 Transmit Data PC/AT
4 Data Terminal Re PC/AT
5 Signal Ground
6 Data Set Ready modem
7 Request to Send PC/AT
8 Clear to Send modem
9 Ring In modem
Here are the RS-232 Signal Conventions
Pin Description Signal Source
--- ----------- -------------
2 Trensmitted Data Terminal
3 Received Data Modem
4 Request to Send Terminal
5 Clear to Send Modem
6 Data Set Ready Modem
8 Carrier Detect Modem
20 Data Terminal Ready Terminal
22 Ring Indicator Modem
7 Signal Ground
If you want to use the control signals, you could try the following cable:
DB-9 Pin Description DB-25 Pin
-------- ----------- ---------
1 Carrier Detect 8
2 Tramsmit Data 3
3 Received Data 2
4 Data Terminal Rdy 20
5 Ground 7
6 Data Set Ready 6
7 Request to Send 4
8 Clear to Send 5
9 Ring Indicator 22
To use a cable with no control signals (known as a null modem cable) try
the following:
DB-9 Pin Description DB-25 Pin
-------- ----------- ---------
2 Tramsmit Data 3
3 Received Data 2
5 Ground 7
DB-9 : Wire pins 7&8 together
Wire pins 1,6,&4 together
DB-25 : Wire pins 6,8,&20 together
Wire pins 4&5 together
I have not tried these cables yet, but am sure they will work.
Andrew Thomas
{dacvax|harpo|ihnp4|inuxc|seismo|ucbvax}|pur-ee|pucc-i:ad0
( *Not responsible for any damages. Void where prohibited. Penalty
required for early withdrawl..............)dmt@ahuta.UUCP (d.tutelman) (01/15/85)
REFERENCES: <816@pucc-i> Thanks for posting the pin assignments. I'd like to make one small correction, not in the pins but the terminology. A "null modem cable" is NOT a modem cable without control leads. It's a cable that REPLACES a modem, so that two back-to-back terminals (or terminal and computer) can converse without benefit of a modem. For example: Transmit data ------------------------------ Receive data Receive data ------------------------------ Transmit data Request to send ------------------------------ Clear to send Clear to send ------------------------------ Request to send Modem ready ------------------------------ Terminal ready Terminal ready ------------------------------ Modem ready Ground ------------------------------ Ground is an example of a null modem with some control leads implemented. Note the transposition of leads (Transmit to Receive & vice-versa) that is the characteristic of null modems. Dave Tutelman
rpw3@redwood.UUCP (Rob Warnock) (01/17/85)
+--------------- | Thanks for posting the pin assignments. I'd like to make one small | correction, not in the pins but the terminology. A "null modem cable" | is NOT a modem cable without control leads. It's a cable that | REPLACES a modem, so that two back-to-back terminals (or terminal | and computer) can converse without benefit of a modem. | For example: | ... | Request to send ------------------------------ Clear to send | Clear to send ------------------------------ Request to send | ... | Dave Tutelman +--------------- Quite true, but unfortunately you blew it with your example, which does NOT emulate a pair of back-to-back modems. Request/Clear-To-Send (RTS/CTS) don't work that way. First, you only need to cross-connect them when emulating a half-duplex (or "controlled carrier") modem, since a full-duplex modem usually has clear-to-send true whenever carrier-detect is. Second, CTS is a response to the LOCAL RTS, not the remote's RTS. To properly emulate half-duplex use of RTS/CTS, you have to make a local RTS cause both a local CTS and a remote CD (carrier-detect). (The terms "remote" and "local" are symmetric.) Try it this way ("X" is a cross-over, "+" a join): 7 GND --------------- GND 2 TD ------\ /------- TD X 3 RD ------/ \------- RD 4 RTS --+--\ /----+-- RTS (I request to send; you get carrier) | X | 5 CTS --+ / \ +-- CTS / \ 8 CD ---/ \----- CD 6 DSR --+ +-- DSR (The dataset is ready when the terminal is) | | 20 DTR -+ +-- DTR Alternatively, to correctly emulate a pair of back-to-back full-duplex modems (of the 103/212 style), use: 7 GND --------------- GND 2 TD ------\ /------- TD X 3 RD ------/ \------- RD 4 RTS -(n/c) (n/c)- RTS 5 CTS --+ +-- CTS | | 8 CD --+---\ /---+-- CD X 6 DSR --+---/ \---+-- DSR | | 20 DTR -+ +-- DTR Many variations are possible, especially when non-standard flow-control methods are used, but hooking RTS on one side to CTS on the other is not one that normally makes any sense. Usually flow control is done by cross-connecting DTR and CTS; that is, if the local D(ata) T(erminal) is R(eady), the remote is C(lear) T(o) S(end). Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404
dmt@ahuta.UUCP (d.tutelman) (01/23/85)
REFERENCES: <128@redwood.UUCP> Thanks, Rob. You're absolutely right! And my apologies to the net for the misinformation.