RAF@NIHCU.BITNET ("Roger Fajman") (02/23/88)
> :5 Clear To Send -| > :6 Data Set Ready |- <- 20 Data Terminal Ready > :8 Carrier Detect -| > : > :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. > > No, this doesn't make much sense to me. It's been my experience that > most DTE devices specify DTR as being *always* on, therefore useless > for hardware flow control. If the DTE implements RS-232 properly, > RTS-CTS crossed over will work properly for hardware flow control. > At least it always did when I was working for a modem manufacturer. Many printers have the ability to implement hardware flow control by dropping and raising DTR. Just one example of such a printer is the Qume Sprint 11 that I have sitting next to my CRT right now. I can understand jumpering Request To Send and Clear To Send on each side of the connection. Then each side's request is its own signal to proceed. This does not provide for flow control, however. Please explain why crossing RTS and CTS in the cable is a good idea. It makes one side's request to send the other side's signal to proceed. I'm not the only one who likes to make null modems that way. See the ME210 on page 87 of the Winter 88 edition of the Black Box Catalog. The only difference is they don't wire pin 1.