day@grand.UUCP (Dave Yost) (09/04/87)
I thought I would hoist this up the pole in this
group, seeing all the RS-232 discussion flying about.
If anyone can add to the vendor information in this
little piece, please let me know. Thanks.
=====
Dave Yost
213-650-1089
Grand Software, Inc.
{uunet,attmail}!grand!dyost or dyost@grand.COM
8464 Kirkwood Drive
Los Angeles, CA 90046
Yost RS-232 RJ-45 connections
September 3, 1987
Here is a scheme that solves three of the Seven Great RS-232
Hassles:
1. All cable connectors are the same sex.
2. There is no distinction between DTE and DCE.
3. You can mass-terminate connector cables.
Corollary to 1 and 2: the only difference from one cable to the
next is the length; there are no wiring differences.
Theory of Operation
Each port on every piece of equipment at your site gets its own
appropriately-wired RS-232 to RJ-45 adaptor that you permanently
screw onto the port connector, and everything is connected with
RJ-45 cables instead of RS-232 cables. Thus, every port presents
the same connector interface, RJ-45 Female, regardless of whether
its underlying DB-25 connector was male or female, and cables can
be made easily using an RJ-45 crimp tool.
Now comes the tricky part that makes it all worthwhile: the
wiring of the adpators and the cables.
The RS-232 pinout scheme segregates equipment into two
categories, DTE (Data Terminal Equipment, i.e. terminals) or DCE
(Data Communications Equipment, i.e. modems), with the implicit
and very archaic assumptions that there are only terminals and
modems, and the only connections you ever need to make are from
terminals to modems. Now (unfortunately) RS-232 is used by
other things, like computers, which are sometimes wired as DCE
and sometimes as DTE. If you want to connect DTE to DTE or DCE
to DCE you have pinouts that don't match and you have to make
special cables.
The approach presented here erases the distinction between DTE
and DCE; every piece of equipment has compatible pinouts at the
RJ-45 interface.
RS-232 signals can be viewed simply as 3 outputs, 3 corresponding
inputs, and ground:
Simplified Name DCE DTE
----------------------- ------------
Secondary Modem Control CTS----->CTS
Primary Modem Control DCD----->DCD
Data RxD----->RxD
Ground GND------GND
Data TxD<-----TxD
Primary Modem Control DTR<-----DTR
Secondary Modem Control RTS<-----RTS
(DSR is not that important and can be ignored)
Yost RS-232 RJ-45 connections
September 3, 1987
page 2
The goal is to connect corresponding outputs and inputs.
Rearranging the previous table slightly and doubling the ground
connection, we have:
Adaptor DCE DTE
-------------------------------- ----- -----
Transmit Secondary Modem Control CTS--> RTS--> ----+
Transmit Primary Modem Control DCD--> DTR--> ---+|
Transmit Data RxD--> TxD--> --+||
Ground GND--- GND--- -+|||
||||
Ground GND--- GND--- -+|||
Receive Data TxD<-- RxD<-- --+||
Receive Primary Modem Control DTR<-- DCD<-- ---+|
Receive Secondary Modem Control RTS<-- CTS<-- ----+
The obvious bilateral symmetry here maps nicely to an 8-conductor
RJ-45 flat cable: one side of the cable transmits in one
direction, the other side in the other direction. If you don't
need secondary modem control, you can crimp 6-conductor cable
into the center 6 positions of the connector. If you don't need
any modem control, you can crimp 4-conductor cable into the
center 4 positions of the connector.
To connect devices, you make your cables "with a twist" or
"mirror image", or "side-to-side reversed", or whatever you want
to call it, so each transmit signal goes to its corresponding
receive signals at the other end.
Once you have put these adaptors onto your RS-232 ports, you
can simply connect anything to anything without:
* Using null-modems or null-terminals
* Changing pins on cable connectors
* Building special cables
You can connect
* modem to computer
* modem to terminal
* terminal to computer
* terminal to terminal
* computer to computer
etc., etc., with one kind of cable.
The cables are made from jacketed, 8-conductor flat cable that is
easily mass-terminated to the connectors with a crimp tool.
Yost RS-232 RJ-45 connections
September 3, 1987
page 3
The actual pinouts are:
Cable Page DCE name DTE name Sun-MTI other
--------- ---- -------- -------- ------- -----
/ Gy --- Br Wh 5 CTS--> 4 RTS--> 4 ?
| O --- Bl Br 8 DCD--> 20 DTR--> 20
| Bk --- Y Y 3 RxD--> 2 TxD--> 2
\ R --- Gn Gn 7 GND--- 7 GND--- 7
/ Gn --- R R 7 GND--- 7 GND--- 7
| Y --- Bk Bk 2 TxD<-- 3 RxD<-- 3
| Bl --- O O 20 DTR<-- 8 DCD<-- 6
\ Br --- Gy Bl 4 RTS<-- 5 CTS<-- 5
"Page" is the name of one vendor that makes DB-25 to RJ-45
adaptors. For some reason, their internal color coding does not
match the cable colors (If someone knows why this is, please
tell me). The Page parts are:
DB25641M Modular Adaptor Kit 8 Pin/Male
DB25641F Modular Adaptor Kit 8 Pin/Female
The adaptors, wire connectors, and wire are starting to become
available at electronics stores, sadly without any instructions
such as these. The famous "Fry's Electronics" store in Sunnyvale
calls these adaptors RJ-14 instead of RJ-45 (If somebody knows
what the difference is, please tell me).
The adaptor contains an RJ-45 socket with 8 wires coming out of
it. These wires have RS-232 pins (or sockets as appropriate)
crimped onto them. You simply push these pins into the holes in
the RS-232 connector and then snap the adaptor housing on. There
is one problem, however: the two ground pins have to go into one
DB-25 hole (pin 7). You can solder and tape these wires together
so they come out to one pin, or you can crimp them together with
a simple tiny plastic thingy made by AMP called a "Tel-splice
connector 1/2 tap dry", part number 553017-4. So far, this part
seems to only be available in 1,000 quantity for $80 or so.
Believe me, you want them. (If anyone knows of a source for
these in smaller quantities, please tell me.)
As you make the adaptors, label them M-DTE, M-DCE, F-DTE, F-DCE,
or whatever specialized name goes with a weird device that
doesn't fit in these catagories, such as the Sun "MTI" 16-port
multiplexer, which uses pin 6 for what it should be doing with
pin 8.
Is there an RJ-45 adaptor for the IBM-PC 9-pin D connector?
If there is, someone please let me know.
You will want a couple of tiny RS-232 pin insertion / extraction
tools, either the red plastic one with the bronze tip (AMP Part
#91067-2) or the cheapy all-plastic red & white one (maker
unknown).
Yost RS-232 RJ-45 connections
September 3, 1987
page 4
The cable crimp tool I have is AMP part number 231652-1 and cost
me $108. It is not so easy to find. You will probably have to
order it from an industrial telephone equipment distributor.
(Many industrial electronic houses will not even recognize
the AMP part number as valid). At least two other companies,
Palladin and General Machine Products, make an RJ-45 crimp tool,
and two hobby companies, GC Electronics and CalRad, are said to
be trying to make a low-cost tool (with no success so far).
One important missing piece in this plan is an RJ-45 female to
female adaptor that has a "twist". This is required if you want
to take two cables and connect them together to make a longer
cable. Adaptors exist which are either straight through or
which do funny connections convenient for telephone systems, but
I would like to hear of one that does a simple end-to-end twist.
Thanks to folks at UC Berkeley for the idea. Their wiring is
slightly different, I gather for historical reasons, but the
basic idea was there. If I can find out who really originated
this scheme, I'd like to credit him or her by name.
Good luck!
--dave yost
P.S. The remaining four of The Seven* Great RS-232 Hassles:
Matching baud rates
Transparent Flow control
Passing 8 bits of data
Slow speed
* at leastcabo@tub.UUCP (09/08/87)
In an otherwise very intelligent proposal, Dave Yost writes:
() /* comp.dcom.modems / grand!day / 7:19 am Sep 4, 1987*/
() [..]
() doesn't fit in these catagories, such as the Sun "MTI" 16-port
() multiplexer, which uses pin 6 for what it should be doing with
() pin 8.
OK, I've seen one too many of these, so I'll have to speak up.
I don't know what RS232 specifies, as it only is a national standard
that does not apply to the rest of the world, but fortunately there is
a supposedly compatible CCITT recommendation called V.24 that does
apply here. I think I'll start with a small tutorial about the
meanings of the control lines, and then I'll try to explain the
current chaos.
Trivial name Pin # Meaning
Controlled by
PG, SG 1, 7 Protective and Signal Grounds.
TxD (DTE) 2 Data sent by DTE to DCE.
RxD (DCE) 3 Data received by DCE for DTE.
RTS (DTE) 4 DTE requests activating the transmitter.
CTS (DCE) 5 DCE indicates activation of the local transmitter.
DSR (DCE) 6 DCE indicates ``data mode'', i.e. it is
off-hook, not in test-mode, and, to the best
of its knowledge, thinks that there is a
functioning modem at the other end.
DCD (DCE) 8 DCE indicates activation of the remote transmitter;
the data on RxD are valid.
DTR (DTE) 20 Available in two modes (by agreement of DTE and DCE):
Connect Data Set to Line: DTE requests going off-hook.
Rarely used without the monster
dialing standard V.25.
Data Terminal Ready: DTE indicates that DCE may go
off-hook. Today the usual interpretation.
RI (DCE) 22 DCE indicates that a remote DCE requests to enter
a conversation.
The correct way to place an outgoing call is to activate CDSL (DTR),
output your V.25 dialing codes (or ask the manual operator to dial
[I'm serious!]), wait for DSR to get active and then for valid data
(or time out).
The correct way to accept an incoming call is to wait for RI,
*then* activate DTR, and wait for DSR. Of course, if DTR has
been active all the time, the call is answered immediately.
RTS/CTS and DCD are an entirely different set of control lines,
necessary only for half-duplex operation. If a DTE wishes to
get the data on TxD across the wire, it asserts RTS; it is safe
to send data as soon as the DCE activates CTS to signal that
the transmission channel is ``clear'' from the turn-around noise.
The remote DTE then will use DCD to indicate its DTE that valid data
are available on RxD; the DTE should ignore RxD data as long as
DCD is inactive.
So much for the theory.
The real world becomes slightly more complex as a lot of applications
require full-duplex modems. On these modems, it gets a little
difficult to give the directional control pins (RTS/CTS and DCD)
useful semantics. Since pins cost money, some computer interfaces
do not support all of the signals that are provided in V.24.
The DEC DH11 is a particularly bad example: It leaves out DSR while
including DCD. From a certain point of view, this even makes sense:
As a protective measure, incoming modems should time out if DSR
remains active after an incoming call with no sign of DCD ever
becoming active. The software can maintain an imaginary DSR by
monitoring DCD only, and implementing the timeout from the point in
time DTR gets active to the point DCD gets active (and assuming that
when DCD gets inactive, the full-duplex line is broken, anyway).
Now UNIX comes into the play, with a DH11 driver that (sort of)
supports modem control by activating DTR only if somebody tries to
open the line, and letting the open get through only when DCD becomes
active. Surprisingly, in most cases this works even though RI is not
used at all. Unfortunately, for V.24-complying modems there is a
special bad case (the modem goes off-hook but then does not see
carrier) that is not handled well; this problem was solved by
``intelligent modems'' that implement the DSR/DCD timeout inside the
Modem.
The situation we now have is that the role of the DSR pin (pin 6)
has been taken by the DCD pin (pin 8).
Then somebody discovered that CTS is very useful for controlling the
data flow from the DTE to the DCE, and wished that there was a similar
pin for controlling the data flow from the DCE to the DTE.
He missed (or didn't care for) the fact that CTS flow control never
was end-to-end with the V.24 spec, and usurped the RTS pin for the
entirely different purpose of a ``reverse CTS''.
In the heads of most people this fog condenses to pictures like this:
() Simplified Name DCE DTE
() ----------------------- ------------
() Secondary Modem Control CTS----->CTS
() Primary Modem Control DCD----->DCD
() Data RxD----->RxD
() Ground GND------GND
() Data TxD<-----TxD
() Primary Modem Control DTR<-----DTR
() Secondary Modem Control RTS<-----RTS
() (DSR is not that important and can be ignored)
Now, let's try to find out what we really want.
We don't need a ``carrier'' or any other ``modem control'' for
connecting a terminal to a computer, we don't need RTS either. We do
need, however, lines that indicate that the other side ``is there''
(the equivalent of DSR/DTR in V.24 and DCD/DTR in the misguided UNIX
world standard). We also may need lines for flow control (the
equivalent to Pin4/CTS in the hardware handshake world). So why do we
need to keep these funny names from a 25-year-old standard, where
you'll always have to indicate whether you mean the de-facto semantics
or the standardized one? Let's call it:
() Simplified Name DxE DxE
() ----------------------- ------------
() I am ready IaR----->YaR
() I am there IaT----->YaT
() My Data MyD----->YoD
() Ground GND------GND
() Your Data YoD<-----MyD
() You are there YaT<-----IaT
() You are ready YaR<-----IaR
For a Terminal, we connect YoD to RxD, MyD to TxD, YaT to both DCD and DSR to
catch both complying and de-facto standard terminals, IaT to DTR,
YaR to CTS, and (surprise) IaR to DTR (as most Terminals don't
support hardware handshake and we don't have an RTS in this picture).
For a Modem, we connect YoD to TxD, MyD to RxD, YaT to DTR and RTS,
IaT to DSR (or DCD for a non-standard one), YaR open (there is no
hardware flow control with modems), IaR to CTS (or DSR, the best
source for active signal).
For an intelligent modem with flow control, this figure changes in
that YaR can be connected to RTS for hardware handshake, YaT then only
connects to DTR.
For a computer, you have to look into the manual to find out which pins
have which semantics, in most cases you will end up like with a
terminal with the possible exception that IaR may go to Pin4 (or
whatever pin is used for this function).
oOo
Now to the nit-picking:
() [...] If you don't need
() any modem control, you can crimp 4-conductor cable into the
() center 4 positions of the connector.
You always need ,,modem control`` (actually IaT/YaT signals) with
RS232. If you switch off one device, the open line may echo back what
is sent out (the well know situation where UNIX gets mighty slow when
someone unplugs a terminal). I also would propose to always connect
the flow-control line IaR if interconnection to flow-controlled serial
devices is at all likely; otherwise the other end might have to wire
YaR to YaT (or IaT, if dialing data have to be sent with YaT off).
Don't corrupt your new ``standard'' by subsetting too early!
I'm sorry this got so long, but I can't hear ``DSR is not so
important'' and ``RTS/CTS flow control'' any longer.
Regards, Carsten
--
Carsten Bormann, <cabo@tub.UUCP> <cabo@db0tui6.BITNET> <cabo@tub.BITNET>
Communications and Operating Systems Research Group
Technical University of Berlin (West, of course...)
Path: ...!pyramid!tub!cabo from the world, ...!unido!tub!cabo from Europe only.rikki@macom1.UUCP (09/09/87)
This scheme actually works very well. We have been using it internally for over 3 years. Essentially, since manufacturers haven't been able to agree on a standard, we just make all of our machines/terminals/modems look alike and use RJ-45. Ironically, this idea occurred to us as a result of the many problems we had trying to hook up the first Beta-release 3B2's several years ago. We cursed the RJ45's on them then for not being standard RS-232 and then instantly standardized on them. -- Rikki Welsh Centel Information Systems 5515 Security Lane, Rockville, Maryland, 20852, (301) 984-3636 UUCP: decuac!macom1!rikki
guy%gorodish@Sun.COM (Guy Harris) (09/09/87)
> As you make the adaptors, label them M-DTE, M-DCE, F-DTE, F-DCE, > or whatever specialized name goes with a weird device that > doesn't fit in these catagories, such as the Sun "MTI" 16-port > multiplexer, which uses pin 6 for what it should be doing with > pin 8. Or, more correctly, what it *would* be doing with pin 8 1) had Signetics not decided to do us the "favor" of having their 2661 chip *always* shut off the receiver when CD drops or 2) had Systech (the people who make the MTI) provided some way of forcing the chip's notion of CD high so that the state of the CD wire would be irrelevant. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
dave@astra.necisa.oz (Dave Horsfall) (09/11/87)
In article <377@grand.UUCP> day@grand.UUCP (Dave Yost) writes: > > Adaptor DCE DTE > -------------------------------- ----- ----- > Transmit Secondary Modem Control CTS--> RTS--> ----+ > Transmit Primary Modem Control DCD--> DTR--> ---+| > Transmit Data RxD--> TxD--> --+|| > Ground GND--- GND--- -+||| > |||| > Ground GND--- GND--- -+||| > Receive Data TxD<-- RxD<-- --+|| > Receive Primary Modem Control DTR<-- DCD<-- ---+| > Receive Secondary Modem Control RTS<-- CTS<-- ----+ > > The obvious bilateral symmetry here maps nicely to an 8-conductor > RJ-45 flat cable: one side of the cable transmits in one > direction, the other side in the other direction. An interesting proposal, but someone beat you to it! I have here a "Wyse-995 Multiport Adaptor" (bound to be a trademark or three in there somewhere!) which provides 8 RJ-11 sockets on a plug-in AT card. The box also contains cables and adapters for RJ-11 <-> DB25 plugs. They have decreed that their RJ-11 pin assignment is: Signal Card Adaptor Signal Name Pin Cable Pin Name DCD 1 <------------- 6 DSR/DCD TXD 2 -------------> 5 TXD FG 3 -------------- 4 FG SG 4 -------------- 3 SG RXD 5 <------------- 2 RXD DTR 6 -------------> 1 DTR The adaptor RJ-11 pins are brought out to DB-25 1/2/3/7/8/20. A couple of comments: they have retained the frame ground line, as well as signal ground (probably a good idea); and you lose the pretty bilateral symmetry, but it's been replaced with another one... So, it's a nice idea, but keep in mind that a commercial mob have already got their own version out. I can see it now, the RS-232 hassles all over again! (Disclaimer - I don't work for WYSE, I don't plug their products etc) And I don't think I've revealed any trade secrets... -- Dave Horsfall (VK2KFU) ACSnet/CSNET: dave@astra.necisa.oz NEC Information Systems Aust. ARPA: dave%astra.necisa.oz@uunet.uu.net 3rd Floor, 99 Nicholson St JANET: astra.necisa.oz!dave@ukc St. Leonards NSW 2064 AUSTRALIA UUCP: {enea,hplabs,mcvax,uunet,ukc}!\ TEL: +61 2 438-3544 FAX: 439-7036 munnari!astra.necisa.oz!dave
jhc@mtune.ATT.COM (Jonathan Clark) (09/11/87)
In article <51700004@tub.UUCP> Carstenn Bormann (cabo@tub.UUCP) writes at some length about the V.24 standard. I was impressed. I was unable to disagree with any of the statements made, and that's pretty rare for me. I will comment that when the word 'correct' is used in the article the term 'standard-conforming' should have been used: this is a nitpick. The term 'correct' has too many religious overtones these days. >RTS/CTS and DCD are an entirely different set of control lines, >necessary only for half-duplex operation. "Necessary", true. Although they are getting close to that for full-duplex. >Then somebody discovered that CTS is very useful for controlling the >data flow from the DTE to the DCE, and wished that there was a similar >pin for controlling the data flow from the DCE to the DTE. >He missed (or didn't care for) the fact that CTS flow control never >was end-to-end with the V.24 spec, and usurped the RTS pin for the >entirely different purpose of a ``reverse CTS''. I didn't originate this idea, but if I had I would have known that RTS is used for something else *in the half-duplex case* (which I'm not interested in), and called down curses upon the heads of the committee who designed this originally that they didn't foresee the need and put this usage of RTS into the standard. Then I would have knowingly ignored the HimmelGottverdammt standard, 'coz it was stupid. It would indeed have been nice to make RTS at one end map into CTS at the other on a non-multi-point (even full-duplex only) line. >Now, let's try to find out what we really want. Yes, *that* is what is important. Standards which do not meet this criterion are abandoned rather quickly. >We don't need a ``carrier'' or any other ``modem control'' for >connecting a terminal to a computer, we don't need RTS either. We do >need, however, lines that indicate that the other side ``is there'' >(the equivalent of DSR/DTR in V.24 and DCD/DTR in the misguided UNIX >world standard). We also may need lines for flow control (the >equivalent to Pin4/CTS in the hardware handshake world). Yes. And let us not forget the case where some RS-232/V.24 network is connecting the terminal to the computer. A network is buffered, and this is where the problems crop up. Perhaps as the world moves towards multiplexed interfaces and end-to-end protocols the requirement for out-of-band flow control will be satisfied without having to resort to this sort of chicanery, but that day is some way off. I restate what I said some time ago in this discussion: RTS/CTS flow control may not be in the standard, but it is too useful to do without. >Technical University of Berlin (West, of course...) As in 'the GDR doesn't have a University'...? -- Jonathan Clark [NAC,attmail]!mtune!jhc An Englishman never enjoys himself except for some noble purpose.