Spectrometer modules for LED lighting analysis

[theatrus]

Hi! You may remember me from other threads in various places, like the LEDBrick DIY puck and high density stars, plus drivers and the Apogee SQ500 sensor PAR multimeter interface board.

Many moons (months) ago, I dropped some money into a GroupGets buy for a pair of Hamamatsu Micro-spectrometers.

They can resolve light intensity between 340-780nm in up to 15nm increments. They are not cheap ($180 on groupgets, qty1), but are a lot cheaper than other commercial pre-packaged light spectrum units that employ an actual spectrometer (and not a coarse approximation using an RGB light sensor). The actual absolute light intensity level is not specified (designed for relative or ratiometric measurements), so it likely wouldn't make a good PAR meter without a ton of calibration, assuming it had any repeatability of output.

The sensors promptly sat on a shelf for awhile, until now.

The goal is to make a breakout/interface board for the units, USB and/or BLE (wireless!) and do some tests on LED lighting fixtures to see how it performs.

Stay tuned for some ideas, parts, etc.

 

[theatrus]

First things first, we need to figure out how to drive and read the spectrometer. There are two key diagrams to consult - the suggested application and the timing diagram.

The application diagram shows several key signals, some of which the meaning isn't clear at first. After reading through the rest of datasheet, you can generally make out the following pins:

* Video - the spectrometer is like a 2d camera - it is an image sensor in a line after all. Video represents the actual output, as an analog signal, of the sensor.
* Gain - an input, to select the gain
* CLK - A clock input
* ST - A start trigger
* EOS - an end of line/scan indicator - when this signal changes, you reached the end of the sensor

Now, the timing diagram:

There are a few takeaways:

* The sensor needs a clock signal, of a fixed frequency. Based on the datasheet, it need not be very high (0.25 - 200kHz).
* The sensor has an integration time, that is, how long it is accumulating light in its internal cells before allowing them to be read out. This is the period between ST pulses, which means the sensor stores the light l\
evels into a buffer on readout.
* A new video pulse is available every 4 clock cycles. The video pulse is available by the second low clock transition.
* When the sensor is done, it drops EOS for 4 clock cycles.

So, what do we need to use this?

* An A/D. We need to be able to take the voltage from the VIDEO pin (from 0.15-3.3V) for every wavelength as we run the CLK pin. Ideally, this is a 14-16 bit A/D.
* A timing generator where we can produce a CLK rate, and a ST pin timer, at up to 800kHz. We also need to be able to read the A/D at 200kHz, synchronized with the above clock.
* A buffer op-amp - as the output of the sensor is very high impedance, and many types of A/Ds put a large load (relatively) on the signal, we need to provide a simple voltage follower.

In the next installment, I'll look at some interface potentials.

 

[dacianb]

Nice initiative and good luck with it.

But, be aware of the 15 nm resolution of the sensor (together with cmos noise will be a bit higher).
Image bellow is a measurement of a white LED with a PRO spectrometer - look at 440 nm range (where the blue peak is located) - only 10 nm further and you have less than half of power.
With such a sensor you may just miss peaks and will have very eronate readings actually.

Yes, those sensors works for "flat spectrum" lights, but on narrow bandwidth emitters as LEDs are not great.

 

[theatrus]

The peaks should integrate into the relative pixels, no? I'll be able to tell that there is a peak between 450-458 (for example), just not that it's peaked at 451nm (if I had 1nm resolution). The total energy of that peak would be captured, just in a wider bucket.

(It's possible I am misunderstanding the principle of operation or how the diffraction grating is affecting the end result).

The resolution would be useless to bin LEDs by, but plenty to both compare LED lighting mixes and even use it for color grading / looking for fluorescence in corals (hit a specimen with various light sources, record spectrum)

The typical resolution is up to about 8nm from the data sheet, which is a nice bonus. I'm not too concerned with sensor noise as for the most part light levels available are very high.

 

[theatrus]

Quick update as I plan things out.

For the main microcontroller, I'm going for the successor to the Nordic nRF51 I used on my LEDBrick BLE controller, the nRF52832. Easy to make this portable on to a phone or tablet via Bluetooth LE.

http://infocenter.nordicsemi.com/in...r.nrf52/dita/nrf52/chips/nrf52832.html&cp=1_3

http://infocenter.nordicsemi.com/pdf/nRF52832_PS_v1.0.pdf

Bluetooth 4.2, Cortex-M4F (tasty FPU), 512KB of flash, 64KB of RAM, up to 64MHz.

The Bluetooth firmware blobs ("SoftDevices") are actually fairly straight forward to integrate with and the example applications work well.

In order to save some time and make any radio emissions concerns much easier when assembled, I'm going to use a pre-certified module, specifically the Rigado module which is ~$11 on DigiKey, and absolutely tiny:

https://www.rigado.com/product/bmd-300/

I did some rough (rough!) modeling using http://www.polycase.com/kt-40 as the case, which easily fits the sensor and the LED array (for reflection/fluorescence measurement). The plan is to mount them to small right-angle carrier boards internally so they become end mounted.

There is enough clearance between the case and the board to fit an average small Li-Poly case (which are around 0.20"+ thick).

For power control, I'm planning on using the LTC3558 (http://www.linear.com/product/LTC3558) which offers charging, and two switching regulators in a tiny 0.4mm pitch QFN20. The first buck will feed the radio / main microcontroller, and the buck/boost will feed the 5V rail for the sensor, after passing through a high-PSRR low-dropout linear regulator to avoid feeding any noise from the boost converter back into the analog signal path (http://www.analog.com/en/products/power-management/linear-regulators/adm7170.html)

And for those of you who like the Arduino ecosystem, the nRF52 that I'm designing around is now part of the new Arduino Primo:

https://www.nordicsemi.com/eng/News...Pair-using-Nordic-Semiconductor-nRF52832-SoCs

 

[Nonya]

Did it ever materialize?