If you are a recurring visitor of this blog you probably know that the detector in the Raman spectrometer is the TCD1304DG linear CCD, driven by an STM32F401RE nucleo board. If not, you do now. And it looks like this:
The firmwares for the STM32F401 are stable, and I’ve not encountered any problems or bugs in neither the SPI- nor the UART-version.
Each firmware has its merits.
The UART-version is usable with any computer with a USB-port, but because of the limitations of the ST-link’s implementation of a virtual com port it’s rather slow and cannot achieve frame-rates much higher than 1 Hz. This is not a problem for Raman spectroscopy which will probably require long integration times anyway.
The SPI-version is fast, but requires a raspberry pie or something else with an SPI-controller. The frame-rate can be as high as 125 Hz (or higher still, with a slight modification of the DMA-setup). This is high enough that it can be used for glowstick kinetics.
But regardless of the firmware, the nucleo board is not tailored for reading the CCD. The CCD output needs conditioning to match the input range of the ADC, and a (very) cheap development board like the nucleo doesn’t include that.
I’ve tried to do the signal conditioning on the TCD1304 circuit board:
While very cramped it works. However it didn’t do anything positive (or negative) for the noise that always seems to be present, even with very low noise voltage regulators like this (here there’s no opamp for signal conditioning):
the noise is still there:
ok maybe it doesn’t look super-noisy, but in this graph (which is one of the cleanest) the baseline is constantly fluctuating ±4 mV. 8 mV doesn’t sound like a lot, but it’s actually a magnitude higher than the resolution of the ADC (and it’s evident from the data, that it’s not the register imbalance of the CCD in play).
So after a few different PCBs (with and without opamp) the conclusion is that the noise is inherent to the nucleo board. Whether it’s the board’s layout or the choice of voltage regulators I don’t know, though Bertrand in Switzerland suggested that it could be the connection and choice of wire between the nucleo and the CCD (he’s most probably right).
Anyway, it’s great to have an excuse to try something new, and here is the substitute for the nucleo board¹:
It’s an STM32F405RG on a 4-layer PCB, with discrete power planes for the digital and analog parts of the board. All regulators have a noise level of 20 µV (that’s 40x beneath the ADC’s LSB). The analog section features a ±4.65 V power supply for the four AD8027 high speed, low distortion, rail-to-rail opamps (not fitted).
The circuit around opamps U0 and U1 looks like this:
(correct for the supply voltages) and the simulation like this:
(sorry for the mess of the circuit). The blue trace represents the signal from the TCD1304 in the LDO-version of the PCB. The green trace is the conditioned signal, inverted and scaled to fit the range of the ADC.
The plan is to use STMicro’s USB-driver to attach the board as a virtual com port. So far the DfuSe bootloader appears to be working, but I’m back to scratch for getting my compiler to produce working binaries.
Being an absolute dummy with makefiles this may take a while..
Update: I hugely overestimated the troubles I would have with this last part. I can’t even remember what I changed in my f401 makefile (though I do know I did change something).
The board is working. At least my blinky works, and initial speed test with a timer yielded a timer clock with the expected 72 MHz. Which means that the clock configuration is correct:
 The board is inspired by the STM32F4Stamp and I’ve tried to follow all recommendations in the datasheets and application notes for every component. Still I’m sure there’s room for improvement.