To start off the series on new 802.15.4 chip reviews, I've chosen the Atmel AT86RF230/231. The AT86RF230 and 231 are essentially the same chip, however the 231 has some extra features over that were noticeably lacking in the 230. One of the most important additions was a hardware security co-processor. They also added other nice features like antenna diversity, multiple data rates up to 2 Mbps (non-standard), random number generator, and they brought out the RX/TX switch. Since I've never done a review on the 230, let's start with some of the features of that chip. The 231 contains all of the same features as well as the above mentioned extras.

The 230/231 has all of the basic features of other chips out on the market. These include things like an SPI interface, 128-byte Rx and Tx fifos, and RSSI output. One of the nice features that they included was an energy detector which is useful for energy scans. Energy scans are used in 802.15.4 and Zigbee as part of starting a new network. You would scan the channels and choose the one with the lowest energy (least traffic) and fewest networks. Normally, you'd have to convert the RSSI into an energy detection value in software, however this is done automatically in the 230/231.

Another very convenient feature they included is Link Quality Indication (LQI). This is a statistical value of the quality of the link and can be correlated to a packet error rate. The reason why this feature is valuable is that packet error rate is used in Zigbee to calculate the path cost for each router hop. A route will be chosen based on the lowest path cost, and to calculate the cost of a link, you would need to use some type of statistical algorithm in software. Since the hardware maintains a running history of the link quality of all frames, the statistical value should (hopefully) be pretty accurate. 

Lately, I've been working on the stack every day and I need a bit of a change of pace. Only reading hex data and debugging logic errors every day is not good for the soul. Also, the blog has been a bit neglected recently except for my devjournals so I thought I'd start working on a series of chip reviews about the recently released ones. I've been asked by a couple of people to provide reviews for chips over the past few months, but I never got around to it. Since it doesn't require any coding and only requires me to give my own stubborn opinion, I thought it'd be a nice breather for me. It will also give me a chance to learn more about the new chips that have recently made their way on to the market. The chips that I'm targeting for review are the Atmel AT86RF231, GreenPeak GP500C (no datasheet available yet it seems), and the recently announced Freescale MC13224 SoC (PiP?).

I should also mention that these reviews are based on the chip datasheets only and not on actual usage. I'm hoping to change that soon, though :)

Recently, I've been doing a lot of testing in my sim. That means that I've been crawling through the code looking for the causes of different types of bugs. Some are obvious, some are mysterious. However, as a result of looking at the code a lot recently, I found many areas that I'm dissatisfied with. One of the areas that I was unhappy with was my APS layer or the Zigbee application sub-layer. This was the first part of the stack that I worked on and it was written about three months ago. Now that I'm more familiar with the needs, behavior, and patterns of the Zigbee stack, I realized that there was a lot of code that didn't need to exist.

In the APS layer, if you recally my old post on it , I implemented a data queue to queue up the data from the different endpoints, a state machine to handle retries and acks, a transmit process, and some miscellaneous logic functions. All in all, it was a complicated way to implement the APS data request service. A lot of the complication was due to handling reliable acknowledgement. To do this, you needed to keep track of a timer and also buffer the data for re-sending.

Well, after a couple months of stack coding under my belt and a better understanding of when and how to use the Contiki services, I decided to rewrite the APS data request service. This is one of the key functions in the stack because all the endpoints including the Zigbee Device Object will be using this service heavily. The good thing about rewrites is that you usually have much more insight than you did when you originally wrote the code. Since I can now see from the application layer down to the radio driver, I knew exactly how the APS layer needed to behave and what the tx function needed to do. Here is a simple flowchart of how the new data request routine looks:




I was able to get rid of the data queue because it wasn't really needed at the APS layer. The tx process, state machine, and temporary retry buffer got replaced with a retry queue and a callback timer. This greatly simplified things because the callback timer performed the equivalent of a state machine, process, and timer all in one. The retry queue is actually an enhancement. Previously, I could only buffer one frame at a time which meant that I could only transmit one reliable frame (ack requested) at a time. Then I had to wait for a timeout or ACK to send the next one. This is the main reason why I needed a data queue on the transmit side. A retry queue allowed me to set aside only those frames that needed to be sent reliably. When they got put in the retry queue, then they would also have a callback timer set. If the callback timer expires, then they would automatically be sent out again.

The revised design simplified the APS layer and reduced the lines of code by about half. Getting rid of all the complication also made things easier to debug. I've already tested it out and it works in the simulator too.

Now, I'm going to do the same for the MAC layer. The MAC layer has a similar behavioral pattern as the APS layer in which it sends out data and needs to wait for the ACK. I'm pretty sure I can use the APS layer as a guide to simplify the MAC layer too. That way, I can decrease the size of the stack and make it more maintainable, and even add functionality. Also, the APS and MAC data request functions will be similar which kind of gives the stack a nice symmetry...I hope.

Hit a major milestone over the weekend. After rewriting the mac, nwk, and aps data paths, and also rewriting most of the mesh networking code, I finally got everything to work. The reason behind the rewriting, besides cleaning things up is because I have a much clearer picture of how things should work and also the architecture that I want. So I wanted to make everything consistent with each other. This also includes the naming, the patterns (no I don't use C design patterns, but many functions share a common pattern of execution), and the file layout.

I also simplified the mesh routing and improved the functionality. I can now handle multiple route requests which I think may be needed at network startup. When a network starts, all the nodes have no entries in their routing tables. So any node sending data to a remote node that isn't an exact neighbor will be doing route discovery which means broadcasting route requests. Previously, I could only handle one at a time which means that I would have to drop any other route requests. This might have been detrimental to finding good routes on network startup. Or I might just be overly cautious. Anyways, the routing code is smaller, cleaner, and can handle multiple requests so I'm satisfied.

After all of this was implemented, then I started testing late last week. I verified the mesh routing and tree routing on Saturday which is a big event since those seem to be the most difficult parts of the stack to get right.

Once I got those working, then I took Sunday off (my wife was complaining) and today, I finished the remaining services on the nwk layer. Things were much easier to implement now that the code was cleaned up. I also finished out the remaining services on the mac layer that were needed by Zigbee. I'm not implementing a full 802.15.4 mac because it's not required by Zigbee. The spec only uses probably about one-third of the available functionality of IEEE 802.15.4.

The remaining things to do are to verify the rest of the NWK layer and  finish off the APS layer. On the APS layer,  I still need to implement the binding table, group table, discovery cache, and address map. I'm hoping those won't be too hard. I'm a pro at implementing tables and queues now...Ha ha ha...that's actually pretty sad...

Also, I'm starting to look over the Zigbee 2007 protocol compliance documentation. My eventual goal is to get this stack certified as Zigbee compliant, although I'd have to cough up the ~$2k to join the Zigbee Alliance. Ugh...gotta figure out a way to make that happen.

I'll be going to California this Friday for a two week stay over there. My part-time job is requesting all the FAE's (yes, I'm a part-time FAE...gotta pay the billz) to go there for training on the product line. Anyways, it'll give me a chance to visit my sister and parents. My sister is up in the bay area so I'll be in Berkeley next week, and then go down to southern california the week after for the training. I'm hoping to claw my way through most of the remaining APS layer by the time I leave so I can have a clear conscience. Otherwise, it's gonna weigh down on me and I'm going to end up working on it while I'm over there. That's the problem with obsessive behavior.

Other than that, nothing much else. My life seems pretty boring if you take the Zigbee part out of it. Hmmm...it seems pretty boring if you leave it in, too...

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

This is a bit off topic, but since I'm writing in my blog, I thought I'd share an interesting thing I just discovered.

I've been having an infestation of fruit flies in my apartment lately. Is starts with one piece of fruit that has the fruit fly eggs, and once they hatch, they multiply like crazy. Since then, I've taken steps to remove their food sources, however I haven't been able to get rid of them.

Well, as I wrote my last article, they started congregating around my wine glass for a little fruit fly party. And since then, they all sipped some wine, got drunk and passed out inside my wine. I'm not sure if I should be happy I got rid of the flies, or sad that I lost my wine...

Anyways, if anyone out there needs to figure out a way to get rid of fruit flies humanely, try giving them some chianti. 

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

Man, I was hoping to finish up some more documentation tonight, but I ended up watching Sex and the City...the movie...by myself...At least I would have had an excuse if I went with my wife. How's that for procrastinative stress. Its like my penis just fell off. Well, at least I have to say that Carrie Bradshaw is looking good for a 40-year old. Actually, I just checked her out on Wikipedia and Sarah Jessica Parker (real name) is 43 so she looks even better.

Maybe I should just go to bed. That way, I can man up tomorrow and fill in the comments for the data structure fields...Hmmm...that doesn't sound right either.
Wow, my site's front page hit a Google PageRank of 3/10. It was only a couple of months ago that I didn't even have a page rank. It just goes to show you that hard work and perseverance makes you socially inept. Wait a second, that didn't come out right. Anyways, its cool that I have a page rank now.

Hi everyone.
I'm back from my brief excursion. Actually, I was working on a project for the disti that I'm contracting for. Once the PCBs were done, they needed a demo to show to their supplier and customers. At first, I thought it would be easy since I'm using an AVR MCU. I would just use the libraries provided by Atmel to implement the communications and then write a simple driver for the chips that they wanted to demo. Unfortunately, that kind of thinking backfired on me which was why I had to go into hermit mode for the last two weeks.

What happened was that the demo needed to interface to a PC, and not just a desktop PC, but laptops too. The problem is that laptops don't have serial ports anymore, and I didn't want to force people doing the demo to hang one of those USB/Serial converter dongles off of their laptops. Its much better to use the USB directly since you get both a power source and a fast communications link to the PC.

My mistake was thinking that I could take the vanilla Atmel USB device stack, port it to my platform, and have it work. When I did that, I would get intermittent crashes. I had thought that the problem was with my port, but the same type of behavior happened on the Atmel USB eval platform. For a demo, its undesirable, but probably 90% of the time, the demo reference code ends up going into the customer's design. If the code crashes a lot, then that's an easy way to lose a customer so I didn't want to risk it.

This gave me an opportunity to do something that I've been wanting to do for a long time...to write an open source USB stack. This stack, of course, is just a USB device stack, as opposed to a host stack which is much more complicated. However there seems to be a real dearth of good, open-source USB device stacks available. The ones that I've seen are mostly manufacturer stacks, with a couple of open source stacks that are heavily based on the manufacturer source code. What I was looking for was a USB stack that could be portable to different processors and USB device controllers, similar to what I'm trying to do with Zigbee. So basically, I decided to flex my USB muscles a bit. Of course I have a slight advantage with USB over Zigbee because I used to design USB chips (I was one of the designers for the USB IP being used in the Microchip PICs) and wrote a USB host stack before. Hence, there wasn't much of a learning curve for me in terms of protocol for USB as opposed to Zigbee.  

So for the past two weeks, I was writing a USB device stack from scratch. Although it's a pain, there are numerous benefits to taking this approach. The first is that it can be supported locally which means that I can add, modify, or fix the code instead of asking for help from an engineer in another country. This cuts down on the response time and the time that it takes to fix or change the code. The best way to keep a customer happy is to fix their problems fast :)

There are other benefits as well, such as the ability to open source the code (instead of using the yucky manufacturer license agreement which locks the code to the chip), and the chance to write funny comments that only I understand. 

When I was at my old company (actually two companies ago), it would have taken months to design it because of all the management approvals and meetings that were necessary, filling out statements of work, dealing with project managers to draw up the project timelines, and all the so-called USB experts that would endlessly debate the architectural tradeoffs. So now that I'm free from those shackles, I can say that it takes about two weeks of real ass-busting to get a device stack up and running, although it might still require a couple of tweaks ;)

Anyways, the outcome is that the USB stack is working, and the USB communications class driver with the Virtual COM port is up and running. I'll also be open sourcing it as soon as I clean up the code and write up the documentation.

Well, that's about it. Hopefully others will find the stack useful. At least now, its possible to get rid of that pesky FTDI chip (if you're lucky enough to have a USB interface on your micro). The release should be coming soon...and of course a Contiki port as well :)

Now...need to get back on track with Zigbee...

Ahhhh...nice to be back in Tokyo again. My trip to the US was a bit over-dramatic for my taste, but luckily it turned out to have a happy ending. Now that I'm back in my comfort zone, I can get back to work on a bunch of pressing issues. A lot of people have been asking about the next release of the FreakZ stack. I'm going to be working on it this month to try and implement the home automation profile using the Atmel Raven kits. Of course it won't have security, but it should be functional...I hope. I'm looking at the March time frame for the next release of the code with the hardware support.

Now gotta get me some sleep. I'm so jetlagged...zzz...