WS2811 on Teensy 3.0 using FastSPI_LED library

Not open for further replies.
I just found this thread and it got me very excited! My project is a pair of LED staffs that should also be able to do POV, so fast refresh is required. When I initially researched what LED strip to get, I was still using only Arduinos at 16MHz and I read that the timing wouldn't be accurate enough for the WS2811 strips. So I went with a WS2801 + FastSPI which works great, but as I don't have that much space on the staff I now only get 8 pixels per side (3 strands of 8 separated by 120 degrees to make it visible from every direction). Having double that density would be much prettier of course. I now have a Teensy 3.0, and reading the above makes me confident I should be able to drive a WS2811 strip, so I'm going to try for that.

I also would like to be able to drive an SD reader (the one from PJRC) *and* a WS2811 strip at the same time, somehow. Would it be an idea to have an SD adapter that connects to I2C, instead? Okay, that is for another thread.

Also for another thread I suppose is whether I would be okay with about 1200mAh for driving 96 (3 x 16 x 2) WS2811 driven LEDs + a Teensy 3? I wouldn't be running this at full power, and I really only need about 2 hours worth of charge.
The WS2811 takes 30 microseconds per LED. Nothing can change that, because it's the fundamental timing of the WS2811 protocol.

You can connect all 3 strands of 8 LEDs to the same pin, so they always update together. It will always take 240 us, which should be plenty fast enough for human persistence of vision.

The DMA-based approach, when/if it exists, will update 8 strips simultaneously. You could run a wire to each pixel, thereby having 8 strips of 1 LEDs (3 connected in parallel on each pin). That would update in only 30 us. Nothing can change the fact that WS2811 takes 30 us/led, but updating 8 simultaneously cuts the time to one eighth.
That is a great idea. I wonder if I can already do this with the strands of 2801s that I have now, which are basically wired in one long strip, with some logic in the code to make groups of 3 LEDs around the staff appear as one pixel. But your method is much more efficient of course.

So actually I have 16 pixels now for the whole staff, so it would be 6 strands in total, 3 on each side. The thing is that I want to reduce wiring as much as possible, so having everything in one long bus is ideal, but doing this in parallel will actually not add more wiring, AIUI.
I feel almost silly for not having thought of this before. Do you think it's possible with the WS2801, so I can try rewiring this already? So with the WS2811, I would end up with 16 pixels per side, 32 for the whole staff. That's a huge improvement in resolution for POV.

And how do you reckon the speed of the WS2811 compares to the WS2801?

As for DMA and running a wire to every pixel, that is out of the question for this project, as I don't have the space and weight allowance to do so. They LEDs must remain in serial, or have these parallel strands, but still addressed in serial.

Thanks, this is a very helpful thing you suggested, if I understand it correctly.
Last edited:
The WS2811 takes 30 microseconds per LED.

Just to confirm my math is okay here. So for 32 pixels on my staff I'd be looking at a total update time of 960 microseconds, so that would translate to about 1000 fps for the whole strip, correct? That's still really fast, and plenty fast enough for POV indeed.

I just ordered a WS2811 strip, here:

They also have non waterproof ones, these are the ones with simple IP65 casing that is easy to take off. The non waterproof ones are slightly cheaper.
I have some exciting news to share. The last couple days I've been fiddling with using 3 DMA channels to synthesize the WS2811 waveform.


In this test, the top waveform is 800 kHz 20% (WS2811's low bits) and the middle is 800 kHz 48% (WS2811's high bits). The bottom waveform is generated by 3 DMA channels, triggered from the edges of the top 2 waveforms.

Each DMA channel writes a single byte (0xFF) to the register that toggles 8 pins. As you can see, there is considerable latency from each DMA trigger event to the actual update. Fortunately, it's very consistent. I've been reading the datasheet over and over the last couple days... upon each request, the DMA controller takes several cycles to transfer the 32 byte transfer parameters from a small register file into the actual DMA engine. They optimized it to move data at incredible speed (96 MHz = 192 Mbyte/sec memory-to-memory using bursts of 32 bit bus cycles), so this application where a single 8 bit data move happens on each transfer is obviously not well optimized, but it is working nicely.

The scope is set to 5 seconds of persistence. The main thing I'm investigating now is the variance of the DMA response latency. During these tests, I have a loop() function sending strings with Serial.print() as fast as the USB will go. The USB has its own DMA controller to send the packets, and of course the CPU does a memory to memory copy, both of which compete for bus arbitration with the DMA synthesizing the waveform.

Here's a zoomed in view that really shows the latency variation, which becomes jitter on the WS2811 waveforms.


The waveform only changes at most 42 ns, which is exactly 4 cycles of the 96 MHz clock. Luckily, the errors do not accumulate... each of the 3 transitions has a jitter of 0 to +42 ns. The WS2811 datasheet says the timing specs are +/- 75 ns, so this seems to be very good news for the feasibility of synthesizing correct WS2811 waveforms while the CPU and USB are active doing other work.

One caveat is the DMA is only accessing the lower half of memory. My first test versions will target supporting about 1000 LEDs, and I believe it'll be possible to expand to about 2000, maybe 2500 LEDs. I do not believe it will be feasible to locate any portion of the LED frame buffer in the upper half of memory, where the CPU core ties the bus up for many cycles when entering and leaving interrupt routines. We'll have to wait for Teensy++ 3.0 later this year to support more LEDs.
Last edited:
Me too!
I ordered 4 strips + 4 lots of the individual LEDs w/ WS2811. I must say the process was pretty painless (so far). Paid last Friday and FedEx says they'll be here this Friday (same distributor/manufacturer Paul (and others) have used).
Thanks for your continued work on this, Paul!!
OK... I'm going to order 20 meters of the 68LED/meter GE68RGB2811C strips from Gree-LED.
I'll let you know how it goes.

UPDATE: I Received the Lightstrips fromGreeLED.... Here's a timeline with details of my order for 20m of WS2811 Light strips from Gree-LED

Jan 22, 3:30PM -Emailed to inquire about price and availability of 4 x 5m spools (20m) of GE68RGB2811C + shipping to USA
I also inquired about payment options including: Bank Transfer, Western Union, Credit Card, PayPal.
Jan 22, 7:45PM -Britney responded, The unit price is $14.50/m + $36.90 for shipping. Total: $326.90.
Currently only payment options were Bank Transfer or Western Union. She said that they were working on a PayPal option.
Jan 22, 9:20PM -Setup Western union account online, then setup payment to Gree-LED choose the WUPay option which has a $10.00 service fee.
Jan 22, 9:30PM -Setup BillPay account at my bank online, and chose WUpay as one of the payees, Then sent a payment WuPay for $336.90.

Jan 23, 9:30PM -Received an email notice from WuPay that the funds had been received from my Bank
Jan 23, 11:24PM -Received an email notice from WuPay that the funds were available to GreeLED.
Jan 23, 11:03PM -Britney emailed me that they had received the funds
Jan 23, 11:39PM -Received an email notice from WuPay that the funds were picked up by GreeLED

Jan 24, 10:42PM -Britney emailed me with a DHL Tracking Number.

Jan 25, 10:47PM -Picked up by DHL in Hong Kong.
Jan 26, 5:41AM -Departed HongKong
Jan 27, 9:47PM -Arrived Cincinnati
Jan 27, 8:24PM -Departed Cincinnati
Jan 28, 7:20AM -Arrived Philadelphia
Jan 28, 10:30AM -Delivery attempted - recipient not home
Jan 29, 1:08AM -Delivered - Signed for by : SIG ON FILE

Please note I was pretty nervous about using this payment method.
While it worked well for me, I'm not endorsing GreeLED, or Western Union. or saying it will work for you.
Last edited:
I'm leaning towards "Octo" something, maybe OctoWS2811, or Octo2811, or OctoLedStrip.....

I'm also looking for maybe 2 or 3 good beta testers. There's 3 requirements:

1: actually own 8 WS2811 LED strips & a Teensy 3.0
2: must have time to beta test, write about the results, and take a photo or video
3: keep the code & info confidential until official release (about 1-2 weeks)

If you're interested in beta testing, please email me directly,
Aliexpress won't take my payments anymore, and they appear very slow / difficult to communicate with about getting my card verified. They want copies of my ID and card statements. Not sure I trust them. Anyone know another place to get WS2811 strips from at a decent price?

Edit: the seller is okay with me using Paypal instead. So if you have trouble as well, ask them for that. They are officially not allowed to do this, by Aliexpress, and they don't get as much discount on the courier charge, but if you're in a hurry...
Last edited:
Just as a warning/advice to new people buying the WS2811s...

Please be aware that the strips get 'extremely warm', especially if you run them at full brightness. Since the control IC + LED + resistors are all in the same package, heat dissipation is kind of restricted and the strip can get quite warm/hot. Be mindful of this for your applications especially if you're putting them in an sealed enclosure.
Madox that is good to know. I'm working on a LED toy that will feature these. Currently I have 2801s in it, but I try not to run them anywhere near full brightness as I only have 1200mAh to burn. I'll have 96 LEDs, 48 on each side. I do have them sit on an aluminium rod in the middle, so that should help with the heat dissipation. However I will have to build an enclosure around these to have the toy be weather proof. Plus it looks much better with some opaque shielding, I find. Less blinding, too.
Last edited:
Hi everyone,

stepped into this coming from Arduino and driving a ws2811 strip. I Just ordered a Teensy 3.0 to get some more calculation power for realtime matrix content.
Now that I have read a bit further I am wondering whether I need a level shifter to drive Din on the LED strip or not. Does the ws2811 also work with 3.3V logic level?
The WS2811 strips I'm currently using are being driven directly from the Teensy3.0 Pin6 without the need for a level shifter.
I am however using an external 5V power supply with the ground tied to the teensy.
The WS2811 strips I'm currently using are being driven directly from the Teensy3.0 Pin6 without the need for a level shifter.
I am however using an external 5V power supply with the ground tied to the teensy.

Thanks for the prompt response Woozy! I will also have a seperate power source for the strip and the Teensy, so I suppose it should be fine here too.
I'm confused now. It says: "64pcs 5050 RGB LED With 60pcs WS28IC inside to drive 64 pixels".

So how can it have 64 LEDs whilst there are only 60 controllers, per meter?

On the surface, it does look a bit different from what I ordered:

Can anyone shed some light on this?

Just read the title. It says 64 w/ 64 inside. Not sure how different it is from the 60 per meter, but my guess is they are almost the same.
I'm really new to serial ports and USB CDC so I'm still kind of feeling my way around here...

I'm interested in reproducing the work of Madox.
He says he sends the data over USB.

Can I just check whether Serial.available() > 0 to see if there's another byte, similar to Arduino?
When I do that, does it see the serial device as USB CDC?

Or do I need to use the more complex code from the examples here:
If I need to use the more complex code from the examples here, why is that?
Is THIS how you create a USB CDC device and the Arduino Serial code does something different on Teensy?
Or does that equivalent Arduino code even work here?

The benchmarks on this page seem to say that the Teensy 2.0 can handle 901 kbytes/sec.
How much can the Teensy 3.0 handle?
There is no benchmark on this usb serial page for the Teensy 3.0.
The Makefile seems to not even contain a version for the Teesny 3.0.
My concern there is that if I need the USB Serial code to create a USB CDC device, and there is no Teensy 3.0 specific example, how can I do it?

If I'm able to do this using either method, can I use something like pySerial to send the data to the Teensy 3.0?
If so, is there a max baud rate I can set it to? Am I restricted to 115200 or can I set it higher?
Last edited:
not sure if this is relevant but i have
(2) 5 meter rolls of 36 led/m and 36 (ws2801) Ic 36/m at 5v per reel.

Using a teensy 2.0 and can run various light patterns. color changing, sold color, light beam. without many problems except that when both 5 meter rolls are connected the teensy is a little low on the power side. I have the teensy 3.0 i just haven't had time to hook it up with them.
Not open for further replies.