Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!mcvax!unido!tub!cabo From: cabo@tub.UUCP Newsgroups: comp.dcom.modems Subject: Re: Partial RS-232 Solution - (nf) Message-ID: <51700004@tub.UUCP> Date: Mon, 7-Sep-87 17:09:00 EDT Article-I.D.: tub.51700004 Posted: Mon Sep 7 17:09:00 1987 Date-Received: Wed, 9-Sep-87 01:45:19 EDT References: <377@grand.UUCP> Lines: 174 Nf-ID: #R:grand:-37700:tub:51700004:000:8091 Nf-From: tub!cabo Sep 7 22:09:00 1987 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, 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.