OPT4048DTSR incorrect CCT reading

Sensors
1

Hello,

I purchased the OPT4048DTSR sensor.
While the lux measurement seems to be correct. CIE x, CIE y, and therefore CCT also seem to be incorrect.
For example I get:
CIEx: 0.48
CIEy: 0.35
CCT: 1893.74

However, I know that results closer to real ones should be in this range:
CIEx: 0.44
CIEy: 0.41
CCT: ~3000

Is it a configuration issue? Any parameter settings?
Please help me get the correct results.

2

Eh, I just have some general suggestions:

  1. Calibration: The sensor may need proper calibration. The OPT4048 typically requires calibration to account for variations in manufacturing and to adjust for specific light conditions.
  2. Optical considerations:
  • Ensure that the sensor’s aperture is clean and unobstructed.
  • Check if there are any reflective surfaces near the sensor that might affect readings.
  1. Integration time: Adjust the integration time settings. Longer integration times can improve accuracy but may reduce the sensor’s ability to handle rapid changes in light conditions or maybe not be linear across different frequencies.
  2. Gain settings: Verify that the gain settings are appropriate for your light conditions. High gain can improve sensitivity in low-light conditions but may lead to saturation in brighter environments.
  3. Light source characteristics: The type of light source you’re measuring can affect readings. Ensure you’re using the sensor in conditions similar to those it was designed for.
  4. Temperature effects: The OPT4048 can be sensitive to temperature changes. Ensure the sensor is operating within its specified temperature range as well.
  5. Power supply stability: Ensure a stable power supply to the sensor, as voltage fluctuations can affect readings.

To address these potential issues:

  1. Review the datasheet and application notes for the OPT4048DTSR for specific calibration procedures.
  2. Experiment with different integration time and gain settings to find the optimal configuration for your use case.
  3. If possible, compare your sensor’s readings with a calibrated reference device to help narrow down/identify discrepancies.
3

I found the same thing, where the CCT from the OPT4048 was impossibly low, and this after I had tried using the APDS9960 which also gave incorrect results. But Texas Instruments has much very credible documentation and the OPT4048 does seem to be designed to give correct CCT.

So I spent much time carefully reading the TI OPT4048 datasheet
(dated December 2022) and checking each step of how the SparkFun library processes the data. I found two things:

  1. On page 35 of the datasheet, the first term of the CCT equation is given as 437n³, but at the bottom of the SparkFun library file sfe_opt4048.cpp the equation starts with 432 * pow(n, 3), so the 432 in this library must be changed to 437.

In practice, this correction only changes the reported CCT by a few percent, so didn’t fix the problem.

  1. The bigger problem is the matrix math. Equation (8) on page 18 of the datasheet shows the required calculation, where the vector of colour readings from the OPT4048 must be multiplied by the cieMatrix. The “for” loop does not do the matrix math correctly. I couldn’t figure out how to index through the readings, so I kept it simple and the fix is to replace the “for” loops in BOTH getCIEx() and getCIEy() in sfe_opt4048.cpp with:
x = color.red * cieMatrix [0][0] + color.green * cieMatrix[1][0] + color.blue * cieMatrix[2][0] + color.white * cieMatrix[3][0];

y = color.red * cieMatrix [0][1] + color.green * cieMatrix[1][1] + color.blue * cieMatrix[2][1] + color.white * cieMatrix[3][1];

z = color.red * cieMatrix [0][2] + color.green * cieMatrix[1][2] + color.blue * cieMatrix[2][2] + color.white * cieMatrix[3][2];

To get my sketch to use the corrected sfe_opt4048.cpp file I copied all six files in the SparkFun library (OPT4048_Registers.h, sfe_bus.cpp, and so on, including the corrected sfe_opt4048.cpp) into the same directory as my .ino Sketch file, and because the #include “SparkFun_OPT4048.h” in my Sketch uses “” and not <>, the corrected library file will be used instead of the original library file.

The reported CCT now is much more believable.

That was a mighty interesting puzzle.

4

That is some mighty-fine detective work! Post this as an issue in the github to alert the engineering team for that library of the problem(s)!

Again, great work :slight_smile:

5

Done, that was my first github post, thanks for the suggestion.

6

Thanks a lot for your answer. There was indeed a mistake in the algorithm. Your solution works perfectly!