The speed of light Why is the WS2811/12/12B a poor choice for POV displays,

The speed of light
Why is the WS2811/12/12B a poor choice for POV displays, and why is the LPD8806 a good choice? It’s the speed of light:

WS281x
It takes 30 microseconds (millionths of a second) to transmit one pixel worth of data down a strip of WS2811, WS2812, or WS2812B. You can’t send it any faster than that because the pixels themselves operate at a fixed frequency.

This means that you can only transmit 33,333 pixels worth of data down a WS281x strip per second.

If your strip is 100 pixels long, you can update it a maximum of (33,333/100) = 333 times per second. And that assume your code does nothing but call show() over and over.

LPD8806
In contrast, it takes only 1.2 microseconds (millionths of a second) to transmit one pixel’s worth of data down a strip of LPD8806’s. That’s 833,333 pixels per second (versus the WS281x, at just 33,333).

That means that you can update a strip of 100 LPD8806 LEDs (833,333/100) = 8,333 times per second (maximum).

The LPD8806 is about twenty five times faster than the WS281x. Not twice as fast; more than twenty times as fast.

For POV displays, you need maximum refresh rates to get high resolution, high quality images, and the WS2821x’s just aren’t up to speed.

Any POV folks want to chime in here? @Ashley_M_Kirchner_No ?

Now if only they made 5050 LEDs with the LPD8806 controller inside them…

Unfortunately, with the release of the LPD1886, it seems that LPD is joining WS and TM on the 3-wire bandwagon :frowning:

Are you being metaphorical? Is there a reason 3-wire has to be 25 times slower than 4 wire? Is there some theoretic limit on the duration of the ‘bit.’

I’ve heard that some one is making a zero-wire protocol (modulating the voltage line to send the color info). Is that going to be even slower?

Higher speeds aren’t achievable over 3 wire setups?

Yah, that’s all right there.

I asked a few vendors and they all came with with the same answer: they don’t know anyone either working on, or capable of embedding the LPD8806. I’m not sure if that’s because the manufacturer doesn’t want to, or whether they don’t have the capability. I can’t find WHO makes them either.

And I have no problem with things going to 1-wire communications, as long as the speed doesn’t get affected. Unfortunately, the LPD1886 is only 16MHz with a 400Hz refresh (compared to 20MHz and 4KHz refresh on the 8806)

More reason to continue buying 8806 and hoarding them. :slight_smile:

It’s because of protocol differences. With SPI - you have a clock and a data line - basically, on the LED chip side, every time the clock line gets strobed, the data line gets read - so the question becomes one of how quickly can the led chip respond to a change in a line’s state. It also means that timing can slop around a bit (don’t have to disable interrupts on the MCU!). Also, because the clock/data dance is at the heart of SPI, we can use SPI hardware on the MCU’s out there to drive pushing the bits down the line.

The 3-wire protocols have some pretty tight timing requirements in order to differentiate between a 1-bit and a 0-bit. The fastest that I can do this an an 8Mhz avr would be 4 cycles per bit, (line hi; sbrc b, 0; line lo; line lo) - which would be 2Mbps - however time needs to be left for loading bytes and other such, which means, realistically, if you want the chips to be drivable by an 8Mhz cpu, you really don’t want to go much above 1Mbps.

Sure, a higher Mhz cpu could get a higher data rate, but I suspect the higher the clock rate gets, the more suspect the timing accuracy becomes.

This is what’s nice about the clock/data pairing. Sure, you have to worry about going too fast, but that’s about it.

This is why OctoWS2811/FadeCandy are pushing out data over 8 ws2811 lines in parallel - but even then, that’s “only” 6.5Mbps, to the LPD8806’s 20Mbps.

Now, if only one could push data out over 32 lines in parallel…

If only, indeed.

@Ashley_M_Kirchner_No the LPD1886 is 1.6Mhz - not 16Mhz - you’re slipped by an order of magnitiue

Transmission speed of 16Mhz according to datasheet: https://www.insomnialighting.com/datasheets/LPD1886.pdf

Doing the math on their timings - it is 800ns per pixel. The WS2812 is 1.25µs/pixels - so it’s actually more like 1.25Mbps at a recommend rate, vs the fastest speed of 650ns/pixel, which is closer to 1.6Mbps.

I think that line in the data sheet is a typo.

Also - if you run at their recommend 800ns per pixel, because each pixel is 36 bits of data, vs 24 bits of data - it’s still 28.8µs per pixel - which means it’s about the same data rate as the WS2812 (if you look at data rate as “number of pixels you can update/second” vs. “number of bits you can send/second”).

(Also - the datasheet identifies the dat/clk frequency as 1.25Mhz and the DATA tempo as 0.1-1.6Mhz - hmm, this might actually have more flexibility than the WS2812 - which could bode well for some abuse I have planned for the led chipsets…)

(FTR - I have a set of LPD1886 lights here, and a preliminary implementation, but it still needs testing).

Yeah, I’m reading Hz, not Mbps. The 8806 does the same thing, 20Mhz for transmission. Whether either one or both is a mistake would not surprise me as both are translated from Chinese, poorly at that.

The 8806 is a 20Mhz clock speed for data, since it’s 1 bit per clock cycle, that 20Mhz is also 20Mbps.

I think that line is a typo.

Even the PWM clock - it cycles through the PWM set at 400Hz, w/4096 levels per cycle, that’s also a 1.6Mhz clock.

Hmmm - i wonder if these data-line only chipsets are somehow tying the clock for parsing/processing data to the clock that’s used for running the PWM clock? If the circuitry for doing this is simpler than for handling reading a clock/data line, that may explain why chipset manufacturers are going this route.

I have an FPGA board here, I wonder if it’s time to start playing with that before chip manufacturers go beyond the 1.6Mhz clock.

Thinking of designing a FastLED FPGA or ASIC for the masses? :slight_smile:

We’ll see, though I may not need to. Not for a little while long, yet.

(I’d say “I’ve just made a deal that’ll keep the Empire out of here forever.” but, well, we all know how well that went :slight_smile:

ASIC would probably be overkill … but also opens up so-many-possibilities!

Perhaps posting your code might help us determine what’s going on? Please start a new thread also.

With the one wire, the components have to rely on the timing. For the WS281(1|2b?) I would imagine that relying on a clock/rising edge would be faster and more reliable.

The WS2811 flavor has a max speed of 800khz so thats ~ 30µs per pixel(1.25µs * 24) plus 50µs for a reset between frames. They are made to set and hold rather than to be continuously driven.

Any idea what speed the internal PWM on the 5050 pixels is?

Yes, a clock/data line pair, IMHO is easier to run faster and capable of being more reliable, at least in the environments we tend to play in.
(Randomly - USB doesn’t use clock data, instead it uses a non-return to zero line encoding - e.g. in a given clock cycle, a transition from hi to lo or lo to hi represents a 0 bit, while no transition represents a 1 bit - preceding data with an 8 or 32 ‘bit’ pattern of 0, the constant state changes being used to calibrate the clock).

@Colin_Harrington - you might want to take a look at what fade candy does (and FastLED will shortly be doing) - for dithering, with high enough update frequencies, you are effectively continuously changing the PWM value for the chip to give you the effect of fractional brightnesses. Or as mark and I like to say, PWM’ing the PWM :slight_smile:

As for internal PWM on the 5050 - it’s just 3 led components, red, blue, and green. It doesn’t have any internal PWM. This is why we have the WS2801, LPD8806, WS2811, et all.

The WS2812 is simply a 5050 with a WS2811 embedded in it (I took some macro shots of the WS2812 a while back, it’s nifty to see the chip embedded in there!). Presuming you’re asking about that, it has a 400Hz PWM cycle.