Been pretty busy lately trying to put together the initial prototypes for the FreakZ development platform which is also why it's been a little quiet on my blog. I had a very brief respite last week and then had to deal with a bunch of things. The parts that I had ordered from DigiKey got tied up in Japan customs. It turned into a painful ordeal where I had to communicate with customs via regular mail to provide detailed information on the parts, what I was going to do with them, the origin, and of course the cost in order to calculate import duties. Ugh...gonna need to get a lot more savvy about international trade if I'm hoping to sell some boards.

The board panels arrived the same day that my parts did which was kind of nice. After cutting out the boards and starting to assemble them, I realized that I had grossly miscalculated the effects of using a barebones PCB type of service. Not having the soldermask increased the difficulty of assembling the boards very much. It's very stressful when you have to doublecheck each solder joint to make sure you didn't bridge anything. The worst case actually occurred which was was a bridge between power and ground. This is the worst type of short to have because it's nearly impossible to find. It took me hours tracking it down and I had to tear off all the components from the board just to find it. It turned out to be a hairline solder bridge that was nearly invisible to the naked eye. I need to go over all the traces with a 10x magnifying loupe to find it. After that, I was very careful with the soldering iron and tried to avoid touching the ground pours on the board. It was like playing "Operation", that old game where you had to remove things from a body without touching the any sides. 

Needless to say, I won't be using Barebones PCB for prototyping anymore. The service is good and the boards were excellent quality, but the added time and stress from dealing with having no solder mask just isn't worth it. Also, the cost after shipping and the shipping time ended up being worse than using a service like GoldPhoenix which provides a solder mask and a silkscreen. 

I was pretty happy with the modular connector scheme. I think I made the right choice in using right-angled connectors because all the boards will be flush with each other. I was getting irritated at having multi-level boards, plus I needed to keep standoffs of varying heights. Having them all the same height looks more visually appealing and is easier to deal with in terms of parts. 

The breadboard peripheral was originally just for the Tokyo Hackerspace development board since we will be using that as a teaching platform. But after seeing it in real life, I think I'll be using it a lot for the FreakZ platform as well. It's going to be nice to be able to quickly prototype sensor circuits as well as other types, even just to get an understanding of the behavior. Since all the MCU inputs are broken out on the peripheral, it'll be easy to write up quick routines to read digital sensor values or feed them into the AVR's analog/digital converter. Also, since it's using the modular connector, I can swap them in between the FreakZ board and the Hackerspace board. 

Anyways, I finally got the boards assembled last night and need to start powering them up and testing to make sure they're okay. If things work on them, the next step will be to send the finalized gerbers out to a PCB house where I'll probably do a run of about a hundred boards. 

Here's a couple of pictures of the prototypes:

Today was kind of strange. The PCB files went out, the parts have been ordered, documentation's been written, license was changed, and the release was issued. I really had nothing to do today and it was a strange feeling. I started getting fidgety so I decided to investigate a problem with my USB device stack on Linux that someone reported. No problem found...worked on Ubuntu. Great. After such a long time pushing myself with all the stuff that needed to be done, having an involuntary free day like this was really eerie. I didn't know what to do with it.

Another strange thing was that Michael Jackson passed away. I was always a big fan of his, since my days as a pro dancer. If you're in the entertainment biz, you can't help but admire MJ, who was one of the few people that really knew how to put on a show. There's a reason why MJ, JJ (Janet Jackson), and Madonna are still the reigning icons in pop. My wife was devastated. She's a member of an online social fan club for MJ in Japan and I had to pretty much forcefully hold her back from buying a ticket to LA.

Bizarre...

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:

http://sourceforge.net/projects/freakz

Enjoy!

[Akiba] For those of you that get free Post-It's from the office, here's another thing they can be used for...[/Akiba]

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

One of the questions I get most often is about how the Zigbee Cluster Library works. If you just read the spec, then it’s not immediately obvious because many things are implied. Also, you often have to read the Zigbee spec in conjunction with the Zigbee Cluster Library spec in order to understand how things work because specific parts of the functionality are written in each. However the big thing that people have problems with is implementation. The Zigbee Cluster Library is written in the concept of object oriented programming where everything is abstracted. However actual implementations will usually be written in C which does not have these facilities. Thus there’s a significant architectural challenge to map the abstraction of the Zigbee Cluster Library into a language like C. Since I’m updating my documentation about the ZCL to reflect some recent changes I’ve made to it, I thought that some of the material might be useful in a ZCL tutorial. I’m skipping a couple of layers with this tutorial, but I figure there’s no rule that I need to go in order. Hence, with no further ado…

The Zigbee Cluster Library defines a generic interface to the Zigbee stack and consists of attributes and commands. The attributes contain data about that interface, and the commands initiate actions for it. An example is the ZCL’s level control cluster. The “current level” attribute contains the data value that represents the current level of something, ie: a dimmable light. The “move to level” command initiates an action, where the current level will transition to a new level specified in the command’s arguments. That example pretty much summarizes the functionality of the Zigbee Cluster Library.

The difficulty with the ZCL, and the part that I get a lot of questions about, is that it is a completely generic interface. All clusters have the same interface, in that they can contain both attributes and commands. The attributes are also generic, meaning that an attribute can contain any type of data. One attribute could be a character string and another attribute can be an unsigned integer. In object oriented terms, an attribute exhibits polymorphism where an unsigned char attribute can be used like a string attribute. In C, this is not so easy to accomplish.

Before we get into the details of the FreakZ implementation, it might be good to get an idea visually of what the ZCL is. Here’s a diagram that illustrates how a device profile is put together using clusters from the ZCL.

From the diagram you can see all the basic building blocks. The most basic block is the attribute. Multiple attributes are aggregated into an attribute list. Clusters consist of attribute lists and command parsers. Groups of clusters are aggregated into a cluster list. And finally, the cluster list is tied together by the simple descriptor and the frame handler to create a device. Each device is located on a separate endpoint.

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

We had the second meeting of the Tokyo Hackerspace today and I got a chance to present the design idea I had with the development boards. The response was more positive than I expected. We also got a chance to discuss what everyone wanted to get out of the group. I know I've mentioned this before, but there is a huge amount of IT brainpower and experience within the members. A lot of the interest centered on interfacing electronics with web services and physical computing. I'm still trying to get a handle on what physical computing actually is, but I suspect that it's where you interface a PC to real objects like sensor gloves and clothing. Rob Faludi, if you're out there, could you please enlighten me on this subject? 

Anyways, one of the best things is that there is so much energy to learn and try new things. It's like the complete opposite of working with real engineers. I suspect that I'm going to learn more than they will when all's said and done.

In the meantime, one of the issues I think we're going to face is to distill all of the areas of interest into things that are do-able. I think the best way to describe this would be how to separate things into baby steps so that we can actually make progress on hardware hacking and cool projects. I was discussing this with one of the other electronics guys and we think that, on the electronics front, there needs to be some workshops on fundamental electronics and embedded programming. On the other side, I think that we also need to tap some of the computing brainpower for web services and how to access them, as well as the experiences of the artists, musicians, and chefs. Once we can start diffusing the knowledge and experience, I think there's no limit to the design possibilities.

One thing I'm pretty sure of is that Contiki and uIP are going to be really popular. I'm going to be bringing in the Raven wireless boards at the next meeting and showing them some basic Zigbee functionality as well as explaining 6LoWPAN (IPv6 over 802.15.4 for the uninitiated). I'm pretty sure that it's going to spark a lot of ideas. 

Stay tuned, because I think this group has the power to realize a lot of the things that the WSN industry is just talking about. At least...(*buzzword alert*)...the Internet of Things, as applied to real things...

When I first started this blog, I talked about Zigbee on Google Trends . This was in March, 2008. I recently checked again and there's a noticeable difference in news reference volume which means that Zigbee is getting much more press coverage than back when I originally made the post. Here's the picture from March 2008 and the most recent one.

 March 16th, 2008

June 16th, 2009