Five Myths about Zigbee to consider before selecting a wireless solution for your application
>Myth one: Zigbee is low power
Zigbee is low power when compared with Bluetooth or Wi-Fi, but it is not anywhere near as low power as is possible.
- The protocol carries overheads which add to on-time for an end device to transmit a data packet, while a custom design can trim the overhead to be just what is required to send a message and no more. Zigbee radios require about 10x more time to connect and communicate than optimized low power solutions. And there’s even more message overhead when using a Zigbee application profile.
- At a system level, the reliance on a mesh topology to attain range requires multiple high-powered routers, Choosing a different frequency or higher powered RF channel will sometimes provide range more efficiently – it all depends upon the application environment. Selecting the radio and designing the protocol for the application can significantly drop power needs.
- Paradoxically, a high density Zigbee network can become saturated with network management traffic, impacting throughput and further increasing power consumption.
Lighting Example:- one Industry’s struggle with standards-based wireless networks.
“… some industry participants aren’t sold on ZigBee as the basis for a lighting network, or in a larger sense, a network of smart devices that pervade our lives.” – Use of controls escalates in LED lighting despite lack of standards; LED Magazine Feb 2012
“ZigBee […] makes a modest Lightfair impression, but in general, proprietary remains the norm in the lighting-control schemes that are vital to SSL uptake.” – Control technology for LEDs and other lighting remains fragmented at Lightfair; LED Magazine May 2012[/right_text_box]
>Myth Two: Zigbee is low cost
- Zigbee has a large software footprint, partly driven by its high stack needs, and by standards-compliance needs. Zigbee devices need more memory and higher powered micro-controllers than application specific designs. Zigbee requires ~100kB memory vs <16kB for a custom solution.
- Certified Zigbee modules, typically without the ability to add application code, are 5-10X the cost of a custom radio added to a product. Even when designing from chip level, most product designers using Zigbee end up with a second micro-controller running the product application.
- The entry cost of developing a Zigbee solution is often overlooked: development tools, training, ramp-up and familiarization time, licenses often run to tens of thousands of dollars.
>Myth Three: Zigbee is an ‘easy’ development, with low NRE and fast design cycle
This may be the case for trivial applications and where the need exactly matches an existing Zigbee application profile, but is less true in most real world applications.
- Setting up a complex Zigbee application requires a deep familiarity with the details of the chosen Zigbee protocols and the network topology – it’s all too easy to create a Zigbee network which doesn’t quite meet your application’s needs, but then find that your remedies are limited by the protocols. Many product designers look back after completing a Zigbee implementation with a view that “it would have been easier to have created a custom system”.
>Myth Four: Zigbee is an ad-hoc, self healing network
Nearly, but only “with a little help from my friends”.
- Configuring a Zigbee network can be a considerable exercise in its own right; automatic configuration and healing requires significant intelligence and complex algorithms to be programmed into the application. The problem of orphan nodes (nodes that cannot find a valid router, even though the network is below capacity limits) can be significant and require complex time and power consuming solutions. If the network layout changes, then the configuration process may need to start again.
- A Zigbee network requires that it knows its own configuration (owned by the “Coordinator”): Routers, once identified, need to stay put. Routers that go-off-line or move can also leave behind orphans which can be problematic to clear up (and this is up to you to do).
>Myth Five: Zigbee is long range
Through its meshing capabilities, Zigbee can attain long range. However, this comes at a price and there are nearly always better ways to achieve range in an application specific application.
- While long range can be achieved by mesh configurations, the price of meshing is lost efficiency, in spectrum usage and power consumption. Often it is better to achieve range directly (e.g. by sacrificing data rate, choosing other frequencies, etc.).
- The 2.4GHz band primarily employed by Zigbee is limiting – lower range in air, more blocking by solid objects and water, interference from other devices. For many applications, 900MhZ bands, or 433 MHz offer much better solutions (as in the lighting example in the sidebar). In theory Zigbee supports other frequencies; however, in practice, such implementations are rare, off the mainstream and harder to develop.
Why, oh why, is it not simple to have Zigbee give me what I need?
Simply put: the dilemma of universal vs. optimized. Zigbee is a standard: intended to provide interoperability in many market areas. That is both its strength and its weakness. If your application demands that you interoperate with other devices form other manufacturers, then Zigbee can be a great solution. However, interoperability and universal applicability has a price and the myths we outline above start to reveal some of this price.
It is because of this that other standards continue to emerge to “compete” with Zigbee (e.g. EnOcean, Wave2M, Z-wave, ANT, 6LoWPAN, ISA100, Google Android@home, to mention just a few). It is also the reason that Zigbee itself fragments (core, PRO, IP, RF4CE) and its standards proliferate even in similar application spaces (11 profiles so far, and counting). Finally, it is the reason that so many industries, such as the lighting industry, find themselves unable to rally around a single standard.
It is the reason that people continue to develop custom solutions and that Venture’s partners use RFOS to develop truly optimized “application specific integrated wireless” solutions.
