ZigBee Wireless Networking
What Venture Capitalists Won't Tell You About Wireless
By Mike Fahrion, B&B Electronics
"There's a murky aspect of ZigBee (802.15.4 wireless mesh networking) that most vendors are reluctant to talk about - but you're going to find out about it sooner or later.
So we might as well get it out in the open now.
The Murky Aspect is the fact that "ZigBee" can mean a half dozen different things, none of which are necessarily compatible with each other. Actually, ZigBee does only mean one thing since the standard was ratified in December. But the ZigBee term has already become the "Kleenex" of mesh networking. The majority of mesh networking protocols available today are not compatible with one another.
Remember the "fieldbus wars" of the late 1990's? If you're in the automation business, you watched the battles between DeviceNet, Profibus, Interbus-S, SDS, AS-I, Foundation Fieldbus and numerous others. In the HVAC business it was (and is) LonWorks, BACnet, N2 and more. In the IT world, it was Ethernet, Token Ring, and Local Channel. None of these networks are compatible with the others.
The parallel today in wireless is that ZigBee defines a "one size fits all" networking protocol, but it lacks key features such as frequency diversity and router power management. Implementation of these details is proprietary. There is a big difference from the fieldbus wars, though. Most all of the sensor mesh protocols are built on top of an 802.15.4 radio. That congruity means that there has been a lot of effort put into making 802.15.4 a stable and robust platform.
Eventually the marketplace battles will declare a few winning configurations (hey, that's what the Venture Capitalists are in the game for). But until then, if you implement ZigBee, you'll probably be using a proprietary protocol rather than the newly ratified standard.
Now remember, that's not necessarily bad. Wireless Mesh networks are supposed to be synergistic, i.e. the more nodes you have, the more redundant your network is, because you have more paths for data to travel. But it also means that nodes are busier, batteries may run down faster, and data is available at more points. Do you want that? You may not.
Let's say you install a dozen ZigBee nodes for reporting tank levels in your facility. A couple of years later, a system integrator comes in and installs a wireless network for the fire alarm system. Do you want those nodes to talk to each other? You may not want them to, in which case you don't mind if the new system isn't compatible with the old. In fact that incompatibility is good.
Some proprietary ZigBee implementations claim to be superior to standard ZigBee in various ways, but to my knowledge, nobody has rounded up all these vendors' products and tested them side by side.
One thing that's different about ZigBee, compared to the fieldbus wars of 5-10 years ago, is that there's no major industrial equipment vendor (i.e. an Allen-Bradley or Siemens) driving ZigBee with a specific agenda to support an existing installed base. ZigBee standards are going to be driven more by large chip vendors, who hope to someday have one of their chips in every industrial motor, every sensor, and perhaps even every door bell and smoke detector too.
So this battle isn't going to be fought in front of the users, it's going to be an OEM battle that happens behind the scenes. The winners will be those who provide broad support of a number of formats, make them invisible to me and you, and make it easy for device manufacturers to make and support.
You'll want to be sure to choose a vendor that understands what works together, what doesn't, and that can tell you who's blowing smoke and who's telling the truth.
Jump in, the water's fine."
There's no substitute for hands-on ZigBee deployments. Contact the engineers at SSI Embedded Systems Programming for more information about ZigBee or to discuss your next wireless networking product.
|
|
|
| EMBEDDED SYSTEMS NEWSLETTERS |
|
|
|
|
|
Company
