DomeStar In-Depth

An in-depth look at DomeStar is long overdue. Now that it’s back from Maker Faire it’s time to take it apart and see how it works.

Find out more after the break..

What is it?

DomeStar is a 16-foot diameter dome covered by 6,400 addressable RGB LEDs. The LEDs are spread out over 40 strips of 5 meters each. Everything we developed for the project is open-source and available on GitHub.

DomeStar was shown at the NYC Resistor Interactive Show, Disorient Country Club, PEX Summer Festival, Burning Man, the Open Hardware Summit and World Maker Faire.

The Strips

We used strips based on the LPD8806, similar to the ones you’ll find at adafruit. These strips have proven to be fairly durable having been repeatedly wound, unwound, overheated, zip tied, lied on and occasionally stepped upon. You can see in the picture above that some of the spools have warped from the heat of running the LEDs at full brightness while still spooled. The most common failure has been with the connections on the LPD8806 chip. We cleaned these up by cutting open the housing and hitting it with a little solder and flux.

The Controllers

Max Henstell designed the controller boards. They serve two purposes: connect the Teensy to 8 strips to which data is sent in parallel (more on that below), and step the 12V coming from the power supplies down to 5V. We run 12V to the controller so that we can use wire of a reasonable gauge.

The Teensy 2.0 has become a favorite amongst Resistors as it’s cheap, small, and you can talk to it at USB speeds.

The Power Supply

Max also put together the power supply, pictured here with a fresh coat of playa dust. It’s 5 x 12V DC power supplies housed in a convenient carrying case with some pretty sweet Neutrik NAC3FCB locking connectors.

The Firmware and Driver

Matt Mets wrote the firmware that runs on each Teensy. It’s really simple – take every byte that comes through the USB and pass it to the data port. It sets the clock port low just before each data byte, and high just after.

Each controller board is connected so that we’re talking to 8 strips in parallel. Each byte sent over USB represents 1 bit on 8 strips. The registers that control the ports are set all at once rather than one bit at a time.

The host software is responsible for taking image data sent over the network via UDP, chopping it up so that it addresses the strips in parallel, adding in the latch signal, and sending it over 1 or more USB ports. This is really where a lot of the magic lies. Matt spent a long time figuring out ways to manage this using parallel threads so we could keep the frame rate up. There’s also a slower, but easier to understand, python version.

The Animation Software

The final piece of the puzzle is the animation software. We used a processing sketch forked from an earlier project.

The protocol was kept the same as the other project, a simple stream of bytes sent over UDP to feed the host software. An emulator was written so we could work on routines without having everything set up. In practice we tended to just visualize in our heads what the tiny 40 x 160 pixel image would look like when mapped on a 16-foot dome. Matt has proven especially good at this, writing many seemingly simple patterns that look stunning on the dome.

The sketch has an everything-and-the-kitchen-sink feel to it, with support for WiiMotes, audio processing, filters and more. It really shows the point at which processing becomes unwieldy.

What’s Next

The dome is going to go on hiatus for a little while now, but the electronics may make an appearance here and there. Matt and Max are taking what they’ve learned and applying it to BlinkyBoard, a tiny controller designed specifically for these strips.