In the data sheet of some RGB led's I have, the max peak current for R is
60mA while for G and B it is 100mA (@ duty cycle of 10%).
How is the brightness related? 5mA through R about the same brightness as
5mA through B and G?
Basically if I use a duty cycle of 10% do I have to drive the R's with a scaled down current or use the same current for all three? (here I'm talking about getting the same approximate brightness so I can mix colors properly)
The luminous flux versus current is specified somewhere in the datasheet (you'll find its linear in a large region). You should control the currents so the luminous flux is equal for all leds to get white light. Ofcourse, the currents should stay within the limits.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn\'t fit, use a bigger hammer!"
--------------------------------------------------------------
Actually, I'd be a little careful of this "definition" of white light.
I'm working from old memory (decade old, really, and since my own memory isn't what it once was....) but the human eye perceives "power" using the y-curve (CIE has x, y, and z curves), which is a monochromatic filter function. How much of that particular curve's area is filled by some LED distribution relates to perceived brightness (candellas as coupled to your eye.)
While the y-curve is about brightness perceived and simultaneously a part of color perception, it's not the only part of color. Memory serving, photopic color perception isn't merely a matter of setting up equal areas under the y-curve for different distributions, because in the case of color perception itself all three curves are involved, resulting through the CIE 1931/1964 standards in two new X,Y values that are plotted out on the CIE 2D graph. Where that point lies in relation to the chosen white point (for LEDs, not infrequently the point called D65) isn't determined so simply. Well, at least, I certainly had a lot more work to do that that, as I recall, in order to match up with the standards used world-wide. And if it is a bit of a distance away from this point, humans will perceive instead the coloration that is developed by drawing a line from the D65 point through the (x,y) coordinate and intersecting with the CIE curve.
On the other hand.... it might be good enough for horseshoes.
The data sheet should have typical luminance figures for the individual LEDs. The luminance figure includes typical light sensitivity of the CIE standard human eye model (sort of like A-weighted sound levels). Sometimes RGB LEDs include multiples of one color to compensate for lower visible brightness of that color.
Here's a typical high power one (@350mA)
B : 3.5cd R : 8 cd G : 15 cd
So, if those ratios held for your LED, the limiting factor would be the Blue LED (10mA average/100mA peak), and you'd run the Red at around 44mA and the Green at around 23mA. In fact you'd have to fool with them a bit to get them exact, or use duty cycle, which behaves more linearly.
When you get to finer considerations, the efficience of each LED will vary with current and temperature (and from unit to unit).
In general you will need different average currents on each of the LEDs to get the same visual brightness. you can do that by varying the current and/or the duty cycle.
I'm trying but it's hard to get precise without precision components/hardware. It's not a huge deal though as I am just using a fixed subset of colors but I need some idea about the maximum magnitudes I'll need.
e.g., I will define colors as an 3-tuple that specifies the duty cycle for each component of the maximum current.
So (1,1,1) should be white (0,0,1) would be all green etc...
I also want to maximize brightness but if the same current doesn't give the same individual brightness I'll need to figure out the best way to handle that discrepancy. e.g., I could run each component on different integrated drivers so they run at different currents that compensate for the differences.
I guess it is not all to critical and maybe I can get a rough estimate by eye(I'd rather have some device that measures "Brightness" though)
I'll look at it again. I did see some lumens vs something but I didn't see it for individual components.
Going to try to play around with the LED's I have too.. hopefully there are not to much of a variance between them. It's not too critical since I can compensate for the differences but I need figure out the maximum current I'll be using for all 3(which I guess will be the maximum for the red).
The green and blue ones will be more efficient if driven continuously.
You probably have to adjust current by eyeball to get a decent white - and hope the colors mix well. You probably want less current for the blue one than for the other two colors.
The LED could have viewed color vary with angle from which you view it.
I think the best way to get predictable balance on control of the R B G mix is to use around full drive current with PWM to control the output. I think that's what Spehro is getting at with duty cycle.
On a sunny day (Wed, 21 Jan 2009 23:41:46 +0000 (UTC)) it happened snipped-for-privacy@manx.misty.com (Don Klipstein) wrote in :
I find the idea interesting. So yesterday night I connected 3 LEDs in series on a 9V battery. All new high efficiency LEDs, although I have no datasheets from these. Red, green, and blue. I then pointed those to the same spot on a white piece of paper. So, as in series, each has the same current. The result is very very blue: ftp://panteltje.com/pub/rgb_leds_series_white_img_0837.jpg
Now in color TV, 'white' (Y) is encoded as .3 x red + .59 x green + .11 blue This has to do with the human eye sensitivity curve versus frequency.
It looks indeed as if I have to reduce blue intensity _a lot_. What I want to solder together one of these days is a simple PIC with 3 PWM outputs driving those 3 LEDS, and RS232 in, accepting the appended list.
So you can then send for example 238 232 170, and get the color 'pale goldenrod', or ask for 'pale goldenrod' and the LEDs are set that way. Should not be too difficult to program, hope PIC is big enough for all those strings... that table is 17371 bytes... mmm, need external memory or bigger PIC perhaps. Or put the table on the PC side and just send the numbers, using a small PIC.
This is part of the Linux distribution, and as such copyright of Xorg, and likely GPL: The values are 0 for dark to 255 for full on, for R, G and B. ! $Xorg: rgb.txt,v 1.3 2000/08/17 19:54:00 cpqbld Exp $
You don't need to store the entire table as raw ASCII.
For a start, 11 bytes (3+1+3+1+3) for the RGB is excessive.
If you don't need to reject invalid values, you can just store an array of RGB triples indexed using a hash of the string. 657 distinct strings @ 3 bytes each = 1971 bytes.
Even if you need to store all of the strings, there's a lot of scope for compression. gzipping the raw table comes out at 1715 bytes; I don't know how much space a gzip decompressor would take, but LZW is pretty trivial (and no longer patented).
You may be able to improve compression further by taking advantage of the nature of the data, e.g.:
You can lose 101 entries if you equate grey/gray in code.
You can omit the versions with spaces (their RGB values are identical to those without spaces) and strip spaces on input. Or omit those without spaces and skip the space when checking.
You only need [A-WZ0-9] (no X) without case sensitivity, 35 values = 5.17 bits/char = 6 chars in a 32-bit word.
If you store the table alphabetically, you can use an encoding which takes advantage of similarities in consecutive entries (e.g. a code to indicate that the first N characters are identical to the previous name).
Or just find yourself a "demo" coder; a decent one could probably get both data and code into less than 1KiB.
X is MIT-licensed, which means you can do what you want so long as you don't remove any copyright notice or warranty disclaimer. You'll find the same file included with commercial versions of X.
On a sunny day (Thu, 22 Jan 2009 15:55:39 +0000) it happened Nobody wrote in :
Good idea, hash table. I have done that before, have to look up some old C code. Also have some PIC hitech C somewhere, may just work.
What is a 'demo' coder? I like to try the algo that Mr Delorie published here some time ago for the PWM (add values each interrupt tick and use carry to drive LED). Will likely be a PIC 16F648A or a PIC 16F690, as I have those laying about.
It shouldn't because the Mcd value is already corrected for the human eye. If you have good RGB leds and have them output an equal amount of Mcd you should have (something very near) white. At least it works for the RGB lamp I designed last year...
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn\'t fit, use a bigger hammer!"
--------------------------------------------------------------
PS I decided to do the color selection at the PC end anyways, as xforms already has exactly the selection GUI as a demo: ftp://panteltje.com/pub/xforms_color_browser.gif That is .....xforms/xforms-1.0/demos/colbrowser So I only need to modify that a bit, and add the RS232 output (all already written one time or the other). And then I can do the PIC PWM in asm, using the smaller PIC, the 16F648, and leave my PICs with ADC for other purposes :-)
That xforms library is way cool for technical and even advanced non-technical stuff:
formatting link
Use it for all my PC programs. Those who use a MS product will have to move to Linux. Maybe tonight I finish the PC side code, and the PIC code in the weekend?
Someone who codes demos, programs with some kind of "l33t" factor but no practical purpose.
There exist competitions for writing such programs. Traditionally, the programs were judged subjectively according to which had the flashiest graphics. But this can turn into a contest over who has built up the largest library of graphics algorithms. To compensate for this, competitions started imposing relatively tight size limits.
This created spin-offs where the objective was pre-determined, and the code size was the sole measure of success. So you might have a competition where the objective is a DOS .com program to draw a simple image (e.g. the Norwegian flag or the "radioactive" symbol) on an 320 x 200 x 8bit screen, with winning entries using only a few tens of bytes.
It doesn't make sense to store the strings in the PIC. You can write a small program on the PC side, which does the translation, if you want the user to select the names, and which sends the RGB values, only.
You are right, for a decent demo coder 1 KiB is already very much, see e.g. my Arabeske program, which needs 181 bytes:
formatting link
formatting link
Unfortunately it doesn't work any more on Windows Vista (because of the required fullscreen mode), but it works fine on DOS, Windows 98 and Windows XP.
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.