It’s been a struggle, but I finally figured out how to use a Roving Networks RN-XV WiFi module as a remote switch.  It’s not hard now that I know how it works, but figuring out was quite difficult, as the manual is apparently incorrect and the firmware it shipped with was causing problems.  Read on for the solution!

Hardware

Simple! Here’s all you need:

• An XBee breakout board (so you can plug it into your breadboard)
• An XBee Explorer (not necessary with ad-hoc mode, but I had one around so this tutorial will use it)
• 3.3V regulator (ONLY—the module has a 10% tolerance, so anything beyond that will either not work or damage the module).
• 10µF and 0.1µF capacitors for good measure (clean power is especially important when using radio devices)
• Power and Ground (Pins 1 and 10, the top and bottom pins on the left side of the module)
• An LED connected to pin 9.  In practice you’d want to put a current-limiting resistor on it, i.e. 220 ohms, but for a quick test it won’t matter.  The module only drives 8mA on this pin.
• That’s it!

set wlan phrase <your wpa password>
set wlan ssid <your ssid>
save
reboot

ftp u

telnet <module's ip address> 2000

set sys mask 0x21f2

set sys output 2 2

set sys output 0 2

References

• RN-XV User Manual (API reference, etc.)
• RN-XV Datasheet (pinout and electrical characteristics)

The RN-XV WiFi module is a nifty little WiFi module designed to fit the same pinout as an XBee, so it’s intended to be a drop-in replacement.

Tonight I whipped up a little test of the module to get a joystick to talk to a Node.js server over WiFi.  I attached +3V power and ground to the module (pins 1 and 10, respectively), pin 2 (TX) to Arduino digital pin 0 (RX), and pin 1 (RX) to Arduino digital pin 1 (TX).  That’s all the hardware setup you need.

I used this WiFly library to handle the connection.  All it does is talk to the WiFly module over serial and send control commands, so the library abstracts that a bit.  Here’s the Arduino sketch I built:

#include "WiFly.h"

#define PIN_VERT      0  // analog
#define PIN_HOR       1  // analog

#define PIN_PUSH      2
#define PIN_LED_RED   3
#define PIN_LED_GRN   4

int vert = 0;
int hor = 0;
bool push;

char* ssid = "yourNetwork";
char* pass = "yourPassword";

char* serverAddress = "yourServer";
int serverPort = 1337;

Client client(serverAddress, serverPort);

void setup(){
  pinMode(PIN_PUSH, INPUT);
  pinMode(PIN_LED_RED, OUTPUT);
  pinMode(PIN_LED_GRN, OUTPUT);

  digitalWrite(PIN_PUSH, HIGH);    // set pull-up resistor
  digitalWrite(PIN_LED_RED, LOW);  // start off
  digitalWrite(PIN_LED_GRN, LOW);

  Serial.begin(9600);
  WiFly.setUart(&Serial);
  WiFly.begin();

  if (!WiFly.join(ssid, pass, true)) {
    digitalWrite(PIN_LED_RED, HIGH);
    while (1) {
      // Hang on failure.
    }
  }

  digitalWrite(PIN_LED_GRN, HIGH);

  if (client.connect()) {
    client.println("ohai!");
    client.println();
  } else {
    // do nothing
  }
}

void loop(){
  vert = analogRead(PIN_VERT);
  hor = analogRead(PIN_HOR);
  push = digitalRead(PIN_PUSH);

  digitalWrite(PIN_LED_RED, !push);

  client.print(vert);
  client.print('\t');
  client.print(hor);
  client.print('\t');
  client.print(push);
  client.println();
  delay(10);
}

And here’s the very basic Node.js server that just prints out the values it receives:

var net = require('net');

var server = net.createServer(function(socket) { //'connection' listener
	console.log('server connected');

	socket.setEncoding('ascii');

	socket.on('end', function() {
		console.log('server disconnected');
	});

	socket.on('data', function(data){
		console.log(data);
	});
});

server.listen(1337, function() { //'listening' listener
	console.log('server bound');
});

The title says it all: for my “Deconspectrum” installation, I am burning a program onto a bunch of ATMega328 chips using a USBtinyISP (In-System Programmer).  At first I was running into a perplexing problem: the program was running much slower than it should have been.  I could tell immediately because I had a short POST (Power-On Self Test) at the beginning of the program that flashes the LED Red-Green-Blue, and it was going far slower than it should have been.

My first thought was that there was a problem with the ATMega “fuses,” which are just settings for various esoteric details of the chip’s functioning, including clock rate.  But I had never had to bother with them before.  Then I made a further discovery that the only time the program ran correctly was if I installed the Arduino bootloader first and uploaded the program using it.  What gives?

Thanks to the plucky denizens of the ITP Physical Computing list, I learned that indeed, it was a matter of fuses—the Arduino IDE apparently only sets the correct fuses when burning the bootloader, not when burning a program directly using an ISP.

The solution: use avrdude, the program that Arduino uses to actually program the chip behind the scenes, directly.  This turned out to not only solve my problem, but to make the programming process much faster and simpler.  Avrdude takes a “hex” file as an input to transfer to the chip, which is the compiled bytecode that the ATMega actually runs.  This way, I only have to compile the program once, and burn it directly—and since I’m programming about 40 chips, this makes things far faster.

All you need to do is get the AVR “CrossPack” installed (for OSX; for Windows you can use AVR Studio or a number of other packages) and then find your hex file.  In the Arduino IDE, hold Shift while pressing the “Verify” button to produce a verbose debug output.  In there you’ll see a path like this:

/var/folders/9t/7qf1680d2pqgd0hy6qbfkqsr0000gn/T/build5025172614724793636.tmp/myProgram.cpp.hex

You can then copy that file to your project directory:

cp /var/folders/.../myProgram.cpp.hex ~/Projects/myProject/myProgram.cpp.hex

And program your chip like so:

avrdude -c usbtiny -p m328p -b 57600 -U flash:w:myProgram.cpp.hex:i -U efuse:w:0x05:m -U hfuse:w:0xde:m -U lfuse:w:0xff:m

Those settings are for the ATMega328; for the 168 use:

-p m168

To get a list of parts, type:

avrdude -c avrisp

And there you have it! You’ll find that this saves a lot of time if you have to program lots of chips. Besides, not using the Arduino bootloader will save a little space on your chip

Hooking up an RGB LED to an Arduino isn’t hard by itself, but controlling it can be—if you know what color you want to display, how do you know what R, G and B values that is?

Here’s some Arduino code, adapted and simplified from Kasper Kamperman, that I am using in my Deconspectrum art installation to do just that:

void setLED(int hue, int l){
	int col[3] = {0,0,0};
	getRGB(hue, 255, l, col);
	ledWrite(col[0], col[1], col[2]);
}

void getRGB(int hue, int sat, int val, int colors[3]) {
	// hue: 0-259, sat: 0-255, val (lightness): 0-255
	int r, g, b, base;

	if (sat == 0) { // Achromatic color (gray).
		colors[0]=val;
		colors[1]=val;
		colors[2]=val;
	} else  {
		base = ((255 - sat) * val)>>8;
		switch(hue/60) {
			case 0:
				r = val;
				g = (((val-base)*hue)/60)+base;
				b = base;
				break;
			case 1:
				r = (((val-base)*(60-(hue%60)))/60)+base;
				g = val;
				b = base;
				break;
			case 2:
				r = base;
				g = val;
				b = (((val-base)*(hue%60))/60)+base;
				break;
			case 3:
				r = base;
				g = (((val-base)*(60-(hue%60)))/60)+base;
				b = val;
				break;
			case 4:
				r = (((val-base)*(hue%60))/60)+base;
				g = base;
				b = val;
				break;
			case 5:
				r = val;
				g = base;
				b = (((val-base)*(60-(hue%60)))/60)+base;
				break;
		}
		colors[0]=r;
		colors[1]=g;
		colors[2]=b;
	}
}

void ledWrite(int r, int g, int b){
	analogWrite(LED_RED, 255-r);
	analogWrite(LED_GREEN, 255-g);
	analogWrite(LED_BLUE, 255-b);
}

This gives you a very straightforward setLED function that takes a Hue from 0-359 and a Lightness from 0-255 (it could easily be adapted to specify the Saturation as well, which I have fixed at the maximum).

Note that the ledWrite function is designed for common-anode LEDs, where the microprocessor is current-sinking instead of sourcing; if you are current-sourcing, just take out the 255-val inversion.

If you’ve never made a breadboard Arduino, you really ought to try it (I have a quick tutorial)—you’ll suddenly discover that you rarely need an actual (and expensive) Arduino anymore.  The Arduino is built around the Atmel ATmega microprocessor, which you can buy from various places for roughly only $4-5!

However, there are a few things about it that aren’t obvious at first, such as how to connect it to your computer via USB and make it programmable.
First off, be sure that your ATmega chip has the Arduino bootloader on it.  If you bought it from a major supplier such as Mouser or Digi-Key, it does not have the bootloader.  Sparkfun (among others) sells them with bootloaders.

Second, you’ll need an FTDI USB breakout board.  This connects to the TX and RX serial pins on the microprocessor and supplies a USB interface and firmware that your computer can recognize and use.  You’ll need the FTDI drivers for your system, which come with the Arduino software.

Third: the real work.  You need to connect some pins from the USB board to your breadboard:

• GND
• TX
• RX
• DTR
• Optional: 5V (if your breakout board supplies it)

As you can see in the photo, I soldered up a handy little header so I can plug it right into a breadboard.  The serial pins are connected like so: TX→RX, RX→TX.  DTR is connected to a .1µF capacitor that goes to the RESET pin on the ATmega (pin 1).  That pin must also be connected to +5V via a 10kΩ resistor.

The DTR pin is the secret sauce: it pulls the reset pin down, which the Arduino bootloader requires to be programmed.  If you didn’t have this, you’d have to reset it by hand.  This way, it’s completely automatic, just like a regular Arduino board.

Let me know if this works for you!  Enjoy!

If you’ve been enjoying making stuff with the Arduino, but don’t want to buy more Arduino boards just to make a new project, fear not—you don’t need them!

The Arduino board is just a convenient wrapper around the ATmega microprocessor, and it’s easy to recreate on a breadboard.  Here’s what you’ll need:

• ATmega328 (with Arduino bootloader)
• 5V regulator (i.e. L7805)
• .1µF capacitor (the little yellowish disc kind that says “104″ on it)
• 16mhz resonator
• 10kΩ resistor
• >5V power supply (can be any power supply you have, such as wall-warts, since we’re using our own regulator)
• Optional: FTDI USB breakout board (for programming from a computer)

The bootloader is what makes the microprocessor easy to program with the Arduino environment.  You can also buy ATmegas without the bootloader for about a dollar cheaper, but they must have the bootloader manually loaded on to use Arduino.

The resonator is a handy package that combines a crystal, which is where the microprocessor gets its clock signal from, and two capacitors, so all you have to do is plug it into the ATmega.

If you have an ATmega that’s already loaded with your program, you can just build this board as-is without the capacitor and leave pin 1 (RESET) connected to +5V via the 10k “pull-up” resistor.  You can even program a chip on an Arduino, remove it and plug it into your breadboard setup.

The one part remaining that I haven’t mentioned is the programming header I made, on the top right of the top photo (fully visible in the second photo).  This connects to the FTDI USB board I describe in my easy breadboard Arduino programming tutorial.  The pins are, from top to bottom: Ground (Black), RX (White), TX (Green), DTR (Yellow).

Lastly, though not pictured here, it is good practice to use decoupling capacitors on your power supply to protect your microcontroller from any irregularities, as described in this tutorial (a few pages down).

A few months ago I accidentally fried my Wii Sensor Bar (a misnomer as it does not contain sensors of any kind) by powering it with an unregulated 12V power supply—whoops. So instead of buying a new one, which I’m loath to do given the typical prices, I built a new one with some infrared LEDs, a regulated power supply and—yes—a piece of cardboard.

Just solder up each LED after a 220 ohm resistor in parallel with each other—not in series.  This can be done with two “rail” wires, one connecting the positive leads, one connecting the grounds.  Then connect the rails to a standard barrel power connector and plug in your power supply.  I also added a green LED for visible power feedback.  Enjoy!

I recently made some minor modifications to the Liquidware Arduino Temperature Sensor Library which is designed to read from a single TMP421 sensor from Modern Device (the chip is made by TI).  You can download my modified library, LibTemperature2.

Instantiate a LibTemperature2 object with the address of the sensor, which is determined by the A0 and A1 pins on the breakout board according to this chart:

’0′ means Ground, ’1′ means Vcc, and ‘Float’ means unconnected.  So to address 0x1C (0011100b), connect A0 to ground and leave A1 unconnected.  Note that the default address is 0x2A.

Enjoy!

“Cryptophasia” is the working title of a language machine installation that I’ve been working on. Cryptophasia, according to Wikipedia, is “a peculiar phenomenon of a language developed by twins (identical or fraternal) that only the two children could understand. The word has its roots from crypto meaning secret and phasia meaning speech disorder. Most linguists associate cryptophasia with idioglossia, which is literally the same, but cryptophasia also includes mirrored actions like twin-walk and identical mannerisms. Little is known about cryptophasia.”

The installation consists of two motorized drafting machine arms that write to each other, emerging their own glyphic writing system as they do so. It is a continuation of my “language machines” research/art.

These are closeups of the joints of the drafting machine arm: