Table of Contents
Advertisement
MC55 AT Command Set
1.7 Unsolicited Result Code Presentation
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, 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"), received SMs, changing temperature, status of the
battery etc.
A summary of all URCs is given in chapter
To announce a pending URC transmission the ME will do the following:
•
Activates its Ring line (logic "1") for one second, i.e. the line changes to physical "Low" level. This allows the
TE to enter power saving mode until ME related events request service.
•
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
-
while an AT command is being processed, i.e. during the time from sending the first character "A" of an
AT command by the TE until the ME has responded with "OK" or "ERROR", or
-
during a data call.
Please note that AT command settings may be necessary to enable in-band signaling, e.g. refer to
or
.
AT+CNMI
It is strongly recommended to use the multiplex mode to map logical communication channels onto the serial line
of the MC55, for details refer to
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 an URC. Depending on the
AT command, the URC presentation mode can be saved to the user defined profile (see
activated every time you reboot the ME. Several URCs are not user definable, such as "^SYSSTART",
"^SYSSTART <text>", "
^SHUTDOWN
Result Codes (URC)
If autobauding is enabled (as factory default mode or set with
output with 57600 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 Chapter 4.7.1. To avoid problems we rec-
ommend to configure a fixed bit rate rather than using autobauding.
1.7.1
Communication between Customer Application and MC55
Leaving hardware flow control unconsidered the Customer Application (TE) is coupled with the MC55 (ME) via
a receive and a transmit line.
Since both lines are driven by independent devices collisions may (and will) happen, i.e. while the TE issues an
AT command the MC55 starts sending an URC. This probably will lead to the TE's misinterpretation 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 MC55 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 MC55 using activated echo (
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 over both the receive and the transmit paths. This way no URC can be issued by the MC55 in between.
MC55_ATC_V01.05
Confidential / Released
Summary of Unsolicited Result Codes (URC)
[5]
and AT command
" and the Fax Class 2 URCs listed in Chapter
.
Page 27 of 469
. Doing so it is possible to use one channel to still
AT+CMUX
=0), URCs generated after restart will be
AT+IPR
1), i.e. the MC55 echoes characters
ATE
s
m
obile
.
AT+CMER
), or needs to be
AT&W
Summary of Unsolicited
2/10/04
Advertisement
Table of Contents
