home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / dcom / modems / 11985 < prev    next >
Encoding:
Internet Message Format  |  1992-08-12  |  1.8 KB
  1. Path: sparky!uunet!elroy.jpl.nasa.gov!usc!noiro.acs.uci.edu!ucivax!ofa123!Mark.Milhollan
  2. From: Mark.Milhollan@ofa123.fidonet.org
  3. Newsgroups: comp.dcom.modems
  4. Subject: Hardware vs xon/xoff flo
  5. X-Sender: newtout 0.01 Jul 13 1992
  6. Message-ID: <n06fdt@ofa123.fidonet.org>
  7. Date: 12 Aug 92  08:12:00
  8. Lines: 46
  9.  
  10. You wrote: 
  11.  
  12. > I know that the the RS232 'standard' is not really a standard (in the  
  13. > sense of having all details fully specified),  
  14.  
  15. It was _VERY_ complete -- but nobody wants a half-duplex protocol.  Revisions
  16. to allow full-duplex were not universally acceptable when they were first 
  17. introduced, so some confusion ensued. 
  18.  
  19.  
  20. > how off-the-wall is use of hardware flow control? 
  21.  
  22. Compared to the original RS (recomended standard)?  Quite. 
  23.  
  24. Viewed on it's own?  Not too wierd.  Drop RTS when you are not willing to 
  25. accept characters; do not send characters when CTS is low. 
  26.  
  27. Do all modems support this?  Generally all _modern_ modems do -- but the 
  28. default configuration is often such that they are disabled, i.e. DSR, RLSD 
  29. and CTS are always true, DTR and RTS are ignored. 
  30.  
  31.  
  32. > We need to be able to operate to 115 Kbaud and transfer binary data. Does 
  33. > anyone know whether packages that operate at this speed and do binary 
  34. > transfer use hardware flow control? 
  35.  
  36. Usually. 
  37.  
  38.  
  39. > Do any packages use xon/xoff to do this? 
  40.  
  41. None that I know of.  Turnkey (usually Kermit based) solutions might. 
  42. (Escaping the two characters (binary transfer right?) is overhead.) 
  43.  
  44.  
  45. > The statement has been made that many communication packages commonly  
  46. > used on the PC have no provision for dealing with hardware flow control. 
  47. > How true is this?  
  48.  
  49. NOT!  Most packages support hardware flow control.  (Krap doesn't -- be 
  50. careful, much Krap is Pretty.)  Some packages have it disabled initially 
  51. (why? dunno.) so check. 
  52.  
  53. ___
  54.  
  55. --- Maximus 2.00
  56.