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:

The APS layer, also known as the application sublayer, is the top of the main data path in a Zigbee stack. Th only things that lie above it are application objects, which are implementation specific. The APS layer handles data transmission and reception as well as table management. The main tables that are located in the APS layer are: binding, discovery cache, address map, and endpoint grouping tables. We'll discuss the tables later on when they get implemented. Right now, I'd just like to focus on reliable and unreliable data transmission.

The APS data service is the main vehicle for device discovery and management. The application objects use this service to communicate descriptors to each other, handle client/server communications, and perform remote management and provisioning. The data path for this layer can get a bit complicated due to the many options available for transmission and reception. The binding, grouping, and address tables are all used when building the frames. However on a fundamental level, there are only two types of transmissions: reliable and unreliable. Reliable transmission is transmission which requires an APS level acknowledgement from the destination device. Unreliable transmission is when you just send it out and you don't care if it arrives or not.

The IEEE 802.15.4 spec already implements a form of acknowledgement, but this is a PHY layer acknowledgement. Since most 802.15.4 radios implement the ACK in hardware, the 802.15.4 ACK just says that the frame was received into the chip's FIFO properly. The APS level ACK says that the frame was processed correctly as well, which is very important. Many things could go wrong from the PHY to the APS layer. Some examples of dropping a frame between the PHY and the APS processing are:

1)    The received frame requires routing, but no route can be found for it.
2)    The received frame goes to a router with no routing resources and no tree routing ability.
3)    The MAC doesn't pull the received frame out of the chip's FIFO quickly enough and it gets overwritten by another frame.

If a reliable transmission is needed, then an APS frame with the ACK required is probably the safest way to send it. However it also is costly in terms of performance.
I normally try to update my blog everyday. However I'm getting killed by the pollen levels in Tokyo . It feels like I'm getting hit by a mutant form of the common cold. I'm just going to curl up with a beer and watch Entourage on the internet.