Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > RF/Microwave

Bring Zigbee designs to high volume

Posted: 03 Sep 2007 ?? ?Print Version ?Bookmark and Share

Keywords:Zigbee? high volume designs? test?

Andrew Wheeler
Ember Corp.

The Zigbee wireless networking standard is fostering a wide range of newly untethered products for applications such as home and building automation, utility metering and building security. Devices without the cost or power budgets to support wireless connectivity now can leverage proven Zigbee technology for new innovation possibilities. However, "going wireless" brings new test challenges for designers unfamiliar with radio technology.

Zigbee implementations involve mixed analog/digital hardware and software running on a low-cost MCU. Most new designs use single-chip SoCs that integrate the IEEE 802.15.4 radio; MAC; embedded MCU core; AES encryption engine; RAM; flash; peripherals for SPI, UART, I?C, GPIO, A/D; and timers. Few external components are usually required. The Zigbee stack runs as software on the core and is stored in the integrated flash. The device application (such as a wireless light switch, temperature sensor, meters, etc.) is also compiled to the embedded core, sharing cycles and memory with the Zigbee stack.

Sometimes, a separate MCU is desired for the device application, such as when Zigbee is being added to an existing design, or when the application is complex. A Zigbee network coprocessor is a good choice here, where the device application interacts with the Zigbee stack (fully implemented in the co-processor) via a simple serial (SPI or UART) interface.

Other system design choices that affect overall test complexity include optional use of a power amplifier (sometimes desired for long-range applications), and antenna design (PCB-based, external or chip antenna).

Effective test methodologies must be employed at each phase of the design process: prototype, characterization, pilot manufacturing and production manufacturing.

Prototype testing
The prototype phase of the design process occurs when design is complete. For test purposes, it is safe to assume the overall product design, software development and unit integration work are completed. The primary goals are design validation and verification. This test may be divided into two areas: network system validation and validation of the specific hardware design (including radio performance).

As with wired systems, network-based interactions between the system components (for example, sensors, switches, controllers, lights, thermostats, displays, etc., within a building automation system) must be fully validated. The wireless twist is in monitoring the over-the-air interactions between the devices.

Typical tools for wireless networks, such as packet sniffers, were the only tools available early on for Zigbee developers. For large-scale network development, packet sniffers are unwieldy, giving only low-level detail that is not very useful for high-level application validation.

Instead of looking at individual packets, it is more useful to look at end-to-end application transactions across the network. New tools have emerged that permit this through visualization and programmatic analysis. They have been augmented with even more functionality through on-chip network debugging support in some Zigbee platforms.

A typical problem with over-the-air packet analysis in a multihop network is that a sniffer device may hear packets that network devices do not hear and may miss packets that were actually heard by a device. Some Zigbee platforms include hardware interfaces that provide a nonintrusive trace of all packets sent or received by a device. An adapter that connects this interface to a PC-based debugging tool, over a wired Ethernet LAN, enables simplified application validation.

While validation methods for the digital portion of the design are well known, the validation of the radio portion may be unfamiliar. Even for Zigbee's relatively simple IEEE 802.15.4 radios, robust RF performance tests are required, including:

  • Receive sensitivity (1 percent packet error rate, 20byte packet)

  • Receive at all input power levels

  • Transmit output power (for all power levels)

  • Transmit tone test for crystal frequency tuning

  • Error vector magnitude

These tests should be measured:

  • On all 16 15.4 channels

  • Scross the entire device temperature range

  • Across DC voltage range

Communications should also be tested against a Golden Node unit, which is a known, accurate Zigbee node. A Golden Node may be functionally implemented on a piece of high-end test equipment or provided by a platform supplier as reference hardware built to tighter tolerances than permitted by the specifications.

Antenna matching (E and H-Field measurements and 3-D Field Pattern) should also be verified. Power consumption validation, especially for battery-powered or power-harvesting Zigbee devices, should be included for the various operational modes: active radio, active CPU + idle radio and "deep sleep." The active-sleep duty cycle, controlled by software application, should be verified, as this can have a tremendous impact on battery lifetimes.

Like any device, product environmental testing must be performed, as well as regionally required regulatory compliance, including FCC, ETSI, ARB and CE. Zigbee platform providers can provide assistance through proven reference designs and accumulated customer experience.

Characterization testing
Once the prototype test is completed, the next phase fully characterizes the design to verify functionality and repeatability. Additional network system validation may continue, but here the focus is on the hardware itself.

A comparatively large number of units is required to prove repeatability of the design, as well as seed product beta programs; so 500 to 1,000 units may be assembledtypically on a manufacturing "new product introduction" line. Assembling over multiple runs can help prove that the assembly recipe is correct and predict the ultimate manufacturing yields.

Communications with a Golden Node should also be performed, as well as the DC power measurements for all the various sleep states of the device. Each device should be tested (no sampling) to ensure enough statistical information for proper test limit settings, prove design margins and predict manufacturing yields.

Pilot manufacturing test
The characterization phase should have demonstrated that the design is repeatable and predictable, the proper test limits are set, and yields are stable. Focus shifts from the design itself to reliable and cost-effective manufacturing process verification. Assembly and test is now transitioned to a normal production line, requiring test procedures to be simple, automated, and use low-cost equipment. The output of these manufacturing runs should be high-quality, finished products available for final sale.

These tests should all be performed on one channel (high) and at standard temperature and dc voltage. A simple dc power measurement with the system in deep sleep mode should also be performed.

As the finished products enter the market, it may be beneficial to continue to program the Zigbee (and other) devices during the final manufacturing phase, rather than having parts preprogrammed before assembly, just in case a last-minute software change is required. Low-cost, easy-to-use programming tools should be available from the Zigbee platform supplier or their partners.

Production manufacturing test
High-volume manufacturing focuses squarely on reducing test time for lower manufacturing costs as production volumes increase. With the system software fully proven, devices may be preprogrammed prior to assembly. The Zigbee platform supplier may provide a manufacturing library to be included in the final flash image to support simple tests on the manufacturing line without requiring devices to be reprogrammed. This occupies a small footprint in the precious flash (approximately 2Kbytes) and can significantly reduce overall test time. RF performance testing may be carried out together with a Golden Node:

  • Receive sensitivity measured with the RSSI parameter on the device under test.

  • Transmit output power measured with the RSSI parameter on the Golden Node.

  • Simple DC power measurement in deep sleep mode.

Overall manufacturing tests may use standard ICT and/or final integration test methodologies. The RF performance testing can be done at either the ICT or integration test phases, depending on the overall test flow.

About the author
Andrew Wheeler
is chief technology officer at Ember Corp. He co-founded Ember and was VP of engineering. Wheeler earned his master's in electrical engineering at MIT.

Article Comments - Bring Zigbee designs to high volume
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top