CheerLight 2012


Here’s my CheerLight 2012 device, which I call the CheerLCD! And what is CheerLights you say?

CheerLights is an ioBridge Labs project that allows people’s lights all across the world to synchronize, stay linked based on social networking trends. It’s a way to connect physical things with social networking experiences and spread cheer at the same time.

Much like last year, I’ve opted for a small desktop display—a USB-powered computer peripheral—rather than some giant string of multicolored lights…


With the combined power of 3D printing, affordable electronics, and the duct tape of programming languages that is Perl, we’ve developed a device that informs you of what color the CheerLights around the globe are, not only with color, but with words!

(Though we’ve not yet done extensive testing, the text should be legible even by those suffering from color blindness. Accessibility, FTW!)


The CheerLCD consists of a USB + Serial Backpack Kit and LCD Display from our friends at Adafruit Industries. But you can’t just have a display without some sort of thingy to display the display properly… enter the 3D Printer!


The CheerTree was designed specifically to hold the LCD Display. I utilized Inkscape for the design of the front plate, and then brought that shape into OpenSCAD to add the base and create an STL file for printing. (It ended up warping a bit but that just adds to the charm and aesthetic of the overall device.)

I know what you’re saying, “This is all well and good… but we need to see the CheerLCD in action!” As you wish, my friends… as you wish.

There’s some code over on github/CheerLCD, and some files on Thingiverse for the CheerTree.

Enjoy the Holiday Cheer!


Learn Processing!


I had a lot of fun with Processing last year when I joined in with a few other folks and declared May as “Processing Month” and my final project was the Make A Sketch, which was an Arduino + Processing piece.

There’s two other guys at Milwaukee Makerspace with an interest in Processing, and we figured it was worth sharing what we know, and we’ve decided that a 3-hour workshop on the subject would be a good idea, so…

Join us Thursday, February 23rd, 2012 at 6pm to learn about Processing! [Sign up here]

We’ll expect you to have Processing installed on a laptop, basic knowledge of writing code, and a few simple sketches running. If you can do all that, and want to dive a bit deeper into Processing, we’d love to have you there. (If you’re a Milwaukee Makerspace member the cost is $20, otherwise it’s $25 for the general public.)

Besides some basics of Processing we’ll be creating a collaborative team project, so it should be all-around awesome. If you’re a coder who wants to make some interactive art, or an interactive artist who wants to write some code, well… you’ll fit right in. :)



Logging the temperature and humidity (code)

Temperature and Humidity

I’m always annoyed with myself when I don’t publish my code, so this is a follow-up to my Logging the temperature and humidity post.

This whole thing is definitely a work in progress. The hardware has exposed wires, and the software is all just cobbled together pieces. Making something that works is much different than making something that will continue to work, and work properly, and efficiently. Making something that works is a first step. It’s an important step, but it’s only the first step. So let’s begin!

I started with the example from Adafruit over on GitHub and about the only changes I made was to the format output of the data.

// Example testing sketch for various DHT humidity/temperature sensors
// Written by ladyada, public domain

#include "DHT.h"
#define DHTPIN 2     // what pin we're connected to
#define DHTTYPE DHT22   // DHT 22  (AM2302)


void setup() {

void loop() {
  int h = dht.readHumidity();
  int t = dht.readTemperature();

  // check if returns are valid, if they are NaN (not a number) then something went wrong!
  if (isnan(t) || isnan(h)) {
    Serial.println("Failed to read from DHT");
  } else {
    int temperatureF = (t * 9 / 5) + 32.5;

So this outputs the value for the humidity, then a tab, then the value for the temperature, and then a line return. Oh, I did change the code to output the temperature in Fahrenheit instead of Celcius. If we get a bad value, it’ll print “Failed to read from DHT” though I’ve yet to see that in the log files, I should probably take it out. Also, the Arduino just streams data at a fast rate, much faster than I need. I typically put the sleep functions (to limit the amount of data logged) in my reading code which runs on the computer. I think this is the right way to go, but if you have other ideas, please let me know.

Here’s a fairly simple Processing sketch that will read the data coming in from the Arduino. (Obviously you need the Arduino connected to the computer via USB.)

import processing.serial.*;

PrintWriter output;

Serial myPort;    // The serial port: 
PFont myFont;     // The display font: 
String inString;  // Input string from serial port: 
int lf = 10;      // ASCII linefeed 

void setup () {
  // set the window size:
  myPort = new Serial(this, Serial.list()[0], 9600);
  // don't generate a serialEvent() unless you get a newline character:
  output = createWriter("output.txt");

void draw () {
  // everything happens in the serialEvent()

void serialEvent (Serial myPort) {
  // get the ASCII string:
  String inString = myPort.readStringUntil('\n');
    String[] words = split(inString, '\t');
    String humid = words[0];
    String tempe = words[1];
    text("   Humidity: " + humid, 40,90);
    text("Temperature: " + tempe, 40,160);

   output.printf("%d-%02d-%02d %02d:%02d:%02d\t%s", year(), month(), day(), hour(), minute(), second(), inString); // Write to the file
   output.flush(); // flush output

Besides displaying a small window with the humidity and temperature (seen at the top of this post) it will also log the data to a file named output.txt

Processing Output

2011-07-25 19:09:14     44      91
2011-07-25 19:09:14     44      91
2011-07-25 19:09:15     44      91
2011-07-25 19:09:15     44      91
2011-07-25 19:09:16     44      91
2011-07-25 19:09:17     44      91
2011-07-25 19:09:17     44      91
2011-07-25 19:09:18     44      91
2011-07-25 19:09:18     44      91

This is pretty terrible, as we’re getting way too much data. I should probably add some delay into the Processing sketch, as it’s creating a log file line much faster than the sensor can even output data! This will result in large log files and is just wasteful. If all I wanted was the window showing the current temperature and humidity, I’d probably just delete the logging part of the sketch. Add that to the TODO list. Anyway, it works, and as a proof of concept, it’s a start.

Here’s the Perl code I was using:


use Device::SerialPort;
use IO::Handle; FILE->autoflush(1);
my $port = Device::SerialPort->new("/dev/tty.usbmodemfd411");


my $fileout = './templight.log';
my $filerec = './templight-recent.log';

open (FILE, ">>$fileout") or die ("Ooops! Could not open $fileout: $!");

while () {
    # Poll to see if any data is coming in
    my $char = $port->lookfor();

    # If we get data, then print it
    if ($char) {
	$time = localtime(time);
	if (length($char) > 1) {

		my $str = ($time . "\t" . $char . "\n");
		print FILE $str;

		open (FREC, ">$filerec") or die ("Ooops! Could not open $filerec: $!");
		print FREC $str;
		close (FREC);
    # Uncomment the following lines, for slower reading, 
    # but lower CPU usage, and to avoid 
    # buffer overflow due to sleep function. 

    sleep (10);
close (FILE);

The logging here is a little better than the Processing sketch, at least we add some delay with that sleep at the bottom so our log files won’t be quite as large. We’re saving to two files, templight.log and templight-recent.log. The second one just saves the current data, this just enables us to grab the data from that file and do something else with it, like… send it to Twitter or something.

Perl Output

Tue Jul 26 04:30:39 2011        46      89
Tue Jul 26 04:30:49 2011        46      89
Tue Jul 26 04:30:59 2011        46      89
Tue Jul 26 04:31:09 2011        46      89
Tue Jul 26 04:31:19 2011        46      89
Tue Jul 26 04:31:29 2011        46      89
Tue Jul 26 04:31:39 2011        46      89
Tue Jul 26 04:31:49 2011        46      89
Tue Jul 26 04:31:59 2011        46      89

So our output from Perl looks similar, though we have much less data (but still plenty of data) and the date format is a little different. (Chalk that up to laziness.) Oh, the Perl code also has the serial port hardcoded to /dev/tty.usbmodemfd411, which is lame, and I do have code somewhere to grab the serial port dynamically, but I didn’t implement it yet.

Whew! It feels so liberating to publish all that terrible code… (I mean my own code, not Adafruit’s!) Now I feel the need to start re-writing it and making it less terrible.


Processing: TouchOSC


Today in Processing we’re trying out OSC (Open Sound Control) with TouchOSC.

Jason (@plural) is one of those smart guys that hangs out at the Milwaukee Makerspace, and he’s mentioned OSC a bit before, and I figured it was time to take a look.

I got TouchOSC installed on my iPad and I tested it out as a control surface for Apple’s Logic, which was pretty cool, but then I wanted to test it with Processing. Luckily, Stefan Goodchild, made this simple with his TouchOSCAccel code on GitHub.

In the image above, the red one on the left represents the tilt of the iPad as it’s sending data to Processing. The yellow one on the right is the iPad when it’s upside down. (The iPad connects to Processing running on my Mac via WiFi. Remote Control!)

I haven’t even tried to tweak the code yet, but figured I’d mention this neat little combo, because, you know, there may be times you want to control something in Processing using something besides a potentiometer connected to an Arduino.

Note: You will need the oscP5 library.


Processing: HTTP Request

HTTP Request

I’ve been falling behind on Processing Month, but it’s not because I haven’t been hacking away, it’s because I’ve been hitting a lot of walls, not having things work out the way I want them to. I’m trying to not just take other people’s code and go from there, but trying my best to dig through the Processing documentation and reference and figure things out. Sometimes it works… Sometimes it doesn’t.

So that “138” you see above is not very exciting at all. I started working with pulling data from the web into Processing, with the thought that I’ll have a web application output data, that Processing pulls in, and then talks to an Arduino to do… something.

So right now there is a bit of PHP that looks like the following:

<?php echo "138" ?>

And in Processing when I call the println command it outputs this:

HTTP Request

And in draw() after we call the println command, we also call the text command which puts the “138” on the canvas.

I know… it’s fairly unexciting, but it’s a small step. Very small. I have a long way to go to get it working more reliably. Right now, we are reversing the output from the request, and grabbing the first line (index array zero) which should be the last line if we didn’t reverse it. I’m not too clear on array operations yet. (I come from the text processing world of Perl, so there’s a little culture shock in Processing.) Also, if the code outputs anything after the value, it doesn’t work. (I found this out when editing the file in nano, which seems to add an extra line at the end. Urgh)

 * 20110518.pde


Client c;
String data;

void setup() {
  size(800, 600);
  c = new Client(this, "", 80);
  c.write("GET /raster/processing/20110518.php HTTP/1.1\n");

void draw() {
  if (c.available() > 0) {
    data = c.readString();
    String lines[] = reverse(split(data, "\n"));
    text(lines[0], width/2, height/2);

The good news is, since I have been busy with Processing (and if all goes well) I’ll have a new interactive art piece to display at the Milwaukee Makerspace for Bay View Gallery Night.