Comments: Spectral Triad (AS7265x) Hookup Guide

For what it's worth, I've been using this with a Pixel2 from Rabid Prototypes, it's very impressive.

One thing that others might find helpful is the ability to measure the actual wavelength of an LED or what have you, even if it falls between the channel bins. This worked well for me:

First, you need to be sure that there is a single dominant wavelength. This can be done by comparing the maximum value of any channel, and ascertaining that there is no more than one other value greater than about 10% of that, and that it is from a channel adjacent to the maximal channel. We'll base the wavelength on the ratio of these two readings (or just the one reading if it falls at the center of a channel)

The relative response of each channel can be approximated as a Gaussian function with the following parameters: (curve fitted from spec sheet)

response = exp(-1 • (nm - center)^2 / (2 • 9^2))

The spacing (delta) between channels varies between 25 and 50 nm. This method will only work with spacing less than about 30, maybe 35 nm as there needs to be some response overlap. Fortunately this covers the visible spectrum pretty well.

Save the readings in an array as follows:

spectrum[0] = 760 nm reading spectrum[1] = 730 nm reading spectrum[2] = 705 nm reading …

Denote the bin number with the maximum reading as peakBin.

We also use an array storing the actual bin frequencies:

frequency[0] = 760 frequency[1] = 730 frequency[2] = 705 ...

If the secondary peak wavelength is above (shorter wavelength) than the dominant peak, c = 1, otherwise c = -1.

Finally, note the nm spacing between these two bins and calculate the following two values

a = 0.0026808 • delta^2 b = 186.51 / delta

These were determined by plotting the ratios of calculated channel response with different spacing and curve fitting the result.

Now, given appropriate readings (one or two adjacent channels reading much higher than all the others) we can approximate the actual wavelength:

wavelength = frequency[peakBin] - c * (log10(spectrum[peakBin + c] / spectrum[peakBin]) + a) * b

Of course the accuracy is limited by the tolerance of the bin centers (±10 nm).

I used this to measure a low pressure sodium vapor lamp and read 589 nm, dead on the D-line doublet.

I also measured a series of LEDs with the following results

Min Measured Max 730 742 740 nm 650 657 660 nm 620 629 630 nm 600 599 610 nm 585 595 595 nm 520 521 530 nm 495 498 500 nm 460 472 470 nm 455 452 460 nm 445 449 450 nm 420 426 430 nm

I hope this is helpful to someone.

sorry for this very basic question; I'd like to disable the bulbs but I'm not clear on exactly how to do this, I see the example: void disableBulb(uint8_t device); but I'm not clear how /where one uses this in a sketch in order to disable all three LED's (I'm analyzing light through a filter to see the wavelengths emitted and so don't need the LEDs)

The tutorial should probably point out that the library examples return data organized alphabetically (i.e. by sensor), not wavelength, which threw me off until I read the datasheet. To get data in spectral order use: A,B,C,D,E,F,G,H,R,I,S,J,T,U,V,W,K,L.

Does anyone know how to convert the spectral data to CIElab values ? I have one on order and need to convert. Thanks.

Hello to all! I have a question about the measurements method. I do not get from the banana shell image as you publish I would like to know whether the data of the detector are transmitted without any action such as subtract the dark values or logarithm operation on the output.

For those wanting to use this with a Raspberry Pi (or other linux embedded computer), I've started working on a Linux / Raspberry Pi library for the I2C interface: https://github.com/jdesbonnet/as7265x

I'm having an issue with this library. The reading of all 18 channels takes about 600 ms, so about 50 ms per channel, every time the code is fully blocking. I already set it to continuous mode, which makes it a bit faster, but that time no response to my buttons. Short of using interrupts for the buttons (which doesn't work for one of them as GPIO16 on the ESP8266 doesn't have an interrupt - no other pins available) this really is an issue. Any way around this? Short of writing a function that reads a channel at a time, then returns, and on the next call takes the next channel... that'd bring down the blocking to about 50 ms at a time. It seems that this is the time the sensor needs for a calibrated reading.

When I tried checking out the triad, I get the data from only the AS72652 chip repeated three times. Blocking out the other two sensors doesn’t change anything, but blocking the x52 chip makes all the readings go to zero.

And if you look at your Banana Scan data in Google docs, the columns of data for 435, 585, and 760 nm are identical, down to the hundredth place! The only columns that don’t follow this pattern have 7921.65 in one place and 921.65 in another, my guess is a typo.

This is really cool hardware, but I think this is a bug somewhere...