Track My Order
Frequently Asked Questions
International Shipping Info
Mon-Fri, 9am to 12pm and
1pm to 5pm U.S. Mountain Time:
Chat With Us
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 = 760 nm reading
spectrum = 730 nm reading
spectrum = 705 nm reading
Denote the bin number with the maximum reading as peakBin.
We also use an array storing the actual bin frequencies:
frequency = 760
frequency = 730
frequency = 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.
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:
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.
Have you tried our Example 5 - it addresses this. Be sure to reduce your integration cycles.
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...
Hi Captain - A user found a bug in the library a few days ago. We fixed it so you should be able to use the Arduino library manager to update to v1.0.1 of the library. Please create an issue on github if you're still having a problem.
Awesome! I'm making a little analyzer with this and a Pixel 2 from Rabid Prototypes. Data looks much better now, thanks!
If you've found a bug or have other constructive feedback for our tutorial authors, please send us your feedback!
Forgot your password?
No account? Register one!