ZBasic Forum

...or lux, candelas, nits, candlepower, illuminance.

In doing some research for a suitable LED for a project of mine, I'm learning all about luminosity. I think I've got it right, but if anyone would like to offer knowledge and/or advice, I'd appreciate it.

What I've got so far is thus:

A Nit is a measurement typically used for LCD displays (i.e. laptop computer), with a value of around 1000 considered to be sunlight readable. Technically, a Nit is 1 cd/m²) (1 candela per meter²).

A Lumen (lm) is also a measurement of light output related to the candela, although my specific understanding about their relationship is a big foggy.

LEDs are typically rated in either millilumens (mlm) or millicandela (mcd), with the latter being more common.

When calculating the luminous intensity of an LED, one must take into account the area of the emitting surface. For a standard 5mm LED with a frontal area of 19.6 mm²), and a rated output of 200 mcd, I calculate 10204 Nits. Is this right? Sounds high to me, although if I were to arrange a bunch of the above mentioned 5mm LED's into a square measuring 1 meter per side, it would certainly be sunlight readable, even ignoring the emitting area lost in the spaces between them.

Now, how does this relate to Lux? I have no idea. Still working on that one.

-Don

Several thoughts, which you may well have already considered:

From a practical standpoint, depending on your application, to actually see the led as being on or off, the contrast ratio of the two states, and of the led and its surrounding panel / enclosure is important. A matrix of yellow leds mounted on a high gloss yellow panel, for example, would provide a very poor contrast ratio and a poor display, regardless of the led's intensity. Mounting them in a black grommet, or black mounting ring, accentuates the contrast, and one's ability to see the on state. Another example is the red benzel on a red led clock radio. The benzel appears black, and hides the circuitry. When the led segments are on, it transmits the red light, and gives a higher red on black contrast than would perhaps otherwise be present. Active camouflage is a related topic.

Note well the dispersion characteristics of the led's lens. It, too, impacts greatly the ability to see the on / off states, and the angle from which the viewer can make this distinction. A control panel led for an operator sitting directly in front of it is far different from viewing an alarm led from an angle, from across the room, or seeing an led on a vehicle light bar.

You have probably seen the multitude of led driver chips available these days. Depending on what you are using the leds for, they may make life much easier!

JC

Thanks for the input JC

My application is actually rather unorthodox. For right now, I am ignoring the effects of LED viewing angle, as the enclosure will control the dispersion independently of the LEDs' actual field of view.

I agree that contrast is a most important factor. I've found though, that anywhere a panel mounted display is used for something of a mission-critical nature, said panel has already been designed to reduce glare and/or increase the contrast ratio. For hobby projects with brightly colored 'Buy-Me' enclosures, your point is absolutely correct.

The currently available LED driver devices are absolutely wonderful. If you haven't had a chance to play with some yourself, you should. In this project, I'm using a PCA9633 from NXP, which, while perhaps not what you were thinking of, does offer 3 independently controlled channels of PWM for driving LEDs up to 25ma, with a 4th channel available for global dimming. The version I am using is only 8 pins (TSSOP8 package), and utilizes an I2C bus for communication. It requires no external hardware with the exception of the customary pullup resistors on the bus, and biasing resistors for the LED's. With only a few lines of code, I can generate any color using a single RGB led, with no additional processor overhead required. It's saved me the hassle of trying to squeeze 3 channels of PWM from a Mega32 based ZX, and cured my issue of how to globally dim the RGB array.

As far as brightness is concerned, one or more high powered LED and a suitable driver would certainly provide an easy solution. I'm leaning the other way though. Multiple identical LED's, of moderate power, offer the advantage of redundancy. Empirical data has shown me that in bright sunlight, only a moderate amount of power is needed to make the indication recognizable. Perhaps less than I had imagined at first. Further testing should provide some actual math to back that statement up.

-Don

Don_Kirby wrote: ... I can generate any color using a single RGB led...

We have a 3-color LED source in development now, and I can tell you that you can create any color that is inside the device's locus; you cannot generate _any_ color.

The attachment shows the palette possible with 380/520/700nm, for example. Also, one of the three LED colors should be normalized to 100% on; only two values need to be adjusted for color.


Tom

GTBecker wrote:you cannot generate _any_ color.

Of course you are right. I had a bear of a time trying to get the darned thing to emit black...

Seriously though, I did have a hard time getting a bright solid yellow that didn't have hints of orange or green in it. The palette you posted seems to reinforce that.

Would you agree that the least (apparently) bright color should be the one that is normalized to 100%?

-Don

Don_Kirby wrote: Would you agree that the least (apparently) bright color should be the one that is normalized to 100%?

No, the opposite; normalize the largest and scale the remaining two accordingly.

Suppose you want to mix the proportion 2:3:4 RGB. You could send those values, directly, to 8-bit PWMs to see (2/256) : (3/256) : (4/256), which will be very dim, but the right proportion. The same color, but one f-stop brighter results from 4:6:8 RGB, and the brightest possible mix of that color will be 128:192:256 RGB, or 50:75:100%.

This does not consider, BTW, "white" balance of 1:1:1, which we've done with resistors; white can be done in code, but you'd need 16-bit PWMs.

With only 8-bit PWMs, resolution is very important, we have found.

Don_Kirby wrote:... I did have a hard time getting a bright solid yellow that didn't have hints of orange or green...

Some of that is due to the physical construction of the RGB LED. Its simple lens can't equally control the radiation cone of three quasi-point sources, so the colors don't blend homogenously; it's more like a Venn diagram, actually. We are using multiple LEDs in determined orientations to reduce that effect.

OK, That makes sense. Thanks for the explanation.

I am, in fact, using 8 bit PWM, so my whites are only as close as I can get them, which for my purpose, is white enough.

I have long since given up on clear, milky, etc... LED lenses. I've taken to using a diffuser lens to mix the colors outside of the LED package. While I am still married to the particular LED dice within the RGB LED, I can control the mixing fairly well. The results, while not absolutely perfect, are definitely passable. In a .75 x .75 inch array of 4 LEDs, I can't differentiate between the LEDs, much less the individual die.

I think, in the case of my struggle for yellow, I am most likely hitting the resolution limit.

-Don

> ... a diffuser lens...

You've built an indicator, or an illuminator?

An indicator.

-Don

Don_Kirby wrote:Now, how does this relate to Lux?

We're doing an illuminator now, but FWIW, I did a variable-intensity LED display for a project not long ago. The display needed to be just bright enough to be clear under bright noon to dusk conditions, and visible only to the operator. That required an ambient light sensor that had the same view as the operator, on the back of the display, to maintain contrast.

As I recall, we found 11 stops of brightness range, just beyond 10 bits, a convenient PWM number. We found that a specific stack of filters greatly improved contrast, too, of the alphanumeric LED points and the surrounding voids. The dynamic range to assure contrast is what we found worked.

The device can display intensity values, too, as a diagnostic. I believe I displayed pseudo-Lux initially, but later just showed 0 to 4095 "iu", an arbitrary unit that was convenient. Folks apparently thought it meant International Units, maybe something akin to Lux, and never asked about it.

Don_Kirby wrote:I can generate any color using a single RGB led
-Don

It is true that you can not generate the full spectrum of colors with a single RGB LED.

But....

The human eye can not respond to EVERY color either. Just as a RGB LED can only generate 3 separate colors of light that get blended, the human eye responds to colors only with a few types of color receptors.

At its simplest, the eye responds to 3 different colors of light and then the brain blends these to create the perceived color. If there is some odd spike in the spectrum that is not visible, then the spike is not observed.

In real life, unlike the LED's, though, the response spectrum of the individual optical pigments in the eye are not razor sharp. So, the eye does better at achieving a broad spectrum of response.

In principle, if you had a LED that emitted light at the exact center of each optical pigment, then you would be able to blend those signals to create nearly every color able to be observed by the human eye.

-Tony

spamiam wrote:... If there is some odd spike in the spectrum that is not visible, then the spike is not observed...

Hmm; so if a sound is not hearable, then the sound is not heard. Yes, that's true. Surely, that can't be what you meant to say.

Can you provide an example?

GTBecker wrote:Hmm; so if a sound is not hearable, then the sound is not heard. Yes, that's true. Surely, that can't be what you meant to say.

Can you provide an example?

Well, it IS more or less what I meant to say. I can dredge up the specral responses of the receptors i the eye. But needless to say they are not equally sensitive to all wavelengths. There are peaks and valleys and some limited overlap on some of them, but I as I remember, not overlap in all the spectrum. In a region where there is no overlap, then a spike is either going to be missed (if nothing responds to that spectrum), or misinterpreted if only one pigment picks up the spike.

I will look for a reference.

-Tony

[edit]
Here is one reference to the real basics:

http://www.hhmi.org/senses/b120.html

Here is another one, a little less basic, but still can overview.

http://en.wikipedia.org/wiki/Color

One of the key parts of the passage is: "Although the spectrum of light arriving at the eye from a given direction determines the color sensation in that direction, there are many more possible spectral combinations than color sensations"

This is the start of the issue of misinterpretation of the color. The issue of total lack of response requires much more detailed spectral response maps of the visual pigments. Needless to say, they are more "spikey" than the general curves shown in the referenced passages. There are certain narrow ranges on the spectrum that are not nearly as responsive than neighboring wavelengths. This is particularly true in the blue portion where there is less red-green overlap.

-Tony

My 2 cents to add fuel to the fire...
Note also that physiologic systems, (humans), are all unique. Individual specimens have different retinal configurations, and hence would actually perceive the same input differently. Usually it doesn't matter.
Note too that the retinal differences are before one takes into account color blindness, which can be of variable degrees, and involve different colors, as well as changes to the eye's lens, such as through glaucoma, which acts as a front end filter, as would (sun)glasses.

For a human interface, or even for a video display, I'm not sure that the ultra-fine resolutions available matter much. Similar to a residential thermostat that can resolve temperatures to 1/10,000 of a degree. Technically interesting, but not of practical significance.

It is the niche market in such things a photography, image analysis, flame chromatography, etc., where resolution matters, not the warning light flashing on a panel.
JC