Normal relays are pretty simple – supply voltage/current to the coil and it generates a magnetic field, which pushes the switch to the ON position. You only need one pin to run it, although you may need a transistor to supply more current because most microcontrollers can only supply 50mA, which often isn’t enough current to create a magnetic field to move the switch. You must maintain the current to keep the switch on.

Latching relays are similar to this, but once put into position, it “latches” there and requires no further current to stay in that position. This uses less power and makes the switching more reliable – if there is a decrease in current supplied, the switch will still stay in position, unlike the regular relay which could flicker. The downside is that the common types require two pins. Sending current in one direction switches on, and reversing the current switches it off.

So how do you control it? Set two pins to be outputs (the USB Power Shield uses 12/11 and 10/9 for the two relays). Write one pin LOW and the other pin HIGH. After a sufficient time to make the switching happen (50ms or less, check the datasheet for the relay), switch the HIGH pin back to low. This gives the magnetic field a place to sink, as well as making sure no more current is supplied to the coil, preventing overheating and wasting power.

Ideally, with a normal relay you’d like to force the stored current from the magnetic field back through the coil by using a flyback diode across it, but with a latched relay and current running in both directions, a diode would be needed in each direction. And that would simply cause a short circuit both ways. I’ve tested the relays used in the USB Power Shield and they don’t harm the Arduino (even over thousands of cycles) so this isn’t a huge worry here.

Below is some sample code for using the USB Power Shield with an Arduino.

Simply set up the pins for relay1 and relay2:
//give the pins names
int relay11 = 12;
int relay12 = 11;
int relay21 = 10;
int relay22 = 9;
void setup()
{
//set the pins to outputs
pinMode(relay11, OUTPUT);
pinMode(relay12, OUTPUT);
pinMode(relay21, OUTPUT);
pinMode(relay22, OUTPUT);
//make sure they start in the off position
relay1(false);
relay2(false);
// do other stuff
}

Then add these functions to turn the relays on and off:
void relay1 (bool state)
{
if (state)
{
digitalWrite(relay12,LOW); //set the current in one direction
digitalWrite(relay11,HIGH);
delay(50); //hold long enough to switch
digitalWrite(relay11,LOW); //set both to ground to stop current
}
else
{
digitalWrite(relay11,LOW);
digitalWrite(relay12,HIGH);
delay(50);
digitalWrite(relay12,LOW);
}
}
void relay2 (bool state)
{
if (state)
{
digitalWrite(relay22,LOW);
digitalWrite(relay21,HIGH);
delay(50);
digitalWrite(relay21,LOW);
}
else
{
digitalWrite(relay21,LOW);
digitalWrite(relay22,HIGH);
delay(50);
digitalWrite(relay22,LOW);
}
}

Then simply write your main loop to do whatever you wish. Call relay1(true) to turn relay1 on, call relay2(false) to turn relay2 off, etc.

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.