Other sites of interest

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

  • http://thepulsar.be/
    A belgian chemist and optical engineer who does many different things from counting bubbles to building thin film refractometers.
  • http://www.astrosurf.com/buil/
    A subsection of the astrosurf site with a lot of information for building spectrometers. (There’s lots more on the astrosurf site itself.)
  • http://randombio.com/
    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.

 

Advertisements

(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:

spectrograph-mirror-mounts

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:

geometry-overview

Here a few of the mirrors are in place:

1st-spectrograph-with-mirrors

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:

lille-my

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 tcd1304.wordpress.com)

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

Momodulo

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:

DSC02630

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:

1p

One single integration.

15p

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.