My first google searches ended in disappointment – using the built in Terminal program with Screen was unsuccessful (probably because it doesn’t seem like you can set the baudrate). Update: it turns out that you can set the baudrate with screen using an argument like so – “screen /dev/ttyWHATEVER 115200″. Thanks goes to the David in the comments below. After a little searching, it looked like the few serial terminal applications for Mac were old and outdated, but I did manage to find ZTerm. It’s simple and basic – perfect for use with the bus pirate.

Don’t forget that you need to have already installed the FTDI driver so that your computer will see the device over USB. Start Zterm and choose the correct port in the popup window (if it isn’t already chosen automatically). Then you need to change the connection settings to talk to the Bus Pirate properly. Go to Settings->Connection and set it like this:

Data Rate: 115200
Data Bits: 8
Parity: None
Stop bits: 1

The rest you can leave at the default. [UPDATE] On newer firmware versions you’ll need to deselect Xon/Xoff as per Ian in the comments below.

Hit ok and go back to the terminal window to start talking

Hit enter to start communicating. Entering ? will bring up the list of commands like so:

To test some functionality of the bus pirate, we’re going to measure the voltage on the ADC pin. We’ll do this by putting the Bus Pirate into just about any mode besides HiZ – we’ll choose 1-Wire since it’s simple to set up.

Enter “m” to bring up the mode menu, choose 1-Wire by entering “2″. Hook up some voltage to the ADC pin (see the bottom of the Bus Pirate for it’s pinout). Then enter “d” to read the value on the pin. I connected the pin to the 5V input from the USB line, so it reads 5.1V. You can see that full process in the terminal below.

That’s it for the basics! See the Bus Pirate site for more examples of how to use this nice piece of hardware.

Serial control of the lights in Python took longer than expected – we could have saved over an hour of troubleshooting had we simply waited two seconds between opening the serial connection and transmitting the first byte (allowing the connection protocols time to complete), but instead we tried half a dozen Python libraries, thinking the problem was somewhere in the code library. Lesson learned – the exact specifics of interaction between software and hardware is not to be ignored.

We then were able to force the Woot Tracker to update it’s cache, pull down the XML file generated by the tracker, parse it for the value we are looking for (wootoff, true or false), and take action based upon it.

Now we’re simply trying to figure out how to package the program into an .exe that can be hidden in the tray, and also figure out how the timing should work – I would prefer that my server didn’t get a ton of update requests at the same time, especially during a Woot-Off. Right now it looks like we’ll run a custom version of the software on our machine to update the tracker, and the software we distribute publicly will simply pull down the XML (without first updating the cache, because our software has already done so).

On the hardware side of things, I’ve consolidated the driver circuitry onto a small piece of protoboard that pops into the Arduino like a shield. I’ve also cut up an Altoids tin and housed the assembly inside of it. Don’t forget the isolate the top/bottom of the board with electrical tape or similar so the metal case doesn’t short anything.

Here’s a few pictures of the assembly, with the lights being controlled via the Python application.

On the other end of the pipe, the Arduino is listening to the serial communication. The sketch I have set up simply sets pin 9 to HIGH when it receives a 1, and LOW when it receives a 0. That’s it. Then the hardware is controlled as discussed in the previous post.

Prototype console application for Arduino Serial communication

So at this point we have:
a) Hardware control of lights
b) Windows console application for serial communication on/off

Which leaves:
c) Having the application read the tracker for wootoff status
d) Packaging it together in a nice, pretty package

So for those following along with an Arduino, I’m posting the Arduino sketch and the console application below. If you want to use a pin other than pin 9 on the arduino, just modify that part at the top of the sketch. Obviously, you should upload the sketch to the Arduino first, exit the Arduino software (since only one application can access the port at a time), identify which port your Arduino is on, and then run the console application. I AM NOT RESPONSIBLE FOR ANY HORRIBLE THINGS THAT RESULT FROM THE USE OF THIS SOFTWARE, largely because I started college as a CS major and switched to EE a year later because I hate coding. That said, it works fine on my and my roommate’s machines.

Arduino Sketch
Windows Console Application

Occasionally, Woot has extravaganzas where they post item after item in what is known as a woot-off. Little .gif lights spin round and round to alert visitors to this spectacle. Playing on this, Woot occasionally sells physical woot-off lights. They run off of USB power, with a switch in each light/motor piece. Since it’s a standard 5V connection, this opens the doors for all sorts of hackery.

The ultimate goal of this project is to have these lights come on whenever there is a woot-off.

If you aren’t already familiar with the Arduino, become familiar now. I’ll wait.

Ok, so the Arduino is a microcontroller system with a USB-serial input communication, a microprocessor with a bootloader to run “sketches”, and the ability to control over a dozen digital logic pins (including a few with PWM or Analog-In).

The setup will use a PC application for monitoring a “Woot Tracker” (many of these are available online to reduce load on Woot’s own servers). The application will check for the presence of the woot-off lights logo, indicating a woot-off – in the future, the lights will be activated by each changing of an item. The application will then send a byte over serial to indicate the woot-off status to the Arduino. Based on the input from the computer, the Arduino will turn the lights on or off.

Great – so in order to turn on the lights all we have to do is turn on one of the Arduino’s pins (they are 5V at digital high). Unfortunately each pin is only capable of supplying at most 50mA, and these lights run on over 100mA. Luckily, the 5V power regulator on the Arduino is capable of supplying much more current – up to 500mA or so if a good DC power supply is used. So if we hook up the positive lead of these unit to the 5V, we now need to control the ground connection to control the circuit – connect the ground and the lights go on because the circuit completes.

The ULN2803 chip provides this exact function. The chip is connected to 5V and ground. The ground from the device to be controlled is connected to a pin (remember that the positive of the device is already connected to 5V), and the control signal from the Arduino is connected to the corresponding control pin. When the control pin sees 5V (from the Arduino control signal), the ground lead from the device is connected to the ground of the chip, completing the circuit and sending current to the device. In this case, the lights spin up.

Early Woot-Off Light Software/Arduino Control

So far I have the hardware running, and have used the Arduino PC software to send input down the serial connection, turning the lights on and off. The next step will be to write an application to send serial information, and then to expand that application to search the textfile of the woot tracker for the lights.gif. The final stage will be to integrate all the hardware into a small package so the device can be used permanently.