Whew! Just finished my PCB design marathon. Six boards total in about a week and a half including schematic, layout, and checking. I've become quite pro at making my own PCB footprints, which are still a major pain in the ass.

Anyways, I just sent out the gerbers to the PCB fab for prototyping. I'm trying out Barebones PCB this time to see how they are. It's actually a division of Advanced Circuits, but Barebones does really cheap two-layer PCBs with a 1-day turn. The only problem is that they don't include the solder mask and silkscreen, but I figured that for protos, it's not really required. I just want to see if everything functions properly and the mechanicals are okay (ie: the JTAG ICE won't plug in because a card is blocking it). 

The drawback to using Barebones is that the shipping to Japan is painfully high. I made a 7x9 panel that includes 4 different designs with two of each. For two panels, it cost me about $100 which is very good. But the shipping was $90 which nearly gave me a heart attack. I think my next protos will be fabbed in China. As much as I want to support US industry, for PCBs it just makes more sense to do it locally in Asia. However I'm still a big fan of DigiKey :) 

One of the four boards is going to be the main MCU board for the FreakZ development platform. It has an AVR USB with 128 kB flash, hardware bootload (still need to write it tho), and modular connectors for extension boards like radios and sensors. 

Two of the boards are for Tokyo Hackerspace. Once the software is finished for them, they'll be able to sell them in the hackerspace shop and generate funds to build the group. And the fourth board is just a test board for the TI TPS61202 since I had some extra space on the panel. Normally, you would do stuff like venting and thieving to balance the copper if you had unused space. But I hate wasting good PCB space. For those that don't know about the TPS61202, it's a nice DC/DC converter that can boost a 0.5V supply to 5V. I'm going to be throwing some small solar cells and supercaps at it to see how it performs. 

As for the radio boards, I have two of them designed already, the AT86RF230 and the AT86RF212 but I'll proto them on my CNC milling machine. You usually need to tweak the RF a bit and since I don't have an RF simulator, I figure there's going to be some trial and error to get things right. If you're wondering why I'm using a lot of Atmel parts, it's a mixture of having the drivers already available (AT90USB128 and the AT86RF230), and the fact that the Atmel disti is the only one that will sell to me. I still haven't heard back from the other radio distis yet. 

Anyhoo, here's a pic of the panel...


Just updated the release on Sourceforge. This is the first release under the new modified BSD license. The documentation has also been updated to include new material on the ZCL and simulator usage. The package also includes the simulator and command line interface user guide in pdf format. There's still a lot of cleaning up and tweaks to do to get it to conform to the spec, but the basic architecture and data transfers are there now for all the layers except the security manager.

This release marks kind of a transition point from just developing software to run in the simulator to actual implementation of Zigbee networks and devices. I'm going to be moving my focus to building development boards for awhile because of this so there won't be much software dev activity for a bit.

Anyways, glad I could finally get this release out. It was quite a dramatic period...

The release can be found here:



Yeah, you heard right. The next release of FreakZ and FreakUSB will have its licensed changed to Modified BSD with the additional restriction on the FreakZ stack that its subject to the Terms of Use of the Zigbee specification. With the whole licensing headache going on in regards to the Zigbee specs TOU, I decided that it just doesn't make sense to try and maintain a GPL license. For those that aren't up-to-date on their open source licenses, the Modified BSD license is one of the most permissive licenses available and does not require a user to disclose their IP or contribute their modifications to the project. In other words, it's very commercial-friendly. 

It took quite a bit of soul-searching to make the decision to let go of my software. Someone asked me if it's okay with me that a company can make a billion dollars off of my work without contributing anything in return. Of course the answer is that it'd be frustrating. However, my conclusion is that the goals of this project aren't about me or my work being treated fairly. It's to provide a free open-source software stack so that individuals that don't have access to the same resources as large companies can come up with innovative products. Somewhere in that innovation, I'm hoping that devices can be created to help good causes such as environmental and humanitarian issues. There's also a sub-goal which is to provide a check on the balance of power between implementors and hardware vendors. Most vendors use their software stack licenses to lock-in their customers and decrease the freedom of choice in choosing the best hardware for the required application. Having an open source, hardware agnostic stack can remove those limitations and allow people the choice to mix and match MCUs and radios. 

I know that some people will be disappointed to hear that I'm changing the license from GPL and I can only apologize. I was originally contemplating using a modified-GPL where it would be subject to Zigbee's Terms of Use. However even after adding this exception, there will still be issues with things like the Certicom patent and licensing for people that want to use the Smart Energy Profile. To accomodate that would be an added exception, and eventually, I can only imagine that the GPL on FreakZ would end up having so many holes that it'd look like swiss cheese (no offsense to any Swiss people). Arguably, the Smart Energy Profile is one of the best things going for Zigbee, and I imagine that it'd be important for an open source Zigbee project to be able to support it.

When I first started this project, I didn't expect to get any commercial interest. I figured that only hardware hackers and tinkerers would be interested in an open source Zigbee stack. At the time, Zigbee was also waning in popularity, since it was before the Smart Energy industry started taking off. However the situation seems different these days, with Zigbee gaining in popularity due to Obama and his smart grid upgrade, the growing popularity of Zigbee Home Automation, and the recent Continua selection (hmmm...it's debatable whether its a win or not for Zigbee, but at least its something).

I suspect that if, due to the Zigbee spec's terms of use, it is deemed incompatible with the GPL which is highly likely, it would discourage further open source efforts for it. This would be a shame, and it makes it even more important for this project to continue moving forward.

I have emailed the Software Freedom Law Center and the "GPL Violations - Legal" mailing list to get more opinions on the GPL compatibility. I still haven't heard back from the SFLC, however the opinions are mixed on the GPL Violations Legal mailing list. Some of the opinions are that it's okay, but the arguments are a bit weak (ie: the user of the software can simply say that they're not using the Zigbee spec). However it looks like the Zigbee Spec's terms of use at least violate the spirit of the GPL which is to provide software without restrictions. I'll keep people updated on anything I find. 

I'm hoping that in the future, the Zigbee Alliance will follow Bluetooth's lead and allow Adopter membership for free. At that time, GPL'd software for it can exist unambiguously. However I'm not going to wait for that to happen. My old mentor would always tell me: "It doesn't matter whether the decision is right or wrong. A decision needs to be made." Hence  the next release will be using the permissive Modified BSD license with the additional Zigbee Spec TOU restriction.

Apologies if I've disappointed anyone out there. A stronger license can be applied by any individual by forking the code and applying a restrictive license to their contribution. 

In any case, I'm going to Akihabara to blow off some steam. This whole thing has taken a lot of energy out of me. The release will be coming soon...

I just finished writing the Simulator and Hardware Command Line Interface User Guide document. I was originally going to release this document and the code together, however the whole GPL license thing kind of took me by surprise. I'm initially going to tack on an exception to the GPL for the Zigbee Alliance membership fee so that I can get the code out quickly. I'm hoping that it will be within the next two days. However this is only temporary and it makes so that this code can't be used with any other GPL projects due to the exception. 

In the meantime, the license is going to be in limbo until either the Zigbee Alliance decides to open up Adopter membership (not very likely) or I decide on a new license. It's tough to give a timeframe on this, but I'm not going to drag it out too long. I'm leaning towards just going BSD to avoid this whole fiasco as well as the Certicom patent issue which would require an additional exception to the GPL. Of course, I'd have to give up on my idea of keeping the code open, but then the GPL is a weak tool against people that really don't care to adhere to the terms anyways. 

Oh well, another day, another issue...it's a beautiful day in Tokyo and the air is clean because of recent rainstorms. I'm going out to walk my dog and enjoy the weather. I hope you all have the same good luck :)

Here's the document. The code should follow within a few days.

Doc Link

Well, I'm seriously lagging on the documentation so unfortunately, nothing much to report. It's not that the documentation is difficult, but it's the mountains of other things I need to wade through before I can get to it. That seems like the case for most things I'm trying to do these days, where the volume of tasks seems to be increasing. I guess its inevitable as the project marches forward that small things start to consume time and energy as well as the major things. 

I'm hoping to get the dev boards done soon, but I've been agonizing over the power supply section recently. I can go with the el-cheapo voltage regulators, but I'm leaning towards using a DC-DC converter on them. TI has a new switching converter out that can boost voltages from 0.3V up to 5V, but it's a bit on th expensive side. The main benefit of using something like this is that the dev boards will be able to accept different types of inputs.

The standard dev board usually has a DC jack and possibly the option to be powered off the USB. Battery power is a different issue where you have to take into consideration the battery types that you want to be compatible with. Lithium batteries (coin cells) usually run at 3V, standard alkaline batteries are 1.5V/cell, and NiMH ones run at 1.2V/cell. For my dev boards, I want to be compatible with both alkaline and NiMH batteries which usually come in the same form factors (AA or AAA) so that you can use disposable (ugh) or rechargeable batteries. That means that you'd have to be able to support the minimum voltage which is 1.2V/cell.

Along with that, I'm planning on some experiments using solar power and super capacitors which presents another pain in the ass. Solar cells run at ~0.6V/cell which represents the diode drop across the PN junction of the cell. To make things more complicated, super caps function as normal capacitors but with a huge amount of capacity. That means that they can run from the full voltage rating all the way down to zero, as opposed to batteries that slowly lose voltage as they discharge and drop off steeply when they're almost empty. 

Of course the drawback of using the switching converter is that the power supply ripple looks pretty ugly from the datasheet which would make sensitive measurements difficult. This kind of goes against the whole concept of wireless sensing if you can't do the sensing part well. The tradeoff I came up with is to use the boost converter for the 5V supply and drop the voltage to 3.3V with a linear regulator. It's a waste of power, I know, but at least you'll have a smooth 3.3V supply which powers most of the main components that I'm planning to have on the board. The 5V supply is just for any peripheral components on the modular connectors that might need it. Not sure if this is the best solution, but at least it's a solution. 

The casual observer would say that I'm overdesigning the power options, which is probably true. However one of the most important factors in wireless sensors is power utilization since that's the lifeblood of a WSN node. Hence, I'm very interested in experimenting with different power options for different situations. Plus, the new DC/DC converter chip I mentioned can accomodate all of the potential inputs (hopefully) since it's designed specifically for energy harvesting types of apps which work at low voltage. So anyways, I've been agonizing over the power supply for the dev boards for quite a while and I think I'm converging on this solution.

Hmmm...what was my point in writing this post again?

Yesterday was a major breakthrough in the development. I've been spending all week tracking down and cleaning up bugs in the actual hardware. And finally, I was able to test most of the major ZDO and ZCL functions. This includes the ZDO device discovery and network management functions as well as the ZCL's general read/write/report attributes commands and the on/off and level control (dimming) clusters. The ZCL report attribute function is particularly interesting because you can set it to report attribute data periodically. This should work well for something like energy monitoring, where you monitor the accumulated energy usage, and upload the data to the internet periodically, say hourly. 

Regarding the development, I'm lucky that I decided to take the time at the beginning of the project to put together a simulator because it increased the debugging speed and efficiency more than I could have imagined. I found that there was a very high correlation between the hardware behavior and the simulator behavior, and I was able to reproduce all bugs (except driver related ones) on the simulation platform. That helped me catch a couple of really nasty bugs like a memory leak that I found. It would have taken a couple of days to debug that one in hardware, but with GDB, I just needed to set a breakpoint on memory access and then view a stack trace after the break happened. 

My current test setup is using two Atmel AVR Raven USB stick's interfacing to the PC via FreakUSB and the USB Communications Device Class serial emulator driver on it. I've also implemented an identical command line interface as the simulator so that it's easy to go back and forth between hardware and simulator with no differences in commands. I'm also using the Daintree Network Analyzer I just got and it's much more useful than I expected it to be. I caught a couple of protocol errors, some bad decisions in my ZCL interpretation, and many constants that I needed to modify to be Zigbee compliant. Interestingly enough, I'm using the Zigbee Pro decode mode and my stack is still decoding okay...heh heh. 

Hopefully within a week or so, I'm going to put together a document on how to use the simulator and hardware command line interface and all the commands that have been tested so far. I'll be releasing the code and documentation together, since it doesn't make sense to release one without the other. The number of commands in the command line interface has increased to about 40 and it's quite useful for exercising the stack, and even adding customized commands. Unfortunately, without documentation, it's going to be a pain in the ass to figure out how everything works. I'm also going to describe my test setup, which I would recommend to anyone interested in using the FreakZ stack. I found that the most efficient method is to have two devices that interface to the PC and use the same command line as the simulator. As I mentioned earlier, the high correlation between the hardware and sim means that you can write applications, test and debug them on the sim, and then move them over to hardware when things are working. Since each node has a command line, you can also control each node to simulate an event and see how the rest of the network behaves. Although I didn't know how useful it would be, that crappy, little simulator I wrote at the beginning of the project has turned into an excellent development tool.

Unfortunately, I couldn't do anything really crazy with the Raven USB sticks because they're tiny and don't have any IO for interfacing to sensors or external circuits. Also, the Raven LCD boards which come with the Raven kit can't interface to a PC so a command line interface is out of the question. Basically, the Raven kit is a way to evaluate Atmel's MCU and radio, but isn't really meant to be a full hardware/software development platform. In the end, I finally just bought an extra Raven USB stick from DigiKey to set up my tests. They're available now for about $40. I'm going to be taking a short break from stack development to design development boards that address these issues. Mostly, I'm going to make boards with increased I/O, USB and serial interfaces, and separate boards for the MCU and radio. That way, they can have the command line interface, connect to external circuits, and the MCU/radio combinations can be mixed and matched. I'm excited about the last one because I want to try out some of the 868/915 MHz radios. I heard that they have a longer range for the same power than 2.4 GHz radios and they're less susceptible to physical barriers. It'll also be a good platform for me to do actual testing and reviews of radio performance from the different vendors. I'll have more details on the development boards later.

In the meantime, here's some pics of my little demo I set up for everyone. The picture sequence shows the LED on the Raven USB sticks turned on via the Zigbee Home Automation Profile's On/Off cluster commands. The Zigbee frames can be verified by the trace from the Daintree analyzer. The last picture is just a shot of my test setup.  I deliberately chose to turn on LEDs because I wanted to bask in the not-so-subtle irony of taking 16 months to toggle an LED...

Finally got some time to move the stack into hardware and start testing it out. I'm using two Raven USB sticks which have their own serial terminal window. The reason I chose the USB sticks is because I implemented a command line using FreakUSB so I can issue commands to each of the nodes and check the responses. I moved the whole simulation command interface on to the USB sticks as well so the commands are all the same and the supported commands are identical with the simulator. So far, the behavior correlates well with the simulator. As I mentioned earlier, I finally got the balls to pony up some cash for a Daintree Zigbee analyzer. The guys at Daintree gave me a sweet deal on the analyzer, since they cut me a big discount on the Pro version which supports the visualization, decoding, and 6LoWPAN and RF4CE as well as Zigbee Pro. Here are some shots of my ZDO testing with the permit join, lqi, and binding requests/responses working as well as the network formation and join...


Just a quick update. I've been taking a bit of a breather from the stack since a friend is in town and I'm taking him around. But I did get a chance to implement code for the AVR Raven USB stick. The commands and structure is the same as for the simulator so it will make it easier for testing. I also did a test build and the current size of the stack (minus the test code and the USB stack) is ~55kB including the ZCL. Currently, the ZCL supports the general commands, reporting, and the Basic, On/Off, Level Control (dimming), Identify, Groups, and Scenes clusters. Hopefully, I'll have some time later on to load it into the hardware and get it up and running. In the meantime, gonna go check out the Grand Sumo tournament tomorrow. Nothing like watching a bunch of big, sweaty men in thongs wrestling with each other...

It's smack in the middle of Golden Week now and it's been kind of nice. Things have been quiet lately on the work front because all of Japan is basically shut down. This gave me some breathing room to work on the stack and also gave me a much needed chance to rest and get my bearings again. This weekend, I treated myself to my first massage in over a year (uhhh...a normal massage...) and the shiatsu guy was shocked at what bad condition my neck and shoulder muscles were in. Apparently, I need to take more breaks from the computer because he said my upper back and shoulder muscles were like beef jerky.

I also got a chance to meet up with Vlad from WebOfThings in Akihabara. He was in Japan for a conference on localization in wireless networks and another one on pervasive computing. Hmmm...it seems like everyone is working on much cooler stuff than me. I took him on my standard tour of the cool places in Akihabara (to me) like shops that sell microcontrollers, sensors, FPGAs, process automation equipment, and other knicknacks, and of course my favorite surplus components store, Super Junk.

We finally ended up at a traditional soba restaurant where we were having drinks and talking about wireless sensors. As the drinks flowed, the conversation got more intense, and finally, I think we made his girlfriend fall asleep. It was really nice to have someone to actually talk about wireless sensors with. I normally just read, write, or post news about them, but rarely have bi-directional converations on the subject.

As for the stack, these past few days, I ended up knocking out a couple more clusters. Now that the groups table was finished and working, I implemented the "groups cluster". This is a cluster that's mainly used by a commissioning tool to set up the multicast groups on the nodes. The reason I wanted to implement it is because the "scenes cluster" required the groups cluster support in the ZCL. The scenes cluster allows you to create customized scenes for your home, where you can specify which lights are on, how dim they are, what temperature the thermostat is set to, etc...And because of this, the scenes cluster is needed by most of the devices in the home automation profile. So the main point is that with the groups, scenes, on/off, and dimmer clusters going, there may be some simple home automation Zigbee app examples coming soon. 

In fact, I'm feeling so close to having actual working hardware based on standard device profiles (home automation for now) that I've finally given in and am buying a Daintree protocol analyzer. The Microchip Zena has served me well while working on the lower layers like the MAC, NWK, APS, and AF layers, but for profile specific decoding, Daintree seems to be the way to go. Having the ability to decode my frames will serve two purposes: make it easier to debug and also make sure that my frames are formatted correctly. I'm hoping that having a tool like that will help me implement the profiles quicker, and also give me some confidence that my stack is working correctly.

One of the Daintree sales people I talked to recognized me from the domain in my email address so there's  a chance they might hook me up with a discount. Apparently, she checked out my site and realized how financially pathetic I am. I'm hoping that this will be one of the last major purchases I need to make. I have to maintain a safe cash cushion in case the whole dev board venture doesn't work.

That's pretty much where things stand right now. I'm hoping to pause development on the clusters after a bit more testing and then move on to some actual hardware implementation. If things work out like I hope, then there may be some simple home automation devices working soon...

Thought this would be a good time to provide a status update with the news about Zigbee migrating to IP just coming out. The FreakZ stack development is going to continue as planned, although this might throw a wrench into my plans for compliance since so many things will be up in the air. Almost all of the development right now is in the Zigbee Cluster Library which will likely remain intact anyways. 

I'm not planning any changes to the network and application layers of the stack until they release more details about how the spec will be affected and the timeframe. I suspect that the Zigbee Alliance will have no choice but to use 6LoWPAN, and in that case, the plan will obviously be to integrate uIP and the excellent SICSLoWPAN work that's already been done by the guys at SICS and their partners. Since I'm using Contiki already, I'm not too worried about integrating the SICSLoWPAN code. I'm going to need to brush up on my TCP/IP and IPv6 though :)

As for the current status of the stack, I'm just getting back into the groove of things as my life slowly returns to normal after handling all of the equipment moving and logistical issues last week. I've already tested a lot of the new ZCL functions and am also adding new clusters. I'm hoping to have the full set of general clusters implemented soon which will at least make it possible to implement a simple home automation profile. I'm also modifying a lot of the ZCL code to simplify it because I felt my previous implementation was overly complicated, especially since a lot of people will be working directly with the ZCL code as opposed to the lower layers of the stack. Golden Week starts this Wednesday in Japan and is a whole week of holiday, so that should free up some additional time for me to dedicate to the development (and maybe take some time off as well). 

Well, this is a short post, and the main point was just to let people know what the plans are in light of the news that was just announced.

Updated 2009-04-28: Is it me or do I have a tendency to write run-on sentences...

I've decided to drop the weekly wrapup and just go back to calling this the status update. I found that I was basically just reporting the software status anyways, with an additional side of regurgitating the news that happened that week. Basically, WSN news doesn't move fast enough to support a weekly summary. Ha ha ha.

I'm a bit disappointed to say that software is moving slowly right now. There were so many things going on that I've been struggling to find time to work on it. I got hit with a double whammy where both my new PC and my 'pick and place' machine arrived. Yep, you heard right. I bought a pick and place machine for automated PCB assembly and had it installed in my apartment. If you can imagine what a room in a Tokyo apartment is like, imagine one with a pick and place machine sitting next to a CNC machine and the walls lined with steel racks and shelving. I basically had to tear down everything in my room and reorganize it around the two machines. It felt like an exercise in packing algorithms, or real-life tetris. I must have one of the highest room space utilization percentages in Tokyo.

The reason I decided to purchase a pick an place machine is because I want to try and support the project by selling development boards and modules. I've already had a couple of requests for a development board to test out the FreakZ stack, but realistically, I'd be making them in low volume batches of something like 50 or a 100. At those volumes, the outsourced assembly cost is greater than the cost of all the components and PCB. That's why you see such a big price difference between companies that send their boards out for assembly versus ones like Sparkfun and Arduino that do their own assembly in-house. It's also evident in the variety of boards you can produce. You need to do batches of something like 500 to a 1000 pieces to make the board cost effective for outside assembly which means that you can only target areas that have enough demand to support selling boards in that amount. However if I don't need to worry about volume pricing, I can make specialty boards that might not appeal to everyone, but are interesting. My personal fascination is with sensors and automation, so you'll probably be seeing a lot of those types of boards. Unfortunately, it's a bit niche-y so I doubt I could sell a whole lot of boards that sense and report soil moisture and pH for agricultural tech development, but it'd be pretty damn interesting :)

Anyways, the reason I'm mentioning all of this is because recently I've been busy developing a hardware platform for the FreakZ stack. I'm actually collaborating with a friend in France on the board design where I design the AVR boards, he designs the ARM boards, and we share the gerbers. It's a good way to speed up support for different architectures and peripheral boards. All the boards will be using the same connector interface so the sensor and radio peripherals can be moved around from MCU board to MCU board. I'll also be working on radio peripheral boards that support different chips and configurations, ie: 2.4 GHz and 900 MHz 802.15.4 radios and some with RF amps and LNAs on the front end. 

Since I'm on my excuse train, might as well say that I had a really tough time migrating to the new PC. I'm surprised that it took about two and a half days to get stabilized on it. There were battles against driver problems, data migration, and then just loading all the programs that I use and tweaking them. However once everything was set up, it felt really nice to be on a powerful machine with scads of RAM. I finally ended up taking the stock Dell machine with the 3 GHz Core2Duo and upgrading it to 4 GB RAM and 1-TB hard disk. I did it myself because Dell overcharges for the parts. I was shocked that 4GB of RAM only cost me $50 and the 1TB hard drive was about $70. I remember my first 1 GB hard disk and it cost me an arm and a leg. I also added three external 1-TB mirrored RAIDs for reliable storage of important documents, designs, software, etc. The source code working repository for FreakZ, FreakUSB, and past software projects are now kept there as well as old board designs, some ASIC and FPGA stuff, and of course my *ahem* anime collection. Also upgraded to a dual-HDMI video card and two 24-inch monitors. I am happy to report that I now have a workstation class machine sitting on (or under) my desk. Yay! :)

So finally, I'm hoping that things will stabilize enough this week that I can get back to testing the source code and moving it into hardware. Apologies for all the delays. I know a lot of people are waiting for the working code. It seems that as I get deeper into the project, I need to juggle more tasks. However it's probably one of the most fun (and intense) projects I've ever worked on :) 

Here's a couple of shots of the new PC setup and the pick and place machine. My apartment is turning into quite a nice little factory. Now I need to buy a fire extinguisher...