OctoWS2811 and PWM?

Status
Not open for further replies.

byrd

New member
I am working with the VideoDisplay.ino file on the Teensy board and a self implemented Java program based on the movie2serial Processing sketch. What I want to do is to control the brightness of the LEDs. So my question is, does the OctoWS2811 library support PWM and if not, how can the VideoDisplay sketch be modified to implement PWM? Has anyone tried that before? Thanks in advance for any help.
 
The simple answer is no, OctoWS2811 doesn't support PWM.

The not-so-simple answer involves first figuring out what's meant by "PWM" in this context. I could write a very long message, but maybe better if you take the lead and paint a clearer picture of what you're trying to ask?

But I will point out 2 quick facts.

1: The LED controller chips inside WS2812B do indeed use PWM to control the brightness of each color. Some use ~425 Hz PWM, others ~2000 Hz.

2: Transmitting 1 set of LED data to the controllers takes 30 us per LED (24 bits at 800 kHz), plus a 300 us end-of-data idle time.
 
So, in order to dim the LEDs, a multiplication of all R, G, and B values with the same attenuation factor could be a solution. If using a T3.x, there are DSP instructions which allow packed multiplication of up to four 8bit values within one CPU cycle.
 
I could write a very long message, but maybe better if you take the lead and paint a clearer picture of what you're trying to ask?

Thanks for your quick answer. I am working with some colleagues on an art object which is illuminated by LED stripes. The LEDs are very bright, so we need to dim them. But restricting the RGB range to e. g. 0 - 50 instead of 0 - 255 is not usefull because the color spectrum would be restricted significantly and the visuals get greyish.

So I think the best solution is to reduce the brightness of the LEDs by enlarging the LED off time. I'm not quite sure but I think we're using WS2812B LEDs with a WS2811 controller. I've attached a photo of the stripes maybe you can identify them.

I'm sorry, but I don't really have a deep understanding of the techniques behind LEDs and controlling them by software. But changing the brightness of LED stripes seems obvious to me, so I thought maybe someone else has an idea how to do this.

rgbw.jpg

If using a T3.x, there are DSP instructions which allow packed multiplication of up to four 8bit values within one CPU cycle.

Thanks for your answer, too. I'm using a Teensy 3.2. Unfortunatelly I don't understand what you mean, my microcontroller skills are pretty poor. Can you please be more specific or if you have some links which may help me I would be pleased.
 
Last edited:
The LEDS are already doing PWM when you set the 0-255 value via an internal controller. All you can do is send red green and blue values in the range of 0-255 to that controller and leave it to PWM away. The peak brightness of the LEDs is a factor of the design so not something you can change without getting a custom run at a factory (and actually want kilometers of the strips).

It is possible to do things like write 0,0,0 to the strip every other up date (or very 1/3 or 2/5 or whatever) for an extra couple of bits worth of PWM but this commits you to a very tight timing cycle of updating strips. If you are late doing an update there will be a brightness spike and you also start to clash with the internal update rate of the pixel controllers (if you try to update before it has completed one PWM cycle).

So yes it is possible, and starts as simply as getting a tight refresh rate working and writing 0 rather than the ordered value half the time (for half intensity).

If this is an art project where power is not really a limit and you are not packing too many pixels into a volume a much easier solution is to look at diffusers and just block the amount of light you need. Before making any decisions on dimming the project try a sample under the lighting and viewing distance they will eventually operate in, not the lighting on your bench.
 
Looking at your photo of the LEDs, I see a large yellow area. My guess is you may have purchased RGBW type, rather than normal RGB. If you're getting results that are too bright, and tend to have washed-out colors, maybe it's due to using the wrong types of LEDs with that bright white LED inside?

Regarding the "PWM" idea, Micah did what she called "temporal dithering" in her Fadecandy code, which is based on OctoWS2811. That's probably where you want to go with this. But it has serious limitations, mainly that the LED strips must be kept quite short. Each LED takes 30 us to communicate. So if the strip is long, you can't achieve hundreds of updates per second, which are needed if you're going to try to effectively blink the LEDs on and off rapidly to get more low-end range.

There's also an open-ended question of how well the LED controllers inside each chip handle the individual changes (some I've tested... not well) which doesn't matter much if the LED's PWM is 425 Hz and you give it new data at 30 Hz. Each color gets display for ~14 of the LED controller's PWM cycles, so if one of those 14 cycles is done badly, not a huge problem. But if you send data much faster, many of these LED strips respond badly. FastLED's code even has check for the update rate. I've considered adding similar code in OctoWS2811, but so far I've always kept it simple, since most people use it for very large projects where that's rarely an issue.
 
Looking at your photo of the LEDs, I see a large yellow area. My guess is you may have purchased RGBW type, rather than normal RGB. If you're getting results that are too bright, and tend to have washed-out colors, maybe it's due to using the wrong types of LEDs with that bright white LED inside?

Yes, you're right, I forgot to mention that. But the extreme brightness is not because of the white LEDs, its because the LEDs in general are so bright. To show colors we don't use the white LEDs. We have a matrix of 88x88 LEDs, every stripe is 176 LEDs long. So in fact we have 44 stripes with 176 LEDs and we are using 6 Teensys to control them, because every Teensy can control maximum 8 stripes.

We have only washed-out colors if we dim the LEDs by restricting the RGB range. It's mathematical problem. If we use RGB with 256 values per channel, we have 16.6 million colors. If we only use 51 values per channel to dim the LEDs, we only have 132 thousand colors.

Regarding the "PWM" idea, Micah did what she called "temporal dithering" in her Fadecandy code, which is based on OctoWS2811. That's probably where you want to go with this. But it has serious limitations, mainly that the LED strips must be kept quite short. Each LED takes 30 us to communicate. So if the strip is long, you can't achieve hundreds of updates per second, which are needed if you're going to try to effectively blink the LEDs on and off rapidly to get more low-end range.

Ok, I'll have a look at Fadecandy. I'm not sure I can handle it but I'll give it a try.


If this is an art project where power is not really a limit and you are not packing too many pixels into a volume a much easier solution is to look at diffusers and just block the amount of light you need.

We also thought about that, but that's not an option because it changes the aesthetic of the object. It looks quite nice to see the blank LED stripes. When they are covered it is a very different look.
 
Status
Not open for further replies.
Back
Top