TechBlog

Our design team was asked to develop a wireless system to demonstrate a triaxial accelerometer (Freescale MMA7260QT). The goal was to replace the serial cable of the original RD3112MMA7260Q (STAR) demo by a wireless connection using the latest Freescale technology to transfer accelerometer values from sensor to PC in real time.

Key features of the wireless demo include:

• Very small footprint (both hardware and software)
• Low power
• Battery powered
• 20 meter wireless range
• Printed wire antenna
• Real-time response
• Low cost
• May be used as a reference design

After initial evaluation, it was clear that the major design challenge would be to have low power and low current consumption. The target of this demo was to provide accelerometer measurements with a transmission frequency of about 30 transmissions per second. Thus every microAmperesecond (?As) counts when using a very limited power supply.

Knowing the battery for the sensor board without first knowing which wireless technology would be used was a challenge. At the beginning AA and AAA alkaline batteries were considered. The allowable current was adequate, but the physical battery size would overwhelm the rest of the project. Since one of the desires of this demo was to demonstrate Freescale’s very low power technology, it was decided to use a Lithium primary “coin cell” type battery. The popular 220 mAh CR2032 3V coin cell, with a suitable battery holder, proved to be ideal from a form factor point of view while providing sufficient battery life to make a successful demo. To further emphasize the low power battery source, a transparent cover or even no cover was considered for the sensor board.

---

Finding the Right Wireless Technology

---

The next design choice was determining the best low-power wireless technology to transmit data from the accelerometer to the computer. The 2.4 GHz industrial, scientific and medical (ISM) band was selected due to its global acceptance and its ability to take advantage of small board sizes and an inexpensive (printed wire) antenna.

Three well-known standards-based wireless communication technologies operate within the 2.4 GHz ISM band—Wi-Fi, Bluetooth® and IEEE® 802.15.4 technology. Wi-Fi is probably the best known, providing the fastest communication rates, and is ideal for the computer connectivity segment. However it was not designed for extreme low-power operation and long battery life. Bluetooth technology is certainly better for low-power, battery-operated devices, having been designed to provide short-range (10m or less) moderate rate wireless connectivity for phones, headsets and other handheld consumer devices. IEEE 802.15.4 technology, on the other hand, was designed from the beginning to provide months to years of low-rate, short-range (20m to 100m) wireless connectivity for devices operating from a small battery. It is intended for low data rates (such as in sensor and control networks) and excels at extremely low-power consumption. For these reasons, 802.15.4 based radios were chosen for the wireless accelerometer design demo that the team has christened ZSTAR.

---

Demo Overview

---

The demo uses the ZSTAR sensor mode and an 802.15.4 wireless data collector module that is connected to a PC (Typically by USB). Freescale has a number of demo modules that can be used for the data collector. The module used by the ZSTAR demo is the wireless sensor board which uses three main Freescale devices:

• The triaxial accelerometer MMA7260QT, known as “triax”
• The MC9S08QG816-pin 8-bit microcontroller (MCU)
• The MC13191 802.15.4 transceiver (radio modem)

All of these devices are capable of very low power operation. To ensure reasonable battery life, it is necessary to take full advantage of the terrific low power operating modes that all of these devices offer.

Table 1: Current Consumption for Modem, MCU and Triax States
Off	Total device powered off	0.2 ?A
Hibernate	RAM/register content is retained, digital IO retain their states. Reference oscillator is off.	1 ?A
Doze	Crystal reference oscillator is on. RAM/register content is retained, digital IO retain their states. Output clock can be available. Timer can be used for wake-up.	35 ?A
Idle	Reference oscillator running. Fast transition to Rx and Tx modes.	500 ?A
Receive	Receiving mode or CCA	37 mA
Transmit	Transmit mode	30 mA
MCU Operational Mode	Description	Typical Current Consumption
Stop1	All I/O pins automatically transition to their default reset status. Most of the internal circuitry of the MCU is powered off. RAM content is lost.	475 nA
Stop2	Retains RAM, all I/O pin control signals retain state. Wake-up treated as start from reset.	600 nA
Stop3	Retain all of the internal registers and RAM contents, and I/O pin states are maintained. Wake-up treated as an interrupt service.	700 nA
Wait	CPU core clock stopped, all enabled peripherals running	1 mA
Run	All peripherals off, CPU core clock is 32.768 kHz derived from 32.768 kHz crystal	95 ?A
Run	All peripherals off, CPU core clock is ~32 kHz derived from internal oscillator (without frequency locked loop)	150 ?A
Run	All peripherals running, CPU core clock enabled (8 MHz)	3.5 mA
Triaxial Operational Mode	Description	Typical Current Consumption
Sleep	Outputs deactivated	3 ?A
Run	Triaxial accelerometer operating	500 ?A

---

Low Power Considerations

---

Several important factors affect power consumption:

• Power saving modes for the MCU, Triax and Modem are managed for each part of the complete communication cycle (the period in which one set of accelerometer values is sent toward PC)
• The number of packets sent per second (i.e. the rate of the communication cycle)
• The number of packets exchanged per second (the 802.15.4 protocol provides for an acknowledgement for each packet, but to save power only one acknowledgement was sent for every eight transmissions sent from the sensor)
• Packet length (the protocol needs to be simple and lightweight with minimal overhead and minimum data size)

To overview the modes available for the components, Table 1 summarizes the available device states.

---

System Trade-Offs for Low Power

---

Operation of the sensor board must be viewed from a power consumption point of view. Since the number of transmitted packets and their size is consistent and does not vary, the power must be managed looking at the various parts of the duty cycle.

A. Low power or quiet time between communications

Because of the broad flexibility allowed for MCU clock modes, the low power considerations can take advantage of choices between accurate timing and less accurate timing.

1. Accurate (crystal based) receive/transmit timing—every transmit/receive operation can be precisely timed, in addition the receive window can be made as narrow as possible to save current.
   • MCU with 32.768 kHz crystal, Modem in Off mode. The MCU runs at a low speed while waiting for next communication. During time-critical periods, the MCU switches on the frequency-locked loop (bus clock is typically 8 MHz). The disadvantage of this solution is the transition from the Off to the Idle mode takes between 10 and 25 ms, due to the start-up of the voltage regulators and clock oscillator. In addition, the content of the modem RAM and the GPIO state is lost, so all the configurations must be repeated every time. Two crystals (16 MHz for Modem and 32.768 kHz for MCU) are needed.
     Total consumption: 200 nA (Modem) + 9 5 ?A (MCU)
   • MCU with 32.768 kHz crystal, Modem in Hibernate mode, has similar behavior as in the 1a) scenario. The transition time from Hibernate to Idle mode is somewhat shorter (8 to 20 ms). The nice thing about operating in this mode is that the content of the RAM and the GPIO states are retained. This method uses the same two crystals as before.
     Total consumption: 1 ?A (Modem) + 9 5 ?A (MCU)
   • MCU clocked by internal oscillator or externally (via CLKO output provided by Modem), Modem in Doze mode the MCU provides the internal oscillator, and when the MCU is commanded to exit Doze mode, it can do so quickly. MCU resets and configures Modem. Modem can also provide the reference clock in the Doze mode. The MCU programs CLKO to the desired frequency and waits until CLKO stabilizes. Once the CLKO is stable the MCU switches its clock to external source. Precise timing of long time delays is done in Modem by time scheduled exit from the Doze mode, while MCU sleeps at the same time.
     In this configuration, the designer can fully take advantage of automatic initiating the timer-triggered events such as:
     • Activating receive mode
     • Activating transmit mode
     • Activating idle mode

     In addition, the received frames are also “time-stamped” during reception, making a precise timing between various events possible. The microcontroller can remain in the low-power modes. This scenario has slightly higher power consumption than using a separate crystal for the MCU, but only single crystal (Modem crystal) is needed.

2. Inaccurate packet timing
   • MCU timing controlled by internal oscillator (RTI) and Modem in off mode. Disadvantage of this scenario is the communication timing is not that accurate. The MCU timing is controlled by a RTI internal oscillator that does not provide precise timing (only 30 percent). Thus the receiving windows must be wider which also affects power consumption negatively. Single crystal is required. Total consumption: 200 nA (Modem) + ~1 ?A (MCU Sleep mode + RTI enabled)
   • MCU timing controlled by internal oscillator (RTI) and Modem in Hibernate mode is similar scenario to a. Difference is in shorter transition time to idle mode and Modem re-initialization is not needed. Total consumption: 1 ?A (Modem) + 1 ?A (MCU Sleep mode + RTI enabled)
   • MCU clocked by internal oscillator running at the lowest possible frequency (4 kHz), Modem in off mode. The MCU bus clock is driven by an internal clock reference. It is 2 percent accurate (after trimming) which may be sufficient for many applications. The Modem is in off mode, single crystal is required.
     Total consumption: 200 nA (Modem) + 150 ?A (MCU running at 4 kHz internal clock)
   • MCU clocked by internal oscillator running at the lowest possible frequency (4 kHz) and Modem in Hibernate mode. This scenario is similar to c; the Modem is in Hibernate mode. Total consumption: 1 ?A (Modem) + 150 ?A (MCU running at 4 kHz internal clock)

Table 2
Mode	MCU Clock	Accuracy	Modem Mode	Consumption
1a	Xtal 32768 Hz	100 ppm	Off	95 ?A
1b	Xtal 32768 Hz	100 ppm	Hibernate	96 ?A
1c	Clocked from Modem	20 ppm	Doze	36 ?A
2a	RTI clock	30%	Off	1.2 ?A
2b	RTI clock	30%	Hibernate	2 ?A
2c	Internal clock 4 kHz	2%	Off	150 ?A
2d	Internal clock 4 kHz	2%	Hibernate	151 ?A

Another portion of total power consumption is drawn.
B. Transmit and receive events
As seen from the Modem transmit/receive operation mode supply current, Modem’s transmitting and receiving state has a high influence on the power consumption. Therefore, the length of data packets needs to be highly optimized and communication rates must be selected carefully.

On the following charts you can see the influence of communication rates and data payload length versus the battery life. The first chart shows battery life in hours versus the number of frames sent per second. We had to compromise to 30 packet per second to gain sufficient sample rate together with reasonable battery life.

Figure 1: Battery Life Versus Packets/Sec.

Also the data packet length affects the battery life significantly. That is why we send only raw data from triaxial accelerometer (please see the packet format and packet length in Chapter 5.3 of ZSTARRM Reference Manual for further details).

Figure 2

Standard IEEE 802.15.4-compliant packet has 4 bytes of preamble, 1 byte of SFD (Start of Frame Delimiter), 1 byte of FLI (Frame Length Indicator), 2 bytes of FCS (Frame Check Sequence) plus the payload data (125 bytes maximum). As a result, the overhead of a frame is 8 bytes or 8 x 32 = 256 ?s, and the maximum payload transmit time is 125 x 32 = 4000 ?s. The transmit time for a packet then is:

Total TX time (?s) = 256 + (payload bytes x 32)

Standard SMAC Packet for our sensor board has 17 bytes (including 2-byte packet IEEE 802.15.4 control field). There are also so called “warm up” (transition from Idle to Transmit) and “warm down” (Transmit to Idle) periods which take 144 ?s and 10 ?s respectively.

The following chart shows dependence of packet length versus battery life. It is obvious that packet length should be as small as possible.

Figure 3: Battery Life Versus Data Payload

This chart is also quite theoretical because there is another physical limitation in place. The power supply (Lithium battery) provides only very limited continuous current, so if a longer frame would be transmitted, the battery voltage will drop significantly. In the ZSTAR design, a large tantalum capacitor (470 ?F) is designed to improve the response of the power supply to current peaks caused by reception or transmission. Even that, larger data frame (longer than ~50-100 bytes) would still cause a significant voltage drop.

Capacitor calculation: we specified allowable supply voltage drop 100 mV while transmit time (1 ms).

So we finally chose 470 ?F capacitor from the series in the same package.

---

How it Works Together

---

The sensor board was developed to be very small and cost-effective, which is why we used only one crystal at Modem. Also, we needed the accurate communication timing to use Modem Doze mode for communication timing, and the MCU uses internal clock (during its activity), otherwise the MCU is in the Stop3 mode. Communication between the sensor board and USB stick is described below.

Figure 4

Transmitting one data packet is processed.

1. At the beginning of the period, the Modem wakes up the MCU from Stop3 mode. The MCU awakes the Triax from sleep (asserting SLEEP pin of Triax). Then, the Triax outputs stabilize before a measurement can be done. During this time, the Modem is again turned into a timed Doze mode and the MCU also goes to the Stop3 mode.
2. When Triax is ready for measurement, Modem wakes the MCU up again and the MCU measures the Triax. After data is acquired by the MCU, the Triax is switched back to sleep mode, the data packet is formed and moved in to the Modem’s RAM buffer.
3. The Modem transmits the packet over RF.
4. In order to detect the connection lost (between Sensor board and USB stick), the response from the USB stick is awaited. But because the USB stick needs some time to process received data, form a response packet, the MCU sets the Modem to the Doze mode for the short period again.
5. After that short period, the MCU wakes and response from the USB stick can be received within the specified receive window. Then, the Modem is set to Doze mode till the end of the cycle and the MCU goes to Stop3 mode.
6. Between two successive packets, MCU stays in Stop3 mode, Triax is switched to sleep mode and Modem is in Doze mode while its time base measures time to the next packet.

During the evaluation of this communication method we observed that the receiving after every transmission heavily increases the current consumption. Since this was not required or needed, the receive window for the response of the USB stick is only opened at every 8th opportunity. In all other instances, the sensor board goes to the Doze mode immediately after the transmission is finished (states 4 and 5 skipped).

---

Summary

---

The original goal of the ZSTAR project (to transfer real-time data using limited power supply) was evaluated. All aspects of the system design (both hardware architectures and also the software implementation) were explored and optimized for the best performance of the application. XYZ samples from the triaxial accelerometer, together with internal temperature and battery voltage level, are sent 30 times per second using a tiny lithium CR2032 battery for ~100 hours of run-time. The average current consumption of this system is estimated to be 2.5 mA and the measurements confirmed this expectation.

Overall, the ZSTAR design shows cost-effective implementation of the MC1319x Modem family with a cost effective low-pin 8-bit microcontroller (MC9S08QG family) for wireless sensing of 3-axis accelerometer (MMA7260QT).