Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!ucbvax!NIHCU.BITNET!RAF From: RAF@NIHCU.BITNET ("Roger Fajman") Newsgroups: comp.dcom.modems Subject: Re: INFO-MODEMS Digest V88 #52 Message-ID: <8802180550.AA09815@ucbvax.Berkeley.EDU> Date: 17 Feb 88 23:29:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 33 > 1 chassis gnd <-> chassis gnd 1 > 2 txd <-> rxd 3 > 3 rxd <-> txd 2 > 4 rts <-> cts 5 > 5 cts <-> rts 4 > 7 sig gnd <-> sig gnd 7 > 6 & 8 (dsr & dcd) <-> dtr 20 > 20 dtr <-> (dsr & dcd) 6 & 8 Crossing pins 4 and 5 (Request To Send and Clear To Send, respectively) makes no sense to me. If these pins are actually used, the DTE should raise Request To Send when it wants to transmit and wait for Clear To Send before it does. Thus passing one side's RTS to the other's CTS isn't very meaningful. Jumpering them at each end of the cable makes sense, if you really don't want to use them for flow control. However, my favorite arrangement is as follows: 1 Protective Ground <-> 1 Protective Ground 2 Transmitted Data -> 3 Received Data 3 Received Data <- 2 Transmitted Data 5 Clear To Send -| 6 Data Set Ready |- <- 20 Data Terminal Ready 8 Carrier Detect -| |- 5 Clear To Send 20 Data Terminal Ready -> -| 6 Data Set Ready |- 8 Carrier Detect 7 Signal Ground <-> 7 Signal Ground With this arrangement, if one of the devices turns off DTR to stop the flow of data (as many devices can do), the other device will see it as CTS, DSR, and CD all going off. If it pays attention to any RS232 line for flow control, it is likely to be one of those.