The Pixel Matrix

Background
As my old Christmas Countdown reached the its 9th year (and 3rd revision/update), I decided to spice things up a little.  After seeing the new world of “pixels” on some of the Christmas light shows on TV the previous year, I started to investigate using them on a new Christmas countdown.

The pixels work by having 3 individually controlled LEDs inside of each housing; they are red, green, and blue (RGB).  With those three colors, you can make any color of the rainbow from black (all off), to white (all on), and anything in between (by varying the intensity of each color).  In case you are a bit confused, mixing light colors is not the same thing as mixing paint colors (example here).

This new form of controlling Christmas lighting is based off of stage lighting (and effects) for theater.  Stage lighting uses something called DMX512 which is a protocol for controlling 512 channels per “universe” of lighting. With pixels, we need three channels per pixel (one for each color), so we can control 170 pixels per universe (510 channels total; some pieces of hardware ignore the last 2 leftover channels, others use them).  Each pixel has the RGB LED, some resistors, and an IC that handles the protocol control of the LEDs.  When a frame of data is sent down the line of pixels, the first IC will take the top three instructions of information for its RGB LED, and rebroadcast the rest of the frame down the line.  This continues until the last pixel (which is left with nothing to rebroadcast).  In this way, you can individually control each LED, and they don’t need to have an understanding who they are in the chain, and who precedes/follows them.  For more pixels, you can use more universes; I am using 9 universes to control 4380 channels (1460 total pixels).   Since we will be needing a lot of channels, the community uses DMX E1.31 to bundle a bunch of universes together into Ethernet frames that can travel on a regular PC network.

The Design
With the general concepts worked out, I ended up deciding on using pixel strips (like these), but you can also buy strings that look more like traditional Christmas lights (like these).  Pixel strips are flexible PCBs that are very thin, about 14mm wide, and come in reels of 5m length.  I bought the WS2811 variety in 5V, which means that these lights run on 5VDC supplies (NOT 120VAC), and the IC that controls the LEDs are a WorldSemi WS2811 chip.  The strips (much like their pixel string cousins) can be cut to whatever pixel length you want.  After working some numbers and sizes, I decided to go with an 8ft wide matrix (just shy of 2.5m wide).  This meant that one reel of pixels would handle 2 horizontal lines on my matrix.  I ended up buying 10 reels to make a 73 pixel wide by 20 pixel tall matrix (1460 total pixels).

The pixels are spaced 30/m, so roughly 1 every 1.3 inches and the ones I bought come in a clear silicone sleeve to try to make them waterproof.  After cutting the pixel to my length, I had to solder new end-wires on the cut ends, and silicone glue end-caps on to seal up the cut end.  This was the most labor intensive portion of the matrix, and if I was to do this over again, I would buy straight from China and have them cut/soldered/glued to the desired length (and probably save money in the process in addition to time).

I then got a piece of Max-Metal 8ft wide by 30 inches tall from a sign store (thanks to Sign Central in Curtis Bay, MD for all the help).  This material is a thin sheet of High Density Polyethylene sandwiched between two very thin sheets of Aluminum; it is lightweight, sturdy, and waterproof (think roadside signs), and comes in at only 1/8in thick.  I then had 8ft long strips of 4mm thick PVC cut 20mm wide for me.  I glued this down to the Max-Metal using a pixel strip as a spacer.  Once all the spacers were glued down, I then glued the pixel strips to the Max-Metal between the PVC.  What this did was 1) allow for a little extra support on the pixel strips so they aren’t just hanging by the glue, and 2) give me the proper spacing so that I would have 1.3in. pixel spacing in the vertical as well as the horizontal.

I wired my strips up in a “zig-zag” pattern.  This means that the first strip (as you are looking at the front) goes from left to right, then the right-hand end of the strip is connected to the right-hand end of the second strip (which then goes from right to left).  This is considered one string of lights to the software, and comes in at 146 pixels long (two 73 count strips).  Then the third strip in the matrix starts over at the left, goes to the right, then the fourth strip goes right to left, and so it continues.  So in the end I am really controlling 10 strips that take up 20 horizontal lines.  Got it 🙂 ?  The wire I used from my controller to the ends of the strips is plain old 18-3 thermostat wire.  One wire is for ground, the other for power, and the third is for data (only used in 1/2 of my connections due to the zig-zagging).  It is cheap and readily available, the downside is that it is solid-core, so it can be a little stiff (as opposed to stranded).  I would maybe look into something stranded if I was to do it over again.

Power
There are a few comments I need to make about power.  Each RGB color will draw up to 20mA (at 5V) current; so if I wanted a particular pixel to be white and on as bright as it can be, it will draw 60mA.  Power can become a major concern when you are running 5V over 32 ft of wire (the down and back length of a zig-zag).  Due to ohms law, we know that v = i*r.  This means that the voltage drop across that length of wire is the amount of current multiplied by the resistance of the wire.  If I turn a whole 146 pixel strip white, it will draw 8.76A (146*60mA).  If I say the power trace is 18AWG, and there is 32 feet (which would account for there and back of power and ground lines), I would have a resistance of 0.204 ohms.  Plugging back into the original equation, I would see a voltage drop of V=8.76A*0.204ohm = 1.79V at the last pixel, meaning that instead of seeing 5V, it would see 3.21V.  Since these are constant current devices, it means that the LED is going to continue to only draw 60mA even though the voltage was cut by a third and you would end up with a pink LED instead of white (the colors drop out at different rates).

To counteract the pink-effect, I actually inject a voltage at the end of the “10” strips (which conveniently happens to be on the side where the beginning of the strips is getting its voltage and data lines due to zig-zagging).  By doing this, the furthest the voltage needs to go is 16ft round trip and the voltage drop is now 0.89V, which is much more manageable (and in my testing I see no pink LEDs).

One final point on power that you need to be aware of is the TOTAL power consumption.  Although the odds of me running the matrix so every pixel is white and on full blast is next to 0%, it should be noted that the current to run it will be 1460 pixels * 60mA = 87.6A.  Since we are running at 5V, the power needed will be p = i*v, so 87.6A*5V = 438W.  And since your DC power supplies are not 100% efficient and you want a little overhead, if you were going to run it at full white for any length of time, you would want a power supply rated derated at 80% and still be able to supply 438W (so >~550W).  I bought a 300W supply and need to keep that in mind (though a quick test of all the pixels on white and full blast at the same time worked fine for a few minutes).

Controlling the Matrix
Controlling the matrix is a WHOLE other arena.  There are lots of great free and open source software (FOSS) out there that some great people are working on to synchronize your lights to music, run matrices, run mega-trees, custom displays, arches, house outlines, projectors, props, etc.  Since I am not interested in syncing to some greater display (this is standalone), I come at this from a slightly different angle than most.

I ended up going with Sandevice’s e682 as my “controller” and a Raspberry Pi as my “scheduler/PC.”  The e682 takes Ethernet frames of controller data and converts it to what the pixel ICs want to see (including timing and voltages for data lines).  This particular controller can handle 4 banks of 4 outputs each and can controller over 2000 pixels total.  I will be using 10 of the 16 outputs, so I will have some room to grow the matrix in the future or add another prop to it.

The Raspberry Pi is basically a small computer that can run Linux and costs $35.  If you pick this up and then you can get the Falcon Pi Player (FPP) software to run on.  FPP is a variant of NOOBs linux that runs on the PI and is built particularly for controlling Christmas light shows.  This software is great, free, and always being updated to fix things, add features, or make enhancements.  This is what will be running all the time and sending the Ethernet frames that have the DMX512 data to my e682.

To create things like images, fireworks, videos, spirals, pretty much anything you can imagine, I use another piece of free software called xLights/Nutcracker (xL/NC).  It is really two pieces of software that is merged together, but NC is the piece that can take your models (a matrix, a megaTree, leaping arches, etc.), and you can color, animate, and add effects to them.  You do all of this ahead of time, and then create a sequencing file that can be read by the scheduler on the FPP.

What I have done is created a script that counts down to Christmas based on the current time listed on the Pi.  I countdown scrolling the values across the matrix by using the memory map feature the FPP guys have baked in (where you can access pixels directly by just sending across some values, or print text and let the FPP do all the heaving lifting.  I basically play a “show” of effects created from NC non-stop, but override it with the countdown most of the time.  So in-between Countdowns, the effects can be seen on the matrix to make it more interesting.

The power supply, Pi, and e682, all sit in a Cable Guard CG-1500 box that I attached to the back of my matrix.  It is water-tight and allows accessibility if I need to get to things to troubleshoot or fix something.

Lessons Learned
There are a couple of things I would do different if I was starting over:

1 – As mentioned previously, the thermostat wire I used to connect the pixels to the e682 was a bit of a pain to deal with. Solid core is very stiff and only gets stiffer in the cold. If I was doing that over, I would probably try to find something stranded (I’ve heard of people using security wire, but I haven’t checked it out yet).

2 – The size of the countdown (8ft x 2ft) was setup to mimic my old incandescent countdown and does a nice job scrolling the Christmas countdown. My issue with it is that it isn’t good for images or other animations. I think it is best to try to hit a 16:9 or 4:3 ratio to keep with normal TV sizes. I will probably be adding ~6 more strips to the bottom of the matrix to help with that. Then to get a 16:9 ratio, I would use all 26 pixels up/down, and utilize 46 of the left/right pixels for simple animations and pictures.