Several solutions have been found to reduce power consumption at the silicon
level for RF products, including remote controls and RFID systems. For instance,
implementing power management features is one way to extend battery life.
The data manager and strobe oscillator power management features combined
with the systems control can offer substantial reduction in power consumption.
This article will describe the power management features and their impact
on the RF frame, transmission and reception, power consumption, and its
For the PDF version of this article, click here.
While consumers appreciate the latest innovations in RF portable devices, including remote controls with self-identification features and bidirectional communication devices, they continue to demand more run time from a single battery. Consequently, RF designers are forced to find ways to more efficiently use battery power. However, electronic components can become limited due to physical constraints. In order to explore lower power consumption, designers must integrate power management features with the main control of the system to allow for more power and maintain a reliable system.
We will describe two novel power management features that are contained in the Freescale RF devices MC33591, MC33592, MC33593 and MC33594.
Strobe oscillator is one of the power management features in which implementation must be coordinated with the system time frame transmission. This feature is implemented as follows:
One method is to strobe the receiver by periodically doing a sleep/run sequence if a receiver with a very low operating current is required. Periodic wake up can be done by the microcontroller unit (MCU) control. An alternative is to integrate a low-frequency oscillator in the receiver and link to its state machine. If the receiver is operated during TRUN and is sleeping during TSLEEP then we can define a strobe ratio (SR) that is equal to
The average current consumption will be
For example, by using the receiver (MC33591) with a strobe ratio equal to 31, we can have, with Irun = 5.7 mA and Isleep = 115 µA, Imean = 289 µA.
SR, TRUN and TSLEEP should be correctly sized to be compatible with the reception of any incoming frame as Tsleep will have a direct impact on the reaction time of the receiver.
Ideally, it is required that the MCU and the receiver should sleep when there is no RF frame to be received. To check this, however, the receiver has to wake up periodically.
The data manager, the second power management feature, allows the MCU to sleep by doing frame-recognition tasks. It then wakes up the MCU while a valid frame is received. The data manager avoids the complex task of decoding data with MCU. The data manager — a powerful logic block — allows clock recovery from a Manchester coded signal and then decodes the frame. It recognizes a specific programmable ID in the frame and sends on the serial peripheral interface (SPI) port the data that follow. If the MCU is sleeping, it should be able to wake up on a signal coming to its SPI port.
The data manager is converting a Manchester coded signal to non-return to zero (NRZ) signal with a separated clock on the SPI port of the receiver. If selected, this process is initiated when the receiver wakes up and detects a Manchester coded signal at a selected data rate. Manchester code is widely used in RF communication because the direct current (dc) average value doesn't vary with the content of the message, which allows easier demodulation and shaping of the signal. Additionally, each transmitted bit contains a transition that allows easy clock recovery.
Because the maximum transmitted frequency is twice the maximum transmitted frequency for NRZ, Manchester code is limited to low data rata (< 50 kbps). The frame always begins by a preamble that contains some pulses to set up the receiver's internal automatic gain control (AGC), average filters for demodulation, and initiate clock recovery.
When clock recovery is done, the data manager verifies if an ID is received. An ID is a word that is programmable and that can be inserted in the transmitted frame. On Romeo2, the ID is eight bits long. On Romeo3, the ID length is programmable between one and six bits. The ID is used to identify a useful frame to receive. It is also necessary, when the receiver is strobed, to detect an ID in order to stay in run mode and not miss the frame.
Once the ID is detected, a header will be searched to detect the beginning of the useful data to send on the SPI port. On Romeo2, the header is a fixed four-bit word that can be selected or not. On Romeo3, the header length is programmable between one and six bits and its content is defined by user. Once the header is detected, all following data are sent on the SPI port up to the end of the message.
Data on MOSI are available on the falling edge of the clock SLCK; it is then an easy task for the MCU to decode received data. More MCU load would be required if the MCU should decode the data without the help of the data manager. In fact, as the jitter may be important for low-level signals, the MCU would use oversampling to decode correctly.
The end of the message (EOM) is simply a Manchester violation. It is enough transmitting in two-bit duration a constant level either for on-off keying (OOK) or frequency shift keying (FSK) following by stopping RF transmission.
Strobe oscillator and data manager working together
In order to reduce receiver power consumption, the SR should be high. By raising the SR, sleep time TSLEEP will increase and the probability to catch a transmitted frame will decrease. That's why the TRUN and TSLEEP should be adapted to the definition of the frame.
Different methods are used to match SR to the transmitted frame. Some methods are using multiple frame transmission to guarantee that at least one frame will be received. The method described here guarantees that no transmitted frame will be lost.
Different SR is now evaluated for an already defined transmitted frame. The goal for the receiver is to catch at least one ID during its run state. Many ID are transmitted during the ID field.
During TRUN, the receiver should be able to detect an ID. Since the receiver and transmitter are not synchronized, an ID may already be transmitted when run time begins. Therefore, TRUN should be sized to receive two IDs. It will catch one — whatever is the time difference between beginning of transmission of the ID and beginning of run time for the receiver.
TRUN should also include the wake-up time of the receiver TWAKEUP, which includes the crystal oscillator wake up, the phase lock loop (PLL) lock time and all analog parameters setup. The automatic gain controller (AGC) and demodulator need some time to settle to work properly
If ID=b0000… or ID=b1111… then it is possible to detect the ID in a shorter time as there is no detectable beginning and end in this case. This reduces the requested TRUN time to
TSLEEP should be sized to allow the positioning of a run state during the transmission of the ID field. Moreover, no reception is possible during TWAKEUP. The following image illustrates the limit condition to guarantee that an ID will be detected. If the first is missed, the last will always be detected.
It should be noticed that this relation is also valuable for ID=b0000… or ID=b1111…, as the two concerned IDs are the first and the last in the ID field and no more shift is possible.
In conclusion, the proper use of the data manager and strobe oscillator power management features can drastically lower the power consumption without scarifying the link reliability. However, those features must be implemented adequately to address the system needs. For example, in automotive remote keyless entry applications (RKE), the transmitter sends a frame only a few times per day. Its average power consumption is mainly given by its standby current; the length of the transmission has little influence. The receiver, however, is waiting for a frame all day; its power consumption is important because it is connected to the battery of the car.
On the other hand, in tire pressure monitoring systems (TPMS) available on cars, the transmitter may send a lot of frames to the receiver to add redundancy to this security system and to guarantee fast update of the information. As the pressure sensors are located in the wheels, the battery should last at least 10 years and its power consumption may be critical. Therefore, most of the time, it is required that the frame is short. The result is a higher data rate and a shorter ID field. The receiver will have to wake up more often and will consume more power, but as this happens most of the time when the car is moving, the power supply of the receiver is not a problem.
If power is managed properly, the size of the portable devices can be positively affected by reducing the size and number of batteries where its power is related to its chemistry, which affects its physical size.
By using a receiver with an automatic wake up feature, such as a strobe oscillator, and combining this with the data manager, it is possible to drastically reduce the power consumption and maintain a reliable system. Maximum efficiency is achieved when data rate, number of IDs and strobe timing relations are evaluated.
To further optimize power management and maximize battery life, programmable power management features must be implemented and software controllable to allow flexibility so that designers can adequately engage the power management features to the main system control.
ABOUT THE AUTHORS
Laurent Gauthier is a system and application engineer in the MCU division of Freescale Semiconductor. Gauthier earned his M.S. degree in electrical engineering from the Ecole Nationale d'Ingénieurs de Brest in France. In 2001, he joined Motorola and since 2003 has worked for Freescale Semiconductor as a system and application engineer within the RF team in charge of the integration of short-range devices in microcontrollers. He can be reached by e-mail at firstname.lastname@example.org.
Pedro Pachuca is an RF technical marketer in the MCU division of Freescale Semiconductor. Pachuca earned his MS degree in electronic engineering from Instituto Politectnico Nacional in Mexico D.F. He joined Freescale Semiconductor (formerly Motorola) in 1996 for a business development position. Since then he has joined the Freescale eight-bit microcontroller team as RF technical marketer. He can be reached by e-mail at email@example.com.