Feature

32-bit processors have a place in low-power, low-bandwidth ZigBee designs

ZigBee is emerging as a strong contender for low-bandwidth, low-power networks such as you'd find on the factory floor. Different network nodes will require different levels of processing power.

By Rick Gentile, Tom Lukasiak, and Glen Ouellette, Analog Devices -- EDN, 7/13/2007

In today's consumer market, two of the most prevalent local-area wireless technologies are Wi-Fi and Bluetooth. For connectivity between laptops, cell phones, and a variety of other handheld devices, these protocols make us wonder how we ever survived without them. However, ZigBee may be a better choice for low-power, low-bandwidth control-type applications, such as a sensor network for the factory floor. And with a powerful processor, ZigBee can effectively perform many complex tasks within its low-power, low-bandwidth constraints.

The ZigBee Alliance first published the ZigBee specification in 2004 to provide networking for industrial-control, automation, and monitoring applications. The ZigBee protocol specifies a software stack which sits on top of the IEEE 802.15.4 radio standard. The IEEE 802.15.4 specification, designed for low-bit-rate applications (up to 250 kbps), defines the physical layer for the radio. The ZigBee protocol serves as the logical network and application software. The ZigBee Alliance, which includes more than 200 member companies, governs the ZigBee standard and ensures compliance within the specification.

A few key aspects stand out when assessing ZigBee for an application. The first is the low processing requirements of the stack, which translates to low-cost processors. This directly supports the idea of remotely deployed devices that run on battery power. With a collection of remote devices, the next requirement is connectivity. ZigBee-based systems support a range of interconnects including tree, mesh, and hybrid configurations. This is a key advantage because it is makes a ZigBee network much more flexible and robust in a factory or building.

Power

ZigBee networks invariably have some number of nodes that are battery powered. Typical IEEE 802.15.4 nodes are efficient in terms of power consumption because they are designed for that purpose. These devices specify a battery life that is measured not in hours, but in years. To aid these demanding power requirements, the IEEE 802.15.4 protocol uses transmit times that are short in duration, and supports communication of both beacon-oriented and beacon-free modes.

In a beacon-enabled network, all nodes agree on a time-slice scheme that schedules when a specific device will transmit data or when it needs to be awake in order to confirm its membership in the network. A heartbeat type of connection that uses a beacon allows all nodes in the network to be powered off for the majority of the time, partially waking up to acknowledge the beacon interval. The beacon interval can be between 0.015 and 252 seconds. This allows all devices in the system, including the central coordinator, to remain idle until necessary.

In a beacon-free network, many battery-operated nodes can spend most of their time in an idle state. A beacon-free mode provides a way from some of the nodes to sleep for extended periods of time, provided they communicate with nodes that are always on. In practice, it is expected that many battery-powered nodes will run for many years before the battery needs to be replaced. However, this scenario dictates that one central node be awake at all times to receive messages from the battery-operated nodes.

The event-detection or pure-sensor type of node requires a processor, mostly to run the ZigBee stack itself. For this type of processing load, an 8-bit processor can handle the work. The 8-bit processor is also very power-efficient, so that battery life is maintained. Take for example the Atmel ATmega32L (8-bit AVR microcontroller). For this processor, the current draw for a 3.3V core is:

• Active: ~6 mA for 8 MHz clock, ~1.1 mA for 1 MHz clock
• Idle: ~3 mA for 8 MHz clock, ~0.35 mA for 1 MHz clock
• Power-down: < 1 µA

The good news is that as telemetry applications become more intelligent at the end node, developers are not forced to increase the power budget much beyond that of an 8-bit controller when adding a significant increase in performance. This is because today's embedded processors have the ability to work at a range of voltages and frequencies to optimize power consumption for each given application. That is, engineers can program processors with dynamic power management to match the exact processing requirement. The processors also have a variety of power-down modes that allow the bulk of the logic to remain powered off until detection of a specific event. 

An advanced telemetry application using a Blackfin processor, scaled to run in a low-power mode, interfacing to a ZigBee stack and performing some basic signal processing, consumes power on the order of 10s of milliwatts. When power-down sleep modes are used, the average current used is in the microamp region.

Again, looking at some numbers, Blackfin processors run at a range of voltage and frequencies. At the lowest voltage of 0.8V, the processor can run up to 250 MHz. This frequency supports any of the applications described below. The ZigBee stack takes up only a small portion of the MIPS (less than 10 MIPs). This leaves many additional MIPS to perform more advanced processing, such as JPEG encoding or analytic decision making. A typical device running at 50 MHz consumes about 20 mA. At 250 MHz, the consumption will increase to 50 mA. 

The processor can also take advantage of its RTC (real-time clock) to wake up on a regular period. In this mode, the processor is off or in a low-power state the majority of the time. The RTC circuitry runs on a dedicated battery that consumes less than 30 µA of current and is programmed to awaken the processor after some time period. Alternately, the processor can be awakened from its power-down state by a variety of other external stimuli.

Network configurations

A ZigBee network can be as simple as two nodes communicating with each other. However, the strength of ZigBee comes from its ability to handle a collection of sensors, switches, and controllers spread across a large area. Various network topologies, such as tree and mesh, can be used to overcome the short range of 802.15.4 radios (typically up to 70m with line-of-sight) in a large system. A tree configuration relies on a fixed routing table to connect devices to each other. A mesh network optimally relays messages from the source node through intermediate nodes in order to reach the destination. This type of configuration provides network resilience; if one node fails, the network can reroute messages through other nodes. 

Profiles and interoperability

The ZigBee protocol sits above the IEEE 802.15.4 MAC and PHY layers and encompasses the network and application-interface layers. In addition, the ZigBee Alliance also defines some higher-level application framework and application profiles.

These predefined application profiles allow developers the option of either using a public application profile or a custom private profile. Public profiles provide vendors with a means to share functions and control, thus allowing products from multiple vendors to interoperate.

The ZigBee Alliance has defined multiple basic public profiles for home automation, HVAC, and industrial sensors. As an example, a ZigBee-controlled light dimmer could use the home-automation profile. Because home automation is a public profile, a light dimmer from one vendor can interoperate with the light ballast of another vendor using that same home-automation profile.

Meanwhile, some developers may opt to use a private profile, because a custom profile can provide a way to create specific application interfaces that only interoperate with a limited number of trusted devices.

Security

As with Wi-Fi and Bluetooth, those who are new to ZigBee quickly raise questions with regards to security. Because of the types of applications where ZigBee networks find use, security is an important aspect of the protocol. In industrial applications, the networks may have hundreds or possibly thousands of nodes. Securing and managing such a network while retaining the simplicity and low cost of ZigBee becomes a formidable task.

To address the issue, chip and system designers have opted to take varying approaches. One approach is to offload the security functions to a dedicated hardware-accelerator block. This reduces the MIPs loading on the CPU, but may have future impacts should the security requirements change. Another approach is to perform the security in software with newer low-cost, low-power 16- or 32-bit embedded processors. These processors have the performance headroom to deliver the security requirements while retaining the advantages of software programmability.

Emerging ZigBee applications

ZigBee deployment traditionally encompasses control and automation of homes, buildings, factories, and entertainment systems. Most of these types of systems require only a simple microcontroller. Moving to a higher-performance embedded processor opens doors new kinds of ZigBee applications, which fall into the following three classes.

Class 1: Decision-maker

In the role of decision-maker, an embedded processor distills great amounts of data to find the essential information that is relevant to a given application domain. This small amount of information can then be sent to other nodes in a ZigBee network.

Security systems serve as good examples for this type of configuration. The use of biometric information has become an effective way to guard against access to sensitive resources. However, data from a fingerprint sensor or a retina scanner needs to be processed against a database of verified users. To ensure an acceptable user experience, the time to process the raw biometric information must not exceed a predetermined delay. Many manufacturers of biometric products aim for 500 msec as the upper time limit between the biometric scan and the match/no-match decision. In a real fingerprint-access system, a high-performance processor, such as one from the Blackfin family, can make a decision in less than 200 msec if running at 400 MHz. This provides time for the system to perform multiple scan and decision-making passes, thus increasing the overall accuracy (see Figure 1).

Because the decision output from the processor requests a small amount of information (such as. "passed fingerprint authentication" or "failed fingerprint authentication"), the bandwidth requirement on the network is low. The main aspect of the network in security systems like fingerprint access is the latency. A rule of thumb is that every hop that a message goes through adds between 10 and 100 msec of latency, depending on the load of the network. This latency, along with the time needed to verify a fingerprint, must not exceed the acceptable user delay defined by the end manufacturer.

An embedded processor, coupled with the flexibility of a ZigBee wireless network, allows for a cost-effective security system solution.

This type of application would be wall-powered, but it would still be considered a low-power system. At 400 MHz, a Blackfin processor can consume less than 100mA at this frequency.

Main requirements: Decision must be made quickly; network latency should be low

Examples: Fingerprint lock; security camera

Class 2: Media compressor/decompressor

While ZigBee is not a high-data-rate protocol, it is possible to judiciously transfer audio and video media across a ZigBee infrastructure. This can be achieved by using one processor to compress media at the source ZigBee node and another processor at the destination ZigBee node to decompress the media.

One example application of this type is a video doorbell. The setup of such a doorbell system is actually quite simple with a ZigBee network. A video camera at the front door, connected to an efficient media processor and a ZigBee transceiver, serves as the broadcast point. Multiple video displays, utilizing media processors connected to ZigBee transceivers, can be placed throughout the building to pick up images or low-bit-rate video of guests (see Figure 2a). As ZigBee-enabled households and apartment buildings become more prolific, primarily for control of appliances, climate, and entertainment devices, it may be convenient to leverage that infrastructure when adding a video-doorbell system.

Because of the real-time aspect of the data, the media processor must perform the encode and decode algorithms within acceptable user-defined time constraints. A prototype video-doorbell system has been implemented using an Analog Devices ADSP-BF533 embedded media processor and an Ember EM260 ZigBee coprocessor (see Figure 2b). A JPEG encoder/decoder implemented on the 32-bit Blackfin ADSP-BF533 media processor consumes ~50 cycles/pixel for a 12:1 compression ratio. For one frame with 640×480 pixels of resolution, this is 15.4 million cycles. Using this example, it is easy to see that CPU utilization of media algorithms can easily overpower 8-bit microprocessors.

While standard low-bit-rate video encoding is an easy task for today's media processors, it does pose challenges to low-bit-rate ZigBee networks. The most bandwidth-efficient media codecs are the most computationally intensive. The nominal rate of the underlying IEEE 802.15.4 standard is 250 kbps. Because of the CSMA/CA architecture, the realistic maximum is on the order of half the nominal rate. In practice, one can expect to achieve upwards of 60 kbps with large packet sizes in a low-frills configuration without security. With network bandwidth of this order, a good-quality VGA-sized JPEG image can be transmitted every second. One way to increase the frame-rate when transmitting images over a low-bit-rate link like ZigBee is to implement a more advanced codec that yields a higher compression ratio than JPEG.

Advanced media codec algorithms, running on modern processors enable the possibility of media transmission over ZigBee networks.

This application is also most likely to be a wall-powered system.

Main requirements: Media demands a fair amount of memory; media must be compressed and decompressed quickly to maintain streaming

Examples: Video doorbell

Class 3: Gateway/administrator

The Gateway/administrator class of ZigBee nodes is used to bridge a large ZigBee network with a more prolific technology like Ethernet, Wi-Fi, or USB. An embedded processor with higher levels of peripheral integration can decrease the bill of materials.

An example application is a central administrator ZigBee node that collects data from hundreds of nodes in an industrial environment (see Figure 3). The data may need to be processed or filtered before being presented to a PC user through any standard interface like Wi-Fi. The presentation of data can most easily be done with a Web server running on the administrator node.

Depending on the number of slave ZigBee nodes the administrator serves, the embedded processor can be taxed in terms of data bandwidth. There is also a possibility that the administrator needs to store a lot of data locally. For this reason, it is advisable to choose a processor with an on-chip flash, a NAND-flash port, or a hard-drive controller.

Main requirements: Rich portfolio of peripherals including USB, Wi-Fi, Ethernet, and storage (flash or hard drive)

Examples: Ethernet/ZigBee gateway; ZigBee USB dongle

Summary

As the ZigBee community continues to evolve, so do ZigBee-enabled applications. Low power, configurable architectures can be deployed quickly. The nature of ZigBee system facilitates security. And once networks are built, developers can easily extend them in a variety of topology configurations. The end nodes are no longer relegated to the realm of microcontrollers. Embedded processors can provide an application with added capability at the end node—without exceeding the power budget. The extended capabilities include analytics, media compression, and gateway technology. 

References and resources

• dev.ember.com
• www.wirelessnetdesignline.com
• Software adds smarts to sensor nets
• Avoiding Interference in the 2.4-GHz ISM Band:
• How to compare proprietary and standards-based radio solutions
• The Importance of sleep mode power consumption in ZigBee/802.15.4 applications
• Computing Power Consumption on a Blackfin Processor

Rick Gentile is the manager of the Analog Devices' processor applications group. Prior to joining ADI, Rick was a Member of the Technical Staff at MIT Lincoln Laboratory, where he designed several signal processors used in a wide range of radar sensors. He received a BS in 1987 from the University of Massachusetts at Amherst and an MS in 1994 from Northeastern University, both in Electrical and Computer Engineering.

Tom Lukasiak is an embedded applications engineer with Analog Devices. He has a ScB and ScM in Electrical Engineering from Brown University.

Glen Ouellette is a senior applications engineer at Analog Devices, where he is involved in specifying and supporting Blackfin processors. He has a BS Electrical Engineering from the Ryerson University and an MBA from Babson College.