Some tips on building a reliable Zigbee-based wireless control network -

Some tips on building a reliable Zigbee-based wireless control network


With the growing market visibility and momentum of Zigbee, there isgreat value in deploying a certi- fied Zigbee solution. Recent advancesin the Zigbee specification have made it possible to develop a reliableZigbee solution using the current framework.

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

Hardware selection
In developing a Zigbee solution, the first step is todetermine thehardware platform that will be used. Typically, a hardware platformconsists 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 ofsupporting a Zigbee solution. If the Zigbee end product should carrythe Zigbee logo and be marketed as a Zigbee-certified product, thehardware platform and Zigbee software stack must be certified as aZigbee-compliant platform.

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

Figure1: Zigbee defines three node types – a coordinator, router and enddevices.

Module providers have often been through rigorous testing of theapplication and network stack, and have added features to simplify theZigbee interface.

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

Such a solution requires some firmware development, but still freesup the time and costs associated with RF design, prototyping and EMCtesting.

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

If this path is chosen, a 24bit organizational unique identifiermust be obtained from the IEEE to assign a unique 64bit address to eachunit.

If a chipset is used for a custom board, the designer must alsoselect a Zigbee network layer stack. The designer must port the stackto their hardware, test the Zigbee application carefully and evaluatethe network performance.

Many or all of the unresolved Zigbee issues may need to be addressedby the application, which will add significant overhead to developmenttime.

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

Step #1: Select a profile type.
To begin developing a Zigbee application, the designer must determinewhether a public or private profile would best fit their needs. Is thedevice 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 optimizeperformance? If a private profile makes more sense, a request must bemade to the Zigbee Alliance to obtain a private profile.

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

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

Figure2: The enhanced Zigbee specification added a nwkUseTreeRoutingattribute 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 thesystem performs when all of the routing table entries are used.

Since the Zigbee specification makes no provisions for aging orexpiring routing table entries, some Zigbee stack implementations don'tremove old entries.

Once all of the routing table entries are used, the device can nolonger participate in route discovery. If the stack doesn't age orreplace outdated entries, the application should add its own provisionsto do so.

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

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

Since the existing Zigbee specification does not currently have adefined mechanism to do this, the application developer can decide onconditions to move a network to a new channel and develop a solution toaccomplish this.

Step #4: Overcome addressinglimitations.
In many applications, the current network address assignment mechanismmay be sufficient.

However, to prevent the possibility of address duplication, a robustZigbee solution should have a mechanism to reset the network addressesin 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 orreset), the application may also require a solution to uniquelyidentify each node.

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

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

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

Damon Stewart is a firmwareengineer at MaxStream Inc. Toview a PDF of this story, go to “Buildreliable Zigbee-based solutions.”

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.