Power management alternatives for RF portable devices
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 cost-effective results.
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 T
The average current consumption will be
For example, by using the receiver (MC33591) with a strobe ratio equal to 31, we can have, with I
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 T
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.
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 T
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.
Want to use this article? Click here for options!
© 2013 Penton Media Inc.
Acceptable Use Policy blog comments powered by Disqus
Most Popular Stories
CTIA Wireless IT & Entertainment 2010
Read the latest from the show...