Factors to consider when selecting a Zigbee controller for your design - Embedded.com

Factors to consider when selecting a Zigbee controller for your design

The Zigbee networking standard has slowly but surely taken up animportant share of the wireless market. Vendors of Zigbee products areincreasing, and more and more types are coming out. With theincreasingly fiercer competition, the number of providers payingattention to Zigbee's declared features – low cost and low powerconsumption – has grown, hence the increasing popularity of thesingle-chip solution.

Users have opened up to the single-chip solution for its potentialto dramatically reduce the cost, shorten the development cycle andaccelerate time-to-market, thus taking a positive role in the promotionand application of Zigbee. However, some limitations have cropped up asa result of this diversification.

Figure1. The performance of the controller that manages the Zigbee networkcoordinator must be higher than that for other network devices.

Introducing the 'brain'
As shown in Figure 1 above, a Zigbee network has three device types:the coordinator, the router and the end device. The coordinator is theso-called “brain” or center of the entire network, responsible forfunctions such as setting up, maintaining and managing the network, andallocating network addresses.

Because it undertakes many tasks, the performance of the “brain”manager must be higher than that for other network devices. For simplenetworks or applications, the same controller can be used for the threedevice types.

However, the burden on the network coordinator becomes heavier asnetworks expand and applications grow more complex, graduallysurpassing the capability of the single chip. In the same token, Zigbeeend devices and routers need controllers with lower cost and powerconsumption due to their relatively simpler functions.

Figure2. Several factors must be considered when selecting a controller.

Evaluating Zigbee controllers
Various controllers offer Zigbee users a lot of alternatives, making itdifficult to select the appropriate product. One's choice must beconsidered seriously because the controller picked for the Zigbeenetwork coordinator is related to the development of the entireproject.

As shown in Figure 2, above, the following factors should beconsidered –

Performance. For the normal operation and managementof a Zigbee network coordinator, a high-performance controller withmore powerful computing and processing capabilities must be employed.Here, high performance is relative to the end device or router in theZigbee network.

A 32bit MCU can be selected, as well as the 8bit and 16bit MCUs usedbefore. Although the performance and main frequency speed of 8bit and16bit MCUs are increasing continuously, the inherent bus width stilllimits their computing and processing capabilities.

For instance, the network address allocation, routing tablemaintenance and management in a Zigbee network all need large amountsof computation.

The 32bit MCU undoubtedly has the advantage in this regard.Moreover, the 32bit MCU also has greater advantage when implementing aconnection between a Zigbee network and another network.

While the higher processing capability would surely lead to anincrease in power consumption and cost, the network coordinator, whichusually uses the main power supply instead of the battery, needsminimal energy requirements. In terms of cost, the price of the 32bitMCU has gradually dropped, and some low-end 32bit MCUs are even cheaperthan many 16bit MCUs.

Considering performance above cost and power needs when selecting acontroller for the network coordinator device is, in the end, the mosteconomical route because Zigbee end devices and routers, which make upthe main equipment for the entire Zigbee network, are mostly low-pricedproducts.

On-chip resources. For a controller'son-chip resource, first consider whether its peripheral modules meetthe basic application requirements. For instance, there should beenough interface available for the wireless transceivers to connect to.

Also account for whether there are enough modules for thedevelopment of different applications. This is not to say the more thebetter, but rather the closer to the needs the better. Too manyperipheral modules unused will not only mean more expenses but also anincrease in power consumption.

Another factor that should be considered is embedded memory space.Because the Zigbee coordinator is the central node of the network, theprotocol stack software for the “brain” takes up much space. Theexisting typical stack usually takes up over 40Kbytes flash memory and2Kbytes RAM.

If the embedded flash memory and RAM are low, the space left foruser applications becomes too small, forcing users to shorten andoptimize their codes with the greatest effort. For those applicationswith many application codes or need flash to store user data, usershave to give up once memory becomes insufficient.

Therefore, a network coordinator should use a controller with alarge embedded memory to leave enough room for users to writeapplication programs. Keeping the margin of memory space at a certainlevel is also helpful for product maintenance and upgrade.

Development tools. Although a networkcoordinator uses different controllers from those used by other networkdevices, its development tool should be consistent with that for otherdevices. If different development tools are used, suffering variouslosses is inevitable. First, the development cost will increase – moremoney will be spent if more than one type of development tool is used,and more engineers would possibly be needed to operate each tool.

Secondly, the workload will increase – engineers will take much timeand energy to learn and use the different products and developmenttools. Finally, the development cycle will lengthen, and the speed oftime-to-market and promotion will slow.

Compatibility and upgradeability. During product development, future maintenance and upgrade should beconsidered given today's fast-changing society and as product lifecycles become shorter.

Therefore, the developer must reflect on compatibility andupgradeability issues when selecting controllers to avoid added costs.Generally, one chooses a midrange controller in the initial phase ofdevelopment.

Once the development is finished, the controller may be replacedafter the practical proof. If performance of the controller used nowhas much margin, lower-end products can be chosen.

As time passes, an upgradeable controller may be used to, forexample, connect the Zigbee network with an Ethernet network. In aword, the controller selected for one's network coordinator should beflexible enough to provide compatibility with low-end products whilehaving the capability to upgrade to highend applications as well.

Providers. One last point that could beeasily overlooked is the providers that should be considered whenselecting controllers.

Providers that have proven product systems and stable offeringcapability would be perfect for the job. Generally, these kinds ofproviders have a complete and mature set of controllers, excellentteams for technical support, competitive product prices and stableproduct offerings – factors that are very important to users.

Using a proven product provider helps raise the quality of a user'sproduct and shorten its testing period. Selecting the better providerwill get twice the result with half the effort.

A complete offering of various controllers provides opportunity toselect products close to a user's needs and facilitate compatibilityand upgradeability. An excellent technical support team helps userstroubleshoot and speed up development. Competitive price andcontinuously stable offering capability can guarantee that theproduction and user's product can be continued even after severalyears.

The five factors discussed are some points that engineers shouldconsider when choosing a controller for their Zigbee networkcoordinator. Because they are related to one another, a complete andthorough study should be performed and each factor weighed during theselection stage to get optimal results.

Patrick Yang is an Applications Engineer at Freescale Semiconductor

Leave a Reply

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