Wavecom GR64 Installation and operating instructions

A
PPLICATION NOTE
GR/GS64 UART Sleep Protocols
Reference:
W
I_DEV_Gx64_APN_001
Version: 001
Date: 2006/11/09

The information contained in this document is the proprietary information of Wavecom Inc.
The contents are confidential and any disclosure to persons other than the officers,
employees, agents or subcontractors of the owner or licensee of this document, without the
prior written consent of Wavecom Inc, is strictly prohibited.
Further, no portion of this publication may be reproduced, stored in a retrieval system, or
transmitted in any form or by any means, electronic or mechanical, including photocopying
and recording, without the prior written consent of Wavecom Inc, the copyright holder.
Third Edition (August 2006)
Wavecom Inc publishes this manual without making any warranty as to the content contained
herein. Further Wavecom Inc reserves the right to make modifications, additions and
deletions to this manual due to typographical errors, inaccurate information, or
improvements to programs and/or equipment at any time and without notice. Such changes
will, nevertheless be incorporated into new editions of this manual.
All rights reserved.
© Wavecom Inc, 2006
Printed in US
APPLICATION NOTE
GR/GS64 UART Sleep Protocols
Page: 2/26
This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable

Revision History
Edition Change Information
First First Edition
Second Implemented document review comments
Third Added description of “three-wire” sleep mode and wake-up
APPLICATION NOTE
GR/GS64 UART Sleep Protocols
Page: 3/26
This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable

Contents
1Introduction ............................................................................................ 6
2Standby Handshaking ............................................................................. 7
2.1 UART 1 SIGNAL DESCRIPTION........................................................................................ 7
2.1.1 DESCRIPTION ..................................................................................................... 7
2.1.2 UART SIGNALS REQUIRED FOR IMPLEMENTING SLEEP CONTROL........................... 8
2.1.2.1 DTM1 (Data To Module (Wireless CPU®)) .................................................... 9
2.1.2.2 DFM1 (Data From Module (Wireless CPU®)) ................................................. 9
2.1.2.3 RTS1 (Request To Send)............................................................................. 9
2.1.2.4 CTS1 (Clear To Send)............................................................................... 10
2.1.2.5 DTR1 (Data Terminal Ready) .................................................................... 10
2.1.2.6 DSR1 (Data Set Ready) ............................................................................. 10
2.1.2.7 RI (Ring Indicator).................................................................................... 11
2.2 UART LOGIC ............................................................................................................... 11
2.3 SLEEP MODE ............................................................................................................... 11
2.4 TIMING DIAGRAMS...................................................................................................... 12
2.4.1 HOST INITIATED SLEEP ..................................................................................... 13
2.4.2 HOST INITIATED WAKE-UP ............................................................................... 14
2.4.3 WIRELESS CPU® INITIATED SLEEP....................................................................... 15
2.4.4 WIRELESS CPU® INITIATED WAKE-UP................................................................. 16
2.4.5 WIRELESS CPU® REPEATS ATTEMPTS TO INITIATE SLEEP..................................... 17
2.4.6 DSR1 TIMING ................................................................................................... 18
2.4.7 SLEEP MODE ENABLING AND DISABLING............................................................ 18
2.4.8 INCOMING MT EVENT DURING SLEEP ................................................................ 19
3Autonomous Standby............................................................................ 20
3.1 PURPOSE..................................................................................................................... 20
3.2 ENABLING AND DISABLING AUTONOMOUS STANDBY ................................................... 20
3.3 EVENTS THAT WAKE THE WIRELESS CPU®..................................................................... 20
3.4 WAKING THE WIRELESS CPU® USING AN AT COMMAND................................................ 21
3.5 THE INACTIVITY DELAY ............................................................................................... 22
APPLICATION NOTE
GR/GS64 UART Sleep Protocols
Page: 4/26
This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable

4Autonomous Standby and Embedded Applications................................ 23
5Examining Sleep Mode .......................................................................... 24
5.1 PURPOSE..................................................................................................................... 24
5.2 CURRENT CONSUMPTION ............................................................................................ 24
5.3 KEY CONSIDERATIONS ................................................................................................ 25
Table of Figures
Figure 1. Typical Host – Wireless CPU® UART1 interface .................................................... 8
Figure 2. Sequence of events from initial power-up to first sleep activation .................... 13
Figure 3. Host initiating wake-up to UARTs in sleep mode.............................................. 14
Figure 4. Wireless CPU® initiates sleep, Host initiates time-out period a ......................... 15
Figure 5. UARTs in sleep mode, Wireless CPU® initiates wake-up .................................... 16
Figure 6. Wireless CPU® attempts sleep initiation, Host fails to acknowledge................... 17
Figure 7. DSR functioning time periods........................................................................... 18
Figure 8. Asserting Ring Indicator from sleep mode........................................................ 19
APPLICATION NOTE
GR/GS64 UART Sleep Protocols
Page: 5/26
This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable

1Introduction
Low power operation is crucial for applications where power consumption must be
carefully controlled or limited. GR/GS64 Wireless CPU®s achieve significant power
savings by reducing clock rates or eliminating clocks to internal components during
idle periods. In the following descriptions, these reduced-clock idle periods are also
called standby or sleep mode. Your applications must cooperate with the Wireless
CPU® to achieve sleep mode and the best power savings. The purpose of this
Application Note is to describe the methods that your applications can use to enable
low power operation of the Wireless CPU®.
You can choose either of two methods—Standby Handshaking or Autonomous
Standby. Either method results in the same power savings. Standby Handshaking is
the preferred method when all UART signal lines are connected between the Host and
Wireless CPU® and embedded applications are not used. When enabled, the Host and
Wireless CPU® use modem control lines in addition to receive and transmit to
coordinate wake and sleep.
Autonomous Standby can be used where only transmit, receive and ground signals
are available between the Host and Wireless CPU®. This method provides power
savings in a fashion similar to the behaviour of the GR47 Wireless CPU®. Without full
modem control lines, however, the Host must wake the Wireless CPU® using repetitive
AT commands and wait for the Wireless CPU® to respond before issuing further
commands.
Autonomous Standby may also be enabled from embedded applications. Whether
enabled by AT command or the embedded application, any embedded application
delay function will result the Wireless CPU® entering sleep mode.
This Application Note is intended as a reference for integrators, as an aid to
understanding and implementing interface circuitry and applications. These notes are
written to be informative and helpful, but they are by no means definitive or
exhaustive in their content or suggestions.
Where example circuits are shown the reader should use discretion to determine the
suitability of the application. No liability is assumed by Wavecom for mistakes in the
content of this note, nor damage caused to Host applications as a result of
unqualified implementation.
APPLICATION NOTE
GR/GS64 UART Sleep Protocols
Page: 6/26
This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable

2Standby Handshaking
Standby Handshaking can be used when all UART signal lines are connected between
the Host and Wireless CPU®. This method cannot be used by embedded applications.
When enabled, the Host and Wireless CPU® use modem control lines in addition to
receive and transmit to coordinate wake and sleep.
2.1 UART 1 Signal Description
Function: Primary UART
Description: Asynchronous transmit and receive port for data communication
between Wireless CPU® and Host
Signal Name Connectivity Direction If not used
DTM1 [Host⇒Wireless CPU®] required
DFM1 [Wireless CPU®⇒Host] required
RTS1 [Host⇒Wireless CPU®] required
CTS1 [Wireless CPU®⇒Host] required
DTR1 [Host⇒Wireless CPU®] required (for Standby Handshaking)
DSR1 [Wireless CPU®⇒Host] required (for Standby Handshaking)
DCD1 [Wireless CPU®⇒Host] leave open circuit
RI [Wireless CPU®⇒Host] leave open circuit
2.1.1 Description
UART 1 is the primary communications port between the Host application and the
Wireless CPU®. The UART is compliant with NS 16C750, and may be used in
conjunction with the additional flow control signals.
The UART1 interface supports baud rates up to 115.2kbaud (for standard PC) to a
maximum 460.8kbaud. It supports autobauding for AT commands.
The UART 1 interface available on the GR/GS64 products has been extended using a
proprietary method to allow a special mechanism for enabling sleep (low power mode)
initiated by either the Host application of the Wireless CPU®, primarily to conserve
power when communication between the products is not necessary.
The GS/GR64 product possesses a second UART, which implements a subset of the
above signals. However, all references to UART signals in this document are related
to UART 1 only since this is the only UART through which the sleep protocol can be
APPLICATION NOTE
GR/GS64 UART Sleep Protocols
Page: 7/26
This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable

implemented. Although not every signal is explicitly referenced to UART 1 it is
nevertheless implicit.
All of the signals shown in the table above as
required need appropriate hardware
connectivity and software support in the Host application.
Figure 1. Typical Host – Wireless CPU® UART1 interface
2.1.2 UART Signals Required for Implementing Sleep Control
Data is transmitted serially between the Host and Wireless CPU®’s UARTs using data
lines. From the Wireless CPU®’s perspective there is a receive (data from the Host to
the Wireless CPU®) and a transmit (data from the Wireless CPU® to the Host) which
operate asynchronously at the same baud rate in a full-duplex method of data
exchange. Similarly, these signals are present in the Host’s UART. Because of the
confusion which exists when referring to these (identical) signals at both ends of the
interface, the GR/GS64 uses a signal naming convention to identify their purpose in
relation to the Wireless CPU®; data-to-Wireless CPU® (receive) and data-from-
Wireless CPU® (transmit). In a practical implementation of a UART, these are the only
mandatory signals required since these carry the information (commands, responses,
data packets, status, etc.), the primary function of the interface. However, additional
hardware flow-control is necessary to activate and manage the sleep function of the
GR/GS64 products.
Basic flow-control, the regulation of data back and forth, is often necessary to
regulate the rate and volume of data being exchanged, so as to allow processing of
the information and to avoid over-filling the data buffers. Flow-control can be
implemented through a special protocol embedded in the data itself (software flow
control). In the GR/GS64 hardware flow-control is provided by the request-to-send
(RTS) and clear-to-send (CTS) handshaking between the UART interfaces. These
signals are required for sleep control.
APPLICATION NOTE
GR/GS64 UART Sleep Protocols
Page: 8/26
This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable

A further level of flow-control is provided by the data-terminal-ready and data-set-
ready signals. These signals are instrumental in activating the sleep and wake-up
mechanisms.
The UART1 signals described in this document are referenced to the
GR/GS64 system connector. The signal amplitudes are defined in
the respective Integrators Manual. However, they are inverted in
polarity, and potentially smaller in amplitude with respect to an
RS232 implementation. This information is important to note since
the polarity of the signal at the user interface is crucially important,
and may undergo polarity reversal, depending upon the interface
implementation.
CAUTION
2.1.2.1 DTM1 (Data To Module (Wireless CPU®))
[Host⇒Wireless CPU®]
Input signal used to receive data sent from the Host UART to the Wireless CPU® UART.
The default setting of this line is high. AT+IPR can be used to select the baud rate for
this line. Auto baud is supported in AT command mode. This signal is inactive high,
active low at the GR/GS64 system connector interface.
2.1.2.2 DFM1 (Data From Module (Wireless CPU®))
[Wireless CPU®⇒Host]
Output signal used to send data from the Wireless CPU® UART to the Host UART.
The default setting of this line is high. AT+IPR can be used to select the baud rate for
this line. Auto baud is supported in AT command mode. This signal is inactive high,
active low at the GR/GS64 system connector interface.
2.1.2.3 RTS1 (Request To Send)
[Host⇒Wireless CPU®]
Input signal used to control data flow from the Host UART to the Wireless CPU® UART.
When hardware flow control is enabled, RTS1 is held low by the Host to indicate its
readiness to accept data from the Wireless CPU®. The Host raises the RTS1 high at
the GR/GS64 system connector interface to halt data flow from the Wireless CPU®, for
example when the Host’s UART buffer is full. In order to prevent loss of data, the
Wireless CPU® will not send data while RTS1 is held high. RTS1 is held high
immediately preceding, and during sleep mode.
APPLICATION NOTE
GR/GS64 UART Sleep Protocols
Page: 9/26
This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable

2.1.2.4 CTS1 (Clear To Send)
[Wireless CPU®⇒Host]
Output signal used to control data flow from the Host UART to the Wireless CPU®
UART.
When hardware flow control is enabled, CTS1 is held low by the Wireless CPU® to
indicate its readiness to accept data from the Host. The Wireless CPU® holds the
CTS1 line high to halt data flow from the Host, for example when the Wireless CPU®’s
UART buffer is full. In order to prevent loss of data, the Host must not send data
while CTS1 is held high. CTS1 is held high immediately preceding, and during sleep
mode.
2.1.2.5 DTR1 (Data Terminal Ready)
[Host⇒Wireless CPU®]
DTR1 is an input signal from the Host to indicate a desire to communicate.
DTR1 indicates that the Host is ready or waiting to communicate. When sleep mode is
enabled, DTR1 is used as a mechanism by the Host to request a transition to the sleep
state, or to wake the Wireless CPU® from its sleep state.
A logic low state on DTR1 signals the desire to communicate. A logic high signal
indicates a desire or acknowledgement to allow the sleep state. DTR1 remains high
during the period that the sleep state is active.
2.1.2.6 DSR1 (Data Set Ready)
[Wireless CPU®⇒Host]
DSR1 is an output signal from the Wireless CPU® to indicate a desire to communicate.
DSR1 indicates that the Wireless CPU® is ready or waiting to communicate. When
sleep mode is enabled, DSR1 is used as a mechanism by the Wireless CPU® to request
a transition to the sleep state, or to signal to the Host that it has awoken from its
sleep state.
A logic low state on DSR1 signals the desire to communicate. A logic high signal
indicates a desire or acknowledgement to allow the sleep state. DSR1 remains high
during the period that the sleep state is active.
Either the Wireless CPU® or the Host can request and initiate sleep
mode at any time. If the Host initiates sleep, the Wireless CPU® will
not necessarily assume a low-power state. The Wireless CPU®
power state is dependant on what active processes are ongoing.
NOTE
APPLICATION NOTE
GR/GS64 UART Sleep Protocols
Page: 10/26
This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable

2.1.2.7 RI (Ring Indicator)
[Wireless CPU®⇒Host]
Output signal used as an alert from the Wireless CPU® to the Host to request
attention.
The Ring Indicator is used to inform the Host that the Wireless CPU® has something to
communicate. The RI could be activated for
•an incoming voice call
•an incoming circuit switched data call
•an incoming packet switched data call
•an incoming SMS
A falling edge on RI indicates incoming call or message. The signal remains low for a
period of time before going high. RI follows normal Ring Indication protocols,
generating a 1 second low pulse which is repeated until answered or disconnected by
the base-station, except for an incoming SMS, in which case there will only be one
low transition.
Note that an incoming call or SMS may also have an unsolicited
message associated with it. The RI will be used even when the Host
has RTS set to stop data from the Wireless CPU®.
NOTE
RI indicator is not essential for the sleep mode function. It is however a
complimentary means to alert the Host of an event which requires attention.
2.2 UART Logic
The UART1 signals described in this document are referenced to the GR/GS64 system
connector. The signal amplitudes are CMOS levels. A logic high (inactive state) signal
is at VREF (as defined in the Integrators Manual). VREF may differ, depending upon
which variant of the GR/GS64 family you are using. Please refer to the Integrators
Manual for details of digital IO and its operating limits as they apply to your
application and the variant product you are using.
2.3 Sleep Mode
In order to conserve current, the GR/GS64 Wireless CPU® (and sometimes the Host)
will benefit from transitioning to a low power state. The GSM standard permits a
feature known as DRX (Discontinuous Reception), a paging mode adopted by mobile
stations (the GR/GS64 device in this case) in which the radio transceiver is only
required to ‘awaken’ for network paging events on a relatively low duty-cycle basis.
APPLICATION NOTE
GR/GS64 UART Sleep Protocols
Page: 11/26
This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable

This results in significant power reduction. Typically a DRX8 paging mode may
consume less than 2mA. This mode is often referred to as sleep mode.
In order to conserve the maximum amount of current, the UARTs (as well as other
normally active circuitry) also assume a low power state. The interface which controls
sleep in the GR/GS64 is the primary UART, through a handshake protocol between
two reciprocating signals.
The GR/GS64 sleep mode feature is enabled and disabled by using the AT command
AT*E2RS232. The factory default setting and the start-up default for this command is
for the UART not to support sleep mode handshaking. Sleep mode has to be enabled
by AT command each time the Wireless CPU® undergoes a power re-cycle.
Sleep mode can be negotiated when either the Host or the Wireless CPU® decides that
it no longer has any need to communicate with the other side. Either side can wake
up the UART interface when it has something communicate.
The two signals that drive entry into and exit out of this mode are DTR and DSR. DTR
is used by the Host to indicate that it wants to initiate sleep, or to acknowledge the
Wireless CPU®’s request to initiate sleep. Likewise, DSR is used by the Wireless CPU®
to indicate that it wants to initiate sleep, or an acknowledgement of the Host request
to initiate sleep.
If either UART requests entry in to sleep mode, the other UART must acknowledge the
request in a timely manner in order for sleep to be enacted. Sleep mode must not be
enacted until both UARTs have acknowledged the sleep mode request by the
appropriate DTR or DSR handshaking.
Before entering into sleep mode, the RTS and CTS signals should be set to indicate
that no data can be received by either UART, in order not to lose any data.
It is important to point out that even though this mode is called sleep mode, it is not
possible to accurately predict what the Wireless CPU® or Host will do in this mode,
since this is determined by network events and device configuration. The Host or
Wireless CPU® can enter a sustained sleep, where all activity is ceased, or it could
continue normal operation. The only requirement is that the UART interface lines
communicate the desire to sleep and that the DSR and DTR line can take the UART
interface back out of this mode.
The operating mode which specifically pertains to the ‘sleep’ mode described in this
document is also referred to as
Standby Handshaking in supplementary document
such as the GR64 & GS64 AT Command Manual.
2.4 Timing Diagrams
This section illustrates the interaction of the UART1 signal lines when entering and
exiting sleep mode.
APPLICATION NOTE
GR/GS64 UART Sleep Protocols
Page: 12/26
This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable

2.4.1 Host Initiated Sleep
This example shows a sequence of events from initial power-up of the Wireless CPU®
to the first sleep activation, in this case initiated by the Host UART.
Figure 2. Sequence of events from initial power-up to first sleep activation
Time Description
1 The Wireless CPU® is un-powered at this point, all UART1 signals are inactive.
2 The Wireless CPU® has completed its power-up cycle and all UART signals are
active. The UART interfaces are ready to communicate, as indicated by the
respective states of the hardware flow control lines.
3 The first serial data is sent from the Wireless CPU® to the Host.
4 The Host sends data to the Wireless CPU®, followed by a period of inactivity.
5 The Host requests sleep mode initiation by setting DTR1 & RTS1 signals high.
6 The Wireless CPU® acknowledges the request by setting DSR1 and CTS1 signals
high, thereby beginning the sleep period. The flow control lines will remain
inactive from this point onwards, until such time as a wake-up event is triggered.
APPLICATION NOTE
GR/GS64 UART Sleep Protocols
Page: 13/26
This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable

2.4.2 Host Initiated Wake-up
In this example the UARTs are in a sleep mode and the Host initiates a wake-up.
Figure 3. Host initiating wake-up to UARTs in sleep mode
Time Description
1 The UART interface is inactive, the Wireless CPU® and Host may be in a sleep (low
power) state at this point in time.
2 The Host initiates a wake-up request by asserting DTR1 & RTS1.
3 The Wireless CPU® acknowledges the wake-up request by asserting DSR1.
Generally, CTS1 would be asserted at the same instant. At this point both UART
interface are ready to accept data transfers, as indicated by the active states of their
respective hardware flow-control lines.
4 Data is sent by the Host.
5 Data is sent by the Wireless CPU®. Normal data flow can continue until such time as
the flow-control lines change their states, either to interrupt data flow temporarily
or to initiate another sleep request.
Sleep mode has to be enabled by the user before the sleep protocol
is affected. Each time power is re-cycled the Wireless CPU® will
default to sleep protocol OFF. In order to activate sleep protocol it
must be set to ON by using the AT Command AT*E2RS232 and
setting the appropriate <val>
NOTE
APPLICATION NOTE
GR/GS64 UART Sleep Protocols
Page: 14/26
This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable

2.4.3 Wireless CPU® Initiated Sleep
The example shows a similar situation to section 2.4.1, where the Wireless CPU® is
going through its initial power-up. After exchanging some data the Wireless CPU®
initiates sleep. The Host responds within the time-out period
a.
Figure 4. Wireless CPU® initiates sleep, Host initiates time-out period a
Time Description
1 The Wireless CPU® is un-powered at this point, all UART1 signals are inactive.
2 The Wireless CPU® has completed its power-up cycle and all UART signals are active.
The UART interfaces are ready to communicate, as indicated by the respective states
of the hardware flow control lines.
3 The first serial data is sent from the Wireless CPU® to the Host.
4 The Host sends data to the Wireless CPU®, followed by a period of inactivity.
5 The Wireless CPU® requests sleep mode initiation by de-asserting DSR1 & CTS1.
6 Within the request timeout period
a , the Wireless CPU® acknowledges the request by
setting DSR1 and CTS1 signals high, thereby beginning the sleep period. The flow
control lines will remain inactive from this point onwards, until such time as a wake-
up event is triggered.
The time-out period
a is 500ms max. If this period elapses with no
acknowledgement from the Host, the Wireless CPU® will wait for a
pre-defined period before making a further attempt to request
sleep mode initiation.
NOTE
APPLICATION NOTE
GR/GS64 UART Sleep Protocols
Page: 15/26
This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable

2.4.4 Wireless CPU® Initiated Wake-up
In this example the UART interfaces are in sleep mode and the Wireless CPU® initiates
a wake-up
.
Figure 5. UARTs in sleep mode, Wireless CPU® initiates wake-up
Time Description
1 The UART interface is inactive, the Wireless CPU® and Host may be in a sleep (low
power) state at this point in time.
2 The Wireless CPU® initiates a wake-up request by asserting DSR1. Generally CTS1
will also become active at the same instant.
3 The Wireless CPU® acknowledges the wake-up request by asserting DTR1 & RTS1.
At this point both UART interface are ready to accept data transfers, as indicated by
the active states of their respective hardware flow-control lines.
4 Data is sent by the Wireless CPU®.
5 Data is sent by the Host. Normal data flow can continue until such time as the flow-
control lines change their states, either to interrupt data flow temporarily or to
initiate another sleep request.
APPLICATION NOTE
GR/GS64 UART Sleep Protocols
Page: 16/26
This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable

2.4.5 Wireless CPU® Repeats Attempts to Initiate Sleep
In this example, the Wireless CPU® attempts to initiate sleep through the normal flow
control mechanism, but the Host fails to acknowledge within the time-out period for
repeated attempts.
Figure 6. Wireless CPU® attempts sleep initiation, Host fails to acknowledge
Time Description
1 A data transfer between the Host and the Wireless CPU® is completed.
2 The Wireless CPU® has nothing further to communicate to the Host and requests
sleep by de-assertion of DSR1 and CTS1. The Host does not acknowledge the
request before the time-out period
a (500ms) has expired and subsequently re-
asserts DSR1 and CTS1 for the programmable period
b .
3 The Wireless CPU® makes a second attempt to request sleep by de-assertion of
DSR1 and CTS1. The Host does not acknowledge the request before the time-out
period
a has expired and subsequently re-asserts DSR1 and CTS1 for the period b .
4 The Wireless CPU® makes a third attempt to request sleep by de-assertion of DSR1
and CTS1. Once again, the Host fails to acknowledge the request before the time-
out period
a has expired and subsequently re-asserts DSR1 and CTS1.
5 At this point three failed attempts have been made by the Wireless CPU® to initiate
sleep, so no further attempt is made (the status of standby handshake can be
queried with AT*E2RS232?)
6 The UARTs remain active, and data flow can continue at any point in time after the
final attempt at initiating sleep.
APPLICATION NOTE
GR/GS64 UART Sleep Protocols
Page: 17/26
This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable

2.4.6 DSR1 Timing
Two time periods are significant in the functioning of DSR:
Figure 7. DSR functioning time periods
period
a : this is fixed in the GR/GS64 application to 500ms, the time-out period for
the Host to respond to a sleep request from the Wireless CPU®.
period
b : this is programmable by the user, known as the inactivity period . It defines
the interval since the Wireless CPU®’s last de-assertion of DSR1 until it is able to
perform another de-assertion (sleep request). Furthermore, it is intended for
inactivity on the UART in general. Under ‘normal conditions’, the interval timeout
timer will begin after sending or receiving characters on DTM/DFM. This interval is
also valid for cases where the Wireless CPU® has awoken from a legitimate period of
sleep. This period is programmed by the user with the AT command AT*E2RS232,
selecting the appropriate <itimr> inactivity timer value (refer to the GR64 & GS64 AT
Command Manual for details). The inactivity timer is programmable from 100 to
2000 milliseconds.
2.4.7 Sleep Mode Enabling and Disabling
Sleep mode capability can be enabled and disabled by using the AT command
AT*E2RS232, selecting the appropriate <val> and <sel> parameters (refer to the
GR64 & GS64 AT Command Manual for details).
In the event that the Host fails to respond to three consecutive
attempts by the Wireless CPU® to request sleep mode (as illustrated
in Para. 2.4.6), Standby Handshaking (sleep) mode will be
automatically disabled. The user will have to re-enable the feature
(using AT*E2RS232) before sleep mode can be re-enacted.
CAUTION
The Wireless CPU® will attempt to sleep whenever possible, once the sleep
handshaking is enabled. When the Wireless CPU® is first powered it will generally
attempt network registration, then typically the Host and Wireless CPU® will perform
some configuration procedures and a further exchange of communication. This may
take between ten and thirty seconds, longer if there is network congestion. It may be
prudent to wait until after this preliminary activity before enabling sleep handshaking.
Enabling sleep handshaking beforehand may interfere with registration and set-up.
APPLICATION NOTE
GR/GS64 UART Sleep Protocols
Page: 18/26
This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable

2.4.8 Incoming MT Event During Sleep
If an incoming mobile terminated voice or circuit-switched data call is received the
Wireless CPU® will assert RI (Ring Indicator). If an SMS message is received and the
SMS RI function is enabled (using the AT command AT*E2SMSRI) it will also toggle the
Ring Indicator signal. For both of these cases the RI signal will activate during sleep
mode, in addition to the normal UART wake-up handshaking.
Figure 8. Asserting Ring Indicator from sleep mode
Time Description
1 An incoming call is received during sleep. The RI line transitions to its active (low)
state. DSR1 & CTS1 are both asserted.
2 - 4 Events 2 through 4 follow the same process as the Wireless CPU® initiate wake-up
procedure illustrated in section 2.4.4.
(Note that the ring indicator may continue to toggle until the call is established)
If a MT SMS message is received and unsolicited SMS message notification is enabled
with AT+CNMI, the Wireless CPU® will wake, asserting DSR and then send the
indication to the Host via DFM1.
APPLICATION NOTE
GR/GS64 UART Sleep Protocols
Page: 19/26
This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable

3Autonomous Standby
3.1 Purpose
Like Standby Handshaking, Autonomous Standby enables the Wireless CPU® to enter
low power mode during idle periods. However, instead of using the UART signal lines
to request or acknowledge sleep mode, the Wireless CPU® enters sleep mode without
Host interaction, or autonomously. An inactivity timer determines the minimum time
that the Wireless CPU® will delay before entering sleep mode.
The only UART signals required between the Host and the Wireless CPU® are DFM1,
DTM1 and ground.
By default, Autonomous Standby is not enabled at Wireless CPU® start-up.
3.2 Enabling and Disabling Autonomous Standby
Autonomous Standby can be enabled by using the AT command AT*E2RS232 with a
<Sel> parameter of 4. (refer to the GR64 & GS64 AT Command Manual for details).
Autonomous Standby can be disabled by using the AT command AT*E2RS232 with a
<Sel> parameter of 0. The inactivity delay is determined by the <itimr> parameter.
Autonomous Standby can also be enabled or disabled from embedded applications
by using the spm() function. Spm() also sets the inactivity delay.
Whether enabled by AT command or embedded application, the Wireless CPU® will
attempt to sleep whenever possible. The delay before entering sleep mode will never
be less than the inactivity delay setting, but may be longer. When the Wireless CPU®
is first powered it will generally attempt network registration, then typically the Host
and Wireless CPU® will perform some configuration procedures and a further
exchange of communication. This may take between ten and thirty seconds, longer if
there is network congestion. We suggest waiting until after this preliminary activity
before enabling Autonomous Standby.
3.3 Events that wake the Wireless CPU®
During sleep mode, the Wireless CPU® is awakened for the following reasons:
APPLICATION NOTE
GR/GS64 UART Sleep Protocols
Page: 20/26
This document is the sole and exclusive property of WAVECOM. Not to be distributed or divulged without prior written agreement.
Ce document est la propriété exclusive de WAVECOM. Il ne peut être communiqué ou divulgué à des tiers sans son autorisation préalable