OK my turn to ask (again) for help.

OK my turn to ask (again) for help.

Daniel you’ll be happy to learn that I have started my latest project using a Teensy3.1 with OCTOWS2811 adaptor. No more MEGA’s or UNO’s driving multiple pins … YEAH!!

So I have a very basic setup going with just a few ws2812b (for now) and I was doing some benchmark tests between the OCTOWS2811 library by itself and FastLED driving the OCTOWS2811.

I specified 512 LEDs on 8 pins and found that the OCTOWS2811 library goes about 500 FPS while FastLED only goes to about 400 FPS although the documentation claims FastLED to be faster.
Are you limiting the FPS to 400 somehow?
I understand that may be a more practical limit with the ws2812b.

Yes, you don’t want to drive WS2812’s faster than 400fps, and so that’s what the library caps at by default - you can override this with setMaxRefreshRate - http://fastled.io/docs/3.1/class_c_fast_l_e_d.html#a09f4d61853d88482fa5824144c8127ed

(The reason being, unlike the APA102’s where you can blast data as fast as the chip will take it, without screwing things up (even hitting refresh rates much higher than 20khz), the WS2811/12’s like to glitch out when you go above 400Hz)

Ahhh… excellent !

Thought so but could not find that info in the library code by myself.

Just tried it and got it to go to ~ 500FPS

I will play with that for a while to see for myself the effect of pumping data faster than the chip’s own pwm rate… just curious I guess…

Thanks again!

Also, if you do the math, you’ll see 500fps is the limit for 64 ws2812 leds - 64 leds at 30us per led is 2ms per frame which is 500fps :slight_smile:

Also, the ws2812 misbehavior at > 400hz is not constant. It seems to depend on a combination of the chip state and previous led data, never seemed worth it to actually quantify.

(if you want > 400hz, use apa102)

@Daniel_Garcia Got it.

I guess the ws2811/ws2812 get their 400hz timing with a crude internal oscillator that is likely to vary significantly (+/- 10% ??) from device to device in the 1st place.

Still… I will try to qualify and quantify that if I don’t get bored quick with the issue.

Finally appropriate and decent hardware. Good! :slight_smile:
From my perspective as a fps-junkie: for the very most installations 400 fps is enough. Enough in the meaning of you (okay: I) feel no difference anymore compared to more fps. Exceptions might be extreme fast light to sound animations. But beside this practical observation of course I understand the scientific interest in what’s possible. Just my 2ct.

So - other than POV (In which case, seriously, get APA102), the one big advantage to ultra high frame rate is the dithering support and the extra bits of dynamic range (and one thing that I’m hoping @Mark_Kriegsman and I can get spec’d out and start working on, the next time he and I are in the same room together, is moving to 16 bit color from 8 bit color, which, with ultra-high frame rates+dithering we can likely support, even on the 8-bit color led chipsets :).

(Also, I use ultra high frame rates to make, oddly enough, very very very slow moving patterns - the very high frame rates allow me to make my frame to frame changes be even more subtle, and less likely to ‘pop’ to a viewer - I enjoy playing with making light pieces that look constant, until you look away and then back at them later (hours, minutes, days, etc…))

I guess I am just struggling to understand what most seem to understand and accept as obvious in this case!

Where can I get a good technical explanation of the necessity to have more than 400hz pwm cycles for POV ?

I’ve no link for you but some thoughts: POV stuff you usually move or rotate. Lets say it’s about a rotating stick: you use a polar matrix to map your content, right?! So rpm * desired angular resolution = min fps. If you like to see a good graphics quality you want a high resolution - so say we want to have 100 different points along a circle (the other dimension is limited by the leds/m) we need already at a turning speed of 4 rpm 400 fps… The same installation at a wheel of a bike with much higher rpm needs way more fps to allow you the desired resolution of the virtual matrix. Is that explanation helpfull, @JP_Roy ?
P.S. If the written fps rate is higher then the PWM you simply don’t see all the rendered frames… that’s the main reason for using LPD8806s or APA102s.

Yes it is very helpful !

But I am actually thinking of stationary objects and I guess consider people moving around while looking at LEDs blinking at some PWM frequency. Isn’t that also a potential problem with low 400hz rates?

Let me change the question slightly and ask if there is any value to having the fast PWM rates of the APA102 let’s say for a stationary LED display ??

I’m out walking around, so the short answer is yes, there is (there was an art project that I saw years ago that was a stationary stick of LEDs that you could see patterns in as you walked by, a stationary POV).

When I get back home I’ll look up the sites that talk about pwm refresh rates and perception (especially of moving eyes)

Well, if the observers pass your installation on a moving motorcycle for sure. :wink: If you move your eyes very fast over the leds you will allways see a strobe effect. So the more fps - the better. For a stationary audience I would say 100-200 fps are fine - it allows you coding smooth 16Bit trasition as Daniel described it. I tested this with “ordinary” people - above 150 fps the most people don’t see any strobing unless I invite them to focus on that effect. It seem that people are already so used to pulsating light (energy saving bulbs, neon tubes, led light with just one diode on AC) that the brain renders it out. People who spend a lot time in the nature are way more sensitive to it. So much about my human experimentation results with different people…

@Daniel_Garcia Awesome… Thanks!

(As an aside, I try to refer to frame rate and FPS when I’m talking about the number of times per second your code is changing the contents of the LEDs, and refresh rate and hz when I’m talking about the number of times per second the LEDs refresh their pwm cycle. (Running just dithering updates, e.g. calling showwithdelay, falls into either frame rate or refresh rate depending on what level of abstraction my current conversation has)