PWM LED control and LC networks

[MacGyverS2000]

First off, many thanks go to steveowens for taking time out of his busy schedule to discuss my circuit ideas, both through email and on the phone. Kudos! He has certainly helped me move from more complicated ideas to something more simplistic, but I cannot expect him to spend all of his time helping little ol' me.


What exists:I would like to hear the opinions of others as I try to lock down this piece of the circuit. I am controlling a variable number of parallel multi-color LEDs with PWM, each color independantly controlled with a separate PWM stream. Each LED has it's own current-limiting resistor. A PWM period is 32ms long with 1ms resolution, with duty cycles of 0-100%. To be honest, I could probably decrease the period by several factors of 2, but let's start with what I'm currently working with. Voltage supply will most then likely be a regulated +12V to simplify determining max LED current (but I'm all ears on other methods to solve that issue).

Problem: I would like to rid myself of the blinking visible at less than 100% duty cycle, especially at 0-50% duty cycles (I know my low PWM period is partly to blame for the visible flickering). Also, I would like better control of the brightness, especially at low brightness settings...since I'm pulsing at full on/off, even at 3% duty cycle the LED is quite bright (don't have the benefit of an incandescent bulb's filament intergrating effect).

What's been tried:It has been suggested that an LC network with a flyback diode (similar to a switching power supply design - boost/buck regulator, if you will) is the path I should be chasing. So, I've spent considerable time playing with values in an attempt to make a reaosnable circuit. This shoudl be as close to surface mount material as possible (or very small through-hole), so I set a self-imposed limit of <500uH and <20uF (since I have had trouble finding an inexpensive SM cap over 20uF).

Interesting simulation, but the voltage overshoot would blow things sky high. So, I added in a zener after the inductor to clip the voltage...worked reasonably well. Ringing could be removed with a sizeable cap (well over 20uF, though).

Where I'm at now:In doing all of this sim work, I think I lost sight of my goal...controlling the LEDs. After all was said an done, the voltage across the LEDs was still a close approximation of the square wave. If the PWM pulses controlled a FET for each LED color to begin with, slightly smoothing out the square wave train is hardly going to have any effect on the flickering. I'm sure it was thr original circuit's attempt to smooth out the incoming power (and reduce the flicker that way) rather than the PWM pulse, but I've got so many conflicting ideas running through my head I can't sort them out any longer.

Someone push me down a path that makes sense again...

 

[Skogsgurra]

MacGyverS2000,

There are two things to consider; the nature of the human eye and time constants that can be achieved with limited L and/or C.

First. The human eye needs well over 50 Hz to not see the flicker. I would go for 16 or 8 milliseconds. As you say, you can probably double or quadruple the frequency. That would solve the problem, I think.

Second. You need time constants about three or fime times the cycle time if you want to keep the intensity fairly constant. In the simple case (L and R or C and R) the time constants will be L/R or C*R. For three times 32 ms (that is around 100 ms) you will then arrive at L/R = 0,1 second. And if you insert your L limit (500 uH) you will get an R equal to 5 milliohms. Not very practical. Totally impossible, I would say.

If you go for R and C, you will need R*C = 0,1. Your C limit (20 uF) will then make the R = 5000 ohms, which is a possible value, but that will result in very week light since LED is duty cycle driven. With 12 V available, you can get at most a couple of mA in the LED if you use 5 kohms.

So I think that increasing the frequency will solve all your problems - if your micro allows you to do it.

 

[Warpspeed]

Your PWM period of 32mS (31Hz) is very slow, and your filter network has far too short a time constant, so it cannot average, and provide a constant low ripple voltage dc output. That is why you are still seeing a squarewave output.

As you desire to keep the components physically small, the obvious next step is to increase the PWM frequency. Something like 320 microseconds (3.1Khz) might be closer to what you might require.

 

[MacGyverS2000]

skog/warp,

Your comments are well received.

For a 4 MHz clock, I have a cycle time of 1us, or 1k instructions between interrupts. I'm using roughly 30% of those cycles in the ISR. I'll probably increase the clock to 32 MHz, giving me an 8-times improvement, but the 32 duty cycles will be extended to 64 (or possible 128), thereby losing 2- to 4-times improvement. I could increase the ISR rate some to gain it back again, but I need to spend time outside of the ISR, as well.

As a simple test, I doubled the ISR rate to 0.5ms, which should give me a &quot;refresh&quot; rate of 62.5 Hz...flicker was still quite visible...better, but visible. I'm hoping another 2- to 4-fold speed increase through the use of a faster crystal will remove it completely, but I'm still leery. Anything more than a 120-150 Hz refresh rate just isn't going to happen if I still want to do any other calculations in the main routine...3 kHz is definitely out.



OK, so let's say for the sake of argument increasing my refresh rate several times removes the flicker...what can I do about even low duty cycles causing unwanted high levels of brightness? My prototype board uses BJTs to control the max current through the LEDs, but I want the ability to connect any number of LEDs to the board...this necessitates moving to something like FETs (and individual resistors on each LED). The BJTs were semi-useful in that I could put a cap on the base to lower the peak drive current at low duty cycles, thereby truly making the LED somewhat dim with lower current (and even THAT didn't work as well as I had hoped). When moving to FETs, though, I have no such option. Any suggestions?

I can draw a basic circuit, if that would help...

 

[felixc]

- do you have space constraints?
- do you have cost constraints
- do you have manufacturing constraints?
- you plan to build one or a thousand units?
- do you care about EMI?
- do you care about the power efficiency of your circuit?

These are several things that will guide the answers that you'll receive from the community.

My inputs and questions:
- what is the rate of change that you will have in your brightness. Quick like a video display or slow like a level indicator?
- there are LED controllers that have their own charge pumps and everything to deliver precise currents to LEDs. Have you considered them? Maxim, Linear, Zetex are names that come to my mind.
- have you tried a light detector (with compatible wavelengths) to measure the light output vs the currents driven into the LEDs.
- there is also a gamma curve relationship between the perception of the eye and the light output.
- LEDs quickly induce eye fatigue, and I don't think this is because of the pulsating frequency, but the energy sent to a single wavelength, almost like a laser diode.
- a manufacturer of giant LED displays (like the one on the Nasdaq wall) uses a refresh frequency of 1KHz.

 

[MacGyverS2000]

Space constraints are relative, I suppose. I would like to keep any associated circuitry SM, if possible, although I will go through-hole if component values necessitate it.

Cost contraints are relative, as well. I can accept a dollar or two here and there, but if the final product is to remain competitive, I can't do much more than that.

No manufacturing constraints I can think of, other than the two listed above. I expect to make these in large batches (500+ per run), so we're not talking prototypes here...every few pennies helps.

EMI is not an overriding concern, although it wouldn't be wise to go splashing energy all over the place. I would like to keep as much of the high slewrate signals at low voltage/current levels to avoid any potential problems.

Efficiency isn't an overriding concern, either, but I can't throw away several amps just because it's simple (else I would go with a simple power resistor setup). Wasting 5-10% of my power in various components seems like a reasonable level to attain, but I would certainly prefer if it was less.

Rate of change will be near instantaneous...I could drop the duty cycle from 100% to 0% from one update cycle to the next.

Charge pumps are out of the question for several reasons, among them are sheer number required, cost at that number, etc.

Feedback from the LEDs to the controller is not a preferred method since the number of wires between controller and LEDs should be kept at a minimum, and the distance between the two could be 5-10 feet (making current sensing another problem in itself).

The light output will not be viewed directly, but by reflected light. This should dampen any eye-fatiquing effect, not to mention there will be color mixing going on.

With a 32 MHz crystal, I could only come close to a 1kHz refresh rate if the processor did nothing else but update the LEDs...it's just not an option. I'll be doing good to get the 120+ Hz refresh rate I mentioned before.

 

[melone]

Running at 32MHz, you could only update every 1kHz????? Something sounds very strange. How are you implementing the code? Are you manually creating the PWM signals yourself, or do you have actual PWM outputs?

 

[MacGyverS2000]

Manual creation since I'm creating up to 12 PWM streams at once. If I were to keep my code the same (i.e., same ISR rate), but speed up the clock by 8 to 32 MHz, my streams would be updated every 125us (8 kHz). At 32 updates per stream, the period would then be 4ms, or 250 Hz. I could play around with the ISR time a bit, maybe halve it, for a period of 500 Hz. If I move to 64 values for better precision, I'm back to 250 Hz for the period. Either way, I stil need to leave some time for outside operations (i.e., code that determines why the PWM streams should change).

 

[MacGyverS2000]

Well, the blinking issue has been resolved, in a manner of speaking. I moved the PWM stream update code out into the main routine, so it runs as fast as possible. The potential downside is the refresh rate is not guaranteed, but I doubt this will truly be an issue. The great thing is, I'm still running this at 4 MHz...if it becomes a problem after all of the code has been written, I'll merely tack on a faster clock. I'm also quite happy about the results since it means I don't need any extra hardware to limit the flickering. So, I consider this part of the case closed.

However, it still leaves open the case of the LEDs appearing too bright, even at low duty cycles. I'm open to ideas on how to resolve that issue.

 

[MacGyverS2000]

OK, maybe the blinking issue hasn't been completely resolved. Now that the code is in the main routine instead of the ISR, there's no specific update time, right? Well, that has the effect of giving it a beat frequency, one based upon the amount of other code it processes from the top of the list to the bottom (that's my guess)...almost like an RF/IF mixer where the local oscillator is not quite in tune with the frequency of interest. For the sake of argument I'll just assume this piece of code stays in the ISR and the increase in clock speed (or ISR frequency) will fix it.

Still hoping for ideas from your guys about dimming, though.

 

[felixc]

I was talking about an electronic light detector not to use in your end product, but to help you characterize the drive vs. perceived intensity issue. Because eye sensitivity is a gamma curve, perhaps that you will need a higher PWM resolution to better address the low intensity issue. But since you drive PWM streams by software, it would mean more CPU power to accomplish that. You can validate the idea using less outputs. If it does make a difference, you can do several things. A higher-speed CPU. A different CPU. There are cheap DSPs that run very quickly. You can do the PWM externally, in a CPLD for example. Then you would have total control and could use a cheaper CPU to do the control. It depends on your budget envelope, and your development schedule... If you have enough CPU power to output a PWM is software, and enough refresh rate, you can modulate the PWM output to interpolate the light output. (level 1 is too bright, you can do a level 1/2 by alternating between level 0 and level 1).

 

[MacGyverS2000]

Quote from felixc...
=====
If you have enough CPU power to output a PWM is software, and enough refresh rate, you can modulate the PWM output to interpolate the light output. (level 1 is too bright, you can do a level 1/2 by alternating between level 0 and level 1).
=====


Now this has potential merit. Of course, it would require a speed doubling of the processor to avoid dipping below the blinking margin set beforehand, but the idea itself has real merit. I'll chase it down once some other things are settled.

 

[MacGyverS2000]

I've been bogged down now for quite some time trying to resolve a programming issue. Now that the problem is out of the way, I was able to revisit this issue again. Originally all of the code was inside the ISR, but I have now moved the majority of it outside into the main routine.

As a test, I halved the ISR time to 0.5ms and WOW, what a difference (even using the original 4 MHz clock). Even moving from the original 31Hz refresh rate to the doubled 62Hz, the flickering has completely disappeared. Skogsgurra was right on the money with being above the 50 Hz mark to avoid the flickering. And the great thing is no hardware was required


felixc, I'm aiming this next question at everyone, but also you in particular. The final piece will still move from a 4 to 32 MHz clock, thereby giving me a good bit of leeway. If I increase the ISR speed to match any increases in PWM resolution (e.g., move from 1ms interrupts and 32 PWM levels to 0.25ms interrupts and 128 PWM levels), will a single pulse offer me increasing lower brightness levels as the resolution is increased? My intuition says yes, but without a prototype sporting a 32 MHz crystal, I can't try it to be sure. If so, I'll probably stop looking for ways to lower the initial brightness and consider both of my original issues resolved.

Now that one issue has been resolved (flickering), and possibly the second (low brightness levels) without hardware, I'm a REAL happy camper.

 

[melone]

How come varying the pulse width on the PWM doesn't work? That is the whole point of using a PWM, variable output intesity (plus some current savings). If you set the frequency above 100Hz, you can adjust the posistive duty cycle from 0% (completely off), up to 100% (full intensity). Just make sure you keep the frequency constant....

 

[felixc]

The answer is yes. Increasing the PWM resolution will give you the &quot;fine adjust&quot; to your brightness. Because of the gamma curve, the increased PWM resolution will only show better results at low intensities.

Modulating the PWM to increase the number of levels is a technique used in LCD controllers that interface to STN panels. These panels do not have intensity greyscales, so they are produced by modulating the drive and letting the STN material itself, and the eye, do the integration. As the response time from different LCD materials vary, these controllers were allowing you to use several variations to better adapt.

 

[MacGyverS2000]

MY duty cycle is selectable from 0-100%, but the minimum duty cycle still puts out too much light. For this application, a high pulse turns the LEDs on to full capacity. Since LEDs have turn-on times in the microsecond range, I don't have the luxury of a slow turn-on filament and the associated integration effect.

In my prototype design, a single pulse is 1/32 of a period, or 0.5 ms in width. Even half a millisecond is quite a long time in terms of LED brightness, so I'm hoping that decreasing the minimum pulse width will also lower the perceived brightness...if not, I need to start chasing down other solutions for this problem.

 

[melone]

If you are at 0% duty cycle, how could the lights be on? (The output would be 0V)

 

[MacGyverS2000]

Sorry, when I said &quot;minimum&quot; I actually meant the minimum pulse width possible that's not 0%. In the current case with 32 levels, it's a 3% duty cycle.

 

[Chuckles159]

Regardless, to avoid flicker, you need a pulse repitition rate of at least 100Hz. Preferably 200Hz. I have found LEDS to be quite linear with brightness with PWM control. However, it is important to have a repitition rate of at least 100 Hz and there must me NO filtering. Any filtering will make the LEDS behave in a non-linear manner as the PWM duty cycle changes.

 

[MacGyverS2000]

Chuckles, what you suggest goes against both what I have read and what I have tested.

First, with a refresh rate of 31 Hz there was significant flicker, but doubling it to 62 Hz and the flicker has completely disappeared.

Second, LEDs are square law devices, not linear. At low duty cycles the brightness makes large jumps as I move from one level to another, but as the LED becomes brighter, the changes in brightness becomes less and less with each increase in duty cycle.