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:

http://sourceforge.net/projects/freakz/

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

Yaa-Taa is a Japanese expression for excitement. You hear it a lot in anime, which is probably where I picked it up.

Anyways, I just finished multiple 10kB file transfers over four Zigbee router hops in my simulator and the remote files were identical to the originals. It looks like my data transfers are pretty solid now. One step closer to getting this bad boy out...

Now since its a Sunday, I'm going to have a glass or three of wine and watch some anime.

Cheers...

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

Greetings from the land of endless rain.

For some reason, the rainy season came early to Japan and its been raining for almost two weeks straight here. I didn't realize it before, but when it rains this much, it becomes very difficult to walk your dog. That means that I have to spend extra time playing with my dog in my futile attempts to tire her out. I didn't go through this last year (its the second year of having a dog for me) because the rainy season was pretty sparse, but interestingly enough, the rainy season is actually eating into my work schedule via dog playtime. Go figure...

On the subject of productivity, I came to the conclusion that my previous method of managing my schedule and tasks (ie: doing whatever popped into my head) was insufficient. I now have a fairly large open source project to take care of, two part time jobs, and a lot of company accounting and administration due to my recent incorporation. On top of that, I have to balance my wife-time, dog-time, and for some reason, I seem to have to do all the household chores. My wife still doesn't believe I have real work since I'm at home all the time and she's out of the house doing her "real" part-time job (ie: waitressing). Which is why she nags me to clean the house since I'm at home. I guess it doesn't matter, even if you pay the rent and the bills. Ha ha ha...sad...

Anyways, I've been experimenting with different methods of managing myself and my time since I had my recent anxiety attack. I believe most of it was due to my inability to fully understand the amount of stuff I had to do. It just felt like I kept on getting hit with so many things to do that I ended up shutting down. Since then, I've been trying to use a task list to manage my tasks and a calendar to start understanding my schedule. It was okay for a while, but I noticed my task list kept on growing as things kept on popping into my head and ending up on my list. Unfortunately, I also noticed my calendar was identical everyday...stay at home...write software...I need to get more of a life...

On a friend's advice, I checked out the book "Getting Things Done" by David Allen. It seems to be the preferred geek method of handling productivity and efficiency. I think it's mostly because there is a lot of logic and organization that's required, which is pretty much the same as writing software, handling software projects, or even maintaining your file system on your computer.

The author pretty much says that simple to-do lists and calendars are insufficient to handle real world projects since they don't capture all the information that's actually floating around in your head. That pretty much was enough for me to hear to try it out. You basically need to dump all the projects into some type of organizing system (I actually made my own paper organizer), and keep running lists of all projects, broken down as far as possible into their simplest tasks. You also need to keep one main running list which is the actual task list (next actions) and its composed of tasks from each project as well as one-off tasks like going grocery shopping. I don't want to get too much into the details here, since it gets a bit technical, however you can check it out on Wikipedia or just by googling GTD (that's the slang for Getting Things Done). It seems like its quite popular among the geek community.

I've been on it for about a week and a half and I'm slowly building my confidence in being able to handle so many things at once. Its a bit overwhelming when you have all your real projects written down on paper and you see the volume of things that need to actually get done. It was no wonder that I had such a problem with it. I'll probably stick with this methodology for a while since it seems like its working out for me. Anyways, now that I'm independent, I figure I need to step up my game a bit.

On to the more interesting things...

Last week, I managed to write a self-checking testbench for the ZDO layer and finish testing it. I fixed all of the bugs that I found during testing so I'm pretty confident that the ZDO functions I implemented are working as I expect.

Unfortunately, the same test fixture can't be used for the testing on the NWK and MAC layers since they require more interaction with other nodes. Hence I've decided to use my current simulator to simulate two nodes and exchange data between them as my basic test. My requirement is that my tests be self-checking so I also decided to write a script parser with some language extensions that can control an independent program (process) running the checker. My last attempt at a script parser failed miserably so I'm hoping this time, I can get things right.

On top of that, I need to re-format all my function headers to be compatible with Doxygen so that I can have at least some crude documentation when I release the code. Well, that and fill in the argument and descriptions for those headers. From the look of the amount of work I have to do, I'm thinking that the release will most likely take place towards the latter part of this month. In case there are an doubting Thomases out there, I've already promised myself that I'm going to release the code in September, so it'll happen even if the code is non-working and there's no documentation. However I'd prefer that not to be the case.

Until then, looks like I'm going to need to bust some ass.
Toodles...

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