Serial Interface Flow Control; Software Flow Control (Xon/Off Handshake); Hardware Flow Control (Rts/Cts Handshake) - Multi-Tech MultiModem EDGE Reference Manual

1.6 Serial Interface Flow Control

Flow control is essential to prevent loss of data or avoid errors when, in a data call, the sending device is transferring
data faster than the receiving side is ready to accept. When the receiving buffer reaches its capacity, the receiving
device should be capable to cause the sending device to pause until it catches up.
There are basically two approaches to regulate data flow: Software flow control and hardware flow control. The High
Watermark of the input/output buffer should be set to approximately 60% of the total buffer size. The Low Watermark
is recommended to be about 30%. The data flow should be stopped when the capacity rises close to the High
Watermark and resumed when it drops below the Low Watermark. The time required to cause stop and go results in
a hysteresis between the High and Low Watermarks.

1.6.1 Software Flow Control (XON/OFF Handshake)

Software flow control sends different characters to stop (XOFF, decimal 19) and resume (XON, decimal 17) data flow.
The only advantage of software flow control is that three wires would be sufficient on the serial interface.

1.6.2 Hardware Flow Control (RTS/CTS Handshake)

Hardware flow control sets or resets the RTS/CTS wires. This approach is faster and more reliable, and therefore,
the better choice. When the HWM is reached, CTS is set inactive. When the LWM is passed, CTS goes active again.
To achieve smooth data flow, ensure that the RTS/CTS lines are present on your application platform.
Configuring Hardware Flow Control
•
Hardware flow control must be set on both sides: with AT\Q3 or AT+IFC in the ME and an equivalent RTS/CTS
handshake option in the host application.
• The default setting of the ME is AT\Q0 (no flow control) which must be altered to AT\Q3 (RTS/CTS hardware
handshake on). The setting is stored volatile and must be restored each time after rebooting the ME.
•
AT\Q has no read command. To verify the current setting of AT\Q, simply check the settings of the active profile
with AT&V.
Buffer Design Considerations
•
The serial interface (ASC0) uses two buffers, one for the uplink and one for the downlink. Each buffer has a
capacity of minimum 1024 bytes.
•
Uplink direction (where ME is receiving data from host application):
CTS control is based on the filling level of the ME's receive buffer. When the application detects that CTS is
being deactivated it must instantly stop sending data to the ME's receive buffer. But still, after deactivation of
CTS, the receive buffer of the ME can accept another 512 bytes.
•
Downlink direction (where ME is sending data to host application):
The transmit buffer of the ME can hold at least 1024 bytes. After deactivation of RTS the ME sends max. 2 more
bytes and then stops transferring data to the application.
The maximum time RTS can be kept inactive without losing data is determined by the buffer size and the
maximum possible over-the-air data rate. In any case, the local data rate between DCE and DTE (AT+IPR)
should be set to a value higher than the maximum possible over-the-air data rate.
•
Buffer size recommended for the host application:
Just like the ME, the host application should include send and receive buffers for each serial interface. To handle
large amounts of data at high speed a buffer capacity of 1024 bytes is recommended. If the host application is
designed mainly for one direction (uplink or downlink) a lower buffer size will do for the direction where less data
is transferred.
In fact, the optimal size of the host application buffers is a matter of finding the balance between the amount of
data, data throughput, and reaction time of the application when handling the buffer, processor performance and
available memory. To give an example, a small buffer size (such as 256 bytes) increases the frequency of
deactivating RTS/CTS and the frequency of flushing the buffer, thus diminishing the efficiency of the application.
Also, please consider that RTS/CTS flow control cannot stop the data stream coming from the network, e.g.
in a GPRS or fax connection. So the lack of appropriate hardware flow control increases the risk of losing data
packets if, like in the case of UDP, the connection protocol has no or only minimum error handling functions.
Other network protocols are using high level flow control mechanisms. For example, to prevent loss of data
the TCP protocol uses retransmission algorithms.
Multi-Tech Systems, Inc. AT Commands for EDGE Modems (S000371G)
Chapter 1 – Introduction
15