Path: utzoo!utgpu!watmath!xenitec!zswamp!p0.f171.n221.z1.fidonet.org!Geoffrey.Welsh From: Geoffrey.Welsh@p0.f171.n221.z1.fidonet.org (Geoffrey Welsh) Newsgroups: comp.dcom.modems Subject: Re: RS232 to modem connectionREAD/NEW/FOLLOWUP Message-ID: <894.25151214@zswamp.fidonet.org> Date: 18 Sep 89 13:49:30 GMT Sender: ufgate@zswamp.fidonet.org (newsout1.26) Organization: FidoNet node 1:221/171.0 - Izot's Swamp, Kitchener ON Lines: 74 > From: GPWRDCS@gp.govt.nz (Don Stokes, GPO) > Message-ID: <328@gp.govt.nz> > I have never connected all lines in an RS232 line in my life. Quite > simply, if one needs only 3, 7 or whatever lines in a cable, one uses a > 3, 7 or whatever core cable (or near approximation) - dealling with > 25-core cables is too much like wrestling snakes, or has insulation that > is too thin, or more often than not, both. 12-core is bad enough. I use > 3 cores in my cables if I can get away with it. If the software and hardware support it, I always prefer to go 9-line for short cabling (computer <--> modem): pins one thorugh eight plus twenty (this provides signal and chassis ground, RxD, TxD, RTS, CTS, DSR, DTR, & DCD. Of course, for wiring terminals from one building to another, you can get away with 4-conductor (GND, RxD, TxD, and the terminal's DTR wired to the host's DCD), but I've always been frustrated by the lack of immediacy that gives me with modem control and the roadblocks that result if I use that kind of setup with a driver that demands fuller hardware handshaking (like the INT 14H drivers in the IBM PC). > I think RTS/CTS are intended for half-duplex modems, certainly the > behaviour is rather different for hdx than fdx, in that with hdx modems, > the RTS is dropped as soon as data transmission stops, which is somewhat > incompatible with the fdx arrangement where the RTS line acts as the > other device's CTS line. In a hdx modem, the RTS line determines > whether a transmit carrier is generated. Yes - full duplex modems use RTS as a signal to the computer/terminal that they're ready to accept data and the terminal/host uses CTS to indicate the same to the modem; that's not how the Request-To-Send and Clear-To-Send lines work in the EIA spec. It is, however, how every late-model 9600+ bps modem uses them. Let's not forget that the specified DSR/DTR handshake has also been overriden by the use of DTR as a hook control on most modems. > Depends what you are doing - my general rule is that the more handshake > lines there are, the more sources of problems there are :-). XON/XOFF > can be very reliable - eg most DEC comms gear will react to an XOFF in > just as much time as it takes to respond to loss of CTS (and in my > experience, is more likely to work). XON/XOFF is sufficiently simple > that it can be hardware implemented, and reasonably easily in software. I prefer to avoid it because binary transfers could easily contain the XOFF or XON character and, if the driver dumbly takes that as an indication that it shouldn't send until it gets an XON, then the transfer locks up. This may not be a concern with terminals (although downloadable character sets and advanced graphics are changing that), but it's vital with modems. I prefer to keep the control signals out of the data path because that allows use of short, simple drivers that rely on unambiguous signals. It may also result in faster operation, since the driver no longer has to process the data in any way, merely pass it on... > Modem control is another kettle of fish. For an originating modem > attached to an interactive terminal, there is no major problem - I am > usually quite happy with three-core cables. For an answering modem, or > originating modem that must run unattended, DCD & DTR should be present > to allow accurate detection of carrier loss, and a bulletproof way of > dropping the carrier. OK, then, we don't disagree... much, anyway. > Just to drive everyone up the nearest wall, I've come across a few > devices that use DTR as their flow control line... Ah, but that's EIA spec! We can't complain that RTS/CTS handshaking as used by recent modems breaks from spec if we're going to complain that some equipment out there CONFORMS to spec, can we? -- Geoffrey Welsh - via FidoNet node 1:221/171 UUCP: {{uunet!}watmath!xenitec!}zswamp!171.0!Geoffrey.Welsh ARPA: Geoffrey.Welsh@p0.f171.n221.z1.fidonet.org