Specifications
Chapter 1 – Introduction
Multi-Tech Systems, Inc. AT Commands for EDGE Modems (S000371B) 16
1.6 Serial Interface Flow Control
Flow control is essential to prevent loss of data or avoid errors when, in a data or fax 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.
During Multiplex mode (AT+CMUX) it is recommended to use hardware flow control.
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 High Watermark is reached, CTS is set inactive until the transfer from the buffer has
completed. When the Low Watermark is passed, CTS goes active again.
To achieve smooth data flow, ensure that the RTS/CTS lines are present on your application platform. The
application should include options to enable RTS/CTS handshake with the GSM engine. This needs to be done with
the AT command AT\Q3 - it is not sufficient to set RTS/CTS handshake in the used Terminal program only.
The default setting of the GSM engine 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 the GSM engine was
switched off.
AT\Q has no read command. To verify its current setting, simply check the settings of the active profile with AT&V.
Often, fax programs run an intialization procedure when started up. The intialization commonly includes enabling
RTS/CTS hardware handshake, eliminating the need to set AT\Q3 once again. However, before setting up a CSD
call, you are advised to check that RTS/CTS handshake is set.
RTS/CTS hardware handshake must also be set if you want to take advantage of the CYCLIC SLEEP modes.
For further details refer to AT+CFUN.
1.7 Unsolicited Result Code Presentation
URC stands for Unsolicited Result Code and is a report message issued by the ME without being requested by the
TE; e.g., a URC is issued automatically when a certain event occurs. Hence, a URC is not issued as part of the
response related to an executed AT command.
Typical events leading to URCs are incoming calls (“RING”), waiting calls, received short messages, changes in
temperature, network registration etc.
A list of all URCs can be found in Section 20.7, Summary of Unsolicited Result Codes (URC).
To announce a pending URC transmission the ME will do the following:
• The ME activates its RING line (logic “1”) for one second; i.e., the line changes to physical “Low” level. This
allows the TE to stay in power saving mode until an ME-related event requests service. If several URCs occur
conincidentally or in quick succession, each URC triggers the RING line independently, although the line will not
be activated between each URC. As a result, the RING line may stay low for more than one second.
If an incoming call is answered within less than one second (with ATA or if autoanswering is set to ATSO=1, then
the RING line will be deactivated earlier.
The “^SHUTDOWN” URC will not activate the RING line.
• If the AT command interface is busy a “BREAK” will be sent immediately but the URC will not be issued until the
line is free. This may happen if the URC is pending in the following cases:
∗ During the processing of an AT command (i.e., the time after the TE echoes back the first character “A” of
an AT command just sent by itself until the ME responds with “OK” or “ERROR”).
∗ During a data call.
Please note that AT command settings may be necessary to enable in-band signaling; e.g., refer to
AT+CMER or AT+CNMI.
It is strongly recommended to use the multiplex mode to map logical communication channels onto the serial line of
the Multi-Tech wireless modem, for details refer to [5] and AT command AT+CMUX. Doing so it is possible to use one
channel to still process URCs while having a data call active on another.