7 unsolicited result code presentation, Unsolicited result code presentation – Siemens TC63 User Manual
Page 27
TC63 AT Command Set
1.7 Unsolicited Result Code Presentation
s
TC63_ATC_V00.490
Page 27 of 501
5/24/05
Confidential / Draft - Do not copy
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"), waiting calls, received short messages, changes in
temperature, network registration etc.
A list of all URCs can be found in Section
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
or if autoanswering is set to
the RING line will be deactivated earlier.
The "
" 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
.
It is strongly recommended to use the multiplex mode to map logical communication channels onto the serial line
of the TC63, for details refer to
and AT command
. 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
), or needs to be
activated every time you reboot the ME. Several URCs are not user definable, such as "
",
If autobauding is enabled (as factory default mode or set with
=0), URCs generated after restart will be
output with 57600 bps until the ME has detected the current bit rate. The URCs "
<text>", however, are not presented at all. For details please refer to Section
. To avoid prob-
lems we recommend to configure a fixed bit rate rather than using autobauding.
1.7.1
Communication between Customer Application and TC63
Leaving hardware flow control unconsidered the Customer Application (TE) is coupled with the TC63 (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 TC63 starts sending an URC. This will probably 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 TC63 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 TC63 using activated echo (
1), i.e. the TC63 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.