Post by thread:[EE] LED color mixing: RGB...O?

I just bought some LEDs from Digikey/Mouser for a color mixing project I'm thinking of playing around with (why paint when you can light?), but I'm a little confused by the fact that the "matched" LEDs I bought come in FOUR colors: RGB and orange. This is new to me, and you-know-whoogle doesn't have anything to offer. I accidentally bought GBO in my first order, so I picked up some red ones from Mouser (same manufacturer part number, but Mouser doesn't have a minimum order)(I prefer Digikey due to proximity). I have all four- am I "supposed" to use them all? Mike H.

That will probably be so that they can be used in a traffic or automotive application. You can make orange from green and red, but a failure results in a red or a green where an orange should be. ie. It doesn't fail safe (see earlier thread). Traffic lights are the obvious one. It's pretty tightly regulated for roadage signs as well as the colour infers the importance. Steve. On 27 Nov 2006 at 11:03, Mike Hord wrote: {Quote hidden}> I just bought some LEDs from Digikey/Mouser for a color mixing > project I'm thinking of playing around with (why paint when you > can light?), but I'm a little confused by the fact that the "matched" > LEDs I bought come in FOUR colors: RGB and orange. > > This is new to me, and you-know-whoogle doesn't have anything > to offer. > > I accidentally bought GBO in my first order, so I picked up some > red ones from Mouser (same manufacturer part number, but > Mouser doesn't have a minimum order)(I prefer Digikey due to > proximity). I have all four- am I "supposed" to use them all? > > Mike H. > --

Many of the higher-end LED assemblies used for stage and architectural lighting use this mix - they call it RBGA (amber). Some even use white, as well. I guess you get a better mix gamut that way and have more control over the color and how natural you can make the white balance. It's also worth noting that they tend to use 16 bit controls on the PWM for dimming. It seems that fewer bits than this (i.e. less temporal resolution in the pulses) gives you visible steps (quantization errors) at low light levels. Alden Steve Baldwin wrote: {Quote hidden}> That will probably be so that they can be used in a traffic or automotive > application. You can make orange from green and red, but a failure results > in a red or a green where an orange should be. ie. It doesn't fail safe (see > earlier thread). Traffic lights are the obvious one. It's pretty tightly regulated > for roadage signs as well as the colour infers the importance. > > Steve. > > > On 27 Nov 2006 at 11:03, Mike Hord wrote: > > >> I just bought some LEDs from Digikey/Mouser for a color mixing >> project I'm thinking of playing around with (why paint when you >> can light?), but I'm a little confused by the fact that the "matched" >> LEDs I bought come in FOUR colors: RGB and orange. >> >> This is new to me, and you-know-whoogle doesn't have anything >> to offer. >> >> I accidentally bought GBO in my first order, so I picked up some >> red ones from Mouser (same manufacturer part number, but >> Mouser doesn't have a minimum order)(I prefer Digikey due to >> proximity). I have all four- am I "supposed" to use them all? >> >> Mike H. >> --

Bill, Combination of Red and Green gives Orange what's wrong with red? Andre -----Original Message----- From: spam_OUTpiclist-bouncesTakeThisOuTmit.edu [.....piclist-bouncesKILLspam@spam@mit.edu]On Behalf Of William "Chops" Westfield Sent: Monday, November 27, 2006 9:26 AM To: Microcontroller discussion list - Public. Subject: Re: [EE] LED color mixing: RGB...O? On Nov 27, 2006, at 9:03 AM, Mike Hord wrote: > I'm a little confused by the fact that the "matched" > LEDs I bought come in FOUR colors: RGB and orange. Apparently RED leds are a big no-no on commercial equipment; perhaps the OGB selection is for that sort of application? BillW

be interested as well....since I'm using a blue/red LED combo William Chops Westfield <westfwKILLspammac.com> wrote: On Nov 27, 2006, at 9:52 AM, Marcel duchamp wrote: >> Apparently RED leds are a big no-no on commercial equipment; > > Bill, could you elaborate on that one? > Was that tongue-in-cheek or serious? > Serious, although I don't know the details. At some point there was a real fire-drill here to eliminate the use of red LEDs; I suspect some telco or european standard that reserves red for truly "critical" notifications. I'll see if I can find out... BillW

We've had to restrict the use of red leds so that they are only used to indicate a fail or alarm condition. Using them for power-on indication is a definate no-no. I'm not sure which market it came from - possibly Europe. Richard P On 28/11/06, alan smith <.....micro_eng2KILLspam.....yahoo.com> wrote: {Quote hidden}> be interested as well....since I'm using a blue/red LED combo > > William Chops Westfield <EraseMEwestfwspam_OUTTakeThisOuTmac.com> wrote: > On Nov 27, 2006, at 9:52 AM, Marcel duchamp wrote: > > >> Apparently RED leds are a big no-no on commercial equipment; > > > > Bill, could you elaborate on that one? > > Was that tongue-in-cheek or serious? > > > Serious, although I don't know the details. At some point there > was a real fire-drill here to eliminate the use of red LEDs; I suspect > some telco or european standard that reserves red for truly "critical" > notifications. I'll see if I can find out... > > BillW > -

> what's wrong with red? > Here's some of the "discussion" that ensued. An interesting combination of standards, "common sense", typical usage, and urban legend: > [see] http://eetd.lbl.gov/Controls/publications/1621Note.pdf > ===== > I have also heard (but could not find a reference to substantiate) > that in Germany for service providers the color RED denotes that > the equipment is on fire ! This is fairly consistent with the > "emergency condition" mentioned below. ===== {Quote hidden}> Red indicators are used in some industries for specific purposes, > so its probably best if general purpose equipment avoids its use > in case our equipment is installed with or near other equipment > in those industries. When ethernet first became popular, the > blinking red LEDs on many ethernet adapters in the 1980's led > to complaints from some industries. > > For example, the US Military and the telephone industry are very > particular about the use of red indicators on their equipment. > > http://hfetag.dtic.mil/docs-hfs/mil-std-1472f.pdf > >> a. FLASHING RED shall be used only to denote emergency conditions >> which require operator action to be taken without delay, or to >> avert impending personnel injury, equipment damage, or both. > >> b. RED shall be used to alert an operator that the system or any >> portion of the system is inoperative, or that a successful mission >> is not possible until appropriate corrective or override action >> is taken... > > Telcordia GR-2914 has a similar requirements, but they don't have > free copies of their standards on the web. ===== > The theory is to make it easy for craft to take the appropriate action: > red == replace, yellow == test, green == good. There is no doubt > some Telcordia GR on this, but I don't know which one ===== > We heard a rumor about some rule in the EU that banned a red LED unless > bodily harm was imminent, but were never able to find the source. > > We spoke with a number of Cisco people in EMEA that thought this must > be > a joke, and also had one of our compliance engineers look into it - no > one found anything. [but this is not so different from the Mil-Spec listed above for flashing red] ===== > I belive it was NEMA standards - red lights mean "ALARM" so a tech can > quickly identify a device having problems. Someone also mentioned that typical red/green dual-color LEDs are particularly difficult to distinguish for the 7% of males who are color-blind... BillW

alan smith wrote: {Quote hidden}>be interested as well....since I'm using a blue/red LED combo > >William Chops Westfield <westfwspam_OUTmac.com> wrote: >On Nov 27, 2006, at 9:52 AM, Marcel duchamp wrote: > > > >>>Apparently RED leds are a big no-no on commercial equipment; >>> >>> >>Bill, could you elaborate on that one? >>Was that tongue-in-cheek or serious? >> >> >> >Serious, although I don't know the details. At some point there >was a real fire-drill here to eliminate the use of red LEDs; I suspect >some telco or european standard that reserves red for truly "critical" >notifications. I'll see if I can find out... > >BillW > > I wonder if it has anything to do with red being associated with danger? We are currently building a bunch of industrial machinery bound for China. The Italian engineering company that wrote the spec says that all push buttons for the motor starters are supposed to be green for stop and red for start. Pilot lights are to be red for running and green for stopped. Just backwards from the way most of the equipment we build for use in the USA... Aaron

Well, lots of speculation about limited allowance of red LEDs, and that may be the deal. I spoke to an optical engineer friend of mine and while he admits that he has no specific expertise in it, he couldn't think of a good reason, either. Since these things are marketed as being for outdoor signs where they would form discrete pixels, I guess it's possible. It's just odd that of all the "sets" of LEDs, only this one had all four colors. Ah well. I have some extra orange LEDs now. I have a project for them, too. ;-) Mike H.

> > > I wonder if it has anything to do with red being associated with danger? > > We are currently building a bunch of industrial machinery bound for > China. The Italian engineering company that wrote the spec says that > all push buttons for the motor starters are supposed to be green for > stop and red for start. Pilot lights are to be red for running and > green for stopped. Just backwards from the way most of the equipment we > build for use in the USA... > > Aaron > It does make sense though. If red means danger and green means safe. Pressing the red button makes the thing dangerous (ie running) press the green button to make it safe. Western way is red = stop, green = go danger doesn't come into it.

And when did Italy move East - Oh - maybe the spec requirement came from China? But I'm in Shanghai right now and the engineers here say that the emergency stop buttons are always red. It's a bit hard to find out more about the led colours but the equipment here only has green leds showing. On the ATE displays a green colour is used for a pass and red is used for a fail FWIW. RP On 28/11/06, Jake Anderson <@spam@jakeKILLspamvapourforge.com> wrote: {Quote hidden}> > > > > > I wonder if it has anything to do with red being associated with danger? > > > > We are currently building a bunch of industrial machinery bound for > > China. The Italian engineering company that wrote the spec says that > > all push buttons for the motor starters are supposed to be green for > > stop and red for start. Pilot lights are to be red for running and > > green for stopped. Just backwards from the way most of the equipment we > > build for use in the USA... > > > > Aaron > > > > It does make sense though. > If red means danger and green means safe. > Pressing the red button makes the thing dangerous (ie running) press the > green button to make it safe. > > Western way is red = stop, green = go danger doesn't come into it. > > > -

>We are currently building a bunch of industrial machinery bound for >China. The Italian engineering company that wrote the spec says that >all push buttons for the motor starters are supposed to be green for >stop and red for start. Pilot lights are to be red for running and >green for stopped. Just backwards from the way most of the equipment we >build for use in the USA... This is actually the same way around as traffic lights. Think of the colours in these terms - green - safe for humans to get involved, safe to proceed (traffic light) red - dangerous equipment in operation, danger ahead (traffic light) So when you press the red button you are making the equipment an unsafe environment. When you press the green button you are making the equipment a safe environment. The Italians have had things this way around for a long time, and when you think about it being like traffic lights it makes sense.

> >Apparently RED leds are a big no-no on commercial equipment; perhaps > >the OGB selection is for that sort of application? > > This may be due to CE certification, and similar rules > elsewhere. I did a unit that used a red neon indicator as a > power indicator, and had to change it to a green LED to get > by the certification fellow who was checking for CE. > > Red must only be used for an emergency alarm AIUI. Maybe that explains the popularity of blue LEDs. Still, it's pretty cool that you can get green neons (& other colours) these days. Is that what you used? Tony

>Maybe that explains the popularity of blue LEDs. I was told by my Keithley rep that the 2400 sourcemeter originally had a red LED for "output on", but they had to change it, and ended up with a blue one. >Still, it's pretty cool that you can get green neons >(& other colours) these days. Is that what you used? No, I couldn't bet a suitable neon, so ended up using an LED. I wasn't going to go to a lot of trouble, as we were making only 2 units. I just wanted an indicator that showed the mains was on if the switchmode supply went belly up, or a lack of it if a fuse blew. Result was some distributed resistors to drop mains to LED voltage.

On Tue, 28 Nov 2006 09:59:37 -0200, you wrote: >Alden Hart wrote: > >> It's also worth noting that they tend to use 16 bit controls on the PWM >> for dimming. It seems that fewer bits than this (i.e. less temporal >> resolution in the pulses) gives you visible steps (quantization errors) >> at low light levels. > >If you had a log scaled PWM generator, fewer bits would be fine -- most are >not, but it's not impossible, depending on the technology used. > >Gerhard You generally need a minimum of 12 bits, mostly to cope with nonlinearity at low levels - you can take a 256 level value and put it through a linearising table to give a 12 bit PWM value to get a nice smooth fade.

Gerhard Fiedler wrote: > Alden Hart wrote: > > >> It's also worth noting that they tend to use 16 bit controls on the PWM >> for dimming. It seems that fewer bits than this (i.e. less temporal >> resolution in the pulses) gives you visible steps (quantization errors) >> at low light levels. >> > > If you had a log scaled PWM generator, fewer bits would be fine -- most are > not, but it's not impossible, depending on the technology used. > > Gerhard > > Agreed. It's a good idea. A log function would actually be preferable as the lighting level is not evenly distributed across the entire dimming range. I have actually used a mapping table to create a non-linear transfer, but the underlying problem is the resolution of the pulse widths themselves, and what degree of granularity you can control. For example, a 120 hz cycle clock gives 8.33... MS per cycle, which is about 32+ uSec per width increment at 8 bits. Doable for multiple channels with a medium sized PIC. Going to 16 bits takes the pulse resolution down to the 100+ Nsec range - much harder if not impossible (<1 instruction cycle at 20 Mhz). You could use the PWM generators on chip, but then you are limited to 2 control channels - unless you can figure out some clever way to multiplex them. The good news is that this problem only shows up at very low levels (first 6 - 10 steps), and is only visible at very slow fades (e.g. fade-to-black over 10 seconds). You can see this effect in some of the newer LED signs if you watch closely. Evidently the effect is distracting enough that serious architectural and stage controllers use higher resolution PWM. Alden

On Tue, 28 Nov 2006 07:54:16 -0500, you wrote: {Quote hidden}>Gerhard Fiedler wrote: >> Alden Hart wrote: >> >> >>> It's also worth noting that they tend to use 16 bit controls on the PWM >>> for dimming. It seems that fewer bits than this (i.e. less temporal >>> resolution in the pulses) gives you visible steps (quantization errors) >>> at low light levels. >>> >> >> If you had a log scaled PWM generator, fewer bits would be fine -- most are >> not, but it's not impossible, depending on the technology used. >> >> Gerhard >> >> >Agreed. It's a good idea. A log function would actually be preferable as >the lighting level is not evenly distributed across the entire dimming >range. > >I have actually used a mapping table to create a non-linear transfer, >but the underlying problem is the resolution of the pulse widths >themselves, and what degree of granularity you can control. For example, >a 120 hz cycle clock gives 8.33... MS per cycle, which is about 32+ uSec >per width increment at 8 bits. Doable for multiple channels with a >medium sized PIC. Going to 16 bits takes the pulse resolution down to >the 100+ Nsec range - much harder if not impossible (<1 instruction >cycle at 20 Mhz). You could use the PWM generators on chip, but then you >are limited to 2 control channels - unless you can figure out some >clever way to multiplex them. Yes, there is a really neat way to increase resolution without increasing clock. for each PWM cycle ( say 120hz) : You first do all 8 channels in parallel with 32us/step You then do one pulse of 0..31.5us ( on 8MHz PIC) on each channel in turn. This gives you another 5 bits of control at the same refresh rate. The only caveat is that your drivers can switch sufficiently fast. No problem for smaller setups but gets to be an issue whne you are driving big FETs for big LEDs.

>>Agreed. It's a good idea. A log function would actually be >>preferable as the lighting level is not evenly distributed >>across the entire dimming range. > >A u-law or A-law telephony converter comes to mind. Having said that I went investigating, after realising that such a DAC or ADC isn't going to give PWM results. Via http://en.wikipedia.org/wiki/Mu-law_algorithm found this http://hazelware.luggle.com/tutorials/mulawcompression.html which gives some C source code for doing both A and u-law. Don't know that it really helps the OP though.

Robert Ammerman wrote: > My eyes are assuredly not the best, but I once built a three phase dimming > control system (don't ask) which broke each 1/2 into 768 steps (3*256). This > seemed to be enough resolution to avoid discernable step-by-step changes in > light intensity across the entire range, including the low end. > I have seen incandescent dimmer systems work well down to 100 steps - some of the early digital dimming consoles worked like this. It's the LEDs that create the challenges at the low levels because they have no "fade" to smear the steps. Alden > Bob Ammerman > RAm Systems > > > {Original Message removed}

On Tue, 2006-11-28 at 09:51 +0000, Alan B. Pearce wrote: {Quote hidden}> >We are currently building a bunch of industrial machinery bound for > >China. The Italian engineering company that wrote the spec says that > >all push buttons for the motor starters are supposed to be green for > >stop and red for start. Pilot lights are to be red for running and > >green for stopped. Just backwards from the way most of the equipment we > >build for use in the USA... > > This is actually the same way around as traffic lights. > > Think of the colours in these terms - > > green - safe for humans to get involved, safe to proceed (traffic light) > > red - dangerous equipment in operation, danger ahead (traffic light) > > So when you press the red button you are making the equipment an unsafe > environment. > > When you press the green button you are making the equipment a safe > environment. > > The Italians have had things this way around for a long time, and when you > think about it being like traffic lights it makes sense. But using your traffic light analogy it can easily go the other way: traffic light green means "go" -> make the machine go traffic light red means "STOP" -> make the machine stop Neither is more "right" then the other, it's all about the cultural background of the person pushing the button. It is kinda scary that what means "safe" to one person means something the EXACT opposite to another. TTYL

Mike Harrison wrote: > On Tue, 28 Nov 2006 09:59:37 -0200, you wrote: > >>Alden Hart wrote: >> >>> It's also worth noting that they tend to use 16 bit controls on the PWM >>> for dimming. It seems that fewer bits than this (i.e. less temporal >>> resolution in the pulses) gives you visible steps (quantization >>> errors) at low light levels. >> >> If you had a log scaled PWM generator, fewer bits would be fine -- most >> are not, but it's not impossible, depending on the technology used. > > You generally need a minimum of 12 bits, mostly to cope with > nonlinearity at low levels - you can take a 256 level value and put it > through a linearising table to give a 12 bit PWM value to get a nice > smooth fade. That's why I said "a log scaled PWM generator". I meant a hardware circuit that translates eg. 256 linear steps of voltage or time into 256 log scaled steps of time. For example by using a capacitor (dis)charging function. Gerhard