The guys at Atmel came through for me and hooked me up with 2 sets of their AT86RF231 platforms. The timing is perfect because now that the release is finished, the next objective is to port the stack to hardware and get it working. Since Atmel is the only major 802.15.4 chip supplier to hook me up, looks like they'll be the first platform that the stack gets ported to.

The setup is pretty sweet. Two of the base boards have USB connectivity and you can even load the Daintree Basic Edition sniffer (free download from Atmel) on to it. That's good because I've been using a Microchip Zena sniffer (circa 2005) and the software on it is getting a bit aged. Especially since the Zigbee spec went through two revisions since I've had it. 

The other two boards are the same boards that Atmel gives out for their AVR LCD evaluations and development. It has a 128x64 RGB graphical LCD and you can download the software for the graphics widgets from their site. Looks like I'm gonna be havin' some fun. 

The radios are the AT86RF231 boards which aren't available with the low-cost Raven kits. These boards have the AES security engine and the antenna diversity feature so its gonna be interesting to check them out. Especially for the security, that will be the next portion of the stack that I'll be working on. 

Thanks, Ingolf! Let's go clubbing next time you're in Tokyo.

Here are some pictures of the dev kit that I'll be working on for now:

Wow. That had to be one of the most difficult experiences of my life. It  felt like I was passing  a kidney stone. Painful, anxious, but afterwards gratification and relief. After arguing with myself last month, I'm glad that I finally got up the balls to do a release. That was the first time I've done a full release by myself and I have to say that release managers have it pretty tough. At least for the crunch time before a release goes out.

Well, its probably best to reflect a bit on the stack development. First of all, I grossly underestimated the amount of work that a full Zigbee stack would take. When I first started, I had thought that I would be able to finish it after about six months. Unfortunately, that's not the case. I'm going on my seventh month working on it, and there are still a lot of things that need to be implemented.

One of the things I didn't take into account was that the learning curve for Zigbee was much steeper than I had thought. Although I had some minor experience with the spec, a full blown stack development requires intimate knowledge of every detail. I found out that it takes a long time to be intimate with a 600 page spec.

I have to admit that a good portion of my time was also taken up re-writing and re-organizing my code and architecture. As I learned more about each layer, I found that my initial architectural assumptions were incorrect. That forced me to re-write a lot of code and revise the architecture many times, especially on the NWK and application layers.

I think that the code right now is on the right track in terms of architecture. Now that I've been through each layer and experimented with different architectures, I'm pretty sure that the one I have right now is probably close to the one that I'm going to stick with.

Wow. I was finally able to kick that release to the curb. I'll post more details later. I'm pooped...Here is the download info, docs, and some pics...

The release can be found here:

Here's an online version of the documentation:

Docs Link

Here are some teaser pics:



I'm cutting it down to the wire. I have most of the documentation finished and just went through a last linting and testing of the code. I just did some simple tests to make sure that I didn't break anything. I'll be posting the documentation tomorrow and also the code, unless I somehow completely forgot all my Subversion commands.

I've recently been mesmerized by all the stuff happening in the US. I'm still a proud American and hope that the US pulls through the whole financial mess.

Good Luck US!!!

Well, I'm almost finished with documenting the stack. Thank God for Doxygen. I can take care of commenting the code and creating documentation at the same time. Tomorrow will probably be the last chance that I'll have to write documentation for the v0.5 release. I'm going to need to write some prose about how to build the code, operate the simulator, and some general words on the architecture. After that, I need to do a final lint, testing, possibly some last minute cleanup, and then I can upload it on to the sourceforge server. I'm planning on doing it on the last day of this month since I'll probably be cutting it pretty close. Already most of Monday is out for me since I have a meeting I need to attend for work. The upload will happen on Tuesday which means that I'm going to need to bust some ass this Saturday and Sunday to finish things up. *sigh*

I'll probably be going into a quiet period for a couple of days after this is over as I try and catch up on the rest of my life. Other than that, gonna hit up some wine and drink myself to sleep. It is Friday night ya know...

The blog posts are getting a bit sparse as I'm trying to prep for the release. I lost almost a full week accompanying people from the main office of my part time job on customer sales visits. Talk about impending software deadline and I can only sit and listen to PPT presentations. I have some colorful words I want to say about sales calls, PPT presentations, mandatory face-to-face meetings, and old fashioned companies, but right now, I'm exhausted from traveling all around Tokyo hawking chips.

Regarding the release status, I've already started on the documentation, but it will be a bit lean when the code is released. I might have to beef it up later, since my drop dead release date is the end of this month. On that day, the code goes out no matter what condition it's in. I'll try to post another update before the release...

Sorry for the lag in updating the blog recently. I've been so busy with trying to prep the code for a release that I didn't seem to have the energy to post anything. It's difficult to write about Zigbee when you're eating, sleeping, and shitting it.

Seems like there's a lot of activity going on in the wireless sensor networking space. There have been so many press releases recently, especially concerning home automation during the CEDIA show. It looks like next year may be when WSNs start picking up for consumers. 

Some trends I noticed recently were that companies are starting to integrate RF radios into their sensors . I think that this may start to gain more appeal if the WSN markets take off, since the standard WSN node usually consists of an RF module attached to a sensor anyways. Its just more convenient to package them together

And another thing I'm seeing is that company's are starting to make Zigbee end device software with really small memory footprints. I think so far, most companies' end device software is just the router software with the router functions conditionally compiled out (via #ifdef). However I think that if someone wants to make a really small end device, they'd probably have to re-architect it, since there are many optimizations you can make if you don't have the requirement to integrate everything that a Zigbee router needs. And believe me, Zigbee routers need a lot of crap. I think that it should be easy to get an end device down below 16 kB flash and 2 kB RAM, and around that size and below, it would enable a lot of really low cost Zigbee nodes.

As for my software, there have been a lot of bug fixes since I froze the development of my code. I've been implementing a test profile on one of the endpoints and I noticed a lot of problems. Some of it were stupid like the organization didn't make sense, and some of them were rather large bugs concerning bad pointer usage. Horrible...those are real killers.

Anyways, I'm hoping to tie up the testing and fixes by mid next week and start prepping the documentation. After that, it should be all systems go for a source release late this month. This release is a bit stressful so I think I'm gonna take two or three weeks off after it goes out. I haven't had a vacation yet this year, and I can use the free time to play with my new PCB mill. Ha ha ha.

Wish me luck...

I basically finished linting the code, and man, was I surprised. Lint is such an awesome tool. It was finding bugs that would have taken weeks to find, if they could be found at all. Some of the bugs it picked up were things like out-of-bounds errors on arrays, using pointers that were potentially NULL, data type mismatches (yeah, I assigned 16-bit values to an 8-bit variable a couple of times), and more.

It was a bit daunting at first because when I first ran the lint, I had something like 5000 messages. Most of them were bogus, but you still had to figure out why a message would be flagged. The ideal case is to have a clean code base with no lint messages, but this is extremely hard. In some cases, you would need to write the code in a way that would make it easy for the lint tool to understand what you're trying to do. It may sound stupid, trying to write the code to accomodate the tool, however once you see how powerful it is,  it's a small price to pay. Its like having a C expert watching over your shoulder as you code to make sure you don't do any stupid things. 

I did cheat a little and peppered the code with some lint comments. Those are comments that are read by the lint tool so that it knows that the next statement is meant to be written that way, and not to flag a warning. In many of my pointer overlays, I had to do this because the tool didn't seem to like them.

Anyways, after going through lint and catching my stupid pointer bugs and others, I feel more confident about the code. Looks like the next step is to start writing some tests.

Fun, fun, fun... 

Well, I'm pretty much over the minor crisis of confidence I had two weeks ago. Last week was actually a pretty productive week. I got enough of the coding done to handle the things I wanted to include for the first release so I froze the code.

It was a strange experience to go through a sudden loss of confidence. I've learned a lot about myself working on this stack, since its probably one of the largest projects I've ever tried to pull off by myself. Along with the need to improve my coding, I also learned that even having decent technical skills is not enough. My project management skills were sorely lacking. Without a decent idea of how to get from start to release, it was like travelling in a foreign country without a map; you never really know how close you are to your destination. That was what I felt, and it gave me a lot of anxiety. It'd been building up over time, and without realizing it, I had developed a complex about it.

I was also worried about making mistakes on the stack. When you're trying to write something like Zigbee, which is fairly complex, there are so many decisions that need to be made. And each of these decisions bring about consequences that can only be seen later on. In short, its easy to believe that one bad decision can lead to a failed project. At least that's another point of anxiety that I had felt. It's called fear of failure and it leads to perfectionistic tendencies which is usually not a good thing.

However after I spent a lot of time thinking about things, along with a wine bottle, I came to the understanding that mistakes are bound to happen and trying to prevent them all is impossible. Also, since I was intimately familiar with the stack, any mistake that was made could (and should) be quickly corrected. It wasn't the end of the world if a bad decision was made, as long as some decision gets made. If its wrong, then I could just fix it, file it in my stupid mistakes folder, and get on with the development. 

So now, I'm working on improving my project management skills by keeping a working list of things that need to get done to move the project forward. It spans a couple of releases so it should keep me busy for a while and give me the direction that I need. I've also given myself permission to make mistakes, with the understanding that I'm responsible for correcting them. 

With that in mind, I'm feeling renewed motivation and  I feel like I'm improving as an engineer.

So anyways, here's the meat of this post. I froze code development and am currently linting the code. After the linting is finished and cleared, then I'm going to start writing tests against it, especially since a lot of things have changed. I also need to come up with a way to make the tests repeatable and self-checking so I might resurrect my old test fixture I had and keep the simulator just for testing multi-node interaction. 

 And finally, I've included a checklist which was derived from the Zigbee Compliance checklist available from the website.  That way, you can see what's needed for compliance and where the stack development is in relation to it. A lot of the networking and mac points are finished, but you'll see some gaping holes in the app and security layers. Thats because there are many application layer components that rely on security being implemented. FYI, security will need to come in a later release. 

I guess that's about it. Here's the web version of the document , or you can download the pdf from here .

Cheers...and thanks for the support that many people gave me. I don't think I would have made it this far without the encouragement that I've received from everyone...

I've made some important realizations in the past week concerning this project. I've always been a strong starter at things that I attempt, but a poor finisher. Its the syndrome of starting many things, but never finishing one, and it's a problem that I've persistently had throughout my life.

The reason I'm mentioning it is that for the past few weeks, my progress has dramatically slowed. As I get closer to finishing the initial release, the anxiety of actually releasing my code and having it reviewed by the world (the Zigbee world?) has been crippling. I think I've realized this clearly today, since I've barely been able to touch the code for the past week.

It's the same syndrome I've had in the past for big tennis tournaments, large concerts, university exams, etc... and it's all a form of procrastination to escape some type of performance anxiety. In my opinion, the only cure for this is to force myself to release the code, even if its in an imperfect state. Perfectionism is just a means of protecting your ego from criticism, but it usually ends in failure and giving up.

I've been convincing myself that the code needs to be working and bug-free for the initial release, but its actually unrealistic. Without even touching hardware, there's little chance that will happen and in the end, I believe that its more important to get the code out there, than in continuously tweaking minor things. At least it will be a big hurdle for me to get past, and I can use the follow-up releases to get everything cleaned, tested, and working. 

So I will give myself a hard deadline (although slightly generous). I'm going to freeze the code at the end of this month. That will give me enough time to fill in some of the shortcuts I took earlier in the code development, get the application layer in a somewhat satisfactory state, and most importantly, give me some time to start limping back into the developer chair again.

After the code freeze, I'm going to spend about two weeks doing some basic functional testing, and then release the code. It won't be in a usable form, but everyone will be able to see the structure, the organization, and hopefully the potential.

Apologies for keeping everyone waiting for so long. It's been like a marathon and it looks like I hit "The Wall". But I'm going to try and set myself up to climb over it... 

Looks like I made a mistaken assumption in taking the Zigbee application layer lightly. The application layer consists of the application framework (AF), the Zigbee Device Object (ZDO), and the Application SubLayer (APS). I had originally assumed I could crank out the app layer quickly by just implementing a couple of descriptors and some client/server functionality.

However its significantly more complicated than that. The Zigbee spec is kind of a mess at the application layer. The information is dispersed over roughly 250 pages and the partitions between each area of the app layer is kind of blurred. Its taking a significant amount of imagination to try and understand how the spec implementors envisioned the application layer. It takes a couple of passes through the app portion of the spec just to understand what they're talking about and how things fit together.

I started with a simple application framework (AF). Its just one file which handles registering each individual endpoint and the endpoint descriptor (simple descriptor in Zigbee terminology).  So if you had a home automation profile, you would just register the descriptor and endpoint number with the AF. After that, all incoming messages that specify that endpoint will go there. Not too difficult.

The confusing part comes in implementing the ZDO. The ZDO basically manages the whole device and thus it is the main controller for network formation, discovery, joining, etc...  It also has a bunch of descriptors and configuration info that needs to be set on startup. These are all mandatory for protocol compliance. Some examples are the node descriptor, power descriptor, active endpoint list, simple descriptors, device polling rate, etc... 

It also functions as a client and server so certain mandatory functions need to be implemented on both the client and server sides. I had expected this and was able to crank out most of them without too much trouble. 

Nay, the main complexity of the application layer is that it ties the whole stack together. It's like I've been developing individual parts of a car, and now I have to assemble the complete car. It's a bit nerve wracking, since you find that some pieces don't fit well together and need modification. I'm also having problems imagining what the interface into the stack should look like from the user application.

I think the scariest thing is that after the application layer is finished, the stack is supposed to work (sans security). It's like the Shawshank Redemption where you've been in prison so long that you're kind of scared to leave. I'm feeling a bit of a mental block in finishing the remaining portions of the stack because of this.

Anyways, I'm going to try and put a hard freeze on the code soon, depending on the progress moving through the app layer. That way, I can limit the amount of small tweaks that I'm tempted to make and force myself to set a release point. After the code freeze, I gotta figure out a way to put together an automated testbench to test things. The old one doesn't work now that the simulator is multi-process and there are so many variables and inter-relations in Zigbee that its easy to break something by fixing something else. 

Well, I just thought I'd share some of my insecurities with you.