This is a picture of the box top for my new toy. Thanks to a comment from a friend on one of my past posts, I've been looking for a reason to justify buying one. Exactly as his comment suggests, I've grown tired of having to leave my beast of a desktop running to serve as a home server and to host the radio I use to interface with my remote sensor network.

I love this little thing! It's small, quiet, and uses practically no power. I got the fit-PC2 Value model, which comes with everything I need: 1.1 GHz CPU, 1 GB RAM, Ethernet, DVI display port, 6 USB ports, and an empty internal bay for a 2.5" SATA HDD. I already had a 100 GB 7500 RPM drive I could use (left over from a past upgrade on the wife's mac).

Here you can see the fit-PC sitting next to our Time Capsule for a good size reference. I used the Time Capsule as the router for the fit-PC's ethernet. The little thing in the middle is the XBee radio I use to communicate with my garage door opener.

It sits there next to the router drawing very little power, making no noise, and hardly even warms up. I would even go as far as saying it looks pretty cool too - it lives in our living room on a small table next to the TV.

Communicating with the XBee

The OS I decided to put on it is Ubuntu. This means the .NET console application and the ASP.NET application I used on my development box wasn't going to cut it (without getting Mono involved of course). Instead I went with the classic LAMP stack (the 'P' being PHP in this case).

For the time being, I'm not listening with the radio which means I'm no longer getting temperature readings. Instead I'm just using it to open and close my garage door. I did this because I'm hoping to move from using XBee/ZigBee to 6LoWPAN in the future (more on that another time). For that reason I didn't see the need to much time into this. I just wanted to be able to continue operating my garage door opener with my phone!

For anyone interested, this is the PHP code I'm using to open the serial port and send the XBee messages to the remote XBee controlling the garage door opener. The php_serial.class.php that I'm including was pulled from here.

<?php

  if ( isset( $_POST["btnSubmit"] ) ) {
    ini_set( "display_errors","On" );

    include "php_serial.class.php";
    $serial = new phpSerial;
    $serial->deviceSet("/dev/ttyUSB0");
    $serial->confBaudRate(9600);
    $serial->confParity("none");
    $serial->confCharacterLength(8);
    $serial->confStopBits(1);
    $serial->confFlowControl("none");
    $serial->deviceOpen();

    $serial->sendMessage("\x7E"); // Frame start
    $serial->sendMessage("\x00\x10"); // Frame length
    $serial->sendMessage("\x17\x00"); // Frame type (AT command)
    $serial->sendMessage("\x00\x13\xA2\x00\x40\x86\x97\xCB"); // Destination address
    $serial->sendMessage("\xFF\xFE"); // 16 bit dest addr (unknown)
    $serial->sendMessage("\x02"); // apply AT command immediately
    $serial->sendMessage("\x44\x31"); // "D1"
    $serial->sendMessage("\x05"); // HIGH
    $serial->sendMessage("\x92"); // checksum

    sleep(1);

    $serial->sendMessage("\x7E"); // Frame start
    $serial->sendMessage("\x00\x10"); // Frame length
    $serial->sendMessage("\x17\x00"); // Frame type (AT command)
    $serial->sendMessage("\x00\x13\xA2\x00\x40\x86\x97\xCB"); // Destination address
    $serial->sendMessage("\xFF\xFE"); // 16 bit dest addr (unknown)
    $serial->sendMessage("\x02"); // apply AT command immediately
    $serial->sendMessage("\x44\x31"); // "D1"
    $serial->sendMessage("\x00"); // OFF
    $serial->sendMessage("\x97"); // checksum

    $serial->deviceClose();
  }

?>

Enjoy!

I've always turned off the auto-appearance of intellisense in Visual Studio. I feel that it's faster to just finish typing the word than it is to pause slightly and pick the right one from the intellisense dropdown that appears. Whenever I'm typing something really long or when I'm not entirely sure what the method or class name is, then I just hit Ctrl+Space to make the intellisense appear on-demand.

Visual Studio 2010 + Resharper 5.1

In ReSharper's options:

And in Visual Studio's options:

That should do the trick. Enjoy!

A friend shared a link to his post about an extremely cool video of Bret Victor's talk at CUSEC 2012 titled Inventing on Principle.

After watching the very inspiring video, I started snooping around Bret's site. Talk about a treasure trove of goodies! When I stumbled across the below, I had to share (as well as put it in a place I would always remember). I thought it was the coolest way to decode resistors I've seen to date.

Enjoy!

I mentioned in my last post that I have three xbee radios that need to be used (played with!) and that we only have one garage door opener between the two of us - I am not the keeper of said opener. Here I present version one of our new networked garage door opener!

The Old Garage Door Switch

The black box you see with the duck tape is a keyless entry system that was here when we bought the house. I'm the only one who used it (being the one without a remote) so I decided to unplug it and steal the wires that run from the garage door opener. The wires are already run and it's conveniently near a wall outlet so it seemed the right thing to do.

In case you don't know (I didn't at first), the wires that run from your garage door opener (the real one attached to the door) to your standard wall switch works by merely closing the circuit between the two wires temporarily. So your wall switch is just a mechanical switch with two electrical contacts that, when the button is pushed, close the circuit. Releasing the button re-opens the circuit, or breaks the connection between the two wires.

With the knowledge of just how simple it is to activate a garage door opener, all I needed was a way to electronically close the circuit between the two wires. That is exactly what a relay is for.

The XBee Garage Door Switch

What this is, is the remote temperature sensor I had already created plus one additional component (and a few wires).

So the stuff at the bottom of the breadboard is still the power management componentry. It takes the 9 volts coming in from the power supply and regulates it down to exactly 3.3 volts for the xbee. Plus a couple of capacitors to smooth out the current.

Above that is the temperature sensor (tiny black thing) and a few resistors used to get the sensor's reading down to a level the xbee can read. And then there's the xbee itself with the temperature sensor still connected to AD0 (pin 20).

The new piece is the light blue component at the very top. That is a Compact 5VDC/1A SPST Reed Relay. I just connected the two wires from the garage door opener to each side of the relay and then ran a wire from AD1 (pin 19) on the xbee through the relay to ground. To trigger the relay, I just have to turn on AD1. So recalling what I said about the garage door switch, I just turn on the pin, closing the circuit with the relay, and then turn it right back off to re-open the circuit. Just like pushing a button switch :)

Tying Everything Together

I left the temperature sensor on the circuit and I left the xbee configured exactly as-is. This means the console app that I used before still works like a champ. I connected the coordinator xbee to my PC, plugged in the above breadboard, ran the application, and I immediately started getting temperature readings from my garage. All I needed then was to be able to send a command to the remote xbee telling it turn on AD1 and then again to turn it back off.

Digi made this really easy with the xbee API. All I need to do is send it a remote AT command configuring AD1. Specifically, I send a Remote AT Command Request to the address of the remote xbee passing the AT command D1 (configure analog/digital pin 1) with the parameter of 5 to turn on high digital output (3.3 volts). I sleep for half a second and then send the same command again with a parameter of 0 turning the pin back off.

Of course, I needed a way to tell my console application to send those commands. For now I just listen for incoming connections on a named pipe. I created a single ASPX page sitting on my local IIS that, on button click, would open a connection to that named pipe and send it the message "Garage Door". The console app triggers the garage door every time it gets this message.  Sweet!

To get to that from my phone, I opened up HTTP traffic in my firewall to private network traffic and gave my PC a static IP address. So as soon as my phone connects to my wireless router, I can open and close the door with my phone. In fact, anyone who knows the password to my router and knows the IP address of my PC can now open and close the door. Unlimited remotes!!

Awesome, But Not Finished Yet

So now everyone who has access to my router can open and close the garage door. That's cool and all, but I'm not done yet. There are several things I don't like about the situation...

First, I want to be able to tell whether or not the door is currently open. No brainer! Not cool if the opening and closing is automated, but I still have to leave my lazy boy to see whether or not I need to close it at the end of the day.

Next, having a breadboard and exposed components dangling on the wall of my garage isn't cool. It's also not good for the circuit being exposed to dust and whatnot. Mostly it isn't cool though.

More importantly are the implementation details. Currently everything is had coded in a very brittle way. First I assume that any message received at the coordinator is going to be a temperature reading on AD0. Second is the garage door opener. Its address is hard coded to that exact xbee module. The pin is hard coded to AD1. And finally, I'm using named pipes to communicate with a console application from a .net application.

Oh, and I'm not logging the temperature readings, so no cool graphs. Not that there would be many readings coming in yet. Still have to solve the cost problem of creating dozens or remote sensors.

I'm definitely excited about what I have so far. And excited about the fact that I can open and close the door from my truck of course. But I have a lot of work (can I even call it that?) ahead of me.

In my last post I left off with saying that I planned to continue in the book with the second piece of the Simple Sensor Network project - switching the remote sensors to end devices and using batteries instead of the 9v plugs. I also thought I'd create my own PCB instead of using the breadboards. Didn't happen...

I really dig the idea of having one of these temperature sensors in literally every room in the house. Maybe one out front and one out back as well. I can picture having rich graphs showing me the temperature rise and fall from all around my house. Ideally all of the internal sensors would rise and fall in sync as the central air kicks on and off. If one of the rooms fell lower in the winter or rose higher in the summer in between heating/cooling cycles, that would tell me that particular room isn't insulated as well as the rest. Or it would tell me someone left a window cracked, or a varmint decided to make their own entry. All good information to have and at the very least I'd have those cool graphs to show off to oldsters who visit :)

The problem with the XBee-based sensor though, is the cost. The radio itself is roughly $20 and then there are the rest of the components. So we're talking close to 30 bucks per sensor. Not cool if I want to buy more than a dozen (every room - not just bedrooms, outside, attic, etc.). If I plan to implement this idea of a zigbee network of temperature sensors, I need to find a much cheaper solution for end devices.

So I'm done with the book Building Wireless Sensor Networks. Even though I don't think I'll continue using xbee radios everywhere, I am so glad I got the book. It has introduced me to all sorts of fun and coolness that I've never played with before. And I can see using those radios in spots (like the controller or more extravagant devices that use more of the module's functionality), so I'm sure it will be a great reference in the future. It's an excellent addition to my library.

What's Next

I am left with the three xbee radios I've already purchased. I was thinking about what I might do with them as I was leaving to take the kids to school the other morning. As I pulled out of the garage and lamented once again that I still haven't gotten a second remote for the door (the wife has our one remote in her car of course), the idea of creating my own formed. I've read of others doing it with arduinos and netduinos so there's plenty out there on the subject. My next post will show how I accomplished it with a couple of my left over xbee radios. Good times!

This is the project I mentioned in Configuring My First XBee Radios where I'm going to setup the sensor network from chapter 5 in Building Wireless Sensor Networks. I'm going to end up with two remote temperature sensors that are mesh-networked together to stream their data to a base station radio connected to my PC.

Preparing the radios

Coordinator

This is a simple matter of connecting to the xbee with X-CTU and switching its mode from AT to API (along with ATAP = 2). I also went ahead and zeroed out ATDH and ATDL since the coordinator will be receiving data only.

Routers

These stay in AT mode, but need the following settings:

• ATID - set to the same PAN ID as the coordinator
• ATDH - 0 (forces the radio to use 16-bit addressing)
• ATDL - 0 (destination is the coordinator for both routers)
• ATJV - 1 (rejoin network on restart)
• ATD0 - 2 (puts pin 0 in analog mode)
• ATIR - 3E8 (sample rate of 1,000 milliseconds - polls for the temperature once a second)

Something that might be worth noting here. When I first unplugged the coordinator and plugged in the first router, my computer's USB completely stopped working. Yep, I lost both my mouse and keyboard and no amount of unplugging and plugging them in helped. I tried every USB port on my computer. I eventually had to do a hard restart (and luckily only lost a little progress on this post - I save often). I did notice I had left X-CTU running when I did the switch. This time I closed X-CTU in between configuring the two routers and everything worked fine. Don't know for sure if that was the problem since I don't care to reproduce it, but wanted to put it out there just in case you run into the same thing.

Preparing the sensor boards

This was an experience for me. It seems like I have a vague memory of having soldered before, but we might as well say I've never done it. I'm proud to say I finished with only one burn (right index finger). The solder jobs themselves look horrible.

Working with all the parts was interesting as well (transistors, resistors, etc.). Very neat and I'd say rather satisfying when the end product is a physical thing instead of software. Good times!

This is a picture of the first one I put together (the second looks identical). The little black thing poking up right below (in the picture) the XBee is the actual temperature sensor. The mess of stuff near the bottom is the voltage regulator (from 9-volt to 3.3-volt) and the capacitors (to get rid of noise in the power supply). Prototyping on those breadboards is super easy.

Capturing the sensor data

The book actually supplies a program ready to use that will allow you to visually see on your computer all the data being sent from your remote sensors. It's a Processing program that uses some Java libraries to communicate with the XBee radio over the COM port. I could have used that I suppose...

Being the developer that I am though, I wrote my own in .net. I put the code out on github in a project called XBee (real stretch for a project name, I know). You can see the library I wrote along with the project specific to this example at https://github.com/rtennys/XBee. The format of the messages sent from the XBee radios in API mode are very easy to work with. It was a fun little exercise for sure.

What's Next

I think I'm going to do two things next. I'm going to kind of stick with the book moving on to creating temperature sensors that are configured as end devices instead of routers. This allows them to be much more conservative on the energy they consume thus allowing me to use a battery power supply instead of having to plug them in. In addition to what the book shows though, I'm going to create my own PCB instead of using the breadboard.

These are my first three XBee radios. Two of them are already connected to SparkFun XBee Explorers and the one in the middle is tagged with a note to remind me which one is configured as the coordinator (I did the connecting and tagging of course - they don't come like that).

If you don't know already, a ZigBee network consists of exactly one coordinator and any number of routers and end devices. Get the book or read about it on Wikipedia if you want the full story - my aim isn't to reveal everything the book has to offer, but rather document my personal journey into embedded devices.

Firmware

The first step according to the book is to use a program called X-CTU (free from Digi) to ensure the firmware is up to date. So one at a time, I used the xbee explorer to connect the radios to my computer via USB. All three were already configured with the latest firmware so that was easy.

Time to configure and do the first test

The next step is to choose a terminal program that I can use to connect to the radios and issue AT commands to configure them. Since Windows no longer ships with a terminal program, I chose to just use the terminal tab in X-CTU. The author suggested picking a stand alone terminal program for various good reasons, but I just wanted to get to the good stuff.

The idea for the initial configuration and test is to set up two of the radios such that they can talk to each other wirelessly. This means putting both radios on the same network, or setting the PAN address (PAN = Personal Area Network), and then setting each radio's destination address as the other radio. The PAN is a number between 0 and 0xFFFF that you arbitrarily pick. A radio's address however is globally unique and printed directly on the xbee (or you can type ATSH/ATSL to get the high and low parts of the address from within the terminal program).

In the image you can see my configuration for the coordinator. I had already configured the router (using the information from ATSH and ATSL in the screenshot). The "+++" is how you enter into command mode where you can issue AT commands. Outside of that everything you type is sent directly to the radio and transmitted wirelessly. Notice how I had to type ATDL twice? That's because I took too long between issuing the ATDH command and issuing the first ATDL command. Basically the radio times out after 10 seconds and returns to transparent mode where it transmits everything typed instead of looking for commands. I knew it had timed out on me when it didn't return the red "OK". So I typed "+++" again and then reissued the ATDL command followed by the ATWR command to save the configuration permanently.

After that I waited until it timed out and then typed that last line. And sure enough, when I turned around and looked at my laptop (where the router was plugged in), there was the sentence that I had typed on my PC. Super basic and easy but still very cool!

What's Next

Like I said in my first post, I've already devoured the book. Instead of following along in order, I'm going to skip the doorbell and romantic lighting projects and jump to something I find more interesting: Simple Sensor Network (remote temperature sensors). I currently have three radios, so I'll have one connected to my PC as the coordinator and will put the other two at various points around the house. Exciting stuff!

I decided to dip my toes in an area where I have no experience: embedded systems development. Basically, I want to create real, physical things that I can point to, hold, hand to a family member, and maybe even sell.

I can't remember exactly why I picked Building Wireless Sensor Networks to get me started on this adventure. I believe I was reading a review of some other book where the individual said something about not particularly getting much out of the book and suggested this one because we'll get the same content plus so much more (working with the radios). I assumed I would get something .NET related so I could stay within my comfort zone, but at some point I pushed Buy and the deed was done.

I'm glad I did, because it has opened up excitement that I haven't felt in a long time. When the book first arrived I devoured it. As soon as I knew the parts I needed, I ordered a slew of components and tools and have since spent hours and hours reading about everything from home automation to hobbyist robotics nuts. All very cool and I couldn't wait to get started.

The Plan

I thought I'd try to document this journey. As anyone who blogs knows, having to write down your thoughts forces clarity like nothing else. Also, I hinted above about creating something I can sell as a product. I want to capture what I learn about that process because the little I've looked into it so far hasn't been very helpful. In fact, I have no freaking idea how I'm going to go from playground to my first sale. Maybe what I figure out will help someone else.

The Book

Building Wireless Sensor Networks is about just that - building networks of "sensors", or devices with sensors connected to them, that communicate with each other wirelessly. The networking part of the equation uses the ZigBee protocol, and the wireless components the author focuses on are XBee radios. The examples that require a microcontroller use the Arduino. In addition to the specific "how to" sections, I personally think the author did an excellent job of explaining just enough theory and the "why" of things to satisfy my curiosity without putting me to sleep with too much information. Even where I needed more, he explained it well enough for me to google intelligently and get all the detail I could possibly want.

What's Next

I'm going to use this post as a table of contents for this journey so I'll keep it updated with links to each related post. The very next step is to configure my first XBee radios (they're in!). Stay tuned...

1. Configuring My First XBee Radios
2. ZigBee Simple Sensor Network
3. ZigBee Simple Sensor Network Part 2 - Never Mind (end of series)

As I was getting into my next consulting gig, I found myself copying yet again all of those utility extension methods and classes I tend to pull along with me into every project I work on. Enough is enough, I thought! That and it was a great excuse to finally play with NuGet.

You see, I've been avoiding creating a personal library all this time because I didn't like the idea of having an odd dependency that I included in projects. It would have a foreign or personal sounding namespace, versioning and updating it would be a pain, and developers that came along behind me on the project would have this weird black box of random code. I wouldn't want to run into something like that on a project I joined.

Then I figured out that I could create a NuGet package that was content only. Not sure why I hadn't already put that together, but my original thought was that I would have to create a package that delivered a binary which would be referenced by the target project. Easy versioning and updating taken care of, but I'd still be left with the black box of random code. With a content only package, the actual source code from my "personal code library" actually ends up in and lives in the target project.

The final kicker was my noticing source code transformations. By using the $rootnamespace$ token, the NuGet package installer would transform the namespace declarations into whatever the target project was using. No weird or personal namespaces! Pretty much takes care of every problem I had with creating my library.

The Source

The source for my project lives on github in rtennys/Common. I know, real original name.

I set up a basic class library project and unit testing project. Not that I've done a lot of testing mind you, most of the code in the library has been in my possession for a very long time, but I plan to add tests as I modify and grow the core library.

The interesting part to me was automating the deployment into NuGet. Next to the solution file, you'll see my standard deploy.bat and deploy.proj files (if you've worked with me, you probably recognize these!). In here is where I use MSBuild to grab the current build version, copy all the source to a temp folder, replace my namespace with the $rootnamespace$ token, create the NuGet package, and finally upload the package to nuget.org. Very easy and very cool.

With the addition of a hotkey in Visual Studio (see here for details - I do it similar: no context menu, just a hotkey), updating my personal code in a target project is as simple as updating my library, running deploy, and then updating the package at the target. Crazy easy!

The NuGet Package

The package is called RobTennyson.Common. Installing it is as simple as running this in the Package Manager Console:

PM> Install-Package RobTennyson.Common

I don't know that I'd suggest using it since it's my junk pile and filled with my opinion on how things should be done. It's also likely to change a lot and often. But you're welcome to it if you'd like. You're also welcome to snoop around in it and tell me why I'm nuts for doing this or that (like my .Each and .F extension methods!).

Good times!

Like I said here, my first consulting job was a sub-contract with TEKsystems for a company called TD Williamson in Tulsa, OK. Though I’ll still be available if they need anything (questions about the code, bugs, whatever), I completed the last enhancement this week. I feel incredibly lucky that I got this as my first gig after leaving traditional employment behind.

The Customer

First off, I was fortunate with a very cool customer. I could be wrong, but the IT shop I worked with seemed a bit smallish. Whenever I needed something like access or a question answered, the team member who was my point of contact was able to get the answer or get it done insanely fast (sometimes less than an hour!). I needed a good bit of database help in the beginning (back slamming production to development, getting a copy for me to run local and thus disconnected, etc.) and several times I needed new access to other database servers I was asked to integrate with. Their DBAs were awesome! No bottlenecks or bureaucracy or anything to slow down progress as far as I could tell. If it wasn’t a small shop, it was an amazingly well oiled large one.

The Code

This was the surprising part. It's a classic Web Forms application. It uses straight ADO.NET for data access. There wasn’t a single using statement anywhere. If I remember correctly, I found 38 connections that weren’t being closed. Everything is done directly in the code behind. Found a few memory leaks in the Active Directory code. Same redundant email logic repeated all over the place. Magic strings everywhere... Getting the idea yet?

Despite all those negatives, I loved it! It has been a long time since I've been able to belly up to an editor and just engross myself in code for hours and hours. The days flew by like they used to. All of the problems I mentioned above are crazy easy to fix; mind numbingly easy. It's almost like being paid to meditate.

In addition to these simple ways of drastically improving their codebase, I think they were pleased with how fast I was able to get enhancements done. I also fully automated the deployment and added versioning in a way that made it easier to know what is currently in production. All in all, I'd call it a successful gig for both parties and a great start for me.