How many WS2812b's can a Propeller drive?

emiljt

I'm sorry if this has already been asked (I tried looking first).

I'm curious how many ws2812b's a Propeller cog can drive at a decent frame rate (say 30fps)? I found an article talking about a 16Mhz Arduino running 1,000+ at 30fps, but I'm brand new to the Prop, so I'm just guessing when I assume one cog could handle this as well. How many of these have you guys driven with a Prop and what did you use to do it (PASM, C, Spin, one of the library drivers)?

bobjr

I believe the final answer will depend on how you are generating the data to be displayed, and how many pins you can use for transmission.

Some quick math:

Each pixel/led takes 24 bits of data.
Each bit of data takes 1.25µs (That isn't a propeller limitation, it is required by the ws2812b)
So it takes 30µs / pixel / frame.
If you want 30 fps, then you have approximately 33333µs to send data, so you can control ~1100 LEDs on a single line, just like the arduinos that you mentioned.

However, all of that is assuming you only are using 1 output line. If you have 2 data busses, you could get double that, etc. A single cog, with code written in assembly, could probably control 4 lines fairly easily, though I will admit that I don't have any example code to back that up.

The bigger issue is how you are generating this data. If it is a simple pattern that you can generate on the fly, then you could probably get all 8 cogs running, each controlling 4 output lines. If you need to generate the data in a second helper cog, then the limitation will be more based on how you transfer and store the data. I can give more insight here if you give more details on what your end goal is.

MJB

IF you just have a look at the datasheet it gives
800kHz bitrate
24 bit/pix
30 f/sec
==> just above 1000 on one pin

at 80MHz => 100 Clocks/bit = 25 instruction / bit - easily sufficient to send in PASM
but you could as easily handle byte/word/long reads from memory and parallel output
on 8/16/24/32 pins with 1000 LEDs each

so the question is more where to get the data from
RAM = 32kB
so 1000 pix * 24 bit => 3kB
so RAM should be good for 10 000 pixels for picture frame buffer

how do you update it?

you want to play video? from SD?
there e.g Tachyon gives sustained read rates at around 250kB/s (old version 2.7 I think)
thats almost 3000 pixels/second at 30fps

I haven't used that many, but your question made me curious
so I just ran some numbers ...
I only used Tachyon on a few hundred LEDs to play with

Interrested to hear from people who actually implemented it how many they can drive

EDIT: @bobjr hey bob - didn't see your message ...

KeithE

Just food for thought - some devices such as FadeCandy (https://www.adafruit.com/product/1689) keep the number of LEDs per line quite low (64) so that they can do very fast dithering. So even if the final animation runs at say 30 FPS there's dithering happening much faster than that.

jmg

KeithE wrote: »

Just food for thought - some devices such as FadeCandy (https://www.adafruit.com/product/1689) keep the number of LEDs per line quite low (64) so that they can do very fast dithering. So even if the final animation runs at say 30 FPS there's dithering happening much faster than that.

With a 24b Data to the LED, why do they need dithering ?

Keith Young

Also keep in mind these things draw a lot of power.

KeithE

Here's their explanation:

"Fadecandy's temporal dithering algorithm can create super-smooth fades and nuanced colors at a remarkably wide range of brightness levels. The controller hardware updates every LED about 400 times per second to rapidly oscillate between nearby brightness levels for each color primary, gaining some additional brightness precision. This precision gets even higher when averaging over time or space, meaning that larger or more diffuse sculptures achieve even higher levels of precision in low-brightness colors. In addition to this dithering algorithm, the Fadecandy firmware's 48-bit color processing pipeline includes gamma correction, white balance, brightness control, and keyframe interpolation."

I know when I played with some APA parts and used the HSV colorspace the fades were a bit lacking. Especially if you allow for some form of global brightness control. Think very subtle fades where you don't want people to see the steps. FastLED also has the capability to do some temporal dithering.

jmg

KeithE wrote: »

Here's their explanation:

"Fadecandy's temporal dithering algorithm can create super-smooth fades and nuanced colors at a remarkably wide range of brightness levels. The controller hardware updates every LED about 400 times per second to rapidly oscillate between nearby brightness levels for each color primary, gaining some additional brightness precision. This precision gets even higher when averaging over time or space, meaning that larger or more diffuse sculptures achieve even higher levels of precision in low-brightness colors. In addition to this dithering algorithm, the Fadecandy firmware's 48-bit color processing pipeline includes gamma correction, white balance, brightness control, and keyframe interpolation."

I know when I played with some APA parts and used the HSV colorspace the fades were a bit lacking. Especially if you allow for some form of global brightness control. Think very subtle fades where you don't want people to see the steps. FastLED also has the capability to do some temporal dithering.

Interesting, maybe that 'remarkably wide range of brightness levels' is the key here, meaning 8 linear bits per colour are not enough.

Does that mean we will see 3 x 12b LED strings next ?

Tubular

I wrote a pasm driver that'll drive 4 strips from 1 cog. It reads Led data from hub ram so potentially 10,000 leds or so - since each can be as long as you like

I think more practically, a 7 cog, 28 driving pin * ~1000 leds long would be the way to go and simplify wiring.

The data is packed 4 leds to 3 longs, so I used spin to do the heavy lifting on the writing side

You could do temporal dithering on the data in the hub ram using another cog.

Tubular

I looked it up, its actually 5 strips per cog using a 6.25MHz xtal.

Let me tidy it up a bit and post tonight

MJB

Keith Young wrote: »

Also keep in mind these things draw a lot of power.

you can feed in power everywhere,
does not need to run through all the 1000s of LEDs
it is just the data line, that is cascaded

and yes - draws a lot of power

Tubular

Here's some demo code from a recent project.

In it, the planets (each representeed by a led color) chase along a big arc led strip representing the ecliptic.

I'll tidy the driver bit of this up at some point, and stick it in the obex

Publison

Tubular wrote: »

Here's some demo code from a recent project.

In it, the planets (each representeed by a led color) chase along a big arc led strip representing the ecliptic.

I'll tidy the driver bit of this up at some point, and stick it in the obex

Sounds pretty cool. Do you have a video of it in action?

Don M

Is this a trick question? A Propeller can't drive... but it can thrust!

emiljt

Sorry for the late response. Thanks for all the reply's/examples/etc. The Prop has once again proven how cool it is. For the application I plan to make, it wont need thousands of LED's, but it would be nice if just one cog could do all the work so that the other seven are free. Unfortunately power is what will limit my LED usage.

What got my thinking about this though was a new Space Invaders game I saw at an arcade. I'm not really into arcade games, but the screen on this was AMAZING to see in person. When I took a closer look, they seemed very similar to the ws2812 (if not the ws2812). rawthrills.com/games/space-invaders-frenzy/

KeithE

That's a lot of LEDs. Does anyone have much experience with this type of setup? With the typical RGB LED strips you can potentially have one LED chip fail and take out all of the following LEDs. I experienced this personally with an expensive high-density APA102 based strip.

I think that the WS2813 is supposed to work similarly to a WS2812 but allow a single LED to fail and not disrupt the remainder of the strip. "Dual-signal wires version, signal break-point continuous transmission."

http://www.szledcolor.com/download/WS2813 LED.pdf

Tubular

Yeah they certainly fail and I've replaced quite a few. Part of the trouble is they're quite heat sensitive, and its hard to tell whether the extinguished led has failed, or its neighbor, so quite often end up replacing 2 or more. The ws2813 and similar look like good solutions

These days first thing I often do is stick the strip down to Aluminum strip, eg 10x3mm. Then you have a 'cane' that keeps things working as they're used for various projects. Its still possible to bend the cane if required.

Kednerpo

I'm not sure if the attached driver will meet the 30fps you need but it will let you set up multiple strips on multiple pins and automatically refreshes them.

I have been using Adafruits OctoWS2811 Adapter to send data to multiple strips via cat 6. I power the strip from a power supply closer to the strip location.

https://www.adafruit.com/product/1779

Kednerpo

Here is a setup I'm using with a couple OctoWs2811. I'm only using 4 strips and around 600 Leds right now.