Chapter 13. RS-232D Flow Control
Flow control is the communication between the data transmitter and data receiver (to determine whose turn it is to talk). Another name for flow control is handshaking. Flow control is the exchange of predetermined codes and signals between two devices to establish and maintain a connection.
Modem flow control is used between the PC and modem to determine if the modem is ready to receive data from the terminal, if a carrier is present, if the line is ringing, etc.
Source to Destination (End-to-End) flow control
Source to destination flow control is used to control the data communication from the sender to the receiver (it may or may not have a modem involved). Source to destination may involve direct PC-to-PC communication, or PC to serial printer communication. It is also called end to end flow control.
DTE-DCE Flow Control
There are two basic types of DTE-DCE Flow Control used with RS-232D connections: hardware handshaking and software handshaking.
Hardware Handshaking
Hardware handshaking uses the physical signals in the RS-232D cable--such as RTS, CTS, DSR and TSR-- to control the flow of data. Hardware handshaking is used primarily with modems (with PC-to-modem connections, or with terminal-to-modem connections).
PC-to-Modem Handshaking (DTE-DCE)
The basic signals required for DTE-DCE hardware handshaking are as follows:
The following diagram indicates the signals used when two PCs are communicating (using hardware handshaking).
In the following example, DTE(Tx) is originating the call and DTE(Rx) is answering the call. DTE(Rx) is in the auto-answer mode with DTR(Rx) and DSR(Rx) High is ready to answer a call. The procedure for connecting these two PCs--using modems and the telephone line--is as follows:
The communication program controls the handshaking. The DTE (Tx) dials the phone number as shown below:
a. PC sends DTR(Tx) - PC is awake! b. Modem replies with DSR(Tx) - Modem is awake, too! c. PC sends RTS(Tx) - Ready for some data? d. Modem replies with CTS(Tx) - Okay send away! e. PC transmits data on TXD - Initialize dial this telephone number. 
DTE(Rx) is in the auto-answer mode with DTR(Rx) and DSR(Rx) High, indicating that the receive end is ready to answer a call. This has been setup by the communication program that's similar to dialing the number in the previous step (except the modem is now told to go to auto-answer mode). The phone rings as shown below:
The modem--initialized in the auto-answer mode--picks up the phone line and sends Answer Carrier (2125 Hz). Every time the phone rings, the RI (bit) line goes high: the communication program will usually display the word "ring" on the screen.Back at the transmit end, you'll see the following:
a. Modem sends CD(Tx) - We're connected and they are sending us good carrier! b. PC sends RTS(Tx) - Okay send them our carrier (1170 Hz). c. Modem waits - Delay so that Rx modem can lock to the carrier d. Modem sets CTS(Tx) - Okay now we should be ready to send data e. PC sends TxD(Tx) - Here's some data to send over. At the receive end, you'll see this:
a. Modem sends CD(Rx) - We're connected & they're sending good carrier (1170 Hz b. Modem sends Rxd(Rx) - Here's some data for you. 
The communication program then interprets the data and decides if a reply is required (or if more data is coming).
The communication programs handle both data transfer and direction.
Either Originate or Answer can end the communication:
a. DTE(Tx) drops RTS(Tx) or DTR(Tx) - I'm done, hang-up the phone. b. DCE(Tx) modem drops DSR(Tx) and the Carrier (1170 Hz) - I've disconnected. c. DCE(Rx) modem drops CD(Rx) - No carrier, they're hanging up d. DTE(Rx) drops RTS(Rx) - Hang up on them e. DCE(Rx) modem drops DSR(Rx) and the Carrier (2125 Hz) - I've disconnected.
Hardware Null Modems
Null modems are a way of connecting two DTEs together without using a modem - we are nulling out the modems (thus the term "null modem"). When two DTEs are connected together, the TXD Pin2 of one DTE is crossed to Pin 3 RXD of the other DTE. We also have to fool the DTEs into believing that they are connected to DCE devices. This is done by crossing the control lines as follows:
Notice that RI (Ring Indicator) and CD (Carrier Detect) are not used when connecting directly from DTE to DTE. They are a function of a telephone system: by nulling out the modems, we've eliminated the telephone system. This can cause problems when transferring files directly, because most communication programs detect loss of carrier (CD) as a disconnect command. The communication program will abort the data transfer if CD is not present; this can usually be overridden by De-selecting "Transfer Aborted if CD Lost" (or something similar) in one of the communication software configuration menus.
Software Handshaking (Xon / Xoff)
Software Handshaking does not use the RS-232D control signals: it uses the software commands Xon/Xoff to control the data flow. Do not use software handshaking with a modem. If you do, you'll lose several important functions of the modem (such as RI and CD).
Software handshaking is a simple flow control method that is used mainly with DTE-to-DTE and DTE-to-Serial Printer connections. The receiving device controls the flow of data by issuing "Xon" (okay to transmit data) commands and "Xoff" (stop - let me catch up) commands. A good example of this data flow control is the DTE-to-Serial Printer connection.
For example, a dot-matrix printer cannot physically print faster than a transfer rate of 300 bps. Printers are usually equipped with a memory buffer to store data before it is printed. The printer buffer is allowing large chunks of data to be downloaded to the printer from the DTE, thereby freeing up the DTE to do other tasks (other than having to wait for a page to be printed).
When the data is first being downloaded to the printer, the printer issues an Xon command to the DTE. As the print buffer becomes full (at approx.90%), the printer issues an Xoff command that stops transmitting data (until the printer catches up). When the print buffer becomes almost empty (at approx. 20%) the printer issues a Xon command. This process continues until the complete document has been printed.
Software Null Modem
Since we are using software to control the data flow, we can eliminate a few of the control lines used in the Hardware Null Modem cable. In its simplest form, the Null Modem cable consists of SGND, with the TXDs & RXDs crossed.
Usually, we find that we have to add a few control lines to fool the DTE's hardware. There is no standard Software Null Modem configuration for Xon/Xoff: the exact connection will vary from device manufacturer to device manufacturer.
Terminals & PCs
Terminals are considered dumb devices: they can only display data on the screen and input data from a keyboard. They communicate with a mainframe or minicomputer that does the work. Terminals don't have disk drives for storing files, and they are missing RAM for running programs. Terminals cannot work by themselves. They are an extension of the mainframe or minicomputer's display and keyboard.
PCs have microprocessors that are their "smarts" or "brains." The microprocessors can do number crunching and work. PCs have disk drives for storage and RAM for running programs: they are stand-alone devices.
The purpose of communication programs--like Procomm Plus, Kermit, PCLink, or Quicklink II--is to turn your PC into a terminal. The result is the computer world's equivalent of a lobotomy!
If this section was helpful, why not donate to further development?