Well, I finally did it. I mentioned before that I was working on something when I was in the US to while away the time at the coffee shops. That something was an ultra-simple, ultra-small wireless stack that could just be used to transmit and receive data. It’s something that came out of working with the people at Tokyo Hackerspace . A lot of them were interested in being able to control things wirelessly, but I didn’t really have an answer for them. I felt that Zigbee was too complex, and even 802.15.4 had a fairly steep learning curve, due to the need to do passive/active scans and associate with other nodes.

What most of them were looking for was just something that they could transmit and receive data with. I’ve been thinking about how to implement something like that for a while because wireless stacks, even simple ones, can get complicated due to wireless being an unreliable medium. Hence you have to build in complexity to handle timeouts, retries, acknowledgements, etc.

Wow, just read that Google Powermeter bypassed the utilities and is accepting data directly from energy monitoring devices. The exciting thing for me is that the first gadget partner is the TED 5000 (The Energy Detective) which runs a Zigbee stack . This means that the potential is there for Google to open the API and collect data from individual energy monitors. Although the API would have nothing to do with Zigbee, the potential is there for a lot of new monitoring devices to start coming out and there's a good chance that a lot of them will also be using Zigbee. Hence I gotta start busting some ass and get the smart energy profile up. Nothing better than having an open hardware energy monitor running an open source Zigbee stack and sending the usage data to Google Powermeter :)

I got to thinking about why most of the good engineers I meet are both arrogant and pessimistic. I don't think that it's an accidental occurrence and for the record, I exhibit both characteristics quite a bit. But it might be good to give a bit of background information.

When you start writing software or designing hardware, you're at the mercy of a huge amount of unknowns. Take for instance embedded software. If you're writing software for a new platform, you don't know for sure if the underlying hardware is completely working. You could spend days debugging a problem and eventually find out that there was a solder bridge on the board. Or even worse, that the hardware engineer spec'd a part that didn't meet the timing requirements of the peripheral that you're trying to access. 

Or if you're a hardware engineer, you could spend days debugging a problem when it turns out that there was a bug in the chip that was mentioned in two sentences in some obscure errata document. Or even worse, that you had some semi-conductive flux on your SMA terminals that are completely throwing off your measurements and took days to discover.

In the face of these circumstances, self-confidence is absolutely required or else it'd be easy to crumple and just use a lame excuse like my debugger doesn't work. However pessimism is also a self-defense mechanism because everything, including irritating marketing propaganda (and those vexingly optimistic marketing people for that matter) is your enemy. Potential bugs, even rather benign ones like a mistake in register bit numbering by an entry-level engineer that was put in charge of updating a datasheet, can lie around every corner which is why you can't take anything at face value. 

I think the main point I'm trying to convey is that I can understand why engineers are arrogant and pessimistic. Every day that you approach a design, you're facing failure. You're going to war against an infinite amount of unknowns and you have to master tons of knowledge in order to hopefully decode any crumb of clue you're given. When a design doesn't work, you have to plumb the depths of your knowledge (or perhaps Google) to figure out that the 100k pullup should have been a 10k, or that the one register bit you thought was insignificant should have been set to the non-default value. When you get a design that's working, it's not just that the design works, but that you've managed to avoid or overcome all factors in the universe that are plotting against you. 

So yes, I can now see why good engineers are both arrogant and pessimistic. Like war-weary soldiers, they've survived many battles and are still enthusiastic about designing their next projects. And when you try to throw Windows 7 at them, they'll just smile and say "let's wait a bit and see how it goes". 

Well, finally back in Tokyo. I'm a bit late on this blog update because the two week excursion to the US put me seriously behind on a lot of things. One thing that I was suprised with is how busy things have gotten recently. With the part-time job, setting up the webshop, handling inventory, assembling boards, and the various side projects, I'm surprised that I haven't had a nervous breakdown.

Getting the hardware up is taking much longer than I expected. I actually ran into some issues with getting consistent results on the impedance matching between boards. I finally found the culprit which was careless assembly. There were small amounts of flux left on the board when I mounted the SMA connectors and the flux is very slightly conductive. It turned out that it had a random effect on my return loss values between the different boards. It was really frustrating and I was about to throw out all of my SMA connectors since I thought they were causing the problems. Anyways, after cleaning up the boards thoroughly, I began to see consistent results and my yield went up dramatically.

I've also been working on a side open source project which I should be announcing soon (if I can get it to work). I'm a little bit excited about it, but there's really not much commercial application. I think it's gonna be kinda fun, though. I started it when I was in the US because I ended up spending a lot of time at the coffee shops in Berkeley and wasn't used to having a lot of free time. Apologies for the secrecy, but you should be hearing more about it soon...

Other than that, got a lot of stuff done in the US. It was supposed to kind of be my vacation but it turns out that free time gives me more stress than being busy. I ended up talking to a wireless security researcher and am providing a little assistance on his upcoming wireless security book. Mostly just editing and fact checking, but from the material I've seen, it's going to be quite interesting. 

I also got the chance to meet up with the founder of Wireless Glue and his team, who specializes in Zigbee Smart Energy. He was showing me his new prototype device which is a Zigbee-based energy display that will show the real time energy consumption data from a smart meter along with the cost. He's a total geek and had the prototype enclosure made with a 3-D printer, that he sanded and finished himself. That got a lot of geek props from me. He was also filling me in on the latest news about Zigbee Smart Energy since he's one of the SE spec authors and also developed the Zigbee SE compliance test spec. You'll probably be hearing more about his company soon, and he should be releasing a really cool 802.15.4 module which uses a CC2520 (802.15.4 radio) + CC2591 (RF Tx/Rx amp). If you aren't familiar with the CC2591, its an 802.15.4 front end that can boost the signal to +22 dBm on the transmit side (~170 mW or about 60x the power output of the CC2520) and an improvement of about 3x on the receive sensitivity. It's also notoriously hard to work with which is probably why I haven't seen too many devices out there that have successfully tamed the chip.

And finally, I met up with a company thats interested in using my stack for an implementation that would go in actual smart meters. This could actually give me the motivation to work on the Zigbee Smart Energy profile since I've been really lagging on it for awhile. The whole Certicom license thing left a bad taste in my mouth since I heard that it's a hassle working with them and I don't approve of software patents, but since this company is fairly well known in the metering industry, it might help make things a bit easier. At the very least, they have a really great staff of experienced metering engineers plus tons of test equipment. Taking the stack through their QA should help make it much more robust and flush out the nasty bugs.

That's about it for my trip log. As I mentioned, I got the RF boards tuned and producing consistent return loss values. There are about eight of them up so far so I should be able to start setting up my own wireless sensor testing network soon. Oh, and here's a pic of one of my new antennas that I'll be testing. Its got 24dBi directional gain, aka 256x gain versus a standard 0 dBi omni-directional antenna. In other words, if I can get it working, it'll be a monster :)

Going on my second week in California and I'm already ready to go home. The weather in California is beautiful, and driving around in a convertible kicks some serious ass. But nothing can beat being surrounded by circuit boards, ICs, and my equipment.

I actually got a lot of stuff done on this trip like visiting my sister's family, seeing my parents, visiting the SF hackerspace, catching up with live Zigbee members, hanging out with old friends, ordering export controlled 2.4 GHz radios and MCUs, and of course, work. By far, the two most stressful events were work and seeing my parents. I'd have to say it was a tie.

The parents are still complaining about my lack of a job and wondering why I don't pursue a nice, stable corporate career. I tried to explain to them that such a thing doesn't exist anymore, but unfortunately, they didn't buy it. At least they've eased up on pressuring me for a grandchild.

I'm excited about the chips I ordered while I was here. When I first came, I tried to order a bunch of CC2520's since those radios are conspicuously missing from my parts inventory. The problem is that Digikey and Mouser don't ship them outside the US due to the onboard encryption engine which puts them in an export controlled category. That restriction only penalizes people with non-terrorist ambitions since any self-respecting terrorist wouldn't let that stop them from getting a chip. Hey, if they can get nuclear weapons...

Anyways, after about a week, Mouser suddenly got 400 of the CC2520s in stock so I immediately grabbed 200 of them. Just got the tracking number today so I should be receiving them before I leave. 

Another interesting chip I got was the ATXMega128 which is one of the newer AVRs. Yes, I'm an Atmel fan and no, I'm not sponsored by them. The interesting thing about the XMega is that it has an onboard AES security engine which should alleviate the vulnerability found by Travis Goodspeed when the keys are transported across the SPI bus. I'll probably be testing it out to see if it can be used for the Zigbee Security Manager. 

And finally, I found a cute little chip in the ATMega32U4 which seems to be quite new. It's got 32kB flash, 2kB RAM, and integrated USB. It has fairly perfect proportions of RAM/flash for a fun project chip, plus integrated USB which I can port my stack to. I grabbed a bunch of those as well and will be playing with them more in the near future. 

Anyways, until next time...*smooches*...

Well, it's only been about a month and a half since I took some time off from the software tasks to work on making a stable platform for myself. I have to say that it was a lot tougher than I expected. Actually within that time, I also worked on the webshop beta site, getting the administrative things out of the way (ie: registering a merchant account for credit card handling, choosing and ordering inventory, etc), and working on bringing up the Tokyo Hackerspace now that we've secured a house. Yep, things were mighty busy for the past couple of weeks.

It feels like forever since I touched the stack, and it's weird that I call this an open source software project because it feels like all I've been doing recently is hardware. However I feel like I'm building up a good infrastructure for the project's future. I think the difficult thing about open source embedded projects is getting a stable platform to develop on. It's one of the big differences between a regular open source project where you just develop software for a PC and it adds a lot of complication to things. For wireless sensor networks, it's even more critical because there are so many system constraints that you're dealing with: power management, MCU + resources (RAM/flash, IO, peripherals), radios, and antennas.

I guess I'm probably trying to justify the investment in time and effort for coming up with the hardware, but I do think that it's very important. I figure I'm going to be using the dev platform a lot to take things to the next stage, which is actual implementation. There are a couple of good platforms already available, but they're not exactly great for setting up a wireless sensor network. The platforms that are targeted directly at wireless sensor network development are also on the expensive side so I wouldn't be able to justify spending the money to purchase ten of them. And the worst part is that the platforms are fixed so you just need to take what you get with them. I'm hoping to be able to interchange power supplies, MCUs, radios, and antennas so that I can quickly prototype a platform to suit a specific need. 

But enough about that. I won't know how it goes until I get to actual testing, but I can say that I'll be back to working on software soon. The hardware has already arrived and I assembled the first batch. I did the first group of PCBs by hand because I like to work intimately with new boards. It gives you a good feel for any problems or errors that might have been made. Most people just think about functionality but there are a lot of things that can go wrong when fabbing a PCB. Seemingly simple things like having a pads of a footprint off by a couple of mils could turn into a manufacturing nightmare. Or you often find little things that might have gotten missed during the final check like a misaligned silkscreen, a reference designator that's hidden, and so on. That's why I think it's good to perform initial hand placement so you can get a feel for all the nasties that could turn up and bite you. 

Unfortunately, I won't be able to test the boards immediately because I'm headed to California tomorrow. It's a combination of work for my part-time job and also a chance to visit my parents and sister. I'll be up in Berkeley next week for a couple of days, then shuffling on down to Southern California to care of business. While I'm there, I'm probably going to be placing massive orders with Digikey and other US-based suppliers since the shipping is sooooo much cheaper. Everyone in the US doesn't realize how spoiled they are by not having to deal with international shipping. Also, Digikey won't ship any parts with embedded encryption outside of the US. This of course pertains to most 802.15.4 discrete radios and some MCUs I'm interested in, now that Travis Goodspeed has basically obsoleted an encryption engine integrated onto a radio. If anyone from TI is reading this, please send me a contact to order TI radios in Japan. I can't get them through Digikey and the local distis don't even acknowledge my existence. Apparently, open source projects don't get a lot of respect here :/

Other than that, I have to say that things are going quite well for me recently. I'm surrounded by PCBs, development boards, and really cool parts, hanging out with a really great bunch of geeks, and I'm finding Twitter extremely fascinating. Couldn't ask for more...

Here's a couple of pics of me unboxing the WSN dev platform I designed and assembling the MCU and radio boards. The explanations are in the captions:

A strange phenomenon occurred where many people started posting very interesting software on Twitter. The attraction is that Twitter limits posts to 140 characters and so it's a challenge to see what type of functionality you can implement within that 140 character limit. I've been completely astounded by the quality, functionality, and creativity of these twitcodes and I've decided to archive them here. I hope you can enjoy them as well.

Wow. It's already September. Progress feels so slow on the Zigbee project, but if I look back, I can see that I'm light years ahead of where I was one year ago.

At the moment, there is a lull in the software development because I'm putting together the webshop and hardware. As I mentioned previously, the PCBs for the initial WSN dev platform have already been sent out, and I'm waiting to get them back for assembly and testing.

I've also been stocking up on supplies for the webshop. The focus of the webshop, if you can't guess, will be wireless sensor network development. It's mostly targeted at people that are developing their own implementations for wireless sensor networks, which includes protocols other than Zigbee, although I'm mostly using the hardware for Zigbee dev.

The problem is that there are a lot of different protocols and requirements out there for many different applications, but nobody is really making development platforms for them. Many WSN developers are still using hardware developed years ago and are already end-of-life'd like the TMote Sky by Moteiv (now called Sentilla). Other development kits are usually targeted at specific applications by the chip manufacturers, ie: Zigbee, RF4CE, etc or are just distributed to showcase the electronics. The problem is that WSNs are really about the entire system including power supply, antenna, radio, MCU, and sensors. I figure that it's time to make an attempt to put together a system that will try and address this, or at least be something that I can use for my own development. Anyways, its fun developing the platform and I'm looking forward to the time when I can set up a kickass WSN.

Anyways, I've already bought a couple of different sensors that I'll be making boards for, as well as some nice sensor modules for humidity, temperature, pressure, acceleration, etc. I'm also stocking different types of external antennas which are very directional and provide high gain within the transmission area. It's pretty fun because some of them are really manly antennas that get mounted on poles and my wife is already asking me why the balcony is starting to look like a radio station :)

I've also been spending time trying to improve my board assembly flow so that I don't need to spend as much time on it. One of the things I was experimenting with was the solder paste stencil. Most people use plastic mylar ones, however I've found that they're hard to cut on my CNC due to the heating from the CNC bit. It leads to imperfect stencils and they're hard to work with. I purchased some solid copper sheet metal from the local store (yes, the local stores carry them in Japan), and was able to succesfully cut the stencils with very good precision. Even the QFN leads came out well on the mask which was surprising. I also tested out the amount of solder paste dispensed by the mask by reflowing a bunch of the Tokyo Hackerspace boards. It worked out pretty well, but I need to adjust the size of the stencil openings to deposit less solder paste. Overall, its possible to tweak the mask to get perfect results so I'm quite satisfied.

On a less serious note, I've been having a lot of fun on Twitter recently. A bunch of the software geeks including many WSN researchers like Adam Dunkels, Joakim Ericcson, and Raluca Musaloiu have been participating in #twitcode sessions. The goal is to come up with a functioning program within one twitter post which contains 140 characters. It's actually 131 characters usually because you attach the search tag "#twitcode" at the end to make it easily searchable. Some of the featured twitcodes are:

  •  Linked list library by Adam Dunkels  - A generic linked list library that can be used as a building block for data structures
  •  twIP IP stack by Adam Dunkels - A very constrained IP stack that can respond to pings. This actually made it on to Slashdot .
  •  Tiny Webserver by Raluca Musaloiu - A 128 character webserver written in Python
  •  CPU Emulator by Joakim Ericcson - A CPU emulator capable of 8 operations: a +/- b, a=b/b=a, jump, jump if a=0, break, two gp registers (a,b), 99 words RAM

I was also having fun playing and came up with some twitcodes of my own:

  •  Twitter post buffer stack - LIFO buffer stack for holding twitter posts, ie: in case you want to queue a batch of twitter posts for transmission. It was built using Adam Dunkel's linked list library twitcode :)

Probably most are wondering what the purpose of this is. There really is no purpose other than playing around and seeing what you can squeeze in a Twitter post. If I could summarize it, I'd say it's like sudoku for geeks. There's also a nice twist because you get to break every rule in software coding style. Most of us are always trying to write clean, readable code so it's nice when you can just get down and throw caution to the wind. A lot of the code relies on inferring behavior from the ANSI C spec and compilers which is a huge no-no in software design. That's probably why it's so fun. Anyways, I'm starting to see the real benefit of Twitter now, like how a bunch of wireless sensor network researchers can spontaneously get together and write code that fits into twitter posts. Totally useless and beautiful in its uselessness :)

Well that's basically it for what I've been doing lately. Attached are some pics of my current prototype WSN dev platform and some of the antennas that I'll be using and putting in the shop:

Updated 2009-09-02: Mistakenly said that Moteiv became Sensinode. I meant to say Sentilla. That's the problem with being stupid.
I just did a massive purge on the blog of 75% of the users. All deleted users were checked against the botscout database for matching spambot signatures (ip and email address). Nevertheless, if anyone has any problems with logging in, please send me an email through the site. Or you can also PM me.

Well, the Twitter thing is turning out pretty interesting. I originally made fun of all the people on Twitter because I had thought that it was only for people with nothing better to do than post the painful details of their lives. Actually, I found that I'm one of those people. I had a lot of mental resistance to joining it, but eventually gave in because all the people in Tokyo Hackerspace were using it and trying to convince me of all the wonderful things about it. After having used it for about a week now, I have to say that it is in fact pretty useful. I don't think it's for everybody, but it does have two very good qualities that I can see now. The first is that it's an excellent source of information. If you follow people that are roughly in the same industry as you, ie: wireless sensor networks, then you can see them constantly posting links to interesting topics that are relevant. It's especially important for me because I'm trying to aggregate WSN news so I'm always looking for new information sources. The other thing that is quite handy about it is that it's a good way to keep people posted on the status of the project in real time. If you just look at the blog, then it might seem as if the activity is slow. However there are a lot of things that go on behind the scenes that never make it to an actual blog post but can easily be thrown into a sentence on Twitter. I guess I should refer to it as a tweet, but I still find the term a bit embarrassing. In other words, for someone like me, Twitter is a very good communications tool to fill in the information gaps that the blog can't cover as well as find sources of interesting WSN tidbits.

Aside from that, I've finally sent the first FreakZ development platform board files to the PCB fab. The reason it took so long was because I had to verify both the MCU board and the radio board together. I went through three different radio prototypes before settling on the one I have now. It contains both an SMA connector and a chip antenna and either source can be selected by moving a DC blocking capacitor. I had originally thought to use just an SMA connector, but that proved to be a hassle. External antennas are expensive, bulky, or require cables so if you have more than one or two, it becomes unwieldy. Chip antennas are a better choice if you don't need the performance of an external antenna and just want the convenience of having something ready to go.

I decided to leave the SMA on as well though because there are some situations where an external antenna is much better. Chip antennas are not very efficient and the impedance is not always matched correctly to 50 ohms. That means that you may lose energy to impedance mismatch or simply losses in the antenna. Also, chip antennas usually radiate outward uniformly which is not always desired. There aren't many cases where I need to radiate a signal to my ceiling (Z axis) and would rather have the energy concentrated in the XY-axes. There are many excellent external antennae that are directional so if you know the direction of the receiving node, you can point the antenna at it and concentrate the energy towards it. That way, it's a better use of the available transmit power and you can increase the transmission range. There are some fairly inexpensive directional antennae in Akihabara that are 9 dBi which means that they have ~8x the power in the direction they're pointed at compared to a uniformly transmitting (isotropic, which is what the 'i' stands for in dBi) point source antenna. 

The initial FreakZ dev kit will consist of two main boards: the MCU board and the radio board, connected by a standardized connector. The reason they're separated is because I want the freedom to interchange different MCU boards with different radios.  That's also the reason why I'm standardizing my connector and pinout so that all boards can connect with each other. The initial MCU board will be an AVR, more specifically, the AT90USB128 which is the same MCU as on the Raven boards. That way, people that are already using the Raven can use the FreakZ board as well with basically no software change. The reason why you might want to do this is because it's almost impossible to prototype on the Raven boards which I found to be one of its greatest shortcomings. Although Ravens are great for doing protocol stack development, when it comes time to do an actual implementation, it's very difficult. 

That brings me to the third board, which is the breadboard peripheral. This board is the same as the Tokyo Hackerspace breadboard I designed for the hackerspace workshops, and it also includes a standardized connector. The MCU board's I/O, interrupts, SPI/I2C, and power pins are also broken out on the board so that it's easy to interface back to the microcontroller. The main feature is that there is a breadboard where you can quickly try out different sensors and circuits. That way, you can interface the sensor/control circuits to the MCU and communicate the data to other wireless nodes easily. It's basically the rapid prototyping platform that I wanted for myself, including the ability to swap out MCUs and radios which is one of the main points of having an open source stack.

If you remember, I had made some prototype boards previously and actually got two of them working. So in what little spare time I had, I actually set up a 4-node network which was quite nice. What was even nicer was that I was able to do the route discovery across the four nodes properly and communicate with the nodes on the end of the chain, while hopping the intermediate nodes. However I can't really do much real testing until I set up a somewhat larger network so I'll have to wait for the board sets to come back from the fab.

And finally, I'm putting together a couple of application circuits. One of them is an AC energy monitoring module which should come in handy for a lot of power monitoring applications. I'm hoping I don't electrocute myself during development but if it works out, then it might turn into an easy way to add energy monitoring to things like automated light switches/dimmers, or other apps. I'll keep everyone informed about how this goes.

In the meantime, I gotta get my ass back to writing tutorials. My tutorials section has been stagnating on the NWK layer for the past few months. Also, if you want to see what's going on with the project (or me) in real-time, you can check out my Twitter page . I'll try and see if I can figure out a way to publish the messages in a blog sidebar as well. 

Here's some pics of the boards I just sent out:

I've been getting a lot of emails on the status of the Zigbee stack recently and its probably because it looks like nothing is going on. Actually, there is a lot of stuff going on but its pretty much behind the scenes and the details don't make it on to the blog. So I finally gave in and created a Twitter account, in case there's any curious souls that want to know the mundane trivialities that I'm doing battle with on a daily basis. Well, that and apparently, all the cool people in the WSN industry seem to be on Twitter.

Here's the Twitter link: 


It's been a while since I wrote a status update on the FreakZ stack. Actually, on the software side of things, there isn't much to report. However it seems that this summer is pretty busy for me.

I've been getting a fairly steady stream of visitors to Tokyo that I've been meeting with. It's actually quite interesting because I've gotten the chance to meet people from Hong Kong, Korea, US, France, Taiwan, and a couple of other locales. It's nice to meet people in the industry and also from different countries because it gives me the chance to see how things are in other parts of the world, especially in terms of wireless sensor networking. One thing that has really surprised me about open source is that discussions and exchanging information is so much easier. Back when I was a company employee, there was always an air of suspicion and distrust when talking to people outside the company. We were conditioned to protect company secrets, no matter how inane or useless they were. By removing that factor and being completely open, I'm surprised at how willing people are to discuss important topics or even teach me about things that I didn't know. 

I recently met with two guys, an RF engineer who designs front end transceivers for ICs and an embedded Linux developer interested in doing WSN applications on Linux. The RF engineer schooled me on a lot of the RF questions I had, especially for impedance matching and return loss measurement for balanced (differential) RF signals.  I was also having a pretty intense discussion about the possibility of using Linux for WSN apps. I think it will be important for gateways and coordinator/controller apps, but Contiki/TinyOS seems to be a better fit for WSNs in my opinion rather than a full featured OS. 

I've also been busy helping the Tokyo Hackerspace set up their webshop. I think a couple people are wondering why I'm spending so much time on Tokyo Hackerspace. The reason is pretty obvious to me. Being an isolated developer trying to tackle a field as wide as wireless sensor networking and Zigbee is pretty difficult. I'm also limited by being pretty narrowly focused on the communications and engineering side of the WSN industry. In plain terms, my domain is narrow so I feel like the scope of my thinking is similarly limited.

Just saw an article mentioning that Peter Alfke from Xilinx is retiring . He's a legend in the FPGA community and was an FPGA guru on the Usenet group: comp.arch.fpga . I remember when I was just starting out designing with FPGAs back in another life, I was completely clueless about how to use the devices. His posts were my textbook and I gradually got the hang of taming the wild beasts. Back then, the FPGA compilers were complex and bug-ridden, the chips were completely cryptic, and it would take a whole day to compile a design on a Pentium 100 MHz PC. At least the PCs are faster now :)

Goodbye Peter, and if I ever get a chance to work on FPGAs again, I'm going to google your posts on the Usenet archives. Although I didn't know you personally, I felt like I did...