DIY spectrometer (AS7341 based)

This is the one I’ve seen used, it appears to be a combination of those two:
n = (x - 0.3320) / (y - 0.1858)
CCT = 449 * n^3 + 3525 * n^2 6823.3 * n + 5520.33

Oh man :smiley: Thanks!

I did do a quick comparison between the AMS and wikipedia one (B35AM 3500K source). The Wikipedia one produces slightly higher CCT numbers.

CCT = 3646K, Duv = –0.012651
CCT = 3733K (wikipedia)

CCT = 3821K, Duv = –0.012644
CCT = 3884K (wikipedia)

CCT = 3702K, Duv = –0.012832
CCT = 3781K (wikipedia)

Btw, I’ve switched from using all channels (excluding flicker) to using only F1 to F8 as input (the clear channel overpowers all other channels, NIR seems pointless for flashlights). Don’t know if and how that affects results. Any thoughts as to what would be better?

This is an awesome project! I’ll have to order myself an AS7341 to have a play with too.

Might be better off getting something like a bit of Lee Filters 250 Shouldn’t be too hard to source small sheets, and probably more consistent than Ali.

And yes, it affects results (provided I didn’t make any mistakes refactoring). AMS excel values as source:

Do you want a reference LED ? I see you’re in EU, I could measure an LED at different current and send it to you in an envelope and the SPDs.

Interesting project! I tried this a couple years ago and got really frustrated with the results, but I’m afraid I gave up too soon. My readings seemed to jump all over the place. I think I tried using a diffuser, but it’s been too long so I don’t remember exactly. I’d love to have another go at this at some point.

Time for another update: I’ve made quite a few changes to the code. Refactorisations and cleanups, bugfixes, added more verification code and the basic calculations for spectrum reconstruction (the large calibration matrix and spectrum to XYZ). So if you have a clone, just get the latest code.

The good new is that readings seem to be much more consistent now that auto gain is used. However, reading are off by about 500K (too low), consistently. This is a bit of a mystery, since the AMS excel gives the same results when inputting the raw readings from the sensor. This leads me to assume all calculations are correct, but the raw readings must be wrong somehow. My guess would be integration time is not correct, since that’s the only thing that I can think of that influences the raw values returned. Needs further investigating.

That would be great for fine tuning, thanks for the offer! I’m in Sweden. Currently still having issues getting the reading close to actual CCT, so it might be a bit premature (see above).

As part of the Eurkatronix group GS5 buy I ordered the whole range of E17A CCTs (sm1863c, sm203, sm223, sm273, sm303, sm353, sm403, sm453, sm503, sm573 and sm653), specifically for test purposes. But they don’t come with (detailed) SPDs. The closest data is the test reports on the website and that’s probably close to the actual LEDs I’ll be getting. If that works out (including a proper physical test setup), I’d love to fine tune using a real reference LED.

Did you use any form of auto gain? I initially had the same issue, just couldn’t get consistent readings, unless I looked at the raw readings and adjusted how I held the flashlight at a certain distance and brightness. Results are much more consistent now that the sensor decides what gain to use. There are slight variations when I move the light sideways, but nowhere near the huge jumps in CCT as before.

Just pushed a change so it uses the ‘higher accuracy’ spectral calibration matrix by default. Define USE_XYZ_CALIBRATION_MATRIX in SpectralSensor.cpp to use XYZ calibration matrix as before.

And for those wanting to output the reconstruct spectrum to CSV, check out the Spectrum::saveToCsv() function. It’s primitive, but it works (need a GUI at some point…)

No, I don’t think I did. I really should dust this project off again and try some more things like that (or rebase it on a newer sensor, like the one you’re using).

Any chance you can (digitally) provide a SPD and corresponding CCT and CRI values? Preferably 1nm steps, but 2nm would be fine as well. Possibly one above and one below 5000K (for testing Planckian and D illuminants).

Reason I’m asking is that I’ve started working on calculating CRI values. Having this data allows me to verify if the calculations are correct based on known values, independent of what the AMS sensor produces.

So for the past few days I've been sinking my teeth into the whole CRI thing. It's a lot of info/data to take in, but I think I'm starting to get the hang of it a bit. Going down the rabbit hole further, but it's interesting stuff. But I've ran into another issue. I've been using Osram's ColorCalculator as a sanity check and found that my CIE1960 v value is way too low. This results (among other things) that the chromaticity distance is too big and CRI results are meaningless. Osram provides a few example spectrums, so I took the included "White (2700K)" and used that as input. If all is well, the result should match right? But nope...

See screencapture. Look under preparing test SPD. And ignore convert output part under Calculating CRI. Most basic values are close enough (CCT, xy and u), but the v value is way off:

Now this makes no sense as the calculation from xy to uv is pretty straightforward. As per Wikipedia the formula is:

In my code this is done like this:

// MacAdam simplified Judd's
double n = 12 * xy.y - 2 * xy.x + 3;
u = (4 * xy.x) / n;
v = (6 * xy.y) / n;

So what am I overlooking?

In the color calculator screenshot it shows u’ and v’ (CIE 1976) not u and v (CIE 1960)

Found the discrepancy! It helps writing stuff down :smiley:

More stuff to learn… Osram uses a different color space: CIELUV

Was typing while you posted, but same conclusion :wink:

Relieved it matches now. Next is taking a closer look at chromatic transform and beyond, since the resulting CRI values are very much incorrect.

(and yes, I forgot the ’ in the printout…)

I went down a similar rabbit trail that lasted several months and ended when my son was born late last year.

The most promising thing I found was a bit more DIY in terms of the sensor, but perhaps useful from at least the GUI standpoint:

The upside of the more involved hardware approach is that your resolution can be an order of magnitude greater than the adafruit sensor. If I didn’t have a Xrite Colormunki, I would have already built one myself.

Interesting concept with that diffraction tube and CCT. I’ve tried to write my software in such a way that it should be relatively easy to swap sensors, so who knows what the future holds :slight_smile:

Btw, current status very slow progress. I did manage to solve a bug that messed with the CRI calculation which was related to how C deals with fractional exponents when raising to power. Before that the results were always close to 100 CRI, no matter what. But it’s still not where it should be, albeit improved, and I’m a bit stuck. I’ve verified intermediate calculations as much as possible, given there’s not really something to compare with at that level. Even found a copy of the CIE 12.3-1995 TR that describes the exact calcs. There’s still some things I need to check such as correct input tables and plankian lotus calcs. And I’ve started implementing daylight spectrum for CRI calcs when the CCT is >5000K. More tables.

Anyway, apart from the above, it will be slow progress for the moment. I’m building a garden playhouse for my son, so that kind of takes up a lot of time. Any spectrometer development is done in between and only if I didn’t get killed by swarms of biting insects, all wanting to suck my blood. Really need one of those automated mosquito zapping lasers…