Wizz : The Engineer

back to Engineer
The Wizz Wall THE WIZZ WALL

This is my biggest project so far. An engineering dream I had for so long that became possible when the FAIE (Fonds d'Appui au Initiatives Étudiantes, Student Initiatives Supporting Fund) gave me the budget to do it. The objective was to design and build a full RGB LED display. The total project budget (and cost) was CAN$7110. The original idea was to make a danceable surface (the project was then name the LEDFloor) but it quickly became obvious that it wasn't solid enough to carry even one person. I wasn't too disappointed by that, since I sincerly prefer using it a vertical display than a floor (which you won't see much when people get on it...)

In brief, I took 2 aluminium frames scavenged from portable stages risers and retrofitted the wood panel with a custom CNC-cut acrylic panel. The acrylic holds 72 PCBs, each with 16 RGB LEDs, for a total of 1152 RGB LEDs per panel with 8bit per color resolution, or 24bit per pixel. This means 16.7M colors per pixel and a screen resolution of 24x48 pixels.

The LEDs are driven by TI's TLC5947 LED driver chip. An Atmel NGW100 Network Gateway is interfaced with all the drivers thru SPI using the GPIOs. The AP7000 on the NGW100 runs a Linux Kernel with a custom kernel driver interfacing the sockets and the GPIOs. All the linux software and configuration was done by Benjamin Poirier.

I couldn't get access to a SMT Pick and Place machine or a Reflow Oven, so I soldered nearly 4000 SMT components by hand. Yes, by now I must have cancer from all these flux fumes (do not try this at home), but it was worth the effort. RGB PLCC6 LEDs are from China (eBay), LED Drivers from Texas Instruments (Mouser) and PCBs were manufactured by GoldPhoenix PCB (China).

First Tests

First Tests (myself and Benjamin)

First Tests

Finally all the lines are working

Under the hood

Under the hood

Public appearance

The Wizz Wall in action

Interfacing is pretty easy. The NGW100 has a LAN port from which you connect the LED display to a router or neetwork switch. It has a fixed IP address to which you send streams of RGB values for each pixels on the screen using UDP. Each LED panel then receives the frames to be displayed and simply pushes the values of RGB into the LED drivers using SPI as soon as it receives a complete frame. Stop sending frames and the panels will simply keep displaying the last valid frame received.

You cannot really see any flickering of the screen because the LED drivers are actually large shift registers that control PWM constant-current outputs for each color of each pixel. This makes the color even, no matter the variation between LEDs. The LED drivers are daisy-chained in lines of 48 pixels, or 6 drivers. This make a total of 24 SPI lines driven by GPIOs on the NGW100. A special shield PCB was made to buffer and convert the 3.3V GPIOs to the 5V working voltage of the LED drivers. All the LEDs and drivers are at 5V, which require 2 Meanwell power supplies of 5V 40A, for a total of 80A @ 5V for each panel.

The budget was granted in april 2009 and design and manufacturing started immediatly. After 3 revisions, I had my final version of the LED cells, the PCB on which the drivers and LEDs are soldered. Construction was slow in the beginning, because soldering 4000 components using solder paste, laser cutted stencils in kapton and a hot cooking plate proved to be quite tedious. I finally had all the PCBs assembled and tested by january 2010. I then used CAD software to create a 3D model of the whole mechanical assembly and exported the necessary files to cut the 6 4'x8' acrylic sheets with my good friend's AXYZ 4000 CNC (thanks to Phil & Robocut). Machining took 14 hours (not so bad when you watch Trailer Park Boys while the machine operates). I then assembled the panels in febuary 2010 and by march the thing was alive.

CAD Drawing

CAD software makes everything fit by the millimeter

The panels made their first appearence in a private party on march 5th 2010 with few glitches on the first and last SPI lines. This was caused by transmission reflexions on the clock lines. I used Schmitt-trigger buffers to isolate those lines from the system and the problem was solved.

There's 2 big mistakes I made during this project. The first was to even think about making it (seriously don't try this at home). The other was using CD4050 buffers as data lines buffers between PCBs. Even if the system works, they generate alot of delay and ring alot. Open-collector/drain buffers really are only for driving big loads like relays, motors, LED or such. Proper pull-ups on the CD4050 outputs would have helped, but I should have simply selected another IC like the 74HC245.

Quick montage of various iPhone clips of the Wizz Wall
© Charles Gervais-Dumont 2013