Feb 6

Feb 6 Programmable LED Controller - Part 1: Concept and Requirements

A requirement during the final year in the Electrical Engineering program that UNLV is that every student must take part in the Senior Design Competition. Students can work on projects that are of their own design or work on research that is relevant to a professor or industry sponsor. For my project I decided to build a product that I was asked for at Sin City Scenic but couldn’t find available on the market, a programmable LED controller that could display custom animations.

The marketplace is awash with cheap LED controllers so it is a busy area to work on, but I have yet to find a product that is easily customizable without expensive equipment. Up to this point the options I’ve come across are either cheap, basic controllers that aren’t programmable or DMX decoders that are, in theory, infinitely customizable but require input from a lighting console. At Sin City Scenic I’m often asked for simple LED projects where the customer wants a custom chase sequence (using only their company colors for instance) and for whatever reason DMX control isn’t a reasonable option. I figured what better product to make than one that I have already tried and failed to purchase.

There are some programmable LED controllers out there, but of the few I have found they have some common flaws that prevent them from from being the solution I’m looking for. Usually these controllers are focused only on WS2812 style pixel control LEDs. I imagine this makes them much cheaper and easier to manufacture because this style of LED strip uses an external power supply and doesn’t require the PCB to have thick copper pours or solid power planes. From my perspective though, this prevents them from working on the cheapest and most common LEDs available. The programming software that I’ve found for them also often has a terrible user interface and is painful to use. I am no professional user experience designer, but I believe that instead of trying to reinvent the wheel, if I look to what works in existing and popular editing software like Logic and Final Cut Pro that programming the lights using a timeline view will be a straightforward and intuitive experience.

Early on I decided that I would use a ARM Cortex microcontroller because not only will they handle the primary task, but the large toolset that they make available will allow for an array of value added features. They may not be the first thing that a customer notices, but they will improve the overall experience. Even mid-range chips in the line have a lot of memory and they also have convenient peripherals to communicate rapidly with an EEPROM so I decided that I would store the sequence onboard with no removable memory. This eliminated the need for the SD card that is pretty standard on other programmable controllers. The most common designs I’ve seen have the SD card sticking out of the controller making it more prone to both loss and damage. The space required to fit the SD slot also increases the overall size of the device as well. Instead, on my controller sequences will be sent directly over USB which most Cortex chips have a built in peripheral for. ARM chips also run much faster than many other microcontrollers available enabling the controller to run at higher PWM frequencies with more bits of resolution. This will allow the customer to use 10-bit color space with smooth fades between colors at a PWM frequency that is fast enough for video cameras.

To help me bring my rough idea down to something that was more concrete and could be broken down into functional areas I drew a flowchart showing how power would come into and out of the controller. This helped me to focus on exactly what the specific needs of each segment of the project were and allowed me to begin roughly looking at parts just to make sure that what I wanted actually existed. This caused me to change a few parts, but also surprised me with the capabilities of affordable components. For instance, I found out that there were relatively cheap MOSFETs that could handle the elevated gate-source voltages that I would require when I was sure that I would need some kind of Darlington array type trickery to drive 24V devices wish a reasonable safety buffer. With a set of loose plans and a better idea of what parts were available I was able to come up with some project requirements:

4 channels of control to allow for RGBW LEDs.
5V-24V input voltage for LEDs that will also power the microcontroller and other logic.
Maximum current of 5A per channel.
Multiple chases stored onboard and selectable by the user in the field.
Controller must be able to operate with no USB connected.
PWM frequency must be at least 2kHz.
PWM resolution must be at least 10-bit.

I also started off with some stretch goals that would be nice to add to an already working minimum viable product:

Selectable PWM frequency, either per sequence or globally set.
12-bit or greater PWM resolution.
Support for WS2812 style pixel controlled LEDs.
A bluetooth option for user control.

With these requirements and additional goals in mind I started off on the year long task of bringing the LED controller from idea to competition entry.