People following this blog are probably wondering what I’ve been doing the past four months. Well, I’ve discovered that developing wireless sensor network hardware has been more of a challenge than I had anticipated. The design was actually the easy part. It’s everything that comes after that makes my life difficult. When I started on the hardware development, I thought that I just needed to design the boards, tune the radios, and stick them in a web storefront. Looking back, I’d say this was completely naive. The original idea was to have a supply of boards both for my own use and to sell in a webshop. My eventual goal is to make this open source project self-sustainable and I had figured that making hardware was the easiest way to get there. That was a gross underestimation.

One of the things that I discovered is that designing a schematic and making a PCB is just one small part of the overall design process when you’re trying to bring a board to market. There are a lot of factors that get ignored or underestimated like prototyping, sourcing components, prepping for manufacture, testing, writing documentation, and of course, the killer issue of all low-volume hardware outfits: assembly. A lot of these areas are trial-and-error and the error part is what consumes a lot of the time.

In the last four months, I’ve designed seven PCBs: three for Tokyo Hackerspace, four for FreakLabs. In that time, I’ve learned quite a bit about the flaws in my overall design process   and also the business side of trying to manufacture and sell boards. I’ve made a lot of mistakes that could have been corrected in the design phase if I had more insight into how I was going to manufacture and assemble the boards, but it’s tough to get that insight without going through the overall process a few times. I can’t really complain because although the past four months have wreaked havoc on both the Zigbee project and my personal life (and made me even more anti-social than I used to be), I have to say that I’ve probably also accumulated more hardware, manufacturing, and business knowledge than I’ve ever had in my entire career.

Everyone talks about the machine-to-machine (M2M) universe where the information from a plethora of cost-effective sensors allows people and systems to make even better decisions. One of the many challenges has always been the connectivity required for these sensors.


I was a little surprised that people actually checked out my first pick and place tutorial on setting up the machine. Well, this second one will probably put you to sleep. It deals mostly with the operation of the machine, and it only pertains to an MDC pick and place machine. I think that there is only one person on this planet at this moment that might be truly interested in this information. Hmm...possibly two. But anyways, that's good enough for me.

Hopefully in the future, these tutorials might actually contribute an infinitesimal amount to building the concept of micro-manufacturing. The open hardware community is definitely active in this area and the great thing is that they're spurring innovation and improving their local economies. This will probably be my last pick and place tutorial for awhile, but I figured it was needed to get things started. There just isn't enough information about it on the internet. Although most will probably not benefit from this tutorial at the moment, I think that in the future, when the openhardware community starts automating their operations more, these tuts might come in handy. Let's give it up for hardware hackers with a wad of cash and sore eyes!

With no further ado...

Recently, there’s been some interest in the open hardware community for pick and place machines. Especially with LadyAda's most recent engineering chat featuring her new pick and place . I had always suspected there would be, but never knew for sure because there wasn’t a lot of information out on the internet for indie developers trying to buy pick and place machines. I ended up purchasing my pick and place machine from a company called MDC in Japan who are one of the few makers of benchtop pick and place machines that are relatively inexpensive (ie: <$50,000). Incidentally, when I purchased the machine, I told the president that there would be a lot of interest from indie developers for a machine like theirs. He didn’t believe me. If you inquire about a machine from them, tell them Chris sent you and that the open hardware community loves pick and place machines :)

Anyways, in case anyone else purchases an MDC machine, I decided to put up a step-by-step image gallery tutorial on setting it up. If anything, it will at least help familiarize others with what a pick and place machine is and the different components on it. Hope you like it. 

Please click on the "Read More" button. There are a lot of pictures involved so I didn't want it to bog down my front page.

Forgot to mention. The website of MDC is here . Also Manncorp sells them under their "Economy Pick and Place Machines". Update 2: To answer the questions, my machine cost about ~$20,000 but was a used floor model and has almost no options. I do have quite a few feeders. If you want to fully automate your placement, you'll need to get the bottom vision option which allows placement of fine pitch parts like QFNs and BGAs. Also, the final price will depend on the number and types of feeders you get as well as which model of machine you purchase. And no, I'm not a sales rep for MDC...

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

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.

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.

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:

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