Kevin Hoyt

Wireless Light Sensor (Part 3 of 3)

Wireless can mean many things. There’s the common 802.11 b/g protocol used in wireless internet devices. There’s Bluetooth wireless such as that used in game controllers. There’s also consumer infrared wireless commonly found in television remote controls. For the purposes of making our Arduino light sensor wireless, I’ve chosen ZigBee 802.15 which is designed with low data rate and long battery life applications. Chips implementing ZigBee, usually referred to as XBee, are also available as shields designed to attach to your Arduino.

I should be clear here that if you wanted to use another wireless solution, that they do exist. I found XBee before I knew about the WiShield. I’ll cover the WiShield in the future. One downside is the managing of the TCP/IP and HTTP stacks, with the obvious upside of simply having to be in range of an 802.11 wireless network. Configuration needs to take place on both systems.

XBee

You can purchase XBee shields from many online electronics stores for about $25 USD. You’ll need one of these for your Arduino, and then two XBee chips – one to sit on the shield and another to connect to your computer. XBee chips run a range of costs depending on the distance you want to cover. I am using two 2mW Series 2.5 chips with a range of about 400 feet, costing me about $25 USD each. On the computer side you’ll need a place to attach the second XBee chip. For this I used an XBee Explorer board from SparkFun for $25 USD, but it could also be another Arduino. Total cost for the wireless gear then is about $100 USD.

By comparison, the AsyncLabs WiShield is about $55 USD.

I had to really search to figure out how to configure the XBee chips. The information is very scattered. I eventually came upon this resource which I have archived here just in case. The PDF document will take you through configuring your XBee chips, and is very clear. Word of warning that you will need a Windows installation to run the configuration software. I use VMWare on my Mac to run the Windows installation. I’ve seen a Mac port in very early stages and far from friendly, so for now I suggest using the software mentioned in the guide.

Circuit

There’s one major drawback to the XBee Shield, and that is that it blocks the power pins and doesn’t surface them except through soldering. I’ve found that there’s just enough room in the gap between the Arduino and the shield, to run the wires needed. I used raw wires for this configuration versus the jumper wires shown in the picture on the previous installments of this series. Below is the circuit before the shield is attached, and after the shield is attached.

Since your project will now be wireless, you’ll want to switch out to a standalone power supply. I bought my Arduino as a kit from Adafruit, and it came with a 9V power pack with pre-configured adapter. This makes for a good portable solution, though if you plan on exposing the system to the elements, you may want to design a case (tupperware to the rescue) to protect your investment. With everything wired into place, and the power supply connected, turn on the power pack and let the “remote” solution sit somewhere else (within 400 feet).

Serial to Socket

You may be asking about the sketch on the Arduino. Don’t we have to add some crazy Processing code or library to get this thing to work? Nope, I’m afraid not – and that’s part of the beauty of this system. The XBee ships literally act as an invisible wire. Your program prints serial data, and the XBee takes care of getting across the air to the other chip. How about that other chip?

If you’ve connected the XBee chip to the explorer board, and the explorer board into the USB port on your computer, you are already half way there. The next step is to figure out how that chip presents itself to the computer. For this, believe it or not, I actually open the Arduino IDE and look at that ports menu. Head to Tools -> Serial Port and select one of the options. My board shows up as “/dev/cu.usbserial-A6007to5”. With that selected, just launch the serial monitor from the Arduino IDE and watch your data arrive.

From here we need to configure TinkerProxy to use that USB port label. Open the TinkerProxy configuration file and change the “serial_device1” entry to point not at the Arduino, but at the explorer board. A note here is that you might just want to duplicate the entry line, and comment out the Arduino version so you can easily swap out for future experiments. My configuration file actually has the labels in place, but commented, for most of the various devices I attached (from weather, to XBee, to Arduino, and more).

newlines_to_nils=false

comm_ports=1
comm_databits=8
comm_stopbits=1
comm_parity=none

timeout=300

net_port1=5331

# SparkFun Weather
# comm_baud=9600
# serial_device1=/dev/cu.usbserial-A6007w6X

# XBee
comm_baud=9600
serial_device1=/dev/cu.usbserial-A6007to5

# SparkFun GPS
# comm_baud=4800
# serial_device1=/dev/cu.usbserial-A7005GJU

# Arduino
# comm_baud=9600
# serial_device1=/dev/cu.usbserial-A9005aT8

What about the Flash application? Yeah, sorry, again, no changes needed. The Flash application already knows how to connect to TinkerProxy. The data coming in is the same, in the same format, so the Flash application itself doesn’t change at all. The difference being that the Arduino and sensor itself may now be quite some distance from the computer. Run the Flash application, and you’re on your way.

Of course once the data is in your Flash application, you don’t have to chart it. One of my first experiments simply showed the raw value in the application. From there however it called a ColdFusion script on a web server to store the values in a MySQL database. I had another ColdFusion page that I could then pull up from my web browser and see a generated chart of the last 24-hours of data (though the database held all the data). The fun thing about putting the data on a web server was that it was then easily shared and accessed from anywhere.

Conclusion

Admittedly, this last installment, while being the most impressive technically, doesn’t have much meat – and again, that’s really the beauty of the Arduino/XBee shield combination. The bulk of your time will be in configuring the XBee chips, and the document reference above will serve you well on that front.

From here we can take a number of different directions. Maybe we want to log the data on the Arduino and not broadcast it. Maybe we want more direct internet connectivity. Maybe we want to take the data and tell the Arduino to power something else, such as driving a servo. If there’s anything you’d like to see, please leave me a comment and I’ll put it in the queue for a write-up.