Smooth LED fading via PWM

[Ioannis]

1. Bright LEDs light even with nA current. I had a 5 meter LED stripe that some of the LEDs were ON while not connected to any power source!!! (Yeah, from static charge).

2. LEDs are not like lamps, so you cannot control them by a simple PWM idea. LEDs are current dependant devices so, you have to control them by current source and NOT by voltage as you do now.

My suggestion is not to bother with more resolution an try to control, by PWM, the current of the LEDs. Then you will have the exact same effect like simple filament lamps.

Ioannis

[HankMcSpank]

1. Bright LEDs light even with nA current. I had a 5 meter LED stripe that some of the LEDs were ON while not connected to any power source!!! (Yeah, from static charge).

I reckon this is the issue here....high brightness leds, with a lens that intensifies even the smallest amount of light = looks too 'on' even when almost off!

LEDs are not like lamps, so you cannot control them by a simple PWM idea. LEDs are current dependant devices so, you have to control them by current source and NOT by voltage as you do now.

Yeah, I know led's are current driven devices, but what gives...if the rated forward voltage is say 3.4V, but I run them at 3.1V regulated (because they yield sufficient brightness even at that voltage level)..then PWM principles ought to work fine (in fact, PWM does work just fine without the resistor...I'm running it here now!)....& there's always the internal series resistance of the PIC OP pin (5 ohms? not a lot, but resistance nevertheless)

[Ioannis]

For this specifically LED it might work and as long as the voltage is absolutely stable.

But I insist on using a current source. You will be able to control the brightness for a really 0 to 100%.

Even for a test it is interesting.

I have a client that for more than a year is refering to his power (chinese) LEDs as 24Volts... And I reply with the current of your LEDs is....

Ioannis

[HankMcSpank]

Just going off tack a little (still intend breadboarding this up so I can easily inster leds to suit - but for now stuck with my PCB).

I want the PIC pins to sink surrent, therefore I rejigged everything to have all the LED cathodes pointing at the pin, with all the anodes commoned and a P channel mosfet switching 3.2V to the anodes (via HPWM on the mosfet gate).

Something took me aback a little, with a duty value of 255, my leds were still *just* lit (remember we are talking reverse now, so a value of 255 is essentially 0), I changed the duty value to 256 & then the leds switched off ...therefore for all I thought I was using 8 bit/256 values (PR2=63 @8Mhhz, no pre/post ) I was actually using 257 values (and therefore a value 0f 255 sorta equalled 1)...this sucks cos obviously 257th value needs 9 bits! Now I know 255 is almost 256 so as not to worry that much....but is there any way of setting up the HPWM so that 100% duty = 255 exactly?

(BTW I've since inverted the PIC's HPWM ouput so now a value of 0 = the supply voltage & 255 = 0, which has solved my problem of the LEDs not totally extinguishing at a value of 255)

[HenrikOlsson]

Hi Hank,
I would think PR2=64 would make the resolution an even 8 bits, have you tried that?

/Henrik.

[HankMcSpank]

No I haven't tried it, but according to Mr E's multicalc, a PWM PR2 value of 64 yields @8Mhz gives 259 steps, with a value of 258 yielding a duty of 99.23%

Unless I'm missing something obvious (highly likely!), I'd have thought it'd be simpler to set a HPWM PR2 number that gives exactly 256 steps (therefore a max duty value of 255)

[HenrikOlsson]

Hi Hank,
Hmm, you might be right. It just seems that a PR2 of 64 would be more "even" since 64*4=256. On the other hand, 63 is 111111 in binary and if we stick the two lower counter bits to that we 11111111 which is 255 and then a dutycycle value of 255 "should" be 100%.

You are "splitting" the dutycycle value, putting the 6 high bits in CCPR1L and the two low bits in CCP1CON.5 and .4 right?

/Henrik.

[Charlie]

1. Bright LEDs light even with nA current. I had a 5 meter LED stripe that some of the LEDs were ON while not connected to any power source!!! (Yeah, from static charge).

Static charge is by nature static and won't power LEDs. Do you have a wireless router? There is a known issue with early LED Christmas lights illuminating by acting as rectifying antennae. I have a set - turn off my wireless router and they extinguish. Of course, you might live next door to a ham operator as well... but walking across the carpet won't do it.

[Charlie]

Counting from 0 to 255, with the LED on from 0 to 1 then off from 1 to 255 should work nicely, and extending to 512 should make it dimmer yet, I agree. I'd use resistors, but what you are doing "should" work too. The only part of what you are doing that is different from what I've seen work in the past is having the fundamental of the cycle at 32 KHz. It might work, but I've had issues in the past trying to switch LEDs too fast - you might want to drop that down to a couple hundred Hz. But like most of the suggestions, this is only a guess.

[HankMcSpank]

Counting from 0 to 255, with the LED on from 0 to 1 then off from 1 to 255 should work nicely, and extending to 512 should make it dimmer yet, I agree. I'd use resistors, but what you are doing "should" work too. The only part of what you are doing that is different from what I've seen work in the past is having the fundamental of the cycle at 32 KHz. It might work, but I've had issues in the past trying to switch LEDs too fast - you might want to drop that down to a couple hundred Hz. But like most of the suggestions, this is only a guess.

The only reason I run the frequency so high, is because the hpwm carrier *always* manages to permeate its way into the guitar signal (remember this is small signal stuff, that gets amplified by the guitar amp!)...so you always end up with an audible whine in the background.....with the hpwm at 31khz, the problem is still there, but only dogs can hear it!

It does all work at the high frequency...I will revisit this value of '1' (out of 256 vlaues) 'being a bit too bright' issue....but not until my next breadboard session.

[HankMcSpank]

so I'm running out of program memory, I'm presently using the subroutine below to lookup a counter value (count1 below) to get a preset hpwm value (duty)....

Smooth_fade:    
Lookup count1, [ _
  0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, _
  1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,3, _
  3,3,3,3,3,3,3,3,3,3,3,3,4,4,4,4,4,4,4,4,4,4,4,5,5,5, _
  5,5,5,5,5,6,6,6,6,6,6,6,7,7,7,7,7,7,8,8,8,8,8,8,9,9, _
  9,9,10,10,10,10,10,11,11,11,11,12,12,12,13,13,13,13, _
  14,14,14,15,15,15,16,16,16,17,17,18,18,18,19,19,20,  _
  20,20,21,21,22,22,23,23,24,24,25,26,26,27,27,28,29,  _
  29,30,31,31,32,33,33,34,35,36,36,37,38,39,40,41,42,  _
  42,43,44,45,46,47,48,50,51,52,53,54,55,57,58,59,60,  _
  62,63,64,66,67,69,70,72,74,75,77,79,80,82,84,86,88,  _
  90,91,94,96,98,100,102,104,107,109,111,114,116,119,  _
  122,124,127,130,133,136,139,142,145,148,151,155,158, _
  161,165,169,172,176,180,184,188,192,196,201,205,210, _
  214,219,224,229,234,239,244,250,255], duty
  return

,....now since I've not much program space left , is there any way I can win some room back by for example stuffing the above 256 bytes into EEPROM and then look up the values similar to above? (EEPROM is a bit of a new area to me...I've never had to bother with it before!)

If so....would you be so helpful to put me on the right track? (I'm figuring the 256 bytes will need writing into the PIC at the time of programming it & from thereon afterwards it can be read from EEPROM while the program is running?)

[HenrikOlsson]

Hi Hank,
You use DATA to store the constants to EEPROM at program time. Then you use READ to retreive them at runtime. Something like:

Data 0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, _
  1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,3, _
  3,3,3,3,3,3,3,3,3,3,3,3,4,4,4,4,4,4,4,4,4,4,4,5,5,5, _
  5,5,5,5,5,6,6,6,6,6,6,6,7,7,7,7,7,7,8,8,8,8,8,8,9,9, _
  9,9,10,10,10,10,10,11,11,11,11,12,12,12,13,13,13,13, _
  14,14,14,15,15,15,16,16,16,17,17,18,18,18,19,19,20,  _
  20,20,21,21,22,22,23,23,24,24,25,26,26,27,27,28,29,  _
  29,30,31,31,32,33,33,34,35,36,36,37,38,39,40,41,42,  _
  42,43,44,45,46,47,48,50,51,52,53,54,55,57,58,59,60,  _
  62,63,64,66,67,69,70,72,74,75,77,79,80,82,84,86,88,  _
  90,91,94,96,98,100,102,104,107,109,111,114,116,119,  _
  122,124,127,130,133,136,139,142,145,148,151,155,158, _
  161,165,169,172,176,180,184,188,192,196,201,205,210, _
  214,219,224,229,234,239,244,250,255
 
Smooth_fade:
  Read Count1, duty

/Henrik.

[HankMcSpank]

Hi Henrik,

Great, many thanks ....simple enough & it works a treat!

Weirdly even though I imported all those values to Excel to check there are 256 entries (there are) - I got an error when I came to compile (stack overflow)....I took one entry out & then it compiled ok. Hey ho....but I just got rid of one of the multitude of 1s in there.

Many thanks....I've a bit more room to "breathe" in my bloaty program again

[SteveB]

How about something like this:

Data 1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,3, _
  3,3,3,3,3,3,3,3,3,3,3,3,4,4,4,4,4,4,4,4,4,4,4,5,5,5, _
  5,5,5,5,5,6,6,6,6,6,6,6,7,7,7,7,7,7,8,8,8,8,8,8,9,9, _
  9,9,10,10,10,10,10,11,11,11,11,12,12,12,13,13,13,13, _
  14,14,14,15,15,15,16,16,16,17,17,18,18,18,19,19,20,  _
  20,20,21,21,22,22,23,23,24,24,25,26,26,27,27,28,29,  _
  29,30,31,31,32,33,33,34,35,36,36,37,38,39,40,41,42,  _
  42,43,44,45,46,47,48,50,51,52,53,54,55,57,58,59,60,  _
  62,63,64,66,67,69,70,72,74,75,77,79,80,82,84,86,88,  _
  90,91,94,96,98,100,102,104,107,109,111,114,116,119,  _
  122,124,127,130,133,136,139,142,145,148,151,155,158, _
  161,165,169,172,176,180,184,188,192,196,201,205,210, _
  214,219,224,229,234,239,244,250,255
 
Smooth_fade:
    IF Count1 = 0 THEN 
         duty = 0
    ELSE
         IF Count1 < 26 THEN 
             duty = 1
         ELSE
             Read Count1-25, duty
         ENDIF
    ENDIF
    RETURN

WriteUserByte:
    WRITE 255, UserByte
    RETURN

ReadUserByte:
    READ 255, UserByte
    RETURN

Now you have the upper 25 EEPROM addresses to use. More space could be saved by using similar logic. But this hopefully gets the point across.

Good luck,
Steve