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... 

The team at SICS released a paper documenting their research on increasing the battery life of Zigbee nodes . Currently, according to the Zigbee spec, Zigbee routers and coordinators need to be on and listening all the time which can be disastrous if you're not plugged into a wall outlet or powered by a car battery. 

The paper describes an interesting approach where you introduce a power savings protocol (X-MAC) in between the 802.15.4 MAC layer and PHY layers. That way, the Zigbee network and application layers don't need to change and you get the power savings benefit. One of the researchers, Pablo Suarez, ported the Open-ZB stack from TinyOS to Contiki and implemented some mesh routing functionality to it to evaluate the X-MAC's power savings protocol. Their paper claims a 90% reduction in power consumption (or conversely a 1000% increase in battery life). The downside is that all devices on the network would need to support the X-MAC. But for a 10x battery life in a remote system, it might be worth it! This would be great for remote projects if they could reduce the power consumption and use some form of energy harvesting.

Here's the paper's abstract: 

I put together a Zigbee/802.15.4 chip comparison guide. There is another one up on the web , but it hasn't been updated since 2004. I thought I would put together the 2008 version since a lot of the info on the 2004 chart is a bit obsolete. Such as:

  • The AT86RF210 is EOL'd
  • CompXS was purchased by Integrated
  • Ember's EM2420 was a re-marked CC2420 which disappeared after TI purchased Chipcon
  • ZMD no longer makes their Zigbee chip. I think they cut some deal with Renesas which gave them the IP
So I figured it was time for an update. I don't guarantee the accuracy of the tables, although I took all of the information from the datasheets on the vendors' websites. Also, I initially tried to do it in HTML tables, but HTML tables suck. So I put the tables together in an external program and then exported it as a JPG. Hopefully, you can read it. The first table is a comparison guide for transceivers only. You can click on it to get the full JPG. All values are "typical" unless stated otherwise. The font is a bit small due to the size of the table so I've included a PDF document at the end of the post in case it's difficult to read.

Zigbee Chip Comparison - Transceivers

The second comparison table is for integrated MCUs + Transceivers. The integrated category is quite complex and I might expand this one later.  Integrating an MCU and a radio is difficult because many features come into play: ADC, ADC Resolution, number of timers, types of timers, GPIO, development tools, architecture, etc... I might need to make a more comprehensive list, but here is the first stab at it. Regarding the power consumption values, in cases where a multi-chip module are used (they just stuck an MCU and a radio die on the same substrate), the power values are given as separate MCU and RF numbers since I couldn't get the actual total consumption value. If anyone can correct me on these, please let me know...

I have to say that the Zigbee Alliance marketing machine is doing a pretty good job. I stumbled across a little known service offered by Google (at least little known to me) called Google Trends . It's pretty interesting. It shows the amount of search volume for a particular keyword over time and it can be used to infer the popularity of a term. Here's an image of the Google Trend for Wikipedia spanning from about 2003 until now.

Wikipedia on Google Trends

It pretty much makes sense. There wasn't a lot of action going on until about 2005 when Wikipedia started really taking off. People started generating content, which in turn increased the traffic to the site, which in turn inspired other people to contribute to the content.

Well, my point isn't to show you the popularity of Wikipedia. I actually did a search for Zigbee and found something quite interesting. If you look closely, you can see that the number of searches is relatively constant over time, with a slight decrease over the past two years. That's not very impressive. However if you take a look underneath the trend, there's a figure that's interesting. It shows the number of news references for Zigbee over time is increasing. It was fairly flat from 2003 to 2006 with a couple of spikes, probably corresponding to significant press releases. By the way, the square with the 'A' in it marks the time when the first Zigbee spec was released.

Zigbee on Google Trends

If you look at the trend from 2007, you can see that the news references get much busier. This means that Zigbee is showing up a lot more in the news. This could mean that the Zigbee Alliance is issuing more press releases, but normally, this has the effect of numbing the publications to the releases so that fewer get picked up. In my un-expert and un-professional opinion, this probably means that more companies are either releasing Zigbee products or are announcing that they will be adopting the technology in one form or another. I guess it could also mean that more companies are getting frustrated with it, but let's hope that's not the case. Hmmm...Not bad, Zigbee Alliance!

The trend pretty much follows in the footsteps of Bluetooth which formed the Bluetooth SIG in 1998 and didn't really catch on until about 2005 or 2006. I think it's about that time when I started noticing people seemingly talking to themselves with only a big-ass earbud in their ear and no wires hanging out. I also checked for Bluetooth on Google Trends, but unfortunately, it looks like their data only goes back to 2003. The search volume at that time was also fairly constant already, but if you look at the news references, it starts getting busier around 2006. Here's the chart: