How to smooth the LED brightness transition with PWM control at low levels?

[tooki]

I went to a show recently (a film, with live music before and after, and interview with the director), and the stage lights were PWM dimmed. I had to strain to keep my eyes focused on one object so as to not constantly be distracted by phantom arrays. And even the projector they used (mind you, in the main auditorium of the Zurich Film Festival, so a proper digital cinema projector, not some dinky conference room toy) exhibited some rainbow effects to me.

That's interesting, with the growth of LED source technology in stage lighting and the simultaneous growth of video integration (especially streaming now, but also broadcast and imag) PWM rate is an increasingly important spec for people who are purchasing gear.  (Especially now that most people are finally accepting that before long tungsten and discharge sources just won't be an option anymore.)

Is it, really? Going by the fact that in every. single. thread here about PWM, there are people who think that the same 60Hz frame rate threshold that applies to moving images also applies to PWM, I think the importance of high PWM frequencies is not widely accepted yet.

I'm curious what kind of lighting equipment that venue had and what the actual PWM frequency was.

I have no idea what it was, no way to look at it. If I had to guess, I'd peg the PWM frequency at somewhere around 500-1000Hz. Not super low, but still enough for me to easily detect it without trying.

As far as the projector, it's still quite likely that it was a discharge lamp + color wheel + DLP arrangement.  Laser/LED source projectors are still relatively new and I don't think have a ton of market penetration yet outside of smaller compact systems.  Even a lot of current-model laser based DLP projectors use a phosphor wheel.  Given the price tag on big projectors like that equipment turnover isn't that rapid, so the mechanical limitations of using a spinning wheel are going to be a factor in the display quality for many years to come.  Single-chip projectors with direct laser/LED sources should be able to achieve better performance since the limitation on changeover time between colors is probably limited by the MEMS performance well before the modulation performance of the sources.  Three-chip projectors should be able to do even better since the colors don't have to be temporally overlaid at all.

Good color wheel-based projectors are just fine. I've watched many a movie in digital cinemas over the years, and this was the first time I ever noticed any rainbow effect at all. It was very subtle, unlike in bargain-basement DLP data projectors.

FYI, the MEMS speed is not the limiting factor, not even by a long shot. The micromirrors can move thousands of times per second (over 9000 in current-generation ones), such that they're actually flipped back and forth dozens of times per subframe in order to produce intermediate brightness values. They also use higher-RPM color wheels with far more than 3 segments (adding more colors, and often multiple segments per color) to increase the effective frame rate to 240fps or more. With pulsed LED or laser illumination, it could potentially go much higher.

[Faranight]

A simple test would be to hook up a single LED with an appropriate current limiting resistor directly to the PCA9634 exactly as shown in “10. Application design-in information”, for LED0 - from the data sheet that you linked. This eliminates the mosfet and all of the additional drive circuitry. My guess is that you will see a very different brightness function.

There is some truth that the mosfet may distort the PWM waveform in some manner. Looking at the circuit, you can see that there is a gate resistor present before the mosfet. I was told to put this 100 ohm resistor there to prevent large current spikes on the mosfet driver. But thinking about it, the mosfet has some internal gate capacitance, and together with the resistor they both form an RC filter on the line. I've already checked the scope and the waveform looks quite different (much narrower and spiky) on the input than the one behind the resistor on the mosfet gate. I tried removing the gate resistor and feed the waveform from the function generator directly into the mosfet gate, and the only change this seems to have caused is more ringing on the gate terminal. LED brightness did not seem to change noticeably. I'll try to do a proper test with the output of the driver connected directly to an LED and a current limiting resistor.

Then if you look at the gamma correction function it should be clear why this isn't working.

No, you misunderstand. The gamma correction algorithm is present on the microcontroller, but I was doing the tests with a separate function generator that outputs a square waveform of given duty cycle with no gamma correction. The problem isn't gamma correction, but the fact that the change of brightness on the final step from 1/255 to 0/255 duty cycle is too big while the changes from 1/255 to 2/255, 2/255 to 3/255, 3/255 to 4/255, etc are barely noticeable. See tooki's reply one post above yours. All 8 channels are dedicated to different and separate LED's.

Here is a 16 channel 12 bit controller that can operate at 1.5 kHz also from NXP: PCA9685 https://www.nxp.com/products/power-management/lighting-driver-and-controller-ics/ic-led-controllers/16-channel-12-bit-pwm-fm-plus-ic-bus-led-controller:PCA9685  This was just the first one I found, I'm sure there are others.

Yeah, I just found it myself. It's a 12-bit, but 16-channel PWM driver that apparently even has an external clock input pin. They don't have an 8 channel one though. In worst case I'll have to discard 8 channels, or as StillTrying suggested, maybe use 8 channels for high current and the other 8 for low current? I'll have to study this possibility.



Thanks for all the suggestions so far, everyone. I wasn't expecting my thread to get this much attention. I'm getting new helpful posts faster than I can process them. That sigma-delta modulation approach does look interesting. Although I'm unsure I'll be able to implement it on an existing microcontroller since it already has to process quite a lot of code.

[mikeselectricstuff]

color wheel-based projectors are just fine. I've watched many a movie in digital cinemas over the years, and this was the first time I ever noticed any rainbow effect at all. It was very subtle, unlike in bargain-basement DLP data projectors.

I think most cinema-size projectors use three seperate DLPs rather than colour wheels

[StillTrying]

but the fact that the change of brightness on the final step from 1/255 to 0/255 duty cycle is too big while the changes from 1/255 to 2/255, 2/255 to 3/255, 3/255 to 4/255, etc are barely noticeable.

OK, another theory.

Steps 1/255 and 2/255 might be out (too long or too bright) because of the problems trying to get the mosfet to produce pulses which are only 40ns and 80ns wide. The gate's fast charging and discharging edges getting through the gate-drain capacitance will have a relatively big effect on what the drain is doing at those small pulse widths, especially if the gate's turn off is very fast.

The 3 scope shots show the full 10us period but aren't fast enough to show what's happening to the drain pulses only 40ns to 120ns wide.

[Faranight]

Well, here's the zoomed-in version of the waveform for the mosfet turn-on. This *is* on the breadboard after all...
Yellow is voltage on the mosfet drain, purple is voltage on the frequency generator output (before 100 ohm resistor), cyan is voltage on the mosfet gate (after 100 ohm resistor).
Ring ring, hello? Ring ring, hello? Rign ring, hello? I have a bad connection!

[StillTrying]

I don't know what to make of that, I've seen a lot worse.

It looks like the drain is staying on a bit but that might just be the LED's capacitance holding the voltage, when you switch a LED off by opening a switch the voltage across the LED drops a few 10s of mV and it stops conducting current but the LED's capacitance is still charged for a while so it looks like the switch is not switching off properly, at least on a scope.

All I can think of is to compare the drain pulse widths for the steps 1/255 to 5/255.

[DavidAlfa]

Lower the pwm frequency, it's just a lot, regulation won't be accurate.
10KHz should be more than enough to avoid flickering.
Also you might want a mosfet gate driver.
Also 8 bits are too low for a decent range.
Another way would be a constant current led driver.

[tooki]

color wheel-based projectors are just fine. I've watched many a movie in digital cinemas over the years, and this was the first time I ever noticed any rainbow effect at all. It was very subtle, unlike in bargain-basement DLP data projectors.

I think most cinema-size projectors use three seperate DLPs rather than colour wheels

Eh, it’s not just about the size. From browsing Christie’s site, just as one example, their cinema projectors are all 3-DLP, while their event projectors are about half 1-DLP and half 3-DLP. I would assume that the cinema models are intended for permanent installation, whereas the event projectors are designed to handle the rigors of being schlepped from place to place.

Clearly the film festival happened to rent a 1-DLP projector, or else the rainbow effect would not have manifested.

[tooki]

but the fact that the change of brightness on the final step from 1/255 to 0/255 duty cycle is too big while the changes from 1/255 to 2/255, 2/255 to 3/255, 3/255 to 4/255, etc are barely noticeable.

OK, another theory.

Steps 1/255 and 2/255 might be out (too long or too bright) because of the problems trying to get the mosfet to produce pulses which are only 40ns and 80ns wide. The gate's fast charging and discharging edges getting through the gate-drain capacitance will have a relatively big effect on what the drain is doing at those small pulse widths, especially if the gate's turn off is very fast.

The 3 scope shots show the full 10us period but aren't fast enough to show what's happening to the drain pulses only 40ns to 120ns wide.

You can verify the problem with 8-bit PWM using an Arduino with an LED (via current limiting resistor) connected directly to a GPIO. Note that the 8-bit, 490Hz PWM from an Arduino is only the default; you can also change it to higher frequencies and/or resolutions. You could, for example, use one to test 16-bit, 245Hz PWM to see the effect of the greater resolution.

[tooki]

Lower the pwm frequency, it's just a lot, regulation won't be accurate.
10KHz should be more than enough to avoid flickering.
Also you might want a mosfet gate driver.
Also 8 bits are too low for a decent range.
Another way would be a constant current led driver.

The frequency is a fixed value in the LED driver IC. It can’t be changed. If they want better resolution, they’ll have to use a different driver IC.

[StillTrying]

If I simulate with some of the low power low capacitance mosfets the drain voltages yellow, and the currents through the LED green, don't look too bad for such short 40ns to 160ns pulses. 100R in series with the gate.

So I don't know why the brightness of the first 4 or 5 PWM steps aren't right.

[BrianHG]

I've watched many a movie in digital cinemas over the years,

Cinema grade projectors implicitly demand the use of 3 chip DLP projectors.  No spinning color wheel BS.  No blinking as the PWM rate is way above 240Hz per pixel which have a dedicated DLP chip per color channel.  You will never see a rainbow effect in the cinema with those Barco or Christie projectors.

[tooki]

I've watched many a movie in digital cinemas over the years,

Cinema grade projectors implicitly demand the use of 3 chip DLP projectors.  No spinning color wheel BS.  No blinking as the PWM rate is way above 240Hz per pixel which have a dedicated DLP chip per color channel.  You will never see a rainbow effect in the cinema with those Barco or Christie projectors.

Yup, hence my suspicion that they used an event projector at the film festival. (I should mention, it wasn’t in any of the cinemas in the city — they’re much too small — so it was actually held at the convention center.) But despite being a temporary setup, I would have expected the film festival to have specified something better.

Don’t get me wrong, it was clearly a high-end projector (size and brightness alone would have limited it to something from the likes of Barco or Christie), just not the best.

Or maybe the convention center already had a large-venue projector installed and they just used that? I really don’t know. (And my Google-fu didn’t turn up anything, alas.)

[ejeffrey]

Then if you look at the gamma correction function it should be clear why this isn't working.

No, you misunderstand. The gamma correction algorithm is present on the microcontroller, but I was doing the tests with a separate function generator that outputs a square waveform of given duty cycle with no gamma correction. The problem isn't gamma correction, but the fact that the change of brightness on the final step from 1/255 to 0/255 duty cycle is too big while the changes from 1/255 to 2/255, 2/255 to 3/255, 3/255 to 4/255, etc are barely noticeable. See tooki's reply one post above yours. All 8 channels are dedicated to different and separate LED's.

My point is that if you pay attention to what the gamma correction curve is telling you about visual perception then this behavior is expected.  1/255 is much brighter than 0.  It is roughly equivalent to a 4-bit resolution in that if you put 16 equally spaced (gamma corrected) samples in a row each one would be clearly distinguishable from the next.  The next-to-last one would be 1/256 as bright as the first if you were using gamma=2, if you were using a more standard gamma=2.2 the next-to-last would be 1/445 as bright as the first.

The effect is exacerbated when you are comparing off to on but I suspect that if you toggle between 1/255 and 2/255 at 1 Hz you would see that clearly too.

[DavidAlfa]

The frequency is a fixed value in the LED driver IC. It can’t be changed. If they want better resolution, they’ll have to use a different driver IC.

Oops you're right, my bad. I forgot the LED driver part, thinking it was mcu-driven. Different driver then, yes