Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!pasteur!agate!ig!uwmcsd1!marque!brianb
From: brianb@marque.mu.edu (Brian Bebeau)
Newsgroups: comp.dcom.modems
Subject: Re:  INFO-MODEMS Digest V88 #52
Message-ID: <40@marque.mu.edu>
Date: 18 Feb 88 14:15:32 GMT
References: <8802180550.AA09815@ucbvax.Berkeley.EDU>
Reply-To: brianb@marque.UUCP (Brian Bebeau)
Organization: Marquette University, Milwaukee, WI
Lines: 34

In article <8802180550.AA09815@ucbvax.Berkeley.EDU> RAF@NIHCU.BITNET ("Roger Fajman") writes:
:
: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.  
:  However, my favorite arrangement is as
:follows:
:
: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.

---------------------------------------------------------------------------
Brian Bebeau				 Marquette University		

DOMAIN:  brianb@marque.mu.edu 
  UUCP:  {rutgers,ihnp4,harvard}!uwvax!marque!brianb
	 {rutgers,uunet}!marque!brianb
  ARPA:  brianb%marque.uucp@csd1.milw.wisc.edu
BITNET:  6877BEBE@MUCSD
---------------------------------------------------------------------------