The OctoWS2811

My first experiment in speeding up the LEDs is to use something called OctoWS2811 which is designed to let you drive 8 strips of LEDs in parallel. Theoretically, this would allow me to boost the speed of my antenna from the dismal 9 frames per second to a much more attractive 72 frames per second.

OctoWS2811 started out a library from PJRC for their Teensy 3.2 development board (an Arduino-type board based on a Cortex M4). The main thing you need to know about this library is that it uses direct memory access to drive eight output pins at the same time. You hook up those 8 output pins to eight separate LED strips and, boom!, you’re in business.

PJRC also makes an adapter board that looks like this:

The OctoWS2811 is a small board, about 55mm by 35mm. One end has two RJ-45 ethernet jacks. The rest of the board can be used to mount a Teensy 3.2 controller.
The OctoWS2811 is a small board, about 55mm by 35mm. One end has two RJ-45 ethernet jacks. The rest of the board can be used to mount a Teensy 3.2 controller.

The adapter board basically takes your eight output pins, level-shifts them from 3.3v to 5.0v, and pushes them through 100 ohm resistors. Then it wires them out to two RJ-45 jacks.

The idea is that you mount a Teensy 3.2 controller on that thing. Each RJ-45 jack then provides four twisted pairs (ground + data) which can be sent reliably over longish distances to the LED strips themselves (I found that 25 feet of CAT-6 worked fine).

I wish the adapter had sockets so you could just snap in the controller, but they weren’t too hard to solder on.

For my first test, I made 8 little strips of 8 WS2812b pixels. Here is what the whole thing looks like:

Teensy 3.2 mounted on an OctoWS2811 adapter, with two CAT-6 cables connecting it to a small dual RJ-45 breakout board, which is wired to 8 strips of 8 WS2812b LEDs.
Teensy 3.2 mounted on an OctoWS2811 adapter, with two CAT-6 cables connecting it to a small dual RJ-45 breakout board, which is wired to 8 strips of 8 WS2812b LEDs.

I ran this with the OctoWS2811 library without problems, even up to 1100 pixels per strip.

I also tried using the FastLED library driving the OctoWS2811 library; that worked fine too but was limited to about 680 pixels per strip, presumably due to memory usage.

There are more powerful Teensy boards available than the 3.2, and you might be tempted to use them in your LED projects:

Teensy 3.2Teensy 3.6Teensy 4.0
Speed72 MHx180 MHz600 MHz
Memory256K1M1M

Should you consider the 3.6 or the 4.0 instead of the 3.2? Maybe, if you are planning to do a ton of processing on the chip to prepare the visuals that you send to the LEDs and need the memory or speed for that. But the truth is that if you are driving WS2812s and want a reasonable frame rate, the Teensy 3.2 is powerful enough. If you hook it up to 8800 pixels (8 strips of 1100) it will use 86% of available memory, and those strips of 1100 pixels will only get a 30 Hz refresh rate due to the limitations of the protocol. So adding more memory or processing power is not going help you push more pixels. If you want to build something like Mark Lottor’s Hextron, with 213,840 pixels, you’ll need to use a lot of Teensy’s and figure out how to synchronize them.

Hexatron, by Mark Lottor, was a forest of 486, 20-foot tall LED light poles, each containing 440 LEDs.

Step one: performance!

Thanks for coming to my blog! I’m pretty sure you’re going to find this to be the most boring thing ever.

One of last years’ projects was a 46′ tall antenna “wayfinder” that we used to find our camp from miles away. Here’s what it looked like:

Last year’s camp, with antenna in the background. Click through for a YouTube video showing one of the animations.

It was awesome, but next year I want it to be even awesomer.

The antenna was an off-the-shelf military style field antenna, able to be set up by two soldiers in half an hour assuming that those two soldiers had eight friends and had previously spent an entire weekend in the backyard figuring out how to set it up.

We zip-tied LED strips to the antenna on four sides. Each side consisted of three 5-meter strips at a density of 30 pixels per meter, so there were 450 pixels on each side or 1800 pixels total. (Each pixel is 3 LEDs so I’m calling this 5400 LEDs).

It looked OK, but it wasn’t quite bright enough for my taste. Next year I want to double the number of pixels. And it wasn’t quite fast enough. The maximum frame rate I could get was 18Hz, and if I have to double the number of pixels, that would reduce the frame rate to 9Hz.

(The WS2812B protocol just uses a single wire for the data. You send it a high voltage followed by a low voltage; if the high voltage duration is longer, it’s interpreted as a 1 bit. That requires about 1.25μs per bit. With 8-bit color and three colors (RGB), you need 24 x 1.25μs, or 30μs per pixel, so a single update of my 1800 pixels took 54ms which meant I could get a maximum frame rate of 18fps. Not super fast. If I wanted to make a bouncing thing that bounced up and down the pole on one second intervals, it basically had to jump 25 pixels every frame, “ew David.”)

Thus, my first priority this year is figuring out how to make it faster.

I’m going to investigate two different approaches to making it faster, and blog about it as I go along. The first approach is switching to an APA102C-style LED. This chip can be sent data much, much more quickly at the cost of having an extra conductor for a clock, so you need four wires instead of three.

(Plot twist: the actual LED strips I used last year were WS2815s, a variant which also uses four wires. Instead of a clock, the extra wire is for redundancy and makes it so that if any single LED dies, the whole strip doesn’t die. That seemed important in the desert. In practice, I had two occasions where two pixels in a row died and killed the whole strip, and no occasions where one pixel died and was successfully routed-around. That thing in the desert does not want you to have an easy time. ALSO, another reason I liked the WS2815 is that it uses 12 volts instead of 5 volts, so the voltage doesn’t drop nearly as much over long runs. In short, the APA102C would solve one problem and create two more.)

The other approach is to stick with the WS2815 LEDs, but break up the whole antenna into shorter segments with maybe a few hundred pixels each, so that data can be crammed into each of the LED strips in parallel.

Here are some parts that I have on order as a part of this experiment.

I’m also keen to try Yves Bazin’s experiment. He’s using shift registers to drive 100 separate LED strips in parallel from a single ESP32 controller. My goal in life is to be as cool as Yves.

When these parts come in I’ll set up some experiments and write some reviews. In the meantime, if you have any suggestions or advice, I’d love to hear it; please email me because I am too old for social media.

What’s going on here?

Lately I’ve been working on pixel-addressable LED strips. Those are just strips of LEDs that can be individually controlled, usually with three little LEDs (red, green, and blue) for each pixel. They have a tiny integrated circuit for each one and you use something like an Arduino controller to sent them their color values and thus display cool artistic effects.

Basic pixel-addressable LEDs

The mass market just buys kinda ugly Christmas tree lights at the local hardware store which have been preprogrammed in a factory in China to do boring things with colors that seem logical to a programmer but look bright blue because most RGB colors, when chosen at random, look kinda blue. What I’m trying to do is build things that look unique and original.

This blog is not really intended for mass consumption. It’s not going to be very interesting unless you, too, are working on pixel-addressable LED strips and trying to get them to be fast and amazing!