06/16/2018 at 05:59 •
I've ben working on a custom STM32F405 board with better analog options in a separate project.
The key difference is the utilization of an opamp on the input, to squeeze the last bit out of the STM32F4's 12-bit ADC.
The opamp circuitry looks like this:
For reasons I don't fully understand, the opamp's input and feedback resistor values affect the output from the CCD's typical drive circuit, but changing the resistors to:
there's no clipping of the output. I guess my quantum chemistry professor was right, you can't measure a system without changing it.
12/24/2017 at 16:24 •
With a slight redesign of the SPI-firmware and the accompanying command-line-interface, I'm proud to present a record high (for me at least) frame-rate for the TCD1304 of theoretically 125 Hz.
I'll be conservative and state that 100 Hz is possible. Because of x-mas I'm away from my scope, so a proper speed-test will have to wait.
The very short version of the story is that wiringpi has been replaced in favour of pigpio, and that SPI-communication is triggered by monitoring the logic state of one of the nucleos GPIOs.
Oh and you can collect 65535 integrations in one go.
or look in the source code.
Downloads are available at https://tcd1304.wordpress.com
The UART-firmware is still crawling away at a pace of just above 1 Hz, but with lots more convenience.
11/12/2017 at 14:44 •
The latest firmware and PCB is here:
besides from being smaller, there's now a regulator on the supply voltage:
Vs = 1.22 (1 + R₂/R₁) = 1.22V(1+ 2.7kΩ / 1.2kΩ) = 3.96V
The pinout has been changed:
and so has the GPIOs on the STM32F401re, so everything's much easier to connect:
(The CCD-PCB in the picture is a prototype)
As always go to https://tcd1304.wordpress.com to be sure to get the latest and greatest firmware and software, and instructions to match.
The PCB is available directly from http://dirtypcbs.com/store/designer/details/8475/5829/tcd1304-4v-zip
It's only the UART-firmware that has been updated. The SPI-version will follow shortly.
Both firmwares (SPI and UART) been updated with the new GPIO-configuration:
- fM on PB0
- SH on PA1
- ICG on PA0
- OS on PC0
08/18/2017 at 16:34 •
Jens-Ulrich Fröhlich has written a Java-based graphical user interface for the Linear CCD module for Windows, and I must say I'm impressed. It has many of the features that I wanted to include in my early attempts at a GUI.
And it comes at just the right time. In this school year I will 'convince' my students to try and build their own spectrometers, so a Windows interface is greatly appreciated, as my nerdier students prefer this OS.
Take a look at his blog:
and the github-repository:
05/01/2017 at 13:06 •
It turned out to be very easy to get a working Otterly CCD CLI for MacOS X, as the operating system uses the same underlying tty-system as linux.
It was literally just a matter of getting my hands on a Mac (that was the hard part) and setting up the proper environment for compiling.
One needs to install:
- command line tools
The compiler options need to be modified slightly (link to argp) so there'll be separate MacOS download (shortly).
The tty-naming scheme on MacOS X is confusing. The serial device to connect to is not tty.usbmodemxxx but cu.usbmodemxxx
Of course if you don't care for compiling it yourself, you can just use the precompiled binary. In that case, the only dependency is glib
03/18/2017 at 17:51 •
To make the lives of anyone wishing to use the linear CCD modules easier, I've made a CLI. Hopefully it'll make the software side of things more modular.
In the same time I have given the SPI-enabled firmware an update to give it all the benefits of the improvements to the UART-version, and the two should now be very similar in performance, except of course for the 150x speed-advantage of SPI.
At the time of writing there's only a CLI for the SPI-version of the firmware, but a UART-CLI will follow shortly.
There's of course a CLI for both SPI and UART.
As usual go to tcd1304.wordpress.com for downloads, details etc.
02/03/2017 at 06:12 •
The following notable changes have been implemented:
- CCD fM changed to 2.0 MHz,
- CCD driving GPIOs moved away from ADC-in
- Certain GPIOs pulled down for virtual GND.
- CCD fM is now user configurable at compile time (and all timing requirements are met dynamically)
- ADC sampletime increased
- bugs fixed
For download and more details look in the source code and here: https://tcd1304.wordpress.com
12/28/2016 at 17:46 •
The raspberry pi is no longer strictly needed, as the new UART-enabled version of the firmware allows for direct connection to any (linux/BSD) computer. Using UART will (eventually) allow for "continuous" reading of the CCD and data-driven events.
07/08/2016 at 22:21 •
The firmware was not stable. I experienced crashes. They were infrequent, but still very annoying. Fiddling with the nucleos UART I'd been running into traps of interrupts - there's probably a technical term for it, but I don't know it.
Long story short: The DMA-controllers in the STM32F401RE can run in normal or circular mode. In the normal mode, the DMA stops once the read/write buffer is full. In the circular mode it ..runs in circles and overwrites the buffer from the beginning once it reaches the end.
The good thing about circular mode is you don't have to reinitialize the DMA every time you need to start over. This is especially practical if what you're doing is time-critical ..like say digitizing the output from a CCD.
There are most likely better explanations, but hopefully this gives you a picture of the situation.
The catch, of course there is one, is that the DMA must be suspended if you want a chance to look at the data. I thought I was very clever to that with an interrupt. Piece of cake. Except suspending the DMA causes the same interrupt. Very loopy - yes pun intended.
I spent the entire evening speculating on how to break this loop, and finally, completely off the trail, I found a comment about when to start the ADC with software and when not to.
If you've been over the code you'll know the ADC is paced by one of the nucleo's timers. This means there's no need to start it with software. It also means that the ADC stops when the timer stops. Instead of suspending the DMA in the DMA-interrupt (causing an interrupt inside an interrupt), the DMA-interrupt now disables the timer pacing the ADC.
With the ADC on hold no DMA-requests are generated, effectively suspending the DMA. And so far no crashes :)
Firmware files will be updated asap.
07/08/2016 at 14:57 •
I will keep this short.
Transmitting data with DMA+UART is now working. I can send and receive data through the nucleo's built-in ST-link. However the maximum baud rate I've been able to achive is 230400bps, which means that transmission of data worth a full CCD takes:
I won't have access to an oscilloscope until august, so I can't verify the figure, but from simple tests it does not seem completely unreasonable.
The same amount of data is moved in 4ms with SPI, so communication with UART is roughly 80x slower than with SPI. It's acceptable, but I really wish I could get it under 100ms.
The 230400bps is with 16x oversampling. The STM32F401 can also do 8x oversampling, but neither setting gets me a higher baud rate.