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).
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.
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.
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.
Get the boards I mentioned above. It’s relatively cheap to get going
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).
Awesome! Would be really nice if we can develop some sort of BLF spectrometer that’s better than the Opple
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.
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
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.