RGB LED Colour Mixing & Dimming...

If you can already mix colors with then no extra circuitry is necessary. The obvious thing to try is to proportionally reduce the PWM duty cycle for all colors. For example, to dim by 10% reduce the duty cycle of R by 10% of the current value and G by 10% and B by 10%.

If you want to do it "properly" rather than just guessing that proportional reduction will maintain the colors then you can convert the RGB color to HLS, then reduce the L (Luminosity/Brightness) value to dim (or increase to brighten), and convert back to RGB for output. The code to convert between RGB and HLS is freely available on the net. Here's a C version by Microsoft:

And here's one in Tcl (scroll down the page a little):

The code looks messy but is quite short and quite easily embeddable. This may consume a bit more memory on your controller but saves you from using additional external circuits and components (which would require you to write additional code to control anyway).

slebetman

Thank you for your reply.

Your are right, you can reduce the brightness by changing the PWM, but you are very limited if you have a colour made up of say only 10% red already. Once you have 0%^the colour changes of course...

I will look into the RGB to HLS conversion.

Thanks aga>> Hi

To change the brightness without affecting the color (much) you can reduce or increase the PWM of each LED proportionally. You'll have to limit it when you get to 100% on any of the LEDs and the PWM granularity may affect the color at low levels (but perception changes too, AFAIUI).

I think you'd be better off playing with the PWM only, more linear in terms of perceived brightness.

Best regards, Spehro Pefhany

--
"it\'s the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Ah.. but that is correct. 0% of any given color is black (RGB=0,0,0). You need not worry much about any of the R, G or B values going to 0. What you need to worry about is any component of the color reaching

100%. If any of the R, G or B values have reached 100% then you have reached the maximum brightness of the color. Increasing the other components beyond this changes the color.

Say for example you have an RGB color 255,0,153 (which is sort of bright pinkish purple). This color when reduced by half would be

128,0,77 (which is very dark purple) which is the same color but much dimmer. When reduced by a quarter it becomes 191,0,114 (which is redish purple) which is in between the bright and dark versions of the color. But this method is not as accurate as manipulating color in HLS. That's because HLS models colors based on human perception (hue = what type of color, luminosity = how light or dark is the color, saturation = how rich is the color).

Personally, I would try the straight forward proportional dimming first just to get most of the dimming code working. Then if you want accuracy replace the proportional calculations with the one based on the RGB->HLS->RGB method.

One last word of warning. In the HLS model, any color at 100% brightness turns to white which is contrary to the advise I gave you with the proportional RGB method. If this is not what you want then maybe the HSV model is better suited for your app. Here's some C code for converting between RGB and HSV:

What is the difference between HLS and HSV models? Consult wikipedia:

Spehro & Slebetman

Thanks for all your input. I think I am going to try the RGB-HLS/HSV methods

- should be interesting.

Don't forget to pay your royalties to Color Kinetics first...

:-)

--
Ian

"Tamahome!!!" - "Miaka!!!"

But never pay royalties for hobbies. :)

Jon

Oh, for goodness sake..

I should have gone to look, before. Cripes!

Jon

Prior art is not prior art unless.

A. It is previously published B. The judge likes you. C. You have lots of money and can afford the best legal defense team. D. The judge like you. E. You can bullshit really well. F. The judge likes you.

The appeals process seems to work until the Appeal Judges send you back to the original claim, where now the judge hates you because she (oops, did i say that) was proven wrong by 3 Federal appeal court judges.

Now with software patents. Prior art does not include you previously writing the software, even if you printed it on paper. Not even if it is in well dated source control. Nope, you need to publish it, which makes great commercial sense, especially when security is involved.

This stuff makes me sick.

Here's one someone else built: