Does anyone have experience with retreiving or deducing cct from the rgb sensor from the nano ble sense?
or have an idea on how best to approach this?
thanks, Jan
Does anyone have experience with retreiving or deducing cct from the rgb sensor from the nano ble sense?
or have an idea on how best to approach this?
thanks, Jan
What have you tried? How do you plan to calibrate the sensor?
There is lots of useful and easily found information on the web, for example Map Colors of a CIE Plot and Color Temperature Using an RGB Color Sensor | Analog Devices
It is more about differenences than about actual values, so calibration is not that important, as long as a deviation is fairly constant over the range.
I am hoping there is already some code available somewhere..
The sensor returns values for R, B and G, and it is trivial to compute differences from two sets of measurements.
To get started, look for example code to read the sensor.
Ok, I will start with that, tnx.
I did that and noticed that r, g, b, and c have maximum values of 4097, when defined as int.
In the library I do not see any min or max values for the output. From the datasheet of the
APDS-9960 I get the impression that the output per channel is 2 byte (65535).
Does anyone know if I can read higher values than 4097 and if so, how?
btw I had some problems logging in, but I am janvol2
The ambiguity may be down to which settings are used on the sensor. IDK what library you use and what defaults it in turn uses; you'd have to look into this. See the datasheet, page 20, bottom table. As you can see, the integration time affects the full scale range, according to the formula: CountMAX = 1025 x CYCLES
The library is Arduino_APDS9960.h
The code I use is from the library examples: ColorSensor.ino
the board is Arduino nano 33 BLE sense
I do not see anything I can influence the CYCLES with.
Do I miss something?
Why should that matter?
If you can read R, G, B values from the sensor, you can estimate the color temperature by fitting them to the color temperature curve.
This possibly useful example uses a Python program to fit 8-bit RGB values and modify an image to illustrate the effect.
Lines 59-60:
// set ADC integration time to 10 ms
if (!setATIME(256 - (10 / 2.78))) return false;
It's hard-coded. You could modify this, or create a new function that allows you to set the atime/integration time and call that after begin(). The fact that you're using a library doesn't mean you're limited to what it offers. In this case, the library is limited in its functionality as you can see.
Thanks. That's true. But I want also lux values and since outside lux values can differ between 0 and 100.000 it would be nice to have a higher resolution.
The integration time in the library was probably selected for sunlight illumination, about 100K lux.
For more control over the sensor you need to add options to the library, or choose another.
thanks for the example!
I see, more or less. But I don't consider myself qualified to change the library as a copy.
If you could help me, great. if not, I will see how far I get with the existing 4097.
Progress is made and I can now measure the Kelvin value of a lightsource.
I have a question on Ambient light measurement now..:
I use a light source Dali dt8 controlled, When I swipe from 2700K to 6500K and measure the output in Lux with a standard meter, it stays practically the same of the whole range.
When I look at the ALS output of the ble sense, it is 35% higher at 6500K than at 2700K.
What is the explanation for that fact?
Things get complicated, fast.
There's a couple of things that make this tricky.
First, color temperature is very simply put the blue/red ratio of a light source. This becomes relevant later on.
Second, lux is a measure that's weighted for the sensitivity of the human eye. This means that green light registers high on the lux scale, while the same amount or irradation (in w/m2) in longer (red) or shorter (blue) wavelengths will produce a lower lux value. The weighting is done (AFAIK) according to the human photopic response, which is like this:
Note a high sensitivity for green, which drops off on both sides. The explanation is in the sensitivity of our rods & cones, and likely is not the clean bell curve shown above, but this is what we end up using in practice.
Third, a color sensor like the AMS etc. also has its own, unique spectral sensitivity. Here it is for the sensor you're using:
From here: https://cdn.sparkfun.com/assets/learn_tutorials/3/2/1/Avago-APDS-9960-datasheet.pdf
Fourth, your controllable light source has again its unique spectral output. I assume this is a LED-based light source, and these basically consist of blue LEDs with a phosphor that converts some of the blue light into longer wavelengths. Warm white LEDs have a lower output of blue, while cool white LEDs have a higher output, like this:
Now, if you shift the color balance of the light source, what really happens is that the mixing ratio of cool and warm white LEDs is being changed. Effectively, this increases or decreases the blue peak you see in the image above. After all, changing the height of the blue peak automatically changes the balance between blue and red, and that's what (roughly speaking) defines color temperature.
If you now relate this to the spectral sensitivity of your light sensor as well as the photopic curve (which is relevant for a lux measurement), you'll recognize that, to put it bluntly, it's pretty much a crapshoot what readings you're going to get.
You could calibrate your light sensor (using the code you write and by reading the color channels separately) to the light source you're using so that it more closely matches the readings you get with your lux meter. However, if you use a different light source (e.g. sunlight, which doesn't have the characteristic valley around 500nm/cyan that white LED tends to have), you may find that the readings are different once again. You're essentially running into a variant of metamerism.
Like I said, things can get complicated when it comes to color. I'd suggest to decide how deep you need to dive into this in order to solve the practical problem you're facing; trying to get to the bottom of it will take years of study (and you'll end up with several PhD's only to realize you still haven't figured it all out!) Try not to overshoot the mark; satisfice instead of optimize.
Thanks very much.
I took your exp;lanation and warnings at heart and proceeded making the code to work in practice and it did. Since the judgement is in what you see happening, that is what I used as reference. It worked.
The major difficulty i encounter now is the fact that at low light levels, the 256 bit pwm will not do the job, when mixing colors. I read some things about fast pwm and mbed os, but I do not know how to proceed.
So far I know how to work with the arduino IDE and how to make use of the language reference guide.
I don't mind learning, but on what should I best focus for this?
What is the job, and what is the problem?
sorry, I mean 8bit, of course.. if you have low duty cycles, you can not mix colors properly, be it rgb or cw/ww.
Depends. You'd have to answer this first:
I.e. for what purpose are you mixing colors, and what's going wrong when doing so, involving low duty cycles? At what point does the problem occur, i.e. below which duty cycle? What phenomenon/problem are you running into when doing so? What PWM frequency are you using and what hardware and sketch are you using to PWM what kind of light source (please provide schematic)?