Product is deemed accepted by recipient and is provided without interface to recipient’s products. The documentation and/or product are provided for testing, evaluation, integration and information purposes. The documentation and/or product are provided on an “as is” basis only and may contain deficiencies or inadequacies. The
documentation and/or product are provided without warranty of any kind, express or implied. To the maximum
extent permitted by applicable law, Siemens further disclaims all warranties, including without limitation any implied warranties of merchantability, completeness, fitness for a particular purpose and non-infringement of thirdparty rights. The entire risk arising out of the use or performance of the product and documentation remains with
recipient. This product is not intended for use in life support appliances, devices or systems where a malfunction
of the product can reasonably be expected to result in personal injury. Applications incorporating the described
product must be designed to be in accordance with the technical specifications provided in these guidelines. Failure to comply with any of the required procedures can result in malfunctions or serious discrepancies in results.
Furthermore, all safety instructions regarding the use of mobile technical systems, including GSM products,
which also apply to cellular phones must be followed. Siemens or its suppliers shall, regardless of any legal theory upon which the claim is based, not be liable for any consequential, incidental, direct, indirect, punitive or other
damages whatsoever (including, without limitation, damages for loss of business profits, business interruption,
loss of business information or data, or other pecuniary loss) arising out the use of or inability to use the documentation and/or product, even if Siemens has been advised of the possibility of such damages. The foregoing
limitations of liability shall not apply in case of mandatory liability, e.g. under the German Product Liability Act, in
case of intent, gross negligence, injury of life, body or health, or breach of a condition which goes to the root of
the contract. However, claims for damages arising from a breach of a condition, which goes to the root of the
contract, shall be limited to the foreseeable damage, which is intrinsic to the contract, unless caused by intent or
gross negligence or based on liability for injury of life, body or health. The above provision does not imply a
change on the burden of proof to the detriment of the recipient. Subject to change without notice at any time. The
interpretation of this general note shall be governed and construed according to German law without reference
to any other substantive law.
AC75 AT Command Set
01.002
October 30, 2006
AC75_ATC_V01.002
Confidential / Released
Copyright
Transmittal, reproduction, dissemination and/or editing of this document as well as utilization of its contents and
communication thereof to others without express authorization are prohibited. Offenders will be held liable for
payment of damages. All rights created by patent grant or registration of a utility model or design patent are reserved.
Figure 15.3:SIM usage states of SAP server............................................................................................... 416
Figure 15.4:SIM usage states of SAP client ................................................................................................ 417
Figure 18.1:Audio programming model for AC75 Module............................................................................ 456
Figure 19.1:Formula for calculating the delay.............................................................................................. 498
Figure 19.2:Delay time on I²C after Write .................................................................................................... 498
Figure 19.4:SPI modes selectable on SPI ................................................................................................... 499
Figure 19.3:Delay time on I²C after Read .................................................................................................... 499
AC75_ATC_V01.002Page 13 of 56910/30/06
Confidential / Released
AC75 AT Command Set
1. Introduction
s
1.Introduction
1.1Scope of the document
This document presents the AT Command Set for the Siemens Cellular Engine
AC75 Release 01.002.
Before using the Cellular Engine or upgrading to a new firmware version please read the latest product information provided in the Release Notes [1].
More information is available at the Siemens Website: http://www.siemens.com/wm
.
AC75_ATC_V01.002Page 14 of 56910/30/06
Confidential / Released
AC75 AT Command Set
1.2 Related documents
s
1.2Related documents
[1] AC75 Release Notes, Version 01.002
[2] AC75 Hardware Interface Description, Version 01.002
[3] AC75 Java User's Guide
[4] Remote-SAT User's Guide
[5] GPRS Startup User's Guide
[6] Multiplexer User's Guide
[7] Multiplex Driver Developer's Guide for Windows 2000 and Windows XP
[8] Multiplex Driver Installation Guide for Windows 2000 and Windows XP
[9] Application Note 02: Audio Interface Design
[10] Application Note 16: Updating AC75 Firmware
[11] Application Note 17: Over-The-Air Firmware Update
[12] Application Note 24: Application Developer's Guide
[13] Application Note 22: Using TTY / CTM equipment with AC75
[14] SIM Access Profile Interoperability Specification (Revision 1.0), issued by the Bluetooth Special Interest
Group
[15] ISO/IEC10646: "Universal Multiple-Octet Coded Character Set (UCS)"; UCS2, 16 bit coding
[16] ITU-T Recommendation V.24: List of definitions for interchange circuits between data terminal equipment
(DTE) and data circuit-terminating equipment (DCE)
[17] ITU-T Recommendation V.250: Serial asynchronous automatic dialling and control
[18] 3GPP TS 100 918/EN 300 918 (GSM 02.04): General on supplementary services
[19] 3GPP TS 100 907 (GSM 02.30): Man-Machine Interface (MMI) of the Mobile Station (MS)
[20] 3GPP TS 23.038 (GSM 03.38): Alphabets and language specific information
[21] 3GPP TS 27.005 (GSM 07.05): Use of Data Terminal Equipment - Data Circuit terminating Equipment (DTE
- DCE) interface for Short Message Service (SMS) and Cell Broadcast Service (CBS)
[22] 3GPP TS 27.007 (GSM 07.07): AT command set for User Equipment (UE)
[23] 3GPP TS 27.060 (GSM 07.60): Mobile Station (MS) supporting Packet Switched Services
[24] 3GPP TS 51.011 (GSM 11.11): Specification of the Subscriber Identity Module - Mobile Equipment (SIM -
ME) interface
[25] 3GPP TS 11.14 (GSM 11.14): Specification of the SIM Application Toolkit for the Subscriber Identity Module
- Mobile Equipment (SIM - ME) interface
[26] 3GPP TS 22.101 (GSM 22.101): Service principles
[27] Common PCN Handset Specification (CPHS) v4.2
[28] USB.ORG: www.usb.org/developers/docs/USB_LANGIDs.pdf
AC75_ATC_V01.002Page 15 of 56910/30/06
Confidential / Released
AC75 AT Command Set
1.3 Document conventions
s
1.3Document conventions
Throughout the document, the GSM engines are referred to as ME (Mobile Equipment), MS (Mobile Station), TA
(Terminal Adapter), DCE (Data Communication Equipment) or facsimile DCE (FAX modem, FAX board).
To control your GSM engine you can simply send AT Commands via its serial interface. The controlling device
at the other end of the serial line is referred to as TE (Terminal Equipment), DTE (Data Terminal Equipment) or
plainly 'the application' (probably running on an embedded system).
All abbreviations and acronyms used throughout this document are based on the GSM specifications. For definitions please refer to TR 100 350 V7.0.0 (1999-08), (GSM 01.04, version 7.0.0 release 1998).
1.3.1Quick reference table
Each AT command description includes a table similar to the example shown below. The table is intended as a
quick reference to indicate the following functions:
PIN:Is the AT command PIN protected?
+Yes
-No
±Usage is dependent on conditions specified for the command, or not all command types are PIN
protected (for example write command PIN protected, read command not).
Note: The table provided in Section 23.3, Available AT Commands and Dependency on SIM
PIN uses the same symbols.
ASC0:Is the AT command supported on the first physical serial interface ASC0?
+Yes
-No
ASC1:Is the AT command supported on the second physical serial interface ASC1?
+Yes
-No
USB:Is the AT command supported on the USB interface?
+Yes
-No
MUXn: Is the AT command usable on the Multiplexer channels MUX1, MUX2, MUX3?
+Yes
-No
±AT command is usable, but under the restrictions specified in the section related to the command.
Note: The columns MUX1, MUX2 and MUX3 are relevant only when the GSM engine operates in Mul-
tiplexer mode, that is, when the first physical serial interface is partitioned into 3 virtual channels
by using the Multiplexer protocol. Usage is the same on ASC0 and MUX1.
4
+Yes
-No
±In AIRPLANE mode, not all described functions are available. For example, the test or read com-
Charge: Is the AT command supported in CHARGE ONLY mode?
+Yes
-No
±AT command is usable, but under the restrictions specified in the section related to the command.
Last:If commands are concatenated, this AT command must be the last one.
+Yes
-No
Note: See also Section 1.4, AT Command Syntax for details on concatenated AT commands.
Is the AT command supported in AIRPLANE mode?
mand is usable, the write or execute command is not. Furthermore, only some of the listed
parameters can be changed in AIRPLANE mode. A typical example is AT^SCFG that controls different features.
Example:
PIN ASC0 ASC1 USB MUX1 MUX2 MUX3 Charge 4 Last
-+++±±±+--
AC75_ATC_V01.002Page 16 of 56910/30/06
Confidential / Released
AC75 AT Command Set
1.3 Document conventions
1.3.2Superscript notation for parameters and values
Table 1.1: Symbols used to mark the type of parameters
Parameter typeMeaning
<param>
<param>
Table 1.2: Symbols used to indicate the correlations with other commands
Parameter optionMeaning
<param>
<param>
<param>
<param>
Table 1.3: Symbols used to mark different types of default values of parameters
(num)
(str)
(&W)
(&V)
(ˆSNFW)
(+CSCS)
Parameter value must be numeric type
Parameter value must be string type
Parameter value will be stored with AT&W
Parameter value will be displayed with AT&V
Parameter value will be stored with AT^SNFW
Parameter value has to be (is) coded according to current setting of <chset> (see
AT+CSCS for details)
s
Value optionMeaning
[x]Default value: if the parameter is omitted, the value 'x' will be assumed
(&F)
x
(P)
x
(D)
x
Factory default value, will be restored to 'x' with AT&F
Powerup default value of a parameter which is not stored at power down
Delivery default value of a parameter which cannot be restored automatically
AC75_ATC_V01.002Page 17 of 56910/30/06
Confidential / Released
AC75 AT Command Set
1.4 AT Command Syntax
s
1.4AT Command Syntax
The "AT" or "at" prefix must be set at the beginning of each command line. To terminate a command line enter
<CR>. Commands are usually followed by a response that includes "<CR><LF><response><CR><LF>". Through-
out this document, only the responses are presented,
Table 1.4: Types of AT commands and responses
AT command typeSyntaxFunction
Test commandAT+CXXX=?The mobile equipment returns the list of parameters and value
ranges set with the corresponding Write command or by internal
processes.
Read commandAT+CXXX?This command returns the currently set value of the parameter or
•Optional parameters are enclosed in square brackets. If optional parameters are omitted, the current settings
are used until you change them.
•Optional parameters or subparameters can be omitted unless they are followed by other parameters. If you
want to omit a parameter in the middle of a string it must be replaced by a comma. See also example 1.
•A parameter value enclosed in square brackets represents the value that will be used if an optional parameter
is omitted. See also example 2.
•When the parameter is a character string, e.g. <text> or <number>, the string must be enclosed in quotation
marks, e.g. "Charlie Brown" or "+49030xxxx". Symbols in quotation marks will be recognized as strings.
•All spaces will be ignored when using strings without quotaton marks.
•It is possible to omit the leading zeros of strings which represent numbers.
•If an optional parameter of a V.250 command is omitted, its value is assumed to be 0.
Example 1: Omitting parameters in the middle of a string
AT+CCUG?
+CCUG: 1,10,1
OK
AT+CCUG=,9
OK
AT+CCUG?
+CCUG: 1,9,1
OK
Example 2: Using default parameter values for optional parameters
Query current setting
Set only the middle parameter
Query new setting
AT+CFUN=7,0
OK
AT+CFUN?
+CFUN: 7
OK
AT+CFUN=
OK
+CFUN: 1
OK
AC75_ATC_V01.002Page 18 of 56910/30/06
Confidential / Released
Activate CYCLIC SLEEP mode, don't reset ME
Query ME mode
Set ME back to normal (default parameters: 1,0)
AC75 AT Command Set
1.4 AT Command Syntax
s
1.4.2Combining AT commands on the same command line
You may enter several AT commands on the same line. This eliminates the need to type the "AT" or "at" prefix
before each command. Instead, it is only needed once at the beginning of the command line. Use a semicolon
as command delimiter.
The table below lists the AT commands you cannot enter together with other commands on the same line. Otherwise, the responses may not be in the expected order.
AT command typeComment
V.250 commandswith FAX commands (Prefix AT+F)
GSM 7.07 commandswith Siemens commands, Prefix AT^S)
GSM 7.05 commands (SMS)To be used standalone
Commands starting with AT&To be used standalone
AT+IPRTo be used standalone
Note: When concatenating AT commands please keep in mind that the sequence of processing may be different
from the sequential order of command input. Therefore, if the consecutive order of the issued commands and
the associated responses is your concern, avoid concatenating commands on the same line.
AC75_ATC_V01.002Page 19 of 56910/30/06
Confidential / Released
AC75 AT Command Set
1.5 Supported character sets
s
1.5Supported character sets
The ME supports two character sets: GSM 03.38 (7 bit, also referred to as GSM alphabet or SMS alphabet) and
UCS2 (16 bit, refer to ISO/IEC 10646). See AT+CSCS for information about selecting the character set. Character
tables can be found below.
Explanation of terms
•International Reference Alphabet (IRA)
IRA means that one byte is displayed as two characters in hexadecimal format. For example, the byte 0x36
(decimal 54) is displayed as "36" (two characters). IRA is used here for input 8-bit or 16-bit data via terminal
devices using text mode. This means only characters 'A'..F','a'..'f' and '0'..'9' are valid.
•Escape sequences
The escape sequence used within a text coded in the GSM default alphabet (0x1B) must be correctly interpreted by the TE, both for character input and output. To the module, an escape sequence appears like any
other byte received or sent.
•Terminal Adapter (TA)
TA is an equivalent to Mobile Equipment (ME) which stands for the GSM module described here. It uses GSM
default alphabet as its character set.
•Terminal Equipment (TE)
TE is the device connected to the TA via serial interface. In most cases TE is an ANSI/ASCII terminal that
does not fully support the GSM default alphabet, for example MS Hyperterminal.
•TE Character Set
The character set currently used by Terminal Equipment is selected with AT+CSCS.
•Data Coding Scheme (dcs)
DCS is part of a short message and is saved on the SIM. When writing a short message to the SIM in text
mode, the dcs stored with AT+CSMP is used and determines the coded character set.
The behavior when encountering characters that are not valid characters of the supported alphabets is undefined.
Due to the constraints described below it is recommended to prefer the USC2 alphabet in any external application.
If the GSM alphabet is selected all characters sent over the serial line (between TE and TA) are in the range from
0 to 127 (7 Bit range). CAUTION: ASCII alphabet (TE) is not GSM alphabet (TA/ME) !
Several problems resulting from the use of GSM alphabet with ASCII terminal equipment:
•"@" character with GSM alphabet value 0 will terminate any C string! This is because the 0 is defined as C
string end tag. Therefore, the GSM Null character may cause problems on application level when using a 'C'function as "strlen()". This can be avoided if it is represented by an escape sequence as shown in the table
below.
By the way, this may be the reason why even network providers often replace "@"with "@=*" in their SIM
application.
•Other characters of the GSM alphabet are misinterpreted by an ASCII terminal program. For example, GSM
"ö" (as in "Börse") is assumed to be "|" in ASCII, thus resulting in "B|rse". This is because both alphabets mean
different characters with values hex. 7C or 00 and so on.
•In addition, decimal 17 and 19 which are used as XON/XOFF control characters when software flow control
is activated, are interpreted as normal characters in the GSM alphabet.
When you write characters differently coded in ASCII and GSM (e.g. Ä, Ö, Ü), you need to enter escape
sequences. Such a character is translated into the corresponding GSM character value and, when output later,
the GSM character value can be presented. Any ASCII terminal then will show wrong responses.
AC75_ATC_V01.002Page 20 of 56910/30/06
Confidential / Released
AC75 AT Command Set
1.5 Supported character sets
Table 1.5: Examples for character definitions depending on alphabet
CAUTION: Often, the editors of terminal programs do not recognize escape sequences. In this case, an escape
sequence will be handled as normal characters. The most common workaround to this problem is to write a script
which includes a decimal code instead of an escape sequence. This way you can write, for example, short messages which may contain differently coded characters.
GSM character
hex. value
Corresponding
ASCII character
ASCII
Esc sequence
Hex Esc
sequence
AC75_ATC_V01.002Page 21 of 56910/30/06
Confidential / Released
AC75 AT Command Set
1.5 Supported character sets
s
1.5.1GSM alphabet tables and UCS2 character values
This section provides tables for the GSM 03.38 alphabet supported by the ME. Below any GSM character find
the corresponding two byte character value of the UCS2 alphabet.
(For related mapping definition see: http://www.unicode.org/Public/MAPPINGS/ETSI/GSM0338.TXT)
Figure 1.1: Main character table of GSM 03.38 alphabet
1) This code is an escape to the following extension of the 7 bit default alphabet table.
2) This code is not a printable character and therefore not defined for the UCS2 alphabet. It shall be treated as the accompanying control character.
3) As the standard GSM alphabet does not provide a backspace functionality the AC75 is designed to use the GSM character 08 (hex 0x08) as backspace. This allows the user to easily erase the last character when using an ASCII terminal. On
the other hand, this solution requires entering the escape sequence \08 for writing the "ò" character in GSM alphabet.
AC75_ATC_V01.002Page 22 of 56910/30/06
Confidential / Released
AC75 AT Command Set
1.5 Supported character sets
s
Figure 1.2: Extension character table of GSM 03.38 alphabet
1) This code value is reserved for the extension to another extension table. On receipt of this code, a receiving entity shall
display a space until another extension table is defined.
2) This code represents the EURO currency symbol. The code value is the one used for the character 'e'. Therefore a receiving entity which is incapable of displaying the EURO currency symbol will display the character 'e' instead.
3) This code is defined as a Page Break character and may be used for example in compressed CBS messages. Any mobile
which does not understand the 7 bit default alphabet table extension mechanism will treat this character as Line Feed.
AC75_ATC_V01.002Page 23 of 56910/30/06
Confidential / Released
AC75 AT Command Set
1.5 Supported character sets
In the event that an MS receives a code where a symbol is not represented in Figure 1.2, Extension character
table of GSM 03.38 alphabet the MS shall display the character shown in the main default 7 bit alphabet table
(see Figure 1.1, Main character table of GSM 03.38 alphabet).
s
1.5.2UCS2 and GSM data coding and conversion for SMS text mode
This section provides basic information on how to handle input and output character conversion for SMS text
mode and Remote-SAT if internal (TA) and external (TE) character representation differ, i.e. if the Data Coding
Scheme and the TE character use different coding.
1.5.2.1Implementing output of SIM data to Terminal (direction TA to
TE)
Used character setDCS = 7 bit
GSM
GSMCase 1
GSM (1:1)
UCS2Case 4
GSM to IRA (1:4)
Note: The ratio of SIM bytes to output bytes is given in parentheses.
Case 1
Every GSM character is sent to the TE as it is (8-bit value with highest bit set to zero).
Example: 47'H, 53'H, 4D'H → 47'H, 53'H, 4D'H, displayed as "GSM"
Case 2
Every data byte is sent to the TE as 2 IRA characters each representing a halfbyte.
Example: B8'H (184 decimal) → 42'H, 38'H, displayed as "B8"
Case 3
Every 16-bit UCS2 value is sent to the TE as 4 IRA characters.
Example: C4xA7'H (50343 decimal) → 43'H, 34'H, 41'H, 37'H, displayed as "C4A7"
Problem: An odd number of bytes leads to an error because there are always two bytes needed for each USC2
character
Case 4
Every GSM character is sent to the TE as 4 IRA characters to show UCS2 in text mode.
Example: 41'H ("A") → 30'H, 30'H, 34'H, 31'H, displayed as "0041"
DCS = 8 bit
Data
Case 2
8 bit to IRA (1:2)
Case 5
8 bit to IRA (1:4)
DCS = 16 bit
UCS2
Case 3
UCS2 to IRA (2:4)
Case 6
UCS2 to IRA (2:4)
Case 5
Every data byte is sent to the TE as IRA representation of UCS2 (similar to case 4).
Example: B2'H → 30'H, 30'H, 42'H, 32'H, displayed as "00B2"
Case 6
Every 16-bit value is sent to the TE as IRA representation of it. It is assumed that number of bytes is even.
Example: C3x46'H → 43'H, 33'H, 34'H, 36'H, displayed as "C346"
AC75_ATC_V01.002Page 24 of 56910/30/06
Confidential / Released
AC75 AT Command Set
1.5 Supported character sets
s
1.5.2.2Implementing input of Terminal data to SIM (direction TE to TA)
Used character setDCS = 7 bit
GSM
GSMCase 1
GSM (1:1)
UCS2Case 4
UCS2 to GSM (4:1)
Note: The ratio between the number of input characters and bytes stored on the SIM is given in parentheses.
Case 1
Every character is sent from TE to TA as GSM character (or ASCII with standard terminal emulation, e.g. Hyperterminal).
Character value must be in range from 0 to 127 because of 7-bit GSM alphabet.
To reach maximum SMS text length of 160 characters in 140 bytes space characters will be compressed on SIM.
This must be set using the parameter <dcs> of AT+CSMP (add 64).
Example: "ABCDEFGH" typed is sent and stored uncompressed as → 4142434445464748'H (stored compressed as 41E19058341E91'H)
Case 2
Every data byte is sent as 2 IRA characters.
Maximum text length is 280 IRA characters which will be converted into 140 bytes SMS binary user data
Example: "C8" typed is sent as 43'H, 38'H → stored as C8'H
Case 3
Every 16-bit value is sent as 4 IRA characters.
Maximum text length is 280 IRA characters which will be converted into 70 UCS2 characters (16-bit each)
Number of IRA characters must be a multiple of four because always 4 half bytes are needed for a 16-bit value
Example: "D2C8" typed is sent as 44'H, 32'H, 43'H, 38'H → stored as D2C8'H
DCS = 8 bit
Data
Case 2
IRA to 8 bit (2:1)
Case 5
UCS2 to 8 bit (4:1)
DCS = 16 bit
UCS2
Case 3
IRA to 16 bit (4:2)
Case 6
UCS2 to 16 bit (4:2)
Case 4
Every GSM character is sent as 4 IRA characters representing one UCS2 character.
Example: To store text "ABC" using UCS2 character set you have to type "004100420043".
This is sent as 30'H,30'H,34'H,31'H, 30'H,30'H,34'H,32'H, 30'H,30'H,34'H,33'H → detected as IRA representation of 3 UCS2 characters, converted to GSM character set and stored as 41'H, 42'H, 43'H.
Maximum input is 640 IRA characters repesenting 160 UCS2 characters when compression is active. These are
converted to 160 GSM 7-bit characters.
Without compression only 140 GSM characters can be stored which are put in as 560 IRA characters.
Values of UCS2 characters must be smaller than 80'H (128 decimal) to be valid GSM characters.
Number of IRA characters must be a multiple of four. Problems:
• "41" → Error, there are four IRA characters (two bytes) needed
• "0000" → Error, not an UCS2 character
• "4142" → Error, value of UCS2 character > 7F'H
• "008B" → Error, value of UCS2 character > 7F'H
This affects the maximum input length of a string)
Case 5
Every UCS2 character is sent as 4 IRA characters and is converted into two 8-bit values. This means that the
first two characters have to be '00'.
Example: UCS2 character 009F'H typed as "009F" is sent as 30'H,30'H,39'H,46'H → converted into 8-bit value
9F'H.
Maximum number of UCS2 characters is 140 which are represented by 560 IRA characters. Number of IRA characters must be a multiple of four.
Case 6
Every UCS2 character is sent as 4 IRA characters each and is converted into a 16-bit value again.
Example: UCS2 character 9F3A'H typed as "9F3A" is sent as 39'H,46'H,33'H,41'H → converted into 9F3A'H.
Maximum number of UCS2 characters is 70 which are represented by 280 IRA characters. Number of IRA characters must be a multiple of four.
Invalid UCS2 values must be prevented.
AC75_ATC_V01.002Page 25 of 56910/30/06
Confidential / Released
AC75 AT Command Set
1.6 Serial Interface Flow Control
s
1.6Serial 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 (HWM) of the input/output buffer should be set to approximately 60% of the total buffer size, the
Low Watermark (LWM) is recommended to be about 30%. The data flow should be stopped when the buffer
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.1Software 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.2Hardware 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.
•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.
Buffer design considerations
•Each serial interface (ASC0 and ASC1) of the AC75 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
AC75_ATC_V01.002Page 26 of 56910/30/06
Confidential / Released
AC75 AT Command Set
1.6 Serial Interface Flow Control
of data, data throughput, 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, fax applications usually repeat the transfer of faulty pages.
s
AC75_ATC_V01.002Page 27 of 56910/30/06
Confidential / Released
AC75 AT Command Set
1.7 Communication between Customer Application and AC75
s
1.7Communication between Customer Application and AC75
Leaving hardware flow control unconsidered the Customer Application (TE) is coupled with the AC75 (ME) via a
receive and a transmit line.
Since both lines are driven by independent devices collisions may (and will) happen. For example, if the TE
issues an AT command the AC75 starts sending a URC. This will probably cause the TE to misinterpret of the
URC being part of the AT command's response.
To avoid this conflict the following measures must be taken:
•If an AT command is finished (with "OK" or "ERROR") the TE shall always wait at least 100 milliseconds
before sending the next one.
This gives the AC75 the opportunity to transmit pending URCs and get necessary service.
Note that some AT commands may require more delay after "OK" or "ERROR" response, refer to the following
command specifications for details.
•The TE shall communicate with the AC75 using activated echo (ATE1), i.e. the AC75 echoes characters
received from the TE.
Hence, when the TE receives the echo of the first character "A" of the AT command just sent by itself it has
control both over the receive and the transmit paths.
AC75_ATC_V01.002Page 28 of 56910/30/06
Confidential / Released
AC75 AT Command Set
1.8 Unsolicited Result Code Presentation
s
1.8Unsolicited Result Code Presentation
URC stands for Unsolicited Result Code and is a report message issued by the ME without being requested by
the TE, i.e. 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 23.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 1 second, i.e. the RING line changes to the physical "Low" level.
This allows the TE to stay in power saving mode until an ME related event requests service.
If several URCs occur coincidently or in quick succession each URC triggers the RING line independently,
although the line will not be deactivated between each URC. As a result, the RING line may stay low for more
than 1 second.
If an incoming call is answered within less than 1 second (with ATA or if autoanswering is set to ATS0=1) than
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 AC75, for details refer to [6] 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.
For most of these messages, the ME needs to be configured whether or not to send a URC. Depending on the
AT command, the URC presentation mode can be saved to the user defined profile (see AT&W), or needs to be
activated every time you reboot the ME. Several URCs are not user definable, such as "^SYSSTART",
"^SYSSTART <text>", "^SHUTDOWN"
If autobauding is enabled (AT+IPR=0), URCs generated after restart will be output with 115200 bps until the ME
has detected the current bit rate. The URCs "^SYSSTART", "^SYSSTART <text>", however, are not presented
at all. For details please refer to Section 4.9.1, Autobauding. To avoid problems we recommend to configure a
fixed bit rate rather than using autobauding.
AC75_ATC_V01.002Page 29 of 56910/30/06
Confidential / Released
AC75 AT Command Set
1.9 Common PCN Handset Specification (CPHS)
s
1.9Common PCN Handset Specification (CPHS)
The ME provides features to implement a device following the prerequisites of the Common PCN Handset Specification (CPHS) Phase 2.
CPHS FeatureDescription/RemarksAT command
Alternate Line ServiceUsing two phone numbers with one SIM card.AT^SALS
Voice Message Waiting
Indication
Operator (Service provider) name from SIM
Network and Service Provider Lock
Call ForwardingGet and set diverted call status. Access specific Elementary
Customer Service Profile
(CSP)
Information numbersHierarchically structured service numbers phonebook on
Indicate the receipt of a short message coded as Voice Message Waiting Indicator as defined by the CPHS Phase 2
standard.
Read specific Elementary Files (6F14h, 6F18h) from SIM. AT+CRSM
Lock/Unlock an ME to specific HPLMN and service provider. AT+CLCK,
File (6F13h) from SIM.
Setting services and their menu entries depending on cus-
tomer profiles.
SIM according to CPHS 4.2 (mandatory).
AT^SIND,
AT+CMER, indicators
"vmwait1" and
"vmwait2"
(AT+CPIN)
AT+CCFC, AT+CRSM
AT+CRSM
AT+CRSM
AC75_ATC_V01.002Page 30 of 56910/30/06
Confidential / Released
Loading...
+ 539 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.