is there a formula for each color in a RGB LED ?

Hi,

I'm running 1 totally basic 5 m CC RGB led from 3 pwm pins (NANO).
I'm running the led without resistors (don't ask... breadboard donations accepted... so I make sure that I never analogWrite values over 128.

My question is if there is a formula that tells me how much of each color I must pwm in order to get the same light level (lumens?) from each color. I have red that different led colors produce different quantities of light for the same power.

As this is a totally anonymous led, all I have from the seller is (yes they mixed up, V and mA)

Current : 3V
Voltage: 20 mA
Size: 5mm
Light Color: RED, BLUE, GREEN

I don't expect to anything exact, only a generalization.

Would a test with a LDR produce any useful data ? I don't know if a LDR is more sensitive to any color in particular.
But I'm thinking that I could connect a LDR between 5V and an analog ping placing it just by the led and then analogRead from the pin with the LDR for each pwm level sent to the led. Not sure if I'm making myself clear

thanks in advance

ocsav:
I'm running 1 totally basic 5 m CC RGB led from 3 pwm pins (NANO).
I'm running the led without resistors (don't ask... breadboard donations accepted... so I make sure that I never analogWrite values over 128.

That doesn't matter what values you write. When you analogWrite 128 the pin spends half of its time at 5V and half of its time at 0V. Using a smaller value with analogWrite does absolutely zilch to alleviate the need for a current limiting resistor.

you are right, of course, I forget that pwm is not a variation of voltage, how stupid am I...

ok, from the light side now I know that this led can take the 5v.

ocsav:
ok, from the light side now I know that this led can take the 5v.

The LED will take just about whatever you throw at it. It's the pin on the board you are going to fry.

My question is if there is a formula that tells me how much of each color I must pwm in order to get the same light level (lumens?) from each color

No.

Ok.

I've been reading around and from Led's Magazine I got a relation between R, G and B, which, if I understood correctly would be 2.77 : 5.79 : 1, ok, but I don't understand how to apply it.

If I got a color, say rgb(255, 153, 51) I would end up with 706.35, 885.87, 51.
How do I convert this relation to PWM levels between 0 and 255 ?
No point in trying just do a mod, even if the PWN levels were linear, but they are not.

I got a relation between R, G and B, which, if I understood correctly would be 2.77 : 5.79 : 1,

No you didn't understand it.
What do those numbers mean? Current, power, light output?

Any relationship like that can only apply to one specific make of RGB LED and only if you know what the numbers mean.

As I understood it, it was the relation needed to produce a standard white, and as they were not talking about power my guess is that it will be light output.
The article goes into a lot of detail that I don't understand and it's probably only interesting for a few, but here's the link anyhow: Led's Magazine

And yes, I understand that any relation will be particular for one type/maker/model/batch of led but it would be better than nothing, I'll be happy if I can get "generic" reddish yellow when I ask for an orange. That would be better than greenish blue that I'm getting now.

If you're trying to get orange and getting green-blue then the issue isn't some esoteric formula. You have the LED wired wrong or you have the code wrong.

Thanks for the link

my guess is that it will be light output.

Yes it is.

It tells you how to calculate the current:-

Next, we must return to the LED data sheet. You can estimate the drive current required to produce the desired luminous intensity using the drive current vs. light output graph in the LED datasheet (Fig. 4). Using the example graph, the drive currents required to produce the desired luminous intensities for the three emitters are approximately 8.8 mA for red, 10.5 mA for green, and 4.2 mA for blue. These current requirements can be used to determine the hardware component values used to bias the driver ICs and the variable values used to set the output range of the LED driver software.

So I repeat without a data sheet for the LED you are wasting your time.

And yes, I understand that any relation will be particular for one type/maker/model/batch of led but it would be better than nothing,

Sorry but no, it is not better than nothing.

I would tend to agree with Delta_G's remarks. If you ask for a colour with the red LED on and you are getting a colour with the red LED off then it is wired up wrong.
However, if all the LEDs are on and we are talking about tints of white then this is only to be expected if you simply guess at:-

1. The actual colours of each LED
2. The relationship between LED current an luminosity for each LED colour

Your best bet is to simply drive each of the LEDs ( and their resistors ) with PWM and control the brightness of each one with a pot. Put one LED up to maximum and try to get a white by controlling the other two. This will then give you the PWM ratio to mix. Without a data sheet this is the only way, unless you have equipment to measure the individual wavelength of each LED.

Delta_G:
If you're trying to get orange and getting green-blue then the issue isn't some esoteric formula. You have the LED wired wrong or you have the code wrong.

While in most cases I'd agree, I know the wiring is ok.

My rgb() function is nothing more than

#define RED 3
#define GREEN 5
#define BLUE 6

(...)

void rgb(byte rr, byte gg, byte bb)
{
    analogWrite(RED,rr);
    analogWrite(GREEN,gg);
    analogWrite(BLUE,bb);
}

And the wiring is ok (still need to add the resistors) because calling rgb(255,0,0) produces a full red, rgb(0,255,0) produces a full green and rgb(0,0,255) produces a full blue.
However the light from the blue and specially the green is so much stronger than the red that trying to get orange with rgb(255, 153, 51) (this is an orange in html) produced a greenish blue with a clear RGB led.

I tried to diffuse the led using white nail varnish because looking at the led was hurting my eyes but it changes to much the color, it's impossible to get anything that looks like orange, any combination with a predominant red just looks like salmon. I'll try diffusing it using sand paper.

ocsav:
rgb(255, 153, 51) (this is an orange in html)

But you're using an RGB led and not a computer screen. I wouldn't expect html colors to work here.

What I did, and it worked pretty well, was to use three pots to adjust the RGB until I saw the color I wanted and then wrote down the numbers that made said color.

Grumpy_Mike:
Your best bet is to simply drive each of the LEDs ( and their resistors ) with PWM and control the brightness of each one with a pot. Put one LED up to maximum and try to get a white by controlling the other two. This will then give you the PWM ratio to mix. Without a data sheet this is the only way, unless you have equipment to measure the individual wavelength of each LED.

Yes, I'm going to do that, I don't see other solution. Time to choose what project to sacrifice in order to get a breadboard...
I can try something like rgb(rr, (int)gg/x, (int)bb/y). And run some loops on x an y, but the pots will be much easy.

One question, Is it ok just to add 220R resistors to each pin or is it important to use exact values (I don't see how, I don't have forward voltage values for this leds)?

Delta_G:
But you're using an RGB led and not a computer screen. I wouldn't expect html colors to work here.

Oh! I didn't know that.
I assumed that being both additive processes the basic relation that produces an orange in a screen whould still be valid with leds, but that it would be necessary to include a factor to compensate the fact that the 'dots' for each color produce very different "amounts" of light.
So that's the reason because there are so many "systems" to represent a color, rgb, hsl, xyz, and so on. I haven't look into these other representations, I assumed that rgb would be the right thing for a rgb led.

ocsav:
I assumed that rgb would be the right thing for a rgb led.

Yes it is. But the lights that make up a computer screen are not the same as the light that you have, so the mixes aren't going to be the same. The mixes aren't even going to be the same between two different RGB leds. And if you'll pay close attention and look at a few colorful webpages on different computers, you'll find that it's not even the same for the html from screen to screen.

Is it ok just to add 220R resistors to each pin or is it important to use exact values

It is fine to use the same values because you compensate for different brightness in the PWM value.
Ideally you would play about with different resistor values to give white when they are all full on, but that is a bit more tricky to do.

There are some colours that you can get on a computer scree that you can't get on an LED. Brown is one of them and orange is tricky. I did once try to get all the colours of the resistor colour code on LEDs but I failed, you just can't get some colours. The other thing that makes this tricky is that the eye responds not only to the colour of the LED but also the colour of the background when it makes up it's mind what colour you are seeing. This famous optical illusion illustrates the point nicely.

illusion.png1200×928 55.7 KB

Squares A and B are the same colour.
From Optical illusion - Wikipedia

thanks, great info here.
I had no idea that there were colors that you coudn't do with a LED, brown, of course, never thought about a brown led... I want to ask why but I'm going to look for it.
I know that it's almost impossible to get GOLD on a monitor, but I've seen some quite good goldens.

Anyway, I'm trying to do the thing with pots, I've been trying for hours and no luck, the analog pins that I try to read return a lot of noise, specially on the pot that controls de red led.

Here's the circuit

I tried a few variations, a 10k resistor from pot to GRD instead of a direct link, a capacitor between the 0% and 100% pins... Nothing, I must be doing something fundamentally wrong.

And here's the code.

int potR=A0, potG=A1, potB=A2;
int potRval=0, potGval=0, potBval=0;
int Rv=0, Gv=0, Bv=0;
int lastRv=0, lastGv=0, lastBv=0;
char s[16];

int redPin = 9;
int grnPin = 10;
int bluPin = 11;

int redVal = 0;
int grnVal = 0;
int bluVal = 0;

void setup()
{
  pinMode(redPin, OUTPUT);
  pinMode(grnPin, OUTPUT);   
  pinMode(bluPin, OUTPUT); 
  Serial.begin(9600);
}

void loop()
{
  potRval=analogRead(potR);
  Rv=map(potRval,0,1024,0,256);
  //delay(5);
  
  potGval=analogRead(potG);
  Gv=map(potGval,0,1024,0,256);
  // delay(5);
  
  potBval=analogRead(potB);
  Bv=map(potBval,0,1024,0,256);
  // delay(5);
  
  
  if(Rv != lastRv)
  {
    lastRv=Rv;
    analogWrite(redPin, Rv);
  }
  if(Gv != lastGv)
  {
    lastGv=Gv;
    analogWrite(grnPin, Gv); 
  }
  if(Bv != lastBv)
  {
    lastBv=Bv;
    analogWrite(bluPin, Bv);
  }
  sprintf(s,"%d,%d,%d",Rv,Gv,Bv);
  Serial.println(s);  
}

The green and blue are more or less ok, there are ranges where they flicker a bit but probably that's normal.
But the red one is giving me nightmares.
Not only it flickers a lot at low values, the red pot somehow affects the other pots.

With all pots to the left, I have values 0,0,0, with all the pots to the right I have 255, 255, 255.
I start to turn the red pot to the right, at some point the values from the other pots start to get affected, for example

167,5,5
167,5,5
167,6,0
165,0,0
167,5,5
167,14,5
167,5,6
165,0,0
165,5,5
167,5,5
167,5,5
167,0,0
165,0,5
167,5,5
167,5,5
167,6,0
165,0,0
167,5,5
167,13,5
167,5,6

And this keeps changing without me touching anything.

It's quite interesting to use the Serial Plotter in the Arduino IDE, but the fact is that I have no idea about what I'm doing wrong.
Another strange thing, with the serial output reporting a consisten 6, 0, 0 I see flashes of blue and green, it looks that somehow the red current leaks to the other colors... I tried another led (some batch, same seller) and it do the same thing.

Here's the circuit

No it is an insufficient part of a physical layout diagram, you should post it all.
What value of pots do you have they should be 10K or smaller?
How have you routed the ground? Their should not be a part of the ground that passes the current from the LEDs through the analogue return path.

The code looks fine if a little over long for what you want to do. There is no need to only output if you see a change just keep writing. Just use a delay to control the printout speed.

You have to click in the image, the thumbnail crops some at the sides, I was passing the GND for the cathode with a single wire on the left of the board. I did it like this because of the holly dogma "there must be only one" (ground). 8)

BUT in an inspired moment I decided to move the wire, I moved it to a hole closer to the cathode of the led and noticed that the flicker pattern changed, so I went further, I connected that GND rail to the other GND pin in the other side of the nano (using the same wire). Well, the flickery totally vanished, everything is working as it should I can control each led, green is still quite stronger than red but I can get some nice oranges... There is no more interference from the red pot in the other pins.

By the way, the pots are not 10k, they are 100k which is all that I have at the moment.

Was I in some way, overloading that GND pin ? Even is I was shouldn't it be electrically connected to the other GND pin ? Why does this make a difference ? Should this teach me to connect all the GND pins available in a MCU to a common bus to make sure that any (what? noise?) is spread as much as possible ?

The values in the analog pins are not yet 100% stable, but now I have sequences of 40 or more X value and then one X+1 or in other cases X-1 (but never X, X+1 and X-1), and then another 40 or more X... I guess this means an intermediate value between X and X+1 or X and X-1. Is there a way to mute the sensibility just a bit ?

I thank you guys, you have been a great help.

rgb3pot_bb-2.png936×699 135 KB

You have to click in the image, the thumbnail crops some at the sides,

This is how you post images here image guide

By the way, the pots are not 10k, they are 100k which is all that I have at the moment.

That will explain why changing one pot affected the other values.

Was I in some way, overloading that GND pin ?

No.
It looks like the long ground was propagating interference to the pots, which being 100K, are more susceptible that 10K pots.

I did it like this because of the holly dogma "there must be only one"

Sorry that is not correct. Sure avoid ground loops, but grounds must meet all at the same point. What you did was make that point the Arduino, which is good.

You will always get a +/- 1 reading from any analogue to digital converter. You can take averages if you don't like this, and changing to 10K will make it more stable.