Just wanted to let people know that the Chibi boards have come in. I'm dreading the assembly of another board since I already feel like a sweathouse laborer, but I think this board will be kinda fun to play with. I've added some captions of things that make it kind of interesting...if you're a geek...

Also threw in a shot of one batch of the AT90USB128 (FLAVR128) boards that will be one one of the modular MCU boards for the FreakZ platform. They're in an intermediate assembly stage where the surface mount components have been placed and reflowed. The thru hole components like the right angle headers, JTAG connectors, and DC jack have yet to be installed. 


Finally working through my design backlog and getting ready to start the stack development again. Things took much longer than expected. After releasing the Chibi stack, I realized that hardware is needed or else the stack is meaningless (seems to be true for any stack I guess). So I took a couple of days to design a board specifically for it so that people could play with it. It's mostly targeted at the DIY electronics community which is composed of artists, hardware hackers, and enthusiasts so I had to put some extra thought into it to increase functionality and keep the cost low. I just sent the PCBs out yesterday so I'm hoping that they should be back in about a week and a half (including shipping time).

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:

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.

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:

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.

Spent the past two days working on tuning the RF portion of my circuit. I wasn't sure how it would turn out because it's the first time I tried to make a 2-layer RF board. If you haven't noticed, most of the reference designs are on four layers since the impedance is easier to control that way. It was also good because it gave me time to get to know my network analyzer and me and her are becoming best buds.

When I first started tuning, I was totally in left field. I had used the online transmission line impedance calculators and for a 70-mil microstrip on FR-4 with a 59 mil dielectric, I was supposed to be getting about 63 ohms for characteristic impedance. After tuning the circuit, I calculated the impedance of the receive path to be around 35 + j8 ohms. The imaginary component implies that its an inductive impedance, probably due to the length of the trace. 

It was really bizarre because the real part of the impedance was about half what I expected it to be. It was a good lesson for me because I learned that you can't really trust math when it comes to real world performance of RF circuits. For the online microstrip calculators, they assume that you have a trace on the top layer and an infinite ground plane on the bottom layer. However in the case of my board, it was untrue. I actually had a ground plane on both top and bottom layers. I think the top layer ground plane, which was separated from the trace by just 8 mils, affected the impedance pretty drastically. Also, there were contributions from the balun, DC blocking caps, and the differential RF lines coming out of the chip. I suspect that's why my initial tuning values for my matching network were so far off.

It took me about twelve tries to converge on a good impedance match. It actually took me about 8 tries to see the LC resonant dip for the return loss and then an additional 4 tries to center it on 2.4 GHz. The final outcome was that the minimum of the return loss dip was centered at 2.46 GHz (channel 22) with a return loss of -40 dB or about 99.99% power transmitted. My worst return loss value was at 2.405 GHz (channel 11) which was at -16.1 dB or about 97% power transmitted. Still, not too shabby. Word to the wise, those RF inductor and capacitor kits from DigiKey really came in handy.

So this little experience took me pretty deep into the realm of RF design. I can see that RF calculations can only give you a very, very ballpark understanding of how your circuit will behave and that you actually have to measure it to know the real performance. In short, RF design is messy. Luckily, it seems like I survived the ordeal.

Here's some screen captures of the return loss testing with my network analyzer:

I decided to keep this post separate from my last one because it's mostly a rant about stupid bugs. I spent the last two days tracking down a bug that I had though was due to race condition in the stack. When I run the board without a JTAG, then everything is fine and it runs with no problems. However when I run it on a JTAG debugger, then the system hangs at a certain point. I figured that the JTAG was causing some type of timing change which was able to hit a specific condition to cause a hang. Hence I spent the last two days stepping through the circuit and tracing different areas to see if I could locate where it was hanging. I couldn't.

I then checked the JTAG traces to see if there was any signal integrity problems on the lines.  Finding nothing, I though the crystal settings on the JTAG ICE might be incorrect causing an unstable clock when the ICE was used. No change on any setting. Nearly in tears from the frustration this was causing me, I started probing around the board with the scope. I then found that the supply voltage was at 4.2V instead of 5V coming in from the USB bus. Looking down at the USB hub, I saw that the power cord was slightly unplugged from the power jack.

So to make a long story short, the USB hub had lost its power connection and had reverted to supplying bus power directly from the PC. When a hub is bus powered rather than self powered (having its own DC supply), each port can only supply a max of 100 mA. Had the power been fully plugged in, it would have been able to go up to 500 mA. That's why when I ran the board alone with the JTAG ICE turned off, it was completely fine, but using the JTAG ICE would suck enough power to drop the voltage down to 4.2V. That was just enough to let the microcontroller run a little and then go completely nuts at random points. 

Man, sometimes I hate being an engineer...

Lately, the pace of things to do has been picking up quite a bit for me. Along with trying to make progress on the Zigbee project, I'm also helping the Tokyo Hackerspace set up their website and preparing their boards for production. It's quite a big time suck because I need to source a bunch of parts for those boards. The good thing is that alot of the parts can be reused across the boards I'm making as well, which is the way I designed it. However I didn't realize that sourcing components was such a big pain-in-the-sphincter. There's a balance that's required because the hackerspace boards can't be too expensive and so I'm buying direct from the manufacturers for a lot of the less important components like connectors. DigiKey charges an arm and a leg for connectors and buttons, whereas you can pick them up from the manufacturers for a fraction of the price. The problem is that you need to buy in rather large quantities which is why I'm trying to share parts between boards.

On the FreakZ project, I needed to pick up a calibration kit for the network analyzer so that I could make accurate measurements. I was hoping I could get away with the calibration kit I had, but it unfortunately had Type-N connectors. Those connectors are big-ass RF connectors that are probably used if you want to set up a radio station. I was hoping I could just pick up some Type-N to SMA converters, but after discussing with some RF people, that turned out to be a no-go. The calibration would have been useless unless I put the same Type-N connectors on the board. If you can imagine the connectors on a typical garden hose connected to a 1.5 inch board whose main component is a 5mm x 5mm QFN IC, you can see the quandary that it posed. 

So it turned out that I had to pony up some cash, about $2000 to be exact, to buy a used 3.5mm 50-ohm SMA calibration kit. Both my wallet and my ass are still hurting from it. Well, anything goes to get this project out the door I guess. It's definitely a learning experience. One of the scary things is that it's dangerous to buy the SMA calibration kits used because you don't know if the previous owner knew how to properly care for them. If you twist the connectors when you connect them to the analyzer, you can strip the gold plating and the fragile internal leads. That would turn a shiny $2000 machined calibration kit into this year's Christmas ornaments. 

Anyways,  I tested out the calibration kit and was able to calibrate my analyzer correctly for 2.4 GHz. The next step is to test the return loss of the boards I made. I actually made an additional radio board with the AT86RF230, but with a more flexible structure on the RF line. One of the reasons why I'm going through so much trouble on these boards is because I'm trying to make a 2-layer radio board. Normal boards are 4-layers and you can control the characteristic impedance to 50 ohms through the PCB manufacturer. Thus, you can say I want the boards so that 10-mil lines will be 50 ohms and they'll use a dielectric thickness that allows the board to match this impedance.

For a 2-layer board, you're pretty much stuck at 59-mil or 31-mil dielectrics which means that you're going to need a big, ol' fat trace to get down to 50 ohms. At 59-mil dielectric, you'd need something like a 110-mil trace to get close to 50 ohms. At 31-mils, you're board is going to be flimsy. 110-mil traces aren't very feasible, especially since the max trace size that can fit between the legs of an SMA is about 70 mils. The alternative is to use a sensible trace width (I used 70 mils) and put an impledance matching circuit on the line. I'm hoping that I can make the trace look like 50-ohms at 2.4 GHz by tweaking the components. My goal is to get a return loss value of < -15dB which translates into > 97% power transmission. 

If you followed what I just said, you must be fairly well versed in RF design. Anyhoo, gonna be running some experiments this week to see how things go. 

In the meantime, you're looking at one broke-ass mofo...looks like I'll be eating at home for a while...

Well, I warned everyone that the FreakZ project is now entering a hardware phase so don't be surprised if you hear about hardware for the next couple of weeks ;)

Anyways, I got the MCU board up and running and everything was working as it should. It actually came up very quickly because it's the same MCU as the Raven boards. Hence the MCU initialization and the USB interface is mostly the same. After I verified the MCU was okay, then I started working on getting a radio board to match it up with. The first radio board will be using the AT86RF230 of course. It's the same radio as the Atmel Ravens and will serve as a good reality check. In case there's anything wrong with my system, I can always compare it to the Raven since the hardware is essentially the same. 

I spent most of the weekend working with my CNC machine to optimize its settings. It's been about six months since I last used it, and back then, I felt really rushed to get things up and running so I could get back to the project. This time, I decided to spend more time with it and really learn how to use it well. It's like an instrument, where it can do what you want it to do, but only if you know how to use it correctly. So I was trying out different bits like V-cutters at 30, 45, 60, and 90 degrees and different size end mills. I finally settled on some tools that worked out well for me and gave me the best results.

The CNC software was also recently upgraded, and I purchased the Pro version of the software which will allow me to cut solder paste masks and import DXF (CAD) files. This is going to come in really handy since I'll be making a lot of boards soon, both for the Tokyo Hackerspace as well as the FreakZ project. The CAD import is a nice feature because I can design front panels and mill them in my machine. Previously, the CNC's software could only handle PCBs and some simple engraving. 

After I got familiar with the new software and tried out a bunch of features, I decided to rig some tooling for the CNC to help in aligning my work pieces so that both top and bottom layers align correctly when you need to flip the work piece over. One big issue with people that do homebrew PCBs using etching is that it's very difficult to align top and bottom layers. With the CNC, I could precisely drill registration holes that I could use to align the PCBs and they would be accurate to within a couple hundred microns. 

So anyways, that's pretty much why I've been quiet recently. Although it's great to learn how to use the CNC efficiently, it's just not interesting enough to blog about. Or at least I don't think that people that follow this blog would be interested in me comparing annular ring sizes with respect to different drill bits. 

Well, that's about it. I left out all the boring details and thought I'd just post a couple pics of the finished radio board. It seems like every PCB I'm posting lately has no solder mask. With RF components being 0402 are smaller, soldering them down is a real bitch. The worst was the balun which is basically an array of 0201 components. While I was squinting and trying to attach it to the board, I kept on thinking how I'd be better off trying to solder individual specks of coffee grounds to the damn thing...

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: