sjyng,
I would not try to power the sensor via the 3.3V on the diecimila’s header, since it can source very few milliamperes. That voltage is brought to the header from the USB-serial converter. Second, you should not connect directly the sensor on diecimila’s I/O, since the latter works with 5V logic, not 3.3V. You must adapt the voltage between them (see one of the excellent tutorials on SFE site for this).
Ciao
Claudio
I really appreciate your comments, araknide.
I’ll check the SFE tutorials on power supply, and read through them.
Ciao,
sjyng
sjyng,
the topic is not about power supply, but adapting logic voltages 3.3 ↔ 5.
Ciao
I got the color sensor up and running, but I’m very disappointed with the lack of resolution.
I have CAP_ set to 0 and INT_ set to 4095 for all colors (this is the maximum sensitivity). I’m not using trim. I’m driving the LED at 8ma (maximum is 10ma). The sensor is 3.2mm from the white reflective surface, and there is no ambient light.
The readings I get are approx. red 110, green 120, and blue 80. I was hoping for at least 8-bit resolution with values at or above 255.
Does anyone have any suggestions?
Thanks,
I am using the eval board and had the same experience as you running the sensor with the original 330r LED resistor and 3.3V. This leads, however, to a LED current of about 1 mA or so. I increased the LED current to about 10mA. Now I can tune the white response to 768 (3x256) with 5 caps and an integration time between 1000 and 2000 on each channel.
Can you perhaps check your LED current keeping in mind that the forward voltage of the LED can be up to 3.3V?
Anyway, even if you have it running in a reasonable range the results, especially with colors like pink or violet, can be surprising. It needs a lot of software compensation to give accurate results. I wonder which accuracy can be reached with the sensor and how big the tolerances between different sensors are.
eugen, what value resistor did you use to get 10ma? I’ve ordered some 47ohm SMD 0603.
Could you explain a little about “software compensation”?
Thanks,
Mike,
With 3.3V on the LED you will not get anywhere, as the voltage drop over the LED can be up to 3.3V and you should never drive a LED without resistor.
Right now I increased the LED current by using a 100r resistor and a supply voltage of about 4.2 Volts. The 2.8V regulators for the power supply of the sensor should be able to take that voltage and the logic lines are still readable for both the sensor and the micro. It’s not ideal and needs to be changed to a 3.3V System for micro and sensor and 5V supply for the LED with a 200something resistor.
Re. Software compensation: Once you have it running, you will find out that the response for the RGB sensors is far from linear, and this differently for each color channel. Furthermore the RGB result is even non-linear depending on the percentage of red, green and blue in the individual color. This means that two colours with say the same amount of red will show different results for red depending on the amount of green and blue in the color. There are a lot of statistics to be made and analysed.
I have an original RAL card (a German coloring system) and some not-too-bad estimations for the RGB value of each color to play with. I am still in the empirical stage and collect data, hoping to find methods of software compensation. Not to mention that I don’t know how another sensor of the same type would react - perhaps completely different. Fortunately for me I do this out of personal interest and not as a commecial project.
Hello Eugen,
I don’t have the development kit, and I’m unable to increase the supply voltage without some serious rework. As it is, the supply voltage is 3.3V, the voltage across the 33r resistor is 160mv, so the LED current is 4.8ma. I’m going to stay with this and try to stabilize this experiment.
When doing a white calibration, I am able to get consistent values. Typically, the CAP_ values are about 6 7 1 and 9. The INT_ values are about 1050 1035 1027 and 525 (RGBW). However, when measuring on a black reflective surface, the values are all about 120.
When I perform a GOFS calibration, the OFFSET_ values are all about -120. After setting TOFS, these values should trim the black values to about 0, but I can’t get this to happen. There is no ambient light during the measurements.
Are you able to get trim working? Can you measure a black surface?
Thanks,
Mike
Hi Mike,
Same here: I do white calibration, all values are around 768 (my chosen maximum), reading is consistent. Cap values are RGBC 5525 and integration times between 500something (clear) and 2000. Seems all well balanced. Btw. I have the cap calues constant, as my initial optimisation sequence made them run away and I was too lazy to fix.
With the GOFS/TOFS business I reach optimisation values of around -110, assuming the data is stored in 2-complement integer. These stay amazingly constant when the procedure is repeated. There is no ambient light near the sensor. My blackest black reading I could achieve was around 25 on each channel which is about 3% of the max value. I tried this on matt and glossy black and on black neoprene. I hoped that the neoprene would scatter the light but still there is a rest. Conclusion: The 0 is not possible with my setup and reflective measurement. To ‘compensate’ for that, medium bright colors are measured way too dark.
I have the feeling that the offsets are irrelevant if you measure reflective and have a lightproof enclosure to do that. I get more or less the same readings over all colors if I omit the offset thing completely and start measuring right after the white calibration.
Which color scheme are you using for verification?
The story continues…
Hello Eugen,
I’m using a black, rubber grommet to seal the color sensor from ambient light. My RGB values for a black surface are about [120 120 120], which is about 12% for each color. On a color picker, [12% 12% 12%] is black. Also, on a white surface with the LED disconnected, I get values [0 0 0].
So, I’m going to assume the [120 120 120] values are actually reflected light from the pigment in the rubber grommet and/or the black reflective surface, and that the sensor is working properly.
As far as color scheme, I would like to find a color pallet with both RGB and HSB (or HSV) values. I should buy the GretagMcbeth color chart, but they are very pricey. In the end, I would like to have HSB values from the color sensing process.
I’m not sure what the “clear” color is measuring. Is it a composite of the RGB values?
Thanks,
Mike
PICAXE has the AXE045 board that uses the TAOS TCS230 rgb sensor.
mike80439:
I’m not sure what the “clear” color is measuring. Is it a composite of the RGB values?
The sensor has different color filters in front of photodiodes. One of them is clear, so it is essentially measuring the brightness of the light, or how reflective the surface is.
I’m not exactly sure how to use it in a program but it’s gotta be useful, right?
I am running into a primitive problem where the Arduino keeps returning the values 4361, 0, 0, 0 repeatedly.
I have performed level conversion and am running the color sensor with a 3.3v zener. I tried the code that was posted earlier and used the address value 0x74(which I think should be the right one) and 0x68 and 0x69 as was suggested earlier.
I removed my sensor and still got the same values, so am guessing its not just the sensor. Any guesses about other things that I should check up on that would lead to a valid reading?
Another newbie question:
I found today that SFE introduced the Logic Level Converter.
Would this be a cure for the 5volt(Arduino Diecimila)-3.3volt(Color Sensor from Avago) problem?
What if I use the SFE’s Skinny or the Lilypad, which is based on the ATmega 168V, instead of the Arduino Diecimila for the Avago Color Sensor Eval. Board for the 5volt-3.3volt issues?
Ciao,
sjyng
First of all, the SFE Skinny should be perfect for running this sensor. You would need no level conversion since you can run them both at 3.3V.
The SFE level converter should be able to do it, but I would have a look at this note on bidirectional level shifting: http://wwwasic.kip.uni-heidelberg.de/lh … N97055.pdf.
Has anyone got this sensor communicating with the Arduino, yet?
I’ve got the sparkfun eval board working with a PIC. The whole system can run at 3.3v so there is no need to worry about level conversions.
The sensor seems to be only slightly directional, which makes sense since it’s just a bunch of photosensitive elements without any optics. One way to make it more directional would be to stick a narrow, opaque black plastic tube over it (I guess I could paint a drinking straw?). Like the sensor is sitting at the bottom of a well.
I have not yet done calibration as the sensor is just waving around on the end of some wires sticking up out of a breadboard right now. But it does seem to give nicely varying readings when I wave my cell phone screen, bag of skittles, and coaster in front of it (very close to it, like yeah 2mm from the surface).
I expect calibrating the sensor to be kind of a pain in the ass, so I haven’t done it yet. If somebody has, please let met know if the following sounds like a bunch of bull or not:
Since I’m just going for hue and saturation reproduction, I just need to characterize the input system (the sensor) and the output system (RGB color space on my LCD monitor), and transform between them.
I’ll do it like this! I’ll take a reddish, greenish, and blueish object, illuminate them with the sensor’s tinyass LED, and visually match the colors in a color picker on my computer. So now I have three RGB values on my monitor that match the objects.
But that’s not enough! I’ll also take readings from the reddish, greenish, and blueish objects on the color sensor, so now I have corresponding sensor RGB values for the objects.
Each set of 3 colors is like a coordinate frame in 3d space, so I can transform sensor readings into the sensor RGB space, and then out of the LCD RGB space: lcdColor = MonitorRGBMatrix * SensorRGBMatrix ^ -1 * sensorColor.
Does that make sense?
I should stop writing and just try this, huh. I’ll let y’all know how it goes.
It does make sense, but I think the sensor is
not linear
bleeds between photosites, so, pure red will also give readings on green and blue.
Because of this two, I don’t think you can really calibrate it, unless someone proves I’m wrong ( which would make me happy, since I have 2 this sensors 
)
Odd that you should say the individual channels are not linear… The application note says it is (that is, the readings should increase linearly with respect to the intensity of the light).
It does make sense that there is “bleeding” into G and B if you shine red light at the sensor, since in the datasheet you can see the frequency responses of the R,G,B sensors overlap. This doesn’t preclude calibration … I don’t think.
First thing - I’ll try to confirm the sensor readings are linear with respect to intensity (using a PWM’d LED at fixed distance). Hopefully it is. Yikes.
Hello everybody,
I suspect also that the sensor is not linear. I hooked it up to a Freeduino board (which is an Arduino Diecimilia). I can get nice readings, although I first had to find out that important parts are missing in the proof of concept code earlier on this forum (the actual data registers are never read with this code, only gain registers are set).
I’m trying to make a device that can recognize stage color gel samples. I use an external white led to get transmissive readings. Ideally I would like to get accurate CIE Yxy readings, but we’re still far from that.
I use so called neutral density gels (grey gels which bring intensity down 1 to 4 stops, like the diafragm of your camera does), so the reading should go down divided by 2, by 4, by 8 or by 16. I use LEE gels 209, 210, 211 and 299, but no similar gels are deliverd by Rosco. You could also use camera filters. I noticed the deviation from the theoretical value gets bigger if intensity goes down, and also that the deviation is not the same for all 4 channels. The 1 stop filter still reads sort of ok (half the max value) but readings are getting much too high as intensities go down, on all 4 channels (even the clear channel). On the other hand, when I switch off the led source, readings are close to 0, so it’s not a simple matter of subtracting an offset value.
Speaking of offset values, does anybody of you had succesfull use of the offset registers on the sensor? When I try to use them, results are way off.
I will try to post more details on what I’ve done by now (including a automatic white balance routine wich calibrates maximum readings to 1000) , but unfortunately I will be away for about two weeks now, so that will have to be done later.
Best regards, Maxx
oops, typo in my previous post: of course Rosco does have neutral density gels…