DomeStar
- Processing Simulator
- Processing Transmitter
- Hardware, Firmware and Host (by Max Henstell and Matt Mets)
- DomeStar 2.0 GoFundMe
Summary
DomeStar is a 25-foot diameter dome covered by 6,400 addressable RGB LEDs. The LEDs are spread out over 40 strips of 5 meters each. Several collaborators have contributed to the project. Max Henstell designed the hardware, Matt Mets developed the firmware and proxy software and I developed the Processing framework for the various routines it displays.
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 project has been bouncing around since 2012. It was rebooted with a new dome and new software in May 2016.
Implementation
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 a Teensy 2.0 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. He ran 12V to the controller so that we can use wire of a reasonable gauge.
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 the Art Car Wash Sign.
The protocol was kept the same as the ACW, a simple stream of bytes sent over UDP to feed the host software. A simulator 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.
DomeStar 2.0
In 2016 we rebooted the DomeStar project. We replaced the dome itself, added a foam diffuser layer to the strips, CNCed some new mounting hardware, added sound, and rewrote all the animation software. Eric Mortensen lead the fundraising effort on GoFundMe.
New Dome
We replaced the old flattened and drilled 16-foot PVC dome with a 25-foot one that uses actual connector hubs from SonoStar. We decided to stick with PVC because it’s lightweight and easy for us to transport.
The size presented their own set of challenges. We needed to use bigger ladders, and in some cases ladders stacked on boxes.
Diffuser
I started by testing the strips in a white pool noodle. The effect is very nice, as you can see in this video.
We couldn’t get white pool noodles in the kind of volume we needed so we settled for EPE foam used for pipe insulation which was a little thinner and not as rigid. You can also see the new mounting hardware here.
New Software
I built a new framework and updated the simulator. We introduced mapping that allowed for easier development of routines. Brian O’Clair and Jared Klett contributed routines. Eric Mortensen curated a number of videos that could be played with the mapper.
Audio
Eric Mortensen spearheaded audio integration into the project. Disorient loaned us a four speaker sound system on which Eric plays some interative generative music also controlled by WiiMote.
Other Stuff and Next Steps
DomeStar has been one of my favorite projects to return to. It continues to be popular at regional burns despite having appeared more times than I care to count. Every time we bring it out we try to add something fresh to the installation. Not everything has worked.
DomeStar.us
I created a mobile web app that reads your phones accelerometer data and feeds it back to the dome. The idea is to turn your phone into a paintbrush that will be able to paint color onto the dome. Connectivity an calibration issues have proven too difficult to use it in practice.
More strips and the swirl
Should DomeStar continue to appear the next most obvious upgrade would be to add more strips. 6400 LEDs just aren’t that impressive anymore. I think doubling the count would be a straightforward upgrade. I would also like to experiment with mounting the strips at an angle so that the LEDs are distributed more horizontally. The current aspect ratio of 1:4 makes recognizable imagery really challenging.
DomeStar’s LEDs were repurposed for the octahedron structure in front of Disorient at Burning Man 2015. I also participated in the physical build of the structure.
Because of the harsh envrionmental conditions at Burning Man, I changed the power supplies for sealed Meanwell 5V supplies. Matt Mets made a quick change the PCB to support it.
We also used a Raspberry PI to run the UDP->USB host code. The laptop that ran the Processing code was kept in a container back in camp. We ran a long ethernet cable out to the structure to connect to the PI. It worked reasonably well, but an off-by-one error somewhere caused glitches in the color. I just kept all the routines white rather than ferreting out the bug, because Burning Man.