Electronic – USB Control of WS2801 LEDs

Here are two of many possible approaches to the problem, one using a microcontroller, one without. The microcontroller approach is simpler to implement, the second option is merely included for completeness.

At the outset:

• The physical layout (two concentric circles, et cetera) is irrelevant to the electronic design aspect, except when it comes to PCB layout
• The 12 Volt requirement is not clear, so assuming it simply specifies an available power supply voltage, not the required LED module driving voltage
• Assumption: The LEDs to be used can be driven by currents of up to 30 mA (not high-power LEDs)

Approach 1: Microcontroller based.

Select a multichannel, serially controlled LED driver IC, such as the AMS AS1119 144 channel LED driver ($4.90 each), and control it through any microcontroller that supports I2C (or, for other drivers, SPI) protocol. An Arduino is a good beginner's microcontroller development board for this purpose, while the TI MSP430 Launchpad is a cheaper ($4.30 including international shipping) but less well-supported such board.

The microcontroller will need to be programmed to send out serial commands to the LED Driver for the specific LED patterns and timings desired. An added advantage is that every individual LED can be set to a variable brightness level, using either externally supplied (from the microcontroller) or internal (within the driver IC) PWM signals.

Thus, your rings of LEDs could actually be designed to fade individually up to full brightness, if desired.

The "two rings" are not relevant here, simply treat them as 72 discrete LEDs, to be driven in a pattern of 0, 0+1, 0+1+2, .. 0+1+...+36 .. pause .. 0+1+...+37 .. 0+1+..+72.

If your requirement can be reduced to 32 x 2 = 64 LEDs, then an even cheaper and much more ubiquitously supported LED driver can be used, the Maxim MAX7219. Although this IC is marketed as an 8-digit numeric display driver, it can equally be used for 7-segment numeric LED displays of up to 8 digits, bar-graph displays, or 64 individual LEDs (from the datasheet).

Key advantages of using the MAX7219 are:

1. There are publicly available libraries for the MAX7219 for almost every common microcontroller platform, including the Arduino and the MSP430 Launchpad.
2. The IC is also available in a DIP package, in case you need to hand-solder or wire it up deadbug style.

Key advantage of using the AS1119 is:

1. The IC contains an integrated charge pump, for driving LEDs with forward voltage higher than the available supply, such as for blue or white LED strings.

The selected LED driver IC will need to be configured for the per-LED current desired. This is achieved either through serial commands or using a current setting resistor, depending on the driver chosen.

Approach 2: No microcontroller used

While this approach is not really worthwhile given today's inexpensive and easily programmed microcontroller development boards, this is how I built my first LED display very similar to what you describe, about 25 years ago. This is useful for those with microcontroller-phobia even today.

Select a bar/dot LED driver IC, such as the National LM3914 IC. Each of these supports 10 LEDs or segments, so you will need 8 of them for a 72-LED cascade.

The LM7914 is Expandable to Displays of 100 Steps, but becomes rather touchy in cascades of 8 or more (more than 70 LEDs), in practice.

The cascaded implementation schematic is provided in the datasheet. All you need now is a sawtooth voltage generator to feed into the cascaded arrangement. This can be built using 555 timer ICs and additional components.

There will be no option for brightness control of the LEDs, just a fixed current per LED again set using an external resistor on each LM3914 IC. Also, the blink pattern in the original question is not very simple to generate using this mechanism.

Is this approach advisable? Not at all, but it's been done, so no harm knowing about it.

Here is my interpretation of what I think is happening: -

The chips used in this product require clocked serial data and each chip has outputs that can feed more chips thus, you can create a large array of LEDs and each LED can be controlled individually. That seems to be the idea but, the general problem with controlling LEDs through an array of shift registers is that the guy writing the code to control the LEDs has to keep tabs on what the state of the LEDs are.

No easy feat and say, because of the size of the array a rogue clock occured, the "controller" (aka MCU) wouldn't necessarily be aware that the "system" is now out of sync. I'm half assuming that the chips are distributed through the product so that LED wiring is made simpler - this can aggrevate the problem if there is interference from some external source - I can envisage random LEDs turning on and maybe this is the problem.

The chip does not appear to be 100% adequately documented and of course there is no guarantee that adequate supply decoupling is used in the produce purchased so it's a bit of a lottery as to what is really happening but, given the "antenna"-like nature of the product and also the lack of adequate grounding throughout the strip of LEDs, external influences could have an effect.

Maybe the problem comes from a local wifi router or someone using a drill nearby; maybe someone using an electric arc welder or maybe just a faulty product.