Replacing the STM32F4 nucleo

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:


[1] 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.


Other sites of interest

Here’s a list of pages I find interesting (occasionally steal inspiration from):

    A belgian chemist and optical engineer who does many different things from counting bubbles to building thin film refractometers.
    A subsection of the astrosurf site with a lot of information for building spectrometers. (There’s lots more on the astrosurf site itself.)
    T.J. Nelsons site contains information about lens and spectrograph design.

The list is so I don’t forget about these resources (because I’m sure I already forgot some). Feel free to send me more links.


(my) Latest spectrograph advances

With my girlfriend out of the flat for a few days, it was time to finally do something about the spectrograph. If you’ve been looking at my hackaday projects you may know I’m trying to make a Gil-Simon spectrograph.¹

Much like nuclear fusion reactor technology, my Raman spectrometer has been close to completion since the beginning, and right now I’m closer than ever, and I have the pictures to prove it:


All mirror mounts approximately in their final positions.

As evident from the photo, I’ve become quite adept at anodizing aluminium.

The geometry of the spectrograph is more apparent here:


Here a few of the mirrors are in place:


In the vertical mount: Two 90° off-axis parabolic mirrors (OAP).
In the top center kinematic mount: A 25,4mm elliptical plane mirror.

The mirrors work: The reflection of Little My is caught by mirror on the aluminium angle on the right and focused by the two OAPs:


Unfortunately my 3D printer is out of commision for the time being, so for the time being, I cannot print a mount for the grating..

[1] M. A. Gil and J. M. Simon, “New plane grating monochromator with off-axis parabolical mirrors,” Appl. Opt. 22, 152-158 (1983)

Evermore convenient

My new (used) laptop is killing me. The f#$@%%# track-pad is messing with me even though it’s disabled in BIOS. Laptops are not made the way they used to back in the good old IBM days.

Where am I going with this? Well, the graphical user interface for the UART-firmware requires lots of petting of the mouse (track-point), and real men and women don’t touch filthy animals, they use the terminal.

The GUI was just so convenient for doing quick test reads and display of the data, so I’ve often used it. Of course it’s only convenient until you want to change the parameters, or the tty changed or ..insert own nuisance, then it’s the hell of click-this click-that).

So here is the new Otterly CLI with gnuplot preview

and stay tuned, despite a long stretch of inactivity on-line, I have some stuff coming to a blog near you in the not-so-distant future.

(oh yeah there are also updates to the SPI-firmware and CLI, so check out the downloads section and changelogs at

High-framerate (125 Hz) TCD1304 firmware

Until now, the benefits of using a raspberry pi’s SPI-interface, compared to simply using the built in ST-link’s UART-over-USB to fetch the data collected by nucleo+TCD1304, has been negligible.

But thank dog for x-mas holidays, as it’s given me enough time to do a proper upgrade of the SPI firmware.

The long story short is, that while SPI is more than 100x faster than UART, the SPI-firmware wasn’t designed for multiple readings. A quick back-of-the-envelope estimate of the time required for one recording is:

  • Command upload time: 4.2 ms
  • Timer reconfiguration and CCD flushing: 15 ms
  • A/D conversion time (entire CCD) 7.4 ms
  • Data download time: 4.2 ms

Total: > 30 ms

The left the maximum possible frame-rate at < 33 Hz

This has all changed now:

Continue reading


Despite the silly title, the work behind this post was quite tedious. I’ve been asked to do an advanced science project for the students at my high school, and what better than to have the little ones construct a spectrograph (this is not the tedious part, but it’s for another post).

To this end I’ve redesigned the PCB for the TCD1304 to make it more student friendly. It really just means that I’ve replaced the 10-pin IDC connector with a 6-pin 2.54mm Mini-PV connection. Oh yeah and the TO-92 2SA1015 transistor has been replaced with the same in an SOT-23 housing. And here it is:


Continue reading