Because surplus LED panels from an early 1990s supercomputer is a completely reasonable thing to own, [William Dillon] set to work displaying them on his wall.

The LED panels came from a surplus CM-5 Connection Machine, best known from it’s role as the mainframe in Jurassic Park (only an empty case with LED panels were used in the movie). When not on Isla Nublar, the Connection Machine was a fabulous piece of engineering from the 1980s Artificial Intelligence revival. With some machines having 65,536 processors, it was used for AI research using Lisp (although we were never very good at Lisp.

[William] built a wooden frame out of 1×2 inch maple and installed an X10 module behind the panels as a remote switch. The panels themselves aren’t controlled by a computer, so the only thing left to do was to mount the power supplies. It’s impressive to see the massively over-engineered power supplies that were designed to source 5V @ 30A when the panels only draw 7 Amps. [William] says it was a design feature of the Connection Machine to spare no expense.

[William]‘s next plan is to reverse engineer the panels to display custom messages, and we can’t wait to see what he comes up with. We can’t explain why, but we really want to build one of these panels. Check out the pictures of [William] decommissioning the CM-5.

Macetech’s ShiftBrite is a high-power RGB LED coupled with an Allegro A6281 backpack. The A6281 uses three 10bit pulse-width modulators to mix millions of colors using the red, green, and blue elements in the RGB LED. Multiple modules can be chained together for bigger projects, like the ShiftBrite table.

Below the break we demonstrate a ShiftBrite module using the Bus Pirate. For a limited time you can get your own Bus Pirate, fully assembled and shipped worldwide, for only $30.

ShiftBrite RGB LED module (Macetech, $4.99). ShiftBrite datasheet and example code, Allegro A6281 datasheet (PDF).

The ShiftBrite module is a complete A6281 development board. It doesn’t require any extra parts, just a 5-9volt supply.

The A6281 is one of the most complete RGB LED driver ICs, but it’s only made in a tiny QFN package. The ShiftBrite is a good way to try the A6281 without soldering a small chip.

A bunch of A6281 modules can be chained together. Each module repeats all of the serial input signals on separate output pins, so the A6281 will work over long cable runs.

We used our Bus Pirate universal serial interface to demonstrate the ShiftBrite, but the command sequences will be the same for any microcontroller. We connected the Bus Pirate to the ShiftBrite as shown in the table above.

We setup the Bus Pirate for raw3wire mode (M, 8), and chose open drain outputs (Hi-Z) so we can interface the ShiftBrite at 5volts. The Bus Pirate can’t output 5volts directly, so we enabled the bus pull-up resistors (menu ‘p’ in v2) and attached the pull-up resistor voltage input pin to the 5volt supply. Finally, we enabled the on-board power supply (capital ‘W’).

Interfacing

The LED driver output is only active when the enable pin (EI) is held low.

RAW3WIRE>A <– capital ‘A’, EI pin high, output disabled
AUX HIGH
RAW3WIRE>a <– small ‘a’, EI pin low, output active
AUX LOW
RAW3WIRE>

We used the Bus Pirate’s auxiliary pin to toggle the A6281′s enable pin, but you could also bypass this feature by wiring EI directly to ground. A small ‘a’ in the Bus Pirate terminal takes the AUX/EI pin connection low, enabling the LED output.

Two commands update the A6281 settings. The configuration command controls dot correction and clock settings. The LED pulse-width modulator (PWM) command updates the three 10bit values that set the red, green, and blue channel brightness. Both commands are 32 bits (4 bytes) long, bit 30 selects the configuration or pulse-width modulator command. Refer to the chart above, or datasheet page 7.

The interface protocol is like SPI, but the master-input-slave-output pin is unused. Data is sent most significant bit first, starting with bit 31. Commands are sent by clocking 32 bits into the chip and then toggling the latch pin.

Before we can start mixing colors, we need to setup the A628a’s internal clock and write the dot correction values.

RAW3WIRE>0b01000111 0b11110001 0b11111100 0b01111111 ][
WRITE: 0x47 <--write 32bits of data
WRITE: 0xF1
WRITE: 0xFC
WRITE: 0x7F
CS DISABLED <--latch pin high
CS ENABLED <--latch pin low
RAW3WIRE>

We wrote the values in binary so it's easy to follow along in the table above. Remember that bit 31 is sent first, so the order of bits shown here is opposite of what is shown in the table.

The complete setup command is 32 bits (4 bytes) long. Bit 30 sets this as a configuration command (1). Bit 7 and 8 configure the clock source, value 00 configures the 800KHz internal oscillator (datasheet page 7). Three 7bit 'dot correction' values fine tune the LED color channels if you want to correct a wonky pixel in a large array (see the register locations in the table above). We set all the dot correction values to full (1111111). Several bits trigger test functions or don't have a purpose, these should be entered as 0.

After entering 32 bits, toggle the A6281 latch pin (][) to lock the data into the register. Now that the chip is configured and the output enabled, we can finally play with the LED.

RAW3WIRE>0b00111111 0b11111111 0b11111111 0b11111111 ][
WRITE: 0x3F
WRITE: 0xFF
WRITE: 0xFF
WRITE: 0xFF
CS DISABLED
CS ENABLED
RAW3WIRE>

First, turn all the colors to full. Bit 31 (0) is ignored, bit 30 (0) indicates a LED pulse-width modulator update command, and the remaining bits set all three channels to 100%.  The three PWM values control the output intensity of each color as follows: blue (bits 29:20), red (bits 19:10), and green (bits 9:0). Raise and lower the latch pin (][) to end the command.

Next, test each each color individually.

RAW3WIRE>0b00111111 0b11110000 0b00000000 0b00000000 ][
WRITE: 0x3F
WRITE: 0xF0
WRITE: 0x00
WRITE: 0x00
CS DISABLED
CS ENABLED
RAW3WIRE>

Bit 30 (0) signals an LED PWM update command, followed by a 100% setting for the blue channel (1111111111) and 0% settings for the red and green channels. When we toggle the latch pin (][) the new values are saved and the LED color changes to blue.

RAW3WIRE>0b00000000 0b00001111 0b11111100 0b00000000 ][
WRITE: 0x00
WRITE: 0x0F
WRITE: 0xFC
WRITE: 0x00
CS DISABLED
CS ENABLED
RAW3WIRE>

This time we'll set the LED to 100% red. Bit 30 (0) signals an LED PWM update command, followed by a 0% setting for the blue channel, a 100% setting for the red channel (1111111111), and a 0% setting for green.  When we toggle the latch pin (][) the LED color changes to red.

RAW3WIRE>0b00000000 0b00000000 0b00000011 0b11111111 ][
WRITE: 0x00
WRITE: 0x00
WRITE: 0x03
WRITE: 0xFF
CS DISABLED
CS ENABLED
RAW3WIRE>

Finally, we set the LED to 100% green. Bit 30 signals an LED PWM update, followed by 0% settings for the blue and red channels, and a 100% setting for the green channel (1111111111).  Toggle the latch pin (][) and the LED color changes to green.

Like this post? Check out the parts posts you may have missed. Want to request a part post? Please leave your suggestions in the comments.

Hack a Day review disclosure: Macetech gave us a couple free ShiftBrites at Maker Faire 2008.

We covered SparkFun’s new RGB button pad controller a few weeks ago. This is a full-color clone of the monome interface; a 4×4 grid of buttons with tri-color LEDs underneath. Each LED has 24bits of color control, for more than 16million color combinations. Up to 10 panels can be chained together to create huge button grids, like SparkFun’s Tetris table. We previously used a smaller version in our RGB combination lock.

We asked SparkFun to send us the SPI version of the button controller to test. This is a new product developed in-house at SparkFun, with open source hardware and software. Read about our experience interfacing this board below.

4×4 RGB button pad controller SPI (SparkFun #WIG-09022, $39.95)

The button pad controller is a bare PCB, we also received a button pad cover (SparkFun #COM-07835, $9.95), and two of each bezel (SparkFun #COM-08747, #COM-08746, $3.95).  The SPI version we’re working with can be driven directly by a microcontroller, or by a USB ‘master’. The USB controller version has an additional microcontroller and FTDI USB->serial converter for PC connectivity.

When the button pad arrived, we immediately sat down with the datasheet and tried to interface the board with our Bus Pirate universal serial interface. The protocol described in version 1 of the datasheet didn’t work, at all.

SparkFun open sourced this project, so we determined the correct interface protocol from the source code for the button pad SPI (ZIP) and the button pad USB controller (ZIP). We figured out most of the protocol from the source, but it still took help from SparkFun’s engineers to uncover some of the undocumented, finer points of interfacing the board. Version 2 of the datasheet (PDF) accurately depicts the interface protocol.

Connections

The button pad’s SPI signals are described as they relate to the on-board microcontroller, which is opposite the usual notation. The MOSI (master out, slave in) signal is actually the board’s data output, and MISO (master in, slave out) is the data input.

We tested the button pad with the Bus Pirate, but the same basic principals apply to any custom microcontroller code. The board runs at 5volts, so we powered it from the Bus Pirate’s on-board 5volt power supply. The SPI interface operates at 5volt logic levels, so we connected the Bus Pirate’s pull-up resistors to the 5volt power supply and enabled them on all signal lines.

We interfaced the button board using the Bus Pirate’s raw3wire library. Raw3wire is a software SPI library with bit-wise operations. The hardware SPI library only allows full byte operations which aren’t granular enough to interface the board. We put the Bus Pirate in raw3wire mode (menu option M), and chose the HiZ pin option because the pull-up resistors will hold the bus at 5volts.

RAW3WIRE>l <–configure bit order
1. MSB first
2. LSB first
MODE>2 <–least significant bit first
LSB SET: LEAST SIG BIT FIRST
RAW3WIRE>W <–enable power supply
VOLTAGE SUPPLIES ON
RAW3WIRE>

The button pad communicates least significant bit first, so we also configured the library to communicate LSB first. Finally, we hit capital ‘W’ to enable the Bus Pirate’s power supplies. The button board will flash each color momentarily as part of its power-on self-test.

Single/multiple button board setup

Each board needs to be configured for single or multi-board use. Boards come pre-programmed for single-board operation, but it might be a good idea to set the configuration anyways. The board configuration is permanently stored in EEPROM, so it only has to be done once.

RAW3WIRE>[\_ <--take all signals low
CS ENABLED <--CS enabled is 0volts
CLOCK, 0
DATA OUTPUT, 0
RAW3WIRE>

A special sequence places the board in configuration mode. Begin with all signal lines low (]\_).

RAW3WIRE>-^ 1 1 <–set single board operation
DATA OUTPUT, 1 <–data high
0×01 CLOCK TICKS <–one clock tick
WRITE: 0×01 <–config option 1, number of boards
WRITE: 0×01 <–set the number of boards
RAW3WIRE>w <–small ‘w’, power off
VOLTAGE SUPPLIES OFF
RAW3WIRE>W <–capital ‘W’, power on
VOLTAGE SUPPLIES ON
RAW3WIRE>

To enter configuration mode, take the data line high (-) and send one clock pulse (^), but leave chip select low. The board is now ready to accept configuration settings.

The first byte sent after entering configuration mode tells the board which setting to modify. Currently, only the number of boards can be configured (0×01). Next, send the number of connected boards, between 1 and 10. we sent 1 because we’re interfacing a single board. Reset the board and it will light a LED corresponding to the programmed number of boards.

Set colors and read button status

Now we’re ready to send color data to the board and read the button status. First, note that the CS (chip select) signal is opposite normal conventions. Usually CS activates a chip when the signal is low (0volts), and idles it when the signal is high (5volts); this is usually denoted by /CS, #CS, or !CS. Instead, the button controller is active when CS is high.

A 64byte transaction sets the LED colors and retrieves the button status. The first 16bytes program the red level for each LED, followed by 16bytes of green, and 16bytes of blue. Finish by reading 16bytes from the board to get the status of each button. Buttons data is sent as 0×00 if pressed, and 0xff if not pressed. The datasheet recommends a 400us delay between writing the color frames and reading the button data, but the Bus Pirate is slow enough that we won’t worry about that.

The protocol is simple enough, but there’s one major catch. The clock line must be high before raising CS, or the bytestream will be off by 1 bit. For this reason, many hardware SPI modules won’t work with the board.  This isn’t a problem if your microcontroller lets you twiddle pins that are controlled by a hardware module, but the micros we’ve worked with don’t allow this.

RAW3WIRE>/]255:16 255:16 255:16 r:16[
CLOCK, 1 <--clock must be high prior to raising CS
CS DISABLED <--CS to 5volts, opposite normal use
BULK WRITE 0xFF , 0x10 TIMES <--red LEDs
BULK WRITE 0xFF , 0x10 TIMES <--green LEDs
BULK WRITE 0xFF , 0x10 TIMES <--blue LEDs
BULK READ 0x10 BYTES: <--read button state
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
CS ENABLED <--CS to 0volts, opposite normal use
RAW3WIRE>

This command sets every color of each LED to full, and reads back the 16 button status bytes.

We first set clock high (/), and only then can we raise CS to 5volts (]) and begin the data transaction. 255:16 is a repeated command that sends the value 255  sixteen times. As each color channel has 8bits of intensity control, 255 is 100% on. We send 255 a total of 48 times, once for each color of each LED. Finally, we retrieve one 16byte frame of button data (r:16) and lower CS to end the transaction ([). The button values are all 0xff, indicating that no buttons are pressed.

RAW3WIRE>/] 0:16 0:16 128:16 r:16[
CLOCK, 1
CS DISABLED
BULK WRITE 0x00 , 0x10 TIMES
BULK WRITE 0x00 , 0x10 TIMES
BULK WRITE 0x80 , 0x10 TIMES <--all blue to 50%
BULK READ 0x10 BYTES:
0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
CS ENABLED
RAW3WIRE>

Here, we set the blue level of every LED to 50% (128) and turn off all other colors. The button output now shows that button 0 is pressed.

RAW3WIRE>/] 0 0 0 0 255 255 255 255 0 0 0 0 0 0 0 0 0:16 0:16 r:16[
CLOCK, 1
CS DISABLED
WRITE: 0×00 <– red LED 0, off
… <–more of the same
WRITE: 0×00 <– red LED 3, off
WRITE: 0xFF <– red LED 4, 100% on
WRITE: 0xFF <– red LED 5, 100% on
WRITE: 0xFF <– red LED 6, 100% on
WRITE: 0xFF <– red LED 7, 100% on
WRITE: 0×00 <– red LED 8, off
… <–more of the same
WRITE: 0×00 <– red LED 15, off
BULK WRITE 0×00 , 0×10 TIMES <– all green LEDs off
BULK WRITE 0×00 , 0×10 TIMES <–all blue LEDs off
BULK READ 0×10 BYTES: <–read button status
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
CS ENABLED
RAW3WIRE>

This example shows how to address single LEDs. This time we actually write out all 16 bytes of the red color frame. Buttons 0-3 and 8-15 have a red value of 0 (red off), buttons 4-7 are set to 100% red (255). All green and blue LEDs are off (0, 0%).

Conclusion

It was really frustrating to get this board working because the first version of the datasheet had so many errors. SparkFun’s engineers and support were really helpful, and posted a corrected datasheet within days. As long as you have the updated datasheet, this is an easy board to work with.

We’d like to see a firmware update that eliminates the need to keep the clock signal high before raising CS. This quirk makes the board incompatible with many hardware SPI modules, leaving slow bit-bang routines as the only interface option. Fortunately, the source code is open and available to anyone who wants to make this change.

The button pad controller is a really neat board, and we look forward to using it in a future project.

Hack a Day review disclosure: We asked for a free board and SparkFun sent it to us. We had a terrible time getting it to work with the instructions in the first version of the datasheet, we documented that experience here.

We’re happy to present this guest post from History Hacker’s [Bre Pettis]. Today [Bre] catches up with the Blinkenlights team, who turn entire buildings into displays. Their current project is Stereoscope which goes live in Toronto, Canada today.

Earlier this week, I posted about the beginnings of the blinkenlights project. It started in 2001 in Berlin, but now Seven years later, in May 2008, blinkenlights is back. The City of Toronto asked the blinkenlights team if they would be interested in joining another Nuit Blanche (as they did in Paris in 2002). Short on time and with a lot of ambition, they decided to redesign and push the envelope on the project to make it wireless for The Toronto City Hall since there would be 960 windows split up in two towers. In the above photo, you can see Stereoscope in all its glory.

I can’t help it, this is such an awesome project. I need to know more! I asked Tim to break it on down and give up the details.

What’s the story of the stereoscope project?

After having had a variety of new attempts around Europe that didn’t work out (due to either financial reasons or building owners that withdrew their support in the last minute) it took six years until we could come up with a new project (not counting two small Blinkenlights reprises at the original location).

But in May 2008, the City of Toronto asked us if we would be interested in joining another Nuit Blanche (as we did in Paris in 2002) in October 2008. There was really not much time left, so we immediately started working on this baby with a few really tough deadlines to be met. Especially because we did not want to go with the same technology we used back in 2002. The Toronto City Hall was even bigger than the Bibliothèque nationale de France (960 vs. 520 windows), split up in two towers and we also wanted to push the envelope a bit.

So we came up with the idea of going mostly wireless to save setup time. Although being a much bigger installation, we will probably need only half the time to set everything up – if things won’t go wrong of course.

What makes the stereoscope special?

The facade of Toronto City Hall is special in many ways. First there are two separate towers: both of different height and width. Both facaces are split in two parts of unequal size because there are mechanical floors in the middle without windows.

Even more important the towers have a curved structure and all the windows are faced inwards. This makes it impossible to see all the windows at the same time regardless from where you are. All our previous installations presented just one single screen very much like the screens we are used to on our computers.

Blinkenlights is not about building displays. It’s about participation of people and interpretation of architecture. So we try to “speak the language of the building.” To compensate for the difficult viewing angles, we promote a fluid appearance: things move slowly – what you can’t see now you will see in a few moments. This all also underlines the strange spatial appearance of the facade – hence the name Stereoscope (”spatial view”). We’ll see how this all turns out – we never know how are installations will feel before. It’s going to be a surprise to us as it is to the casual viewer.

How hard was it to create an iphone app?

The idea to create an application for a mobile device is as old as our project. But in 2001/2 there was nothing on the horizon that could do that. The iPhone however is the device we have been waiting for.

First of all we wanted this app to be useful to everybody. So we focused on a simulator that provides a real time view of what is going on. Everyone can load the app and tune in live – wherever they want (as long they have Internet access of course). The foundation for this we had in our code for a very long time – as we have been using IP packets for frame distribution inside our installation all along it just took a copy to be streamed to individual applications that could display the data stream on some kind of visualizer.

The blinkensim program of our original toolkit did that. An intelligent proxy – the blinkenproxy – enhanced this to an on-demand model: the proxy constantly receives the data stream from a single source and re-distributes the stream to every simulator that asks for a copy. We hope our infrastructure scales well enough to handle demand.

For Stereoscope we enhanced our protocol in many ways: each packet is realtime-stamped so the simulator can display the time the stream was generated – either in real time or as a playback from an archival copy. We also added support for multiple screens as Stereoscope supports the notion of individual subscreens and virtual matrixes and more.

We wanted the application to be really, really beautiful to look at. So we put together a team of gifted 3D and 2D graphic artists and two excellent iPhone/Mac-Programmers: the Coding Monkeys from Munich, known for their collaborative text editor SubEthaEdit and the useful Circulator iPhone application. They all joined forces and the result is a pretty outstanding little app that allows to view the building from any angle or predefined viewpoints while it fluidly displays the data stream coming from our central server.

Due to the strange distribution model and the long approval times of the iTunes App Store we might not be able to add more functionality. Every update usually needs a week to show up which is really bad for such a time critical piece. We have tons of more ideas on how to turn this app into a location-aware controller allowing for collaborative painting and other nice ideas. We’ll see how it turns out in the end. Project Blinkenlights is always work in progress and we will keep the data stream running after we have to take down the installation itself so that we can continue to play and experiment with a virtual building for future installations.

What’s broken so far? Has anyone been hurt?

Setup is going really well and we are confident to be ready in time. No casualties so far, knock on wood.

Are you going to port the old movies to the new project and are you specifically going to show a video of a woman dancing in greyscale?

We’ll show a medley of old and new stuff. The new multiple-layer core of our software allows multiple movies and games to run at the same time, target different subscreens and such. There are more new features in the code than I think we can make use of in just two weeks. We’ll see.

Concerning the dancing woman, I was just being told the original data is locked in a computer that is wrapped in plastic standing in a cellar in a small house in the Australian outback. I guess we won’t make it in time to revive that particular animation.

But we want to go for new original content anyway. There is a capable set of tools available for the Mac. We have built an infrastructure to use Quartz Composer to create animations for Stereoscope and we hope experienced designers will use it to create cool stuff. There is a stand-alone 3D simulator for the Mac as well (not yet as beautiful as the iPhone version but we’re working on that).

There will be additional tools for Mac and Windows like a Blinkenpaint-style editor for smaller movies and an updated blinkensim simulator for Linux and BSD Unix. There are third-party tools for as well that we will list on the website.

Is there anything else people should know about the project?

All of our hardware and software will be out in the open. The wireless dimmer technology will be released under a Creative Commons license and the new code will be either BSD or GPL licensed. We are still thinking of Project Blinkenlights as an open platform and something that should evolve and grow. We’d like to see both software and hardware hackers to take up on the work we have done and come up with new ideas and extensions.

We really hope we are not again running into such a long phase of inactivity and will be able to pursue a followup project sooner than later. It might be a nice idea to go ahead with a virtual representation of former installations but I guess it is the real world where it gets interesting as stuff needs to be tangible for people. Nothing beats reality.

Want to be involved? The iPhone app is a tool for people to watch in real time and it can also be used as a testing app when developing animations.

What the blinkenlights team are most interested in is that people create funny animations for the building. They provide an extensive toolset now including a Quartz Composer based development environment on the Mac and a library for Processing that works cross-platform.

They are busy setting up the submission form now and will post more background on everything. So everybody who is interested in participating to subscribe to the blinkenlights blog.

They are also working on a Java based Game API for people who like to code little apps to interact with people calling in with their mobile phones.

If you’re not following Tim on Twitter, you should! He recently twittered that they had ordered pizza and the pizza delivery guy couldn’t find the building so they made the building light up with the words, “Pizza Here!”

[photo: antenne]