Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/17/84; site hao.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!hao!hull From: hull@hao.UUCP (Howard Hull) Newsgroups: net.dcom,net.periphs Subject: Re: Definition of "null modem" cable Message-ID: <1768@hao.UUCP> Date: Fri, 20-Sep-85 16:54:13 EDT Article-I.D.: hao.1768 Posted: Fri Sep 20 16:54:13 1985 Date-Received: Sun, 22-Sep-85 06:39:51 EDT References: <195@almsa-1> <1734@hao.UUCP> <195@laidbak.UUCP> Distribution: net Organization: High Altitude Obs./NCAR, Boulder CO Lines: 151 Xref: watmath net.dcom:1315 net.periphs:863 > >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 Brought to you by Super Global Mega Corp .com