Home arrow Blog arrow FreakZ arrow DevJournal - Getting Ready for Cooja
DevJournal - Getting Ready for Cooja | Print |
Written by Akiba   
Sunday, 04 May 2008
I haven't updated the blog on the status of the stack for a while. The week before last, things got really busy due to the start of the Golden Week holidays in Japan so I ended up working a lot. That ate into a lot of the time that I wanted to spend on implementation.

Also, my wife got laid off from her job last week. Although it doesn't affect us too much financially, the fact that she's home all day is taking a toll on my implementation time. Since she has a lot of free time, she's taken to cleaning the apartment, and I mean thoroughly cleaning. I guess she needs to focus her energy somewhere, but she gets mad at me if she starts cleaning and I'm not on hand to help out. So I've been helping her clean the closets, her room, the floors, laundry, throwing things out, etc. My room only gets cleaned by me. The good news is that the apartment never looked better. The bad news is that it's cutting into my coding time about as much as working full time two weeks ago. Ahhh…the price of marriage.

I did manage to sneak out a bit last week and hide in a local coffee shop. Now that the weather's better, I've changed my normal place that I do my coding. Before, it was at the local hamburger shop, where I can buy a cheap coffee and hang out on the second floor for a couple of hours. That’s important because a lot of places get mad at you if you stay too long with just a cheap drink. But now that the weather's improving, I've been going to a café about 15 minutes away by bicycle. It has a nice veranda with a view of the park across the street. You don't get to see too much greenery in Tokyo so it's a nice change of scenery for me. So although my pace has slowed a bit, the cleaning gave me ample time to think through some of the stack implementation. That helped make my coding more efficient when I had the chance to do some implementation.

Right now, the progress on the stack is quite good. The implementation of the management functions went much more smoothly than my first attempt at it last year. I now realize the mistakes I made on that first attempt, and a lot of them had to do with the initial planning stage.

The main reason things went smoothly this time is the choice of implementation strategy. Starting with the data path was a good move because it gave me an initial means of transport and also I was able to see the code flow moving up and down the stack. The management functions rely heavily on the transport, both direct and indirect, so since it was already available, coding them up went much faster.

Also, my previous strategy was a bottom-up design where I implemented the driver first, followed by the MAC, and then moving up into the NWK layer. This was a mistake. In general, this approach is fine, however a Zigbee stack is unique in that its actually built on top of another protocol, 802.15.4. However I figure that it only uses about 30% of the functionality of the 802.15.4 specification. This is where I got tripped up in doing my bottom up approach.

By going bottom up, I ended up implementing a lot of functionality that wasn't used by Zigbee, thus making things much more complicated than they should have been. Since Zigbee doesn't allow beacon mode, then that basically takes out a lot of the features of 802.15.4: superframes, timeslots, guaranteed time slots, contention access, timing control, etc.

This time around, after the data path was implemented, I then started with the network management functions. This is at the top of the management hierarchy so my management implementation was a top-down strategy. By starting with the NWK layer, I was able to see the MAC functions that I needed and only had to implement them in a way that was usable by the NWK layer. This limits the usability of the MAC in other applications (ie: 6LoWPAN or wHART) but I'm not too concerned right now. The main goal is to have something that works, and that is as small as possible.

I would recommend anybody that is setting out to write their own Zigbee stack to follow this approach, where you implement the data path first, and then do a top down implementation on the management services.

So far, I have the following management functions completed:
  • nwk formation request
  • nwk formation confirm
  • nwk discovery request
  • nwk discovery confirm
  • nwk join request
  • nwk join confirm
  • mac energy scan
  • mac active scan
  • mac beacon notify
  • mac association request
  • mac association confirm
  • mac association indication
  • mac association response
  • mac start request
  • mac poll request

These management functions are enough to start up a network and add devices to it. I also have tests written for most of the functions. Not bad for two weeks of limited implementation time. The tests have been saving my ass, too. As the number of tests is increasing, I'm getting more test failures, since modifications to one area sometimes affect some distant area. If the tests weren't self checking, then it would have been difficult to see these problems. I've even caught some issues that depended on the sequence the tests were run in. Those would have been ugly to debug in hardware. Anyways, if my simple tests are already catching a lot of bugs, then there must still be a whole cockroach nest in my code.

After I take some time to clean up the code and probably write a couple more tests, I'm going to freeze the stack implementation and start porting it over to the Cooja network simulator . If things go as I want, then I should be able to see the stack behavior in a simulated network with multiple nodes. That should flush out a lot of bugs that I can't see right now. I've already been studying up on my Java (I still suck at it) and looking at the Cooja code.

So it looks like I'm getting close to moving into a different stage of the stack development soon. Here is the sequence that I have in my head. After I get the stack working on Cooja, then the network sims start. If I can get it to a point where its stable in a network (I still need to define "stable"), then I'm going to set up a public bug tracker and prepare to do a first release of the source code. It won't be a fully functional or compliant stack, but it should at least be enough to play around with, especially inside the sim. It's difficult to say how long this will take since getting the stack to run on Cooja is a bit of a question mark. The sim is still quite new to me. However it looks like a public release is on the horizon. Somewhere…out there.

By the way, regarding bug trackers, I'm leaning towards Trac for its integration with Subversion, but any suggestions on bug trackers would be welcome. 

Well, that’s about it for this post. My wife imposed a moratorium on my computer usage during Golden Week since its supposed to be vacation time. It lasts until mid week so until then, its likely that I won't be allowed to do any coding. See you after Golden Week.

Hits: 692
Trackback(0)
Comments (0)Add Comment

Write comment

busy
  No Comments.

Discuss...
< Prev   Next >