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.Uiuc
ad0@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.