So far, it’s been a pretty interesting and eventful year but extremely busy, so I decided to take a short summer break. I wanted to take some time off to do stuff I’ve been interested in but been putting off because of all the tasks I’m dealing with every day. One of the things I’ve been thinking about is the Arduino platform. I bought my first Arduino a couple of weeks ago but never had a chance to play with it so this was the perfect chance to get my hands dirty with it.

My first run at the Arduino was quite an enjoyable experience. I can see how it’s become such a useful platform for hobbyists and enthusiasts because it’s a very quick and easy way to prototype designs without having to build or port your own libraries.

The main reason I’ve been looking into the Arduino is because I’m trying to find an easier way to teach embedded electronics and programming to people at the hackerspace. Microcontrollers are fine and dandy, but setting up the toolchain, building from the command line, and tweaking a bunch of registers can get fairly intimidating to people that don’t do it on a regular basis.

Hi all.

Sorry about the delay in releasing the ATXMega boards. There's some good news and bad news.

The bad news is that there won't be SPI DMA support. I was validating the SPI DMA feature and found that DMA transfers for an SPI master can't be made directly to an SPI port. They can only be made to a UART configured as an SPI master. This would have required swapping two pins, but still wouldn't have been much of a problem. The real issue is that when I configured a UART as an SPI master and sent data through it, I ran into what looks like a hardware bug that leaves some SPI transfers incomplete. Here's a shot of a 2-byte transfer:

 

Hence, I've made the decision that I won't be supporting the DMA to SPI feature. I apologize since I believe there were some people that were looking forward to that feature. For people looking for DMA'd wireless transactions, I'd recommend the EconoTAG from Redwire. Its based on the Freescale MC13224 and supports DMA to the radio FIFOs. It's also designed and supported by Mariano Alvira who is a frequent contributor to open source and the Contiki project. 

The good news is that the memory to memory DMA feature is working so that people doing a lot of block copying can now offload that from the MCU.

Anyways, that was the last thing standing in my way to release the ATXMega boards. The boards are now in the shop and I've also put together a set that consists of an MCU board, radio, antenna, and standoffs.

Thanks for the patience and sorry about not supporting that feature. Here are the links to the products:

ATXMega MCU Board Link

ATXMega MCU + Radio Set Link

Just a quick note that Chibi v0.85 is released. The main purpose for this release is to add support for the Atmel ATXMega MCU family. There are other minor changes that were also added. The EEPROM driver was moved to the MCU specific directories since the ATXMega has different EEPROM access method than the standard AVR series. The standard AVR chips have EEPROM libraries that are supported by avrlibc which is not the case for the ATXMega. Along with that, there were some minor cosmetic changes to the demo file to simplify things. It started feeling like it was getting cluttered.

To switch between the different MCUs, just open up the Makefile and set the MCU variable to the processor of your choice. To select the radio, do the same for the RADIO variable. 

Here's the change list:

  • Added ATXMega support for 2.4 GHz and 900 MHz radios
  • Fixed compilation issue on Linux where case sensitivity caused problem with makefile
  • Changed usec_delay function in ATXMega radio drivers to be based on stated MCU frequency F_CPU. There may still be some issues since the clock frequency is changeable on the fly, however old drivers assumed 8 MHz clock
  • Added support for command line via UART rather than USB for ATXMega boards since they use FTDI USB serial bridge to UART
  • Moved chb_eeprom.c/h to MCU specific directories since they are MCU specific
  • Removed "dump" command for register dump
  • Removed "pwr" command to set power. This is just demo so default should be okay. API call is still in driver so this can be implemented as needed by the user. Just didnt want to make things too complicated.

You can pick up the source code from the project page.

Link to Chibi Project Page

Hi all.

Wow! Things have been unbelievably busy recently. Along with the part-time consulting, things have been heating up at the Tokyo Hackerspace recently.

I started a group with another member called "Wireless Wednesdays" that meets two Wednesdays a month. In it, we discuss and try out different things going on with wireless. The first meeting, we actually flashed an 802.11 router with DD-WRT and then demonstrated how to boost the transmission power, partition the networks between public and private, go into repeater mode, and do other fun things with the firmware. We also have a two group projects going on in a rural area outside of Tokyo. One of them is to instrument rice paddies with wireless sensors to help out the elderly farmers so they don't have to climb up the hillside terraces every day to check on the crops. The other project is to help take a census on wild monkeys and boars that keep feeding on the farmer's crops. If we can get a good estimation of the animal count, we can help them plant lower quality side crops outside of the main farm area so that the animals won't need to forage from the farmer's main crops. Not sure if that second one will be successful, but it sounds fun and we might be able to save some animal lives as well as help out the farmers. 

I'm also hoping to set up a test bed managed by the group to test out some of the WSN work going on inside the IETF. There's been a lot of exciting things recently with the release of RPL (the 6LoWPAN Routing Protocol) by ROLL and an upcoming CoAP plugfest by CoRE (6LoWPAN application layer protocol).

I also taught my microcontroller class again at the hackerspace and updated a lot of my lessons. I've been meaning to post the lessons for a few months now, but have been so busy with new designs and other work that it kept on falling through the cracks. However I've been giving out the lesson notes to a few people and have gotten good reviews on them so I think they're ready to be published. Those should be going up soon, once I get a little bit of breathing space. 

I've been working hard to get the ATXMega boards out the door. The first batch are fully assembled and tested and I actually finished writing the documentation last weekend. However I realized that just throwing the ATXMega's out into the wild may not be the best thing to do since they're quite different from the AVR ATMega chips. The number of new features are really amazing, and just as amazing is the amount of documentation you have to go through to figure out what you're doing. Because of that, I decided to postpone the release a bit and put together a software package that shows how to do some fundamental things on the new chips.

As an example of why the test code was needed, you can just take a look at the GPIO configuration. In the ATXMega, you can now configure each pin to be internally pulled down, pulled-up, wired-or, wired-and, or as a buskeeper. Each IO can also be configured as an interrupt and the interrupt can have three different priority levels. There's also slew rate control to increase the rise/fall times of the IO. There are now individual set, clear, and toggle registers for the direction and port registers which get rid of the need for read/modify/writes. And you can batch disparate GPIO pins from different ports together into a "virtual port" which can be accessed just like a normal GPIO port. Damn! The flexibility is great, but the options can make your head spin!

Anyways, so I put together a very simple test code package that hopefully can help make kicking the tires on the ATXMega a little bit easier. It's nothing comprehensive, mind you, but it should show how to get the basics going on the chip. You can find a tutorial I wrote on it here:

Link

I also finished a Chibi port to the ATXMega and should be uploading that soon. 

And finally, the boards will be released after I post the Chibi code and check over the documentation. Stay tuned...

*Whew!*

I’ve been spending the past week bringing up the ATXMega boards that I put together and porting Chibi over to them for testing the radio modules. While doing so, it also got me thinking about how I chose the parts and what the landscape for wireless sensor nodes is starting to look like.

The original idea of wireless sensor nodes was that they would be like dust. They’d be inconspicuous, ubiquitous, and you could essentially just sprinkle a couple all over the place to monitor some area that you’d like to keep tabs on. It was expected that wireless sensor nodes would be small, lean on memory resources, and extremely low power. Fast forward about seven years and we see that there are some real deployments going out with wireless sensor networks and the usage scenarios are much different than what was first envisioned.

It feels like wireless sensor nodes are going down two different paths. On the one hand, you still have extremely resource constrained nodes that are being used for specific applications. These would be like environmental monitoring or proprietary applications where the network and use cases are extremely well defined.

On the other hand, large scale deployments like the US smart grid (as well as the conversion over to smart meters in other countries) are showing that widespread adoption will put a limit on the minimum amount of resources required for a wireless node. One of the biggest resource consumers of a large scale deployment of wireless nodes is protocol standardization. 

One of the interesting things I've been seeing is that Macs are starting to become very common in the tech industry. Strangely enough, there is almost a majority of Mac users in Tokyo hackerspace which is heavily dominated by techies. I also see a lot of Macs in other hackerspaces and at events like the Make meeting in Japan. So it seems kind of strange that there is still very little support for embedded development on the Macs. In fact, I'd have to say that a lot of the info on how to set up embedded development environments on that OS is coming from the open source software and hardware communities. This is probably because they're widely used for Arduino development.

So I finally gave in and went out and bought a used Mac at a local second-hand computer equipment store. It was kind of sweet because it had an 2 GHz Intel Core2Duo CPU and quite a nice screen. It set me back about $400 which was really good considering how well Mac notebooks retain their value. The reason for the low price was that it had a US keyboard which is not very desirable in Japan, except for foreigners like me. 

After having used the Mac a bit, I can say that I understand why people like it. Apple obviously paid a lot of attention to usability and aesthetics. The GUI blows away the Windows XP GUI (I haven't tried Vista or Windows 7) and you can drop down to the command line and go straight into Unix. It's like the best of both worlds!

Anyways, enough gushing. The main reason I got the Mac was to figure out how to develop on the boards I'm making using that OS. It's becoming too important to ignore. Along the way, I can hopefully help others figure out how to set up their Mac environments for development on other boards and platforms. My first attempt at using a Mac for development was very basic. I wanted to access the bootloaders on the AVR USB microcontrollers to perform the fundamental operation of downloading code. It actually is very similar to Linux, however you need to do a couple of extra steps to get dfu-programmer to run on that OS. Once the setup is out of the way, downloading code is extremely easy.

And so, with no further ado, here's how to download code on AVR USB microcontrollers using a Mac. It's at the bottom of the original tutorial. Hope it's useful...

Tutorial Link

Hi all.

Just a quick word to let you know that the Chibi stack has been updated to v0.81. This is just a minor update to add support for the TI CC1190 RF front end and coincides with the release of the AT86RF212-CC1190 board . If you've been interested in what it'd be like to match the AT86RF212 with the TI CC1190, you can check it out at the store. The schematics, layout, and BOM can be found inside the datasheet as usual. And in case you're wondering...the range is pretty sick :)

I made one other modification to the Chibi stack which was to move the command table into the main file as well. It used to be in a separate file so when you added commands to the shell, you had to add the functional code in one file, the prototype in the header, and then the command in a separate file. It was a big hassle so now adding a command can be all done within one file. Part of the reason I changed this is that I'm preparing a tutorial on Chibi and when I heard myself trying to explain it, it made me want to cry. Anyways, that mod was mostly just to simplify things. 

Guess that's about it for now. Back to bringing up the other boards and writing tutorials...Hi-ho, Hi-ho...

Since this is the first shop update, it’s going to be a bit long winded, but there are a lot of exciting things in store (get it? yuk yuk…)

I just finished my first month of having the shop open and it feels pretty good. After I was able to open the shop up, I could finally get down to other pressing things like designing new boards and looking for interesting products to stock. There are also tons of other things that needed to be done like writing documentation and putting together tutorials on how to actually use what I’m selling. I think that’s one of the hardest parts about having a shop and one of the areas that can really make or break things.

I really enjoy scouting for new products. It gives me an excuse to buy a bunch of parts and try them out. There are a lot of duds, but the more things you try, the more ideas you get and recently, I seem to be bursting with ideas…well that or I’m going to have an aneurysm soon. I try to keep the theme of wireless sensor networks in mind when I’m scouting for products and you can see that a lot of the new products are somehow related to this, however there are a couple that get through because they’re just too cool to pass up. Here’s the rundown on what’s new:

Well, I finally ran out of excuses to delay opening the store. There’s still a million things that I can do to tweak the store, boards, inventory or whatever but I’m sticking to my guns and enforcing my cutoff point. At least it will stop my wife from nagging me on when the shop will open. She's my toughest critic.

It’s been quite the journey just to reach this point and I’m definitely a better, or at least more knowledgeable, person for it. What started out as a “quick three month project” turned into a nine month odyssey where I learned that having good design skills is only a minor part of putting together a complete micro-manufacturing operation.

But First, Happy Birthday

A lot of things happened on the way as well. FreakLabs had its third birthday at the start of March. I was so busy taking care of tax issues at the time that I didn’t put up a post about it. I just wanted to say that I’m very happy with the site and how its evolving. Its taken on a life of its own and has become a valuable learning resource for me. This is mainly due to the people that frequent it and are kind enough to leave insightful comments and forum posts. The news feed also forces me to stay on top of things and helps me see how the WSN world is evolving.

I was originally going to open up the shop today, but wanted to write a last post before the grand opening. In my previous post, I talked about the mental side of putting together a one-person manufacturing operation. Actually, I’m going to refer to it as “micro-manufacturing” which is a bit buzzword-y but much easier to type than “one-person manufacturing operation”. Anyways, I think there are quite a few people that are curious about what it takes on the technical side to set up shop as well, so I wanted to talk about my experiences with it to date.

As I talked about before, the mental side was one of the biggest obstacles for me. However the technical side of setting up a micro-manufacturing operation is formidable too. As a designer, I thought that it would be easy to put together a couple of designs and sell them over the internet. It sounds like it’d be pretty standard, but there are many, many skills involved. I was surprised at the amount of things I had to learn.

I promised a while back to write an article describing what I’ve been through in starting a micro-manufacturing operation. There are a lot of books available to guide you through becoming independent, starting a website, and also starting a business. However there is a huge aspect to all of it that is neglected or just given lip service. It turns out that striking out on your own is a huge emotional and mental head game.

When I started down the micro-manufacturing path, part of it was to create a wireless tool set that I could use myself, and part of it was to create a business that could sustain myself and my family while I continued to work on open source software. While there was a lot of technical hurdles that had to be overcome, what I was completely unprepared for was the mental aspect of it all.

While I was trying to design products, build the website, figure out manufacturing, create documentation, generate content, understand accounting, source parts, and the millions of other things that it takes to start up a manufacturing operation, I spent a lot of time by myself and in my head. I had to confront a side of myself that I tried to suppress for a long time. It’s a very ugly side of me that is the culmination of all the emotional baggage I’ve accumulated over my lifetime.

When you go down the path of starting any business, there’s one huge thing you have to deal with: uncertainty. How you deal with it depends on a lot of factors. Preparation, experience, and skill level will take you to a certain point but you’ll eventually find that you’ll be facing situations that are completely new to you. This is where the head games start.

Hey everyone.

I know some people are probably wondering if I'm still alive. I've been in isolation-mode trying to get the shop up (yes...still). It's probably been one of the toughest things I've ever done in my life. However I did have some time to work on the Chibi stack and cleared up a few things that were bothering me. One of them was some nasty frame loss when multiple frames come in closely spaced. This would occur if you did something like broadcast a request to multiple nodes and they all returned a response simultaneously. Only one of those frames would get through and the rest would get lost. The current release fixes that so you should be able to receive multiple frames simultaneously with no loss up to the maximum size of the receive buffer which you can configure in the code

I added version numbering rather than just using release dates for reference. Version numbers are much more intuitive. You'll also find support for the ATMega32U4/AT86RF212 combination. I'm actually making a Chibi 900MHz board and needed this for testing. I'm really enjoying working with 900 MHz because the range is better and there is less attenuation through objects. However I'm still a fan of 2.4 GHz just for the variety of available chips, antennas, front ends, and modules to interoperate with. 

You probably won't hear much from me until the shop is up because I really need to get that out of the way so I can continue with all of my other projects. Multi-tasking that with everything else was just not working. So much has gone on in the past few months that I do have quite a bit of material to post and topics to talk about. Hopefully that should all fall in place after things settle down. In the meantime, check out the latest Chibi software:

Chibi Project Page Link

Greetings everyone. I have some good news and bad news. The bad news is the shop is delayed again. Just when I finished my taxes and thought I was clear to go, I got an email from my antenna supplier that my shipment was delayed due to stock issues. Although its possible to open the shop without antennas, I was hoping to be able to have all the components necessary for a WSN node so that people can order things in one shipment. It's kind of petty, but since its my first shop opening, I wanted it to be fairly complete.