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.
There is still a lot of confusion between the different versions of the 802.15.4 specification.When you mention it, most people immediately think of the original 802.15.4 spec which is otherwise known as 802.15.4-2003. This was the spec that laid the foundation for low-rate wireless PANs (LR-WPANs). The specification described the radio, modulation, bitrate, headers, protocol, and services.

The original 2003 spec had three different radios to choose from when implementing it: 868 MHz, 915 MHz, and 2.4 GHz. By far, the 2.4 GHz radio dominated the product offerings, so much so that there are a many new papers discussing Zigbee co-existence with other 2.4 GHz radio technologies (802.11, Bluetooth).

The main reason that the 2.4 GHz spectrum came to dominate was that 2.4 GHz is a free spectrum in almost the entire world, and also the 2003 spec mandated that the 2.4 GHz would be allowed to run at 250 kbps while the 868/915 MHz frequencies had to run at lower frequencies due to their allowed modulation schemes. For reference, the 2003 spec limited the 868 MHz frequency to run at 20 kbps and the 915 MHz band to 40 kbps using BPSK modulation. Unfortunately, the 868/915 MHz radios never recovered from this and there is still a scarcity of radios at these frequencies.

In 2006, the LR-WPAN working group introduced revisions to the original 802.15.4 specification. The original name of the revisions was called 802.15.4b however since alphabet letters are less exciting than numbers, the industry ended up calling this the 802.15.4-2006 and relegated the old spec to the similarly innovative name of 802.15.4-2003.

Well, I have to admit it. I got sidetracked for a few days. My wife does a lot of acting in independent theater and it turns out that actors and actresses are not very good with computers (if they even own one). So they asked her if she could make the playbill and the pamphlet. Of course she volunteered me to do it so I've been spending the last couple of days brushing up on my Adobe Photoshop, Illustrator, and Indesign skills. With the little time I have between work and the site maintenance, I had to choose between the software and keeping my wife happy. That's a no-brainer. Earning brownie points let's me work in peace and quiet in the future, otherwise if I make her lose face in front of the other thespians, life's gonna be a living hell at home.

So when I could catch a few breaths, I was able to spit out the chip comparison guide which turned out pretty nice. That was actually a benefit of working with the Adobe tools. Indesign is a great piece of software to create layouts including tables. When I started having problems with the HTML tables for the chip comparisons, I decided to do it in Indesign and it was a complete breeze. It even output a nice pdf for me.

On to the development part of this post...