Cool it

The CCD is cooled with a peltier element (TEC1-03510). It’s sandwiched between the two pieces of anodized aluminium secured to chassis:


Continue reading


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

More average

I’ve not yet discovered any bugs in the march updates of the TCD1304-driver firmware, but that doesn’t mean there’s no room for improvement.

For instance, the time to capture a dataset can be as short as 15 ms + integration time,  but transmission of the same dataset takes more than 642 ms.¹  So if you want to average just two readings, it will take you at least 1.3 s regardless of the integration time.

Wouldn’t it be wonderful if the firmware could handle averaging on it’s own? Well, now it can. You can request from 1-15 integrations, which will then be collected, averaged and sent back to your pc (in that order).

The CCD isn’t flushed between readings as the integration time is the same for each collection. That means you’ll save up to:

15·(15 ms + 642 ms) = 9855 ms

that you can spend doing things you love. But wait, there’s more! To actually make it work the CLI has also been updated:

TCD1304-driver firmware (UART) [sep. 10th 2017]

Otterly CCD CLI (sep. 10th 2017)

On an entirely different note, I’ve changed laptop, and somehow it has broken the Otterly CCD GUI. (Well to be fair it was held together with chewing gum and duct tape.) The program’s not exactly beautiful – not on the outside and certainly not on the inside – but I will clean up the communication functions in the coming days.

Oh and I almost forgot. Here are two captures from my OtterVIS with the new firmware:


One single integration.


Fifteen integrations averaged.

There are all sorts of artifacts present in this spectrum of an incandescent bulb, so it’s not so easy to see the improvement. I will see if can find it in my heart to make a better example.

1 The 15 ms goes to flushing the CCD. The 640 ms is because the UART runs at 115.2 kbps.

DIY optical breadboard

The cake is a lie. This is actually a post about anodising aluminium.

The internet is full of information about anodization/eloxation of aluminium, so I’ll just summarize what I’ve learnt is important:

  1. Current control rather than voltage control
  2. Temperature control
  3. Cleanliness is next to godliness
  4. Work in a well-ventilated area
  5. The alloy is important. I’ve used AlMg3 (5754).


Every single paper I’ve come upon agrees on that a current density of at least 1.25A/dm² and an electrolyte temperature of 20-30⁰ C is required for a type II coating (what you want for nicely coloured aluminium), so current control is definitely needed.

Continue reading

Finally Windows

There’s finally a Windows interface for the TCD1304. It’s not me, I didn’t do it, it’s the work of Jens-Ulrich Fröhlich and it looks like this:


The JFS-OtterVIS running on linux.

Being Java-based it can also run on other OS’s, and I’ve been able to play a bit with it on linux and it looks great. The COM-port system of Windows is of course different from linux’s TTY-system, so I couldn’t actually connect to the nucleo board, but the program can handle both. There’s all the basic necessities like wavelength-calibration, baseline, transmission and absorption, printing, scaling etc, and a very well made help functionality. In other words it has all the stuff and more, that I’ve been to lazy to do anything about myself.