DIY spectrometer (AS7341 based)

How about the light in your refrigerator?

You probably need a diffuser over the sensor, all spectrophotometers have one.

:+1:

This may pair well with Gcharts DIY Lux meter.

Yes, it’s on the things-to-buy list.

AMS also distinguishes between emissive and reflection for their eval kits:

Emissive

Reflection

Without diffuser I’m basically using an emissive lightsource while the sensor is in reflection mode. Recommended is the Kimoto 100 PBU (125 microns, 66% transmission, 89.5% haze, 35.5 degree half-angle).

But off course, thanks! Silly me, the whole house, including the freezer has led. But the fridge is old and still has incandescent.

The official dev kit looks to be a no go. I hooked it up to the FTDI break out board as follows:


SK - Connect to SCL
DO/DI - Wired together and connected to SDA (I2C pull ups are on the sensor board)

The AS7341_EvalSw_ALS application detects the board (error msg without board), but fails with some power on issue (tried both channels). Too bad, but worth a try.

Todo… need to switch to the reconstructed spectrum method to get CRI guesstimates;

And some needed data:
Coordinates in both CIE 1931 xy and CIE 1976 u’v’ for both the black body locus and daylight locus, listed by 10K and 1K CCT increments
CRI or Ra TCS spectrum data in 1 nm, 2 nm and 5 nm increments

A minor but interesting detail concerning the eval software. After going through the manual, the select device popup should only happen when there are multiple cables attached. Not the case for me, so I figured maybe it doesn’t recognize it at all. It uses a standard FTDI cable apparently, so I looked up the vendor/product ID, generated a serial and programmed those into the FTDI board. The eval software no longer sees multiple cables and goes directly to the error message.

“Error during setting power on.” means “Error occurred. Set the PON bit in the Enable register (0x80).” Seems I2C communication is not working. I’m guessing this is the 1st thing that’s send out. In my software this is the 2nd thing it does, after checking the AS7341 chip ID.

Another quick update on getting the evaluation kit software up and running; no success. I’ve tried everything I could think of, looked at all the schematics and tried various ways of hooking it up. Just keep hitting that power on error message. To verify that the board and sensor actually work, I even quickly hacked one of the FTDI examples to see if communication with the sensor was possible (e.g. request chip ID). That worked fine. Currently at a loss why this it not working with the eval software. Would have been nice if it worked, but alas. Moving on for the time being.

Btw, any thoughts about this type of diffuser (another one) Doesn’t have any specs to speak of, but probably better than nothing.

Status update: I’ve added auto gain (sensor internal auto gain) and it seems work as it should. The sensor no longer saturates. But (there’s always a but), it seems that the CCT results are way off. They’re too high (e.g. 3500K is reported as 5500K) and I haven’t found a solution yet. The raw values seem to be ok, but then a count get’s calculated that serves as basis for all other calculations.
To calculate the count, an integration time is needed, which in turn depends on the gain used. My guess is that something is off there and I haven’t found the solution yet. I’ve gone over the datasheet many times and there’s nothing obvious there. Count calculation is the same for manual and auto gain, yet the result is way off when using auto gain. I’ll have to look at that later, but for now the garden/house needs some care. So I won’t be working on this for a few days.

For those interested, I’ve uploaded the code to GitHub Note that this is a work in progress, probably has bugs, does not yet produce reliable results and is NOT an end user grade application.

I’m keen to give it a go with Python :innocent:

From the Opple thread:
There’s an introduction to the Adafruit AS7341 and some examples using CircuitPython here:

AMS have a user guide for an AS7341 evaluation board that mentions calibration and CIE1931 XYZ Target Transformation. You may need to determine appropriate correction factors to apply.

https://ams.com/documents/20143/36005/AS7341_UG000400_5-00.pdf

The raw values for each frequency bin could be stored in some spectral power distribution object using the colour project for Python and then the CRI can be calculated:
https://colour.readthedocs.io/en/develop/generated/colour.colour_rendering_index.html

Get the boards I mentioned above. It’s relatively cheap to get going :wink:

I’ve looked at the Adafruit code. The problem is that they don’t go beyond basic functionality (e.g. reading raw values and print them to screen). They’ve added all registers, but don’t use them. Such is the case with auto gain.

Also when not using own readings, all calculations yield the same results as the AMS application notes. I’ve used their example readings as input and the result matches. So it’s unlikely that part of the code is the problem. Disabling auto gain provides believable values, hence my belief something is wrong with how I handle readings done with auto gain.

Edit:
Did a quick and dirty fix. When taking a reading, it 1st takes are reading with auto gain enabled to determine the best gain factor. Then disable it and take the real readings. Much better results. Needs some optimizing, but later (e.g. less SMUX channel switching). Using channel F8 for the time being since that seems to have the highest raw values (even though F7 has the highest irradiance responsivity).

Ordered Adafruit AS7341, Adafruit QT Py and some cables. :beer:

Awesome! Would be really nice if we can develop some sort of BLF spectrometer that’s better than the Opple :sunglasses:

I’ll see if I can create some CSV files that have the calibration matrices. Then they can be shared and don’t need to be created multiple times. Don’t know about Python, but it’s not too tricky to read those in C.

Edit:
XYZ and spectral calibration matrices (taken from AS7341_AD000198_3-00.xlsm aka “AS7341 - from ADC to LUX and CCT”).

Note that there are 3(!) different versions (“Based on Full, Production-Wide Device-Characteristic Dataset”, did device characteristics change over time?);

  • v1.1 (2019-02-13)
  • v3.0 (2021-04-28)
  • Initialization data that comes with AS7341_EvalSW_ALS_v1-26-0.zip

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.