<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hardware flow control is tangentially related to my feature request
    #777.  Hardware flow control uses the RTS signal line for flow
    control;  modern amateur radio cables use RTS (and/or DTR) for
    power:<br>
    <br>
    In classical hardware flow control (classically a terminal connected
    to a modem):<br>
    <ol>
      <li>When the DTE (Data Terminal Equipment: eg a terminal) is
        powered on and ready to receive data, it asserts DTR (Data
        Terminal Ready).</li>
      <li>When the DCE (Data Communications Equipment: eg, a modem, or
        other device communicating with the terminal) is ready, it
        asserts DSR (Data Set Ready).</li>
      <li>In an actual modem configuration, when the modem has
        established a connection with a remote modem, it asserts CD
        (Carrier Detect).  Similarly, when an idle modem receives a
        phone call attempt, it asserts RI (Ring Indicate).  Depending
        upon the modem configuration and what is connected to it, the
        terminal may assert DTR, signalling the modem to answer the
        ringing phone line (and subsequently asserts CD).  While this is
        interesting, it is normally not a factor in the case at hand; 
        I've only included it for context.</li>
      <li>Normally a terminal that is ready to send asserts RTS (Request
        To Send).  This usually stays high for the duration of the
        connection (an exception would be half-duplex modems, which is
        not pertinent here).</li>
      <li>Typically, modems could receive data from a terminal at a much
        higher rate than the modem could send to the remote modem, and
        as a result, had an internal buffer.  The default state of a
        ready modem was to assert CTS (clear to send).  However, if the
        buffer got too close to being full, a modem would drop CTS until
        it had transmitted (emptied) most of the transmit buffer.</li>
    </ol>
    Hardware flow control is #4 and #5 above.  In the modern computer
    world, where the two devices are local (or simulated as same) and
    there is no modem, the above changes slightly:<br>
    <br>
    <ol>
      <li>DTR and DSR are asserted when the respective devices are
        functionally ready, and stay in that state until the
        communications session is over.  Eg:  A printer (DCE) asserts
        DSR when its power-on sequence in complete, until power-off.  A
        software communications program (DTE) typically asserts DTR when
        the program opens the serial connection, until it closes the
        connection.</li>
      <li>RTS and CTS are used for flow control, just as above.</li>
    </ol>
    <p><br>
      When <b>SOFTWARE</b> flow control is used:<br>
    </p>
    <ol>
      <li>RTS is asserted by the DTE at the same time as it asserts DTR,
        and CTS is asserted by the DCE at the same time as it asserts
        DSR.</li>
      <li>One or both of the devices sends X-off and X-on bytes to tell
        the other device to suspend and resume transmission,
        respectively.</li>
    </ol>
    <p><br>
      Sometimes two DTE devices need to communicate, and a wiring change
      is made in the normally straight-through cable, so that what one
      DTE device thinks is DTR/RTS/TX, the other device sees as
      DSR/CTS/RX.  Such is the "null modem" cable.  Some manufacturers
      of devices don't understand this or related wiring issues, leading
      to the need for "gender changers", but this is not pertinent here.<br>
    </p>
    <p>One important feature of all of the above, is that each such
      device acquires its own power.<br>
    </p>
    <p>However, with most Amateur Radios, the radio cable usually does
      not bring anything except "ground" and the "TX" and "RX" data
      lines.  This is the case for all Icom radios that I am aware of,
      as well as and most handhelds from other manufacturers.  My Yaesu
      FT-897D is an exception;  the serial cable provides power to its
      internal serial converter.<br>
    </p>
    <p>For some Icom radios (eg, the ID-880H and IC-2820H) that use the
      Icom OPC-1529R cable, it's a simple three-wire cable providing
      ground, TX, and RX.  Presumably these are at RS-232C acceptable
      levels (that's a whole different discussion).  Other cables (eg,
      the Yaesu one for the Yaesu FT-897D) have a little circuit board
      in the RS-232C/DB-9 shell that does level conversion (and needs
      power, except for the few radios where the cable provides the
      power).  Still other cables, like the ones that split out TX and
      RX signals from a single wire, have additional circuitry for that
      purpose.<br>
    </p>
    <p>Both of the latter cases must get their power from the DTR and/or
      RTS lines from the connected computer.  These signal lines were
      never intended to provide power, but since modern circuits draw so
      little power, using DTR and/or RTS for power doesn't create an
      issue if done correctly.<br>
    </p>
    <p>As I noted in the feature request, some cables want both DTR and
      RTS on, and use ground for the voltage reference base.  Others
      want RTS low and DTR high, and some want the reverse.<br>
    </p>
    <p><br>
    </p>
    <p><br>
      <br>
    </p>
  </body>
</html>