Blinkdom Preparing to Visit the SA Mini Maker Faire 2016

Planning a Trip

Blinkdom is an ongoing project that we take time to update any chance we get. Our excuse to tinker this time is for the San Antonio Mini Maker Faire, Mar 26, 2016 11am-4pm at the SA Public Library. Please come say hello and help remind us to keep going.

Out-of-sync

Because our assembly of software, hardware and electronics is unique we’ve faced some interesting challenges while getting everything to talk. One of the persisting issues we’ve struggled with is the communication from the PixelController software to the PixelPusher hardware. The first 400 RGBLEDs work great but as soon as it crosses to pixel 401 the pixel order gets lost and the 401-600 pixels (the 3rd panel) aren’t in sync.

Why? We wired Blinkdom with 50 pixel strands. Each strand connects to a port on the PixelPusher (PP), that has 8 ports for a maximum of 400 pixels in this setup. Pixel #401 is on the first strand PixelPusher #2. PixelController sends data over the network using ArtNet or E1.31 protocols, both based on DMX512, an aging lighting control system used in entertainment, theater, and architecture. PixelController is sending network data that is actually being intercepted by another piece of software, the ArtNet Bridge, and converted to the PixelPusher protocol. The problem we see is happening in that translation. Complicated, right?

Software Fix

Our first tactic was to alter the PixelController settings to output data that would get translated correctly. After switching between ArtNet and E1.31, defining snake-cabled panels of 100 pixels per Universe, a monolithic 48x25 panel, and a number of other permutations, we got the answer… NO, there are not settings to make it work as is. The real software answer is to write a custom PixelController output interface to talk directly to PixelPusher. Both are in Java, but we don’t do Java. (We did easily talk to a PixelPusher in JavaScript.)

Hardware Fix

Our second tactic is a long standing tradition of throwing hardware at it (ala “Programmers are expensive, hardware is cheap”). Since we couldn’t find anyone running multiple PixelPushers with ArtNet Bridge for advice, we needed to remove the second PP from our setup. This is all related to another software tradition, laziness, which got us in the position initially.

The truth is that PixelPusher supports 240 LEDs per port due to the efficiency of their protocol. We only run 50 pixels because that is the easiest strand we could source, we designed around its dimensions, and if you add more LEDs you need to “inject power”. Injecting power means running dedicated power cabling from the power supply to LED strand every so many LEDs. This prevents LEDS farther from the power supply not getting enough power and appearing dimmer, flickering, or dark. But it means cabling, soldering, stripping wires, attaching connectors, testing connections… physical work.

Fine. Re-wiring is faster and easier than learning Java. So we fixed the hardware after we wrote a test script in Javascript to light up each pixel in order to make sure we wire it up correctly.

All Fixed

Fast Forward 8 hrs… Re-wiring done. Strand tests pass. PixelController re-configured for a 24x25 panel over E1.31.

SUCCESS.

Here’s a snapshot of “Preset 132” proving the 600 LEDs are behaving correctly. (Don’t forget those aren’t tiny pixels. They’re the 3in bottom of water bottles. Three panels are wider than your wingspan.)

If you were following our math, we originally planned Blinkdom to be 1200 pixels/6 panels on three PixelPushers. By soldering the strands in a panel together, we now upgrade to 1600 pixels/8 panels on a single PixelPusher.

More and better!