I got a question on how you could use the Z-Wave routing method on a Zigbee router, but still stay compliant to the Zigbee spec. The reason I got this question was probably because of the article I posted on Zigbee vs. Z-Wave . The Z-Wave protocol implements a light version of mesh routing by using only source routing and the Z-Wave controller is the only device capable of originating a source routing frame. For those that don't know, source routing is a method of mesh routing, where you embed the complete path to the destination within the frame. Why would you want to use the Z-Wave style of routing with a Zigbee device? To make a cheap-ass router, dummy.

Seriously, the Zigbee spec, although supporting many features, is too heavy for a lot of consumer applications. For home automation especially, cheap devices need to be created that can use the benefits that Zigbee has to offer like mesh routing and interoperability, but they can't be too expensive. One way to decrease the RAM and flash requirements is to get rid of AODV mesh routing and just use source routing, a la Z-Wave.

The Zigbee 2006 spec also supports source routing, however this does not seem to be a widely known fact. Most Zigbee articles focus only on the AODV mesh routing which uses the routing tables. Or even worse, that only Zigbee Pro supports source routing. The reason that source routing probably does not get a lot of airplay is that the spec implements it in a rather awkward way. If you do it according to the spec, the method of route discovery requires that you already have the route located in your AODV routing tables. This is useless because if you already have the route, then you don't need to do source routing. Maybe its difficult to explain so I'll try and give a rough example. Say you want to source route a frame from point A to point D. If you are starting fresh with no routes in your routing table or source routing table, this is what you would have to do.

April Fools Day is coming so I thought I would compile a list of pranks that the Zigbee Alliance can play on us.  

Top 10 April Fool Jokes that the Zigbee Alliance can play on us:

  • Hide yo momma jokes randomly in the spec and see if anyone finds them.
  • Zigbee 2006 will be obsoleted and only Zigbee Pro will be supported.
  • Announce a policy of annual Zigbee spec revisions with no backwards compatibility.
  • Microsoft will be joining the Zigbee specification committee.
  • Note: They authored the 8000 page OOXML spec, and are believed to be corrupting the vote currently going on to adopt it.
  • They announce a new layer with an additional multi-hundred page spec on top of the 500 page Zigbee spec and 300 page 802.15.4 spec.
  • They spent too much money at the last few open houses so the next one will be at the Motel 6 in Oakland.
  • motel 6
  • Announce an investigation into creating a new adult toy profile.
  • They make 802.15.4 beacon mode and guaranteed time slots a requirement for Zigbee compliance testing.
  • I become the official spokesperson for Zigbee.
Yes I realize there are only nine. My special number font only went up to nine.
It's been a pretty busy week for me. Been writing code all week, but still struggling to balance coding, blogging, and the j-o-b.

I got the mesh routing functions running and wrote some basic tests for it. The tests took longer than expected to write because the mesh routing consists of multiple steps. For example, to test route forwarding on an incoming packet, I had to generate an incoming frame, wait for the route request to come out of the stack, process the request in the test, generate a route reply, and then wait for the final forwarded frame to come out. What a pain in the ass. But without that test, it would have been hell debugging the code in a live system.

Since I had to parse so many headers, my eyeballs got tired and I decided to implement an automatic header checking system. I wrote a simple checking engine that you load with the expected values and when the frame comes in, it'll parse it and make sure that the header values are what I expected. I also implemented it so that it would check the headers in the MAC, NWK, and APS layers separately.

There's been more and more attention being focused on wireless home automation recently and the two biggest candidates for it is Zigbee and Z-Wave.

Readers of this blog probably don't need much of an introduction to Zigbee because this blog is basically about it, or at least my adventures diving into Zigbee as I write my software. You're also probably aware that there has been a lot of mudslinging (ie: shit talking) between both camps, Zigbee and Z-Wave, as well as an ongoing flame war. So in an interest to educate myself on the real issues behind the talk, I decided to do some research and comparison between Z-Wave and Zigbee. I should note that a lot of the information was just pieced together via the internet since the Z-Wave specification is not public. A lot of the material in this post borrowed heavily from the information found in this article. Since there is not a lot of technical data publicly available for Z-Wave, I recommend perusing this article in Dr. Dobbs Journal since it's an excellent introduction.

Z-Wave and the Z-Wave Alliance is a group that was established around the proprietary wireless networking protocol developed by a Danish company called Zensys. The Z-Wave protocol was designed to be a lightweight protocol for home automation that would be low cost yet still could support mesh networking.

Lets begin with a look at the device types specified by Z-Wave...

Well, it was home to me for over two decades of my life, but I can't say I miss it much. My old hometown was in Irvine, CA in the US and I was suprised to see it make the news . Nothing too exciting usually goes on there...just your average suburbia life. Well, except for the one time they found out that the Florida Cocaine Queen lived there. However I did start noticing the last few times I went back that kids ten years younger than me were driving around BMWs and frantically talking on their fat phones (crackberries). And the guys I knew that used to sell drugs were now selling mortgages. But I guess I never put two and two together to see that it was so addicted to <gasp> subprime </gasp>. Well, at least when I go back to visit my parents, I won't feel like such a poor slob driving around my $9/day rental (Priceline).

Irvine Spectrum

After finishing the simple routing simulator that I wrote in C, I was confident that my implementation of the routing algorithm would work. So I then started to integrate the code into the main Zigbee NWK layer. I had to make a couple of decisions, and as usual, there were tradeoffs associated with the decisions.

One of the decisions I had to make was how to handle route discovery. According to the spec, there are two methods to initiate route discovery. The first is that the route discovery service is invoked by a higher layer (APS). The second is that a frame arrives with the route discovery option set (in the NWK frame control header) and the destination address of the frame does not exist in that device's routing table. My problem mostly dealt with the second option, which is a frame with an unknown destination arrives. How should it be handled?

There were a couple of options, but the two most obvious ones were:

  1. Keep the frame and initiate route discovery. Don't forward the frame until the route reply arrives (giving the route) or the route discovery times out.
    • Advantage: Simplest method. Consumes least resources (RAM, code size).
    • Disadvantage: Performance suffers. Cannot process other frames until current one is finished. Route discovery can potentially take up to 10 seconds. 
  2. Buffer the frame in a waiting queue and initiate route discovery. Continue processing other frames until a route reply arrives.
    • Advantage: No hit in performance. Seriously, 10 seconds is tooooo long.
    • Disadvantage: More complexity. Yet another queue that needs to be implemented. RAM and flash required to implement.

Well, well, I feel much better now. The taxes are behind me, my wife's play program pamphlet that I had to work on is finished, and I took care of some other small errands that I needed to do. Other than that pesky job thing, I have a plethora of free time now, so I thought I would burn some of it by rambling on in my blog.

One of the interesting things about this blog is that it was originally just meant for me to archive my development progress on the software stack that I'm working on. From that, it somehow morphed into a news and information site. Probably my fault, since writing about Zigbee gossip is more interesting than writing about buffer handling. 

Well, that's beside the point, but I do thank the people that emailed me and expressed their appreciation, suggestions, and comments. One of the changes to the site is that there was a management shuffle and my dog is now the CEO . Any problems or disagreements with the content should be taken up with her. You can email either of us via the Contact button.

Some other things that I want to do in the future are:

  • Add more comparisons. The chip comparison seemed to be well liked and I'm now thinking of adding some other ones that at least would interest me. Some examples are: Zigbee module comparisons (since not everybody wants to design a Zigbee board from scratch), wireless sensor protocol comparisons (since not every protocol is a good fit for every application), and an enhanced version of the Zigbee SoC comparison which focuses on the MCU since dev tools and MCU peripherals didn't get quite the attention they deserved in the last one.
  • A layer-by-layer Zigbee tutorial. There are a lot of tutorials out there that are quite good but paint broad strokes and leave a lot of the technical details out. I want to put together a tutorial that's less directed at the general public, and more towards the techie types that are actually doing an implementation.
  • Flash-based interactive tutorials. I've been studying flash recently because it's kind of cool. No I'm not going to put a Flash movie on the opening page. I've simply realized the limits of trying to explain something like the AODV routing algorithm with words. Even pictures can't do it justice because you need to see it in an action sequence to fully grasp how the mesh routing protocol works. Flash is probably the easiest way to implement something like this. Anyways, can't hurt to learn something new. By the way, do you know how many web technologies and programs you need to learn just to put together a simple site like this one? It's mind boggling!
That's basically it for my upcoming plans. Can't say for sure when I'll be able to finish them, but at least there's a place for them inside my littered brain. It's actually quite a lot considering I can only spend about 1-2 hours a day on the blog if I'm lucky. Of course this is all dependent on keeping the wife off my back during the 'me' time. Until then, sayonara.