Designers must choose between developing their own hardware and software from scratch, and integrating a proven Zigbee module solution.

Hardware selection
In developing a Zigbee solution, the first step is to determine the hardware platform that will be used. Typically, a hardware platform consists of either a chipset or a module.

The Zigbee Alliance has defined a Zigbee Certified Platform (ZCP) certification for platforms that are verified to be capable of supporting a Zigbee solution. If the Zigbee end product should carry the Zigbee logo and be marketed as a Zigbee-certified product, the hardware platform and Zigbee software stack must be certified as a Zigbee-compliant platform.

Modules offer substantial advantages over a chipset. Selecting a module spares the developer the cost and pains of RF frontend design, board prototyping, production testing and EMC testing.

Figure 1: Zigbee defines three node types - a coordinator, router and end devices.

Module providers have often been through rigorous testing of the application and network stack, and have added features to simplify the Zigbee interface.

Some module providers offer a flexible alternative if the module firmware does not meet all the needs of a particular application. In some cases, designers can develop their own application on the module hardware and customize the Zigbee application for their own needs.

Such a solution requires some firmware development, but still frees up the time and costs associated with RF design, prototyping and EMC testing.

If a chipset is used, the designer must be prepared to support the extensive design, test and production requirements of a radio design. Using a chipset on a custom board requires supporting the hardware production process, including board-level testing, debugging and rework.

If this path is chosen, a 24bit organizational unique identifier must be obtained from the IEEE to assign a unique 64bit address to each unit.

If a chipset is used for a custom board, the designer must also select a Zigbee network layer stack. The designer must port the stack to their hardware, test the Zigbee application carefully and evaluate the network performance.

Many or all of the unresolved Zigbee issues may need to be addressed by the application, which will add significant overhead to development time.

If it becomes necessary to develop custom firmware on a chipset or module platform, the following steps can be helpful:

Step #1: Select a profile type.
To begin developing a Zigbee application, the designer must determine whether a public or private profile would best fit their needs. Is the device meant to be compatible with generally available Zigbee devices, or is the product intended for a specific application?

Should the settable stack parameters be adjusted to optimize performance? If a private profile makes more sense, a request must be made to the Zigbee Alliance to obtain a private profile.

Step #2:: Determine routing strategy.
The developer should consider whether tree routing should be allowed. For simple, static networks, tree routing may suffice. If nodes could potentially go down and/or reliable data delivery is required, tree routing may be insufficient. In this case, time should be spent evaluating when the stack invokes route discovery.

If the selected Zigbee stack is compliant with the enhanced Zigbee specification, the application layer can take advantage of the network layer management entity (NLME) route-discovery- request primitive and the nwkUseTreeRouting attribute to control route discovery and remove tree routing. (Figure 2, below).

Figure 2: The enhanced Zigbee specification added a nwkUseTreeRouting attribute that can disable tree routing (Top) entirely, and a (NLME) route-discovery requestprimitive to force route discovery as needed. This takes full advantage of mesh routing (Bottom).

If mesh routing is used, the developer should consider how the system performs when all of the routing table entries are used.

Since the Zigbee specification makes no provisions for aging or expiring routing table entries, some Zigbee stack implementations don't remove old entries.

Once all of the routing table entries are used, the device can no longer participate in route discovery. If the stack doesn't age or replace outdated entries, the application should add its own provisions to do so.

Step #3: Consider fixed-channel operation.
For many applications, a Zigbee network can operate reliably on a fixed channel, even in the presence of occasional interferers.

However, for systems that must coexist with other systems in the same frequency band, or that cannot tolerate occasional packet loss, it may be necessary to support channel migration.

Since the existing Zigbee specification does not currently have a defined mechanism to do this, the application developer can decide on conditions to move a network to a new channel and develop a solution to accomplish this.

Step #4: Overcome addressing limitations.
In many applications, the current network address assignment mechanism may be sufficient.

However, to prevent the possibility of address duplication, a robust Zigbee solution should have a mechanism to reset the network addresses in the network (e.g. if a coordinator is replaced).

Since the network address of a device is unreliable and could change (e.g. if the device cannot discover its parent after a power cycle or reset), the application may also require a solution to uniquely identify each node.

Some Zigbee solutions rely on the unique 64bit addresses to ensure that data is delivered to the correct device. If such an approach is used, the application must include provisions to resolve the 64bit address to a 16bit network address prior to transmitting data.

Step #5: Testing.
This should include efforts to verify how the system reacts to applicable scenarios. How does the system respond when a router is turned off? How does the system perform when interference occurs on the operating channel?

If a device receives a new network address, how is the new address discovered? Some module and stack providers have developed provisions to deal with these issues, offloading a significant burden from the application developer.

Damon Stewart is a firmware engineer at MaxStream Inc. To view a PDF of this story, go to "Build reliable Zigbee-based solutions."