Linear CCD module

TCD1304-based linear CCD module driven by a Nucleo F401RE + Raspberry Pi.

Similar projects worth following
The TCD1304 is a high sensitivity 3648 pixel linear CCD. It's used in some Ocean Optics spectrometers, but because of the difficulty of driving CCDs it has not found widespread use in DIY projects.

This project describes a low cost linear CCD module based on the TCD1304. The TCD1304 is connected to an ST Nucleo F401RE board, which takes care of the time-critical driving and reading of the CCD. A Raspberry Pi or a regular laptop hosts a GUI or a CLI for easy control of integration time and display the collected data.

At the time of writing there's linux (CLI and GUI) and macOS (CLI only) support.

There's sufficient information here to get a working linear CCD module, but for more information about the TCD1304 and the driver firmware go to

Driving the TCD1304:

The TCD1304 requires the following input to function

  1. The master clock (fM)
  2. The shift gate (SH)
  3. The integration clear gate (ICG)

The frequency of fM must be in the 0.8-4 MHz range. In this project fM = 2.0 MHz (but it is user changeable)

The SH-period defines the integration time. The ICG-pulse defines the moment the pixels are moved to the shift register.

The datasheet provides the following figure for the timing requirements for the SH and ICG pulses:

This translates to the following:

  1. SH must go high with a delay (t2) of between 100 and 1000 ns after ICG goes low.
  2. SH must stay high for (t3) a minium of 1000 ns.
  3. ICG must go high with a delay (t1) of minimum 1000 ns after SH goes low.

This is all taken care of by the timers in the STM32F401RE. In fact once they're set up the MCU is not doing any work. The only thing the user has to do is to choose ICG-periods that are multiples of the SH-period.

Since the timers controlling the SH- and ICG-pulses are 32 bit (and run with a frequency of 2.0 MHz) the possible integration times are in the range of 10 µs - 2147 s.

Reading the TCD1304:

The data rate of the CCD is 1/4 of fM, which means the pixels are clocked out at 0.50 MHz. The ADC in the STM32F401RE is fast enough to do 12 bit conversions at this rate. The pixel values are sent to a 16 bit array using DMA. From here they are sent to the Raspberry Pi over SPI at 16 MHz - also utilizing DMA - or through UART to a regular PC via the built-in ST-link's USB-connection.

The voltage of an "dark" pixel is around 3.0 V and a "white" pixel has a voltage of around 1.5 V. In other words the data is upside down.

Total cost of the project:

Raspberry pi zero 5$ (optional)

Nucleo F401RE 11$

TCD1304 2-3$

miscellenaeous 5$

All in all it can be built for around 25$

More information:

The source code is littered with comments as best I could, so dig into it if you want to know more details about setting up the STM32F401RE's peripherals.

This project is part of The Otter DIY Raman Spectrometer. You can read more about that here:


Everything comes with the FreeBSD-license, so do with it what you want. The only exception is the Nucleo F401RE which is under ST's evaluation license.

Graphical user interface (linux - UART)

Zip Archive - 158.02 kB - 05/03/2017 at 07:57


Command line interface for the TCD1304 (macOS - uart)

Zip Archive - 45.58 kB - 05/03/2017 at 07:32


Command line interface for the TCD1304 (rpi - spi)

Zip Archive - 23.51 kB - 05/02/2017 at 17:06


Command line interface for the TCD1304 (linux - uart)

Zip Archive - 15.64 kB - 05/01/2017 at 13:59


Graphical user interface for the TCD1304 (rpi - spi)

Zip Archive - 99.96 kB - 08/13/2017 at 08:37


View all 9 files

  • 1 × Raspberry Pi (optional*) *not needed for the UART-enabled firmware
  • 1 × Nucleo F401RE
  • 1 × TCD1304 Sensors / Image
  • 1 × 74HC04 Electronic Components / Misc. Electronic Components
  • 1 × 2SA1015-Y Discrete Semiconductors / Transistors, MOSFETs, FETs, IGBTs

View all 10 components

  • Windows support

    esben rossel5 days ago 0 comments

    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:

  • MacOS X support

    esben rossel05/01/2017 at 13:06 0 comments

    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:

    • xcode
    • command line tools
    • glib
    • pkg-config

    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

  • Command line diy line camera

    esben rossel03/18/2017 at 17:51 0 comments

    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 for downloads, details etc.

  • Firmware revision 2.0 (MHz)

    esben rossel02/03/2017 at 06:12 0 comments

    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:

  • UART is in / rpi is out

    esben rossel12/28/2016 at 17:46 0 comments

    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.

  • A second look at DMA plus a firmware-update

    esben rossel07/08/2016 at 22:21 2 comments

    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 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.

  • First steps with UART

    esben rossel07/08/2016 at 14:57 3 comments

    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.

  • Communication protocols

    esben rossel07/07/2016 at 17:33 0 comments

    The first versions of the firmware communicated using UART through the built-in ST-link. Calling it communication might be a bit of a stretch though. The integration time was fixed to whatever value was set during compilation. Every time the CCD was read, the pixel-values were sent to the termnial by redirection of print with the newlib_stubs library.

    All in all a very clumsy way to transmit the data, and above all it was slow, and by slow I mean 1-2 seconds (I don't remember exactly how slow).

    After reading up on the various communication protocols available on the rpi, I settled on SPI - not because it was the right choice, but simply because I could understand it. The rpi's SPI is annoying though, because it insists on being master, so the data from the CCD is transmitted at the will of the user and not the hardware, potentially creating interrupt conflicts - I think¹. On the upside it's fast: each transmission of 7.4 kb of data takes only 4ms.

    However I find myself wanting to go back to UART. Firstly it would allow the mcu to send data whenever, secondly - and more importantly - it would enable me to cut the ties to rpi and make the module more ..universal: With UART the module could become a readily usable part for custom made spectrometers in university/teaching labs and the fantastic WINSPEK32 could probably be used for data-collection.

    So that's on the program for this summer holiday - provided I find the time between travelling.

    [1] Every once in a while I experience firmwarecrashes, and I suspect the interrupts are to blame. However, I'm an idiot at debugging, so I actually don't know what's going on.

  • Keeping it small(er)

    esben rossel06/13/2016 at 10:20 0 comments

    The linear CCD module is a central component in the OtterVIS LGL spectrophotometer, and for this everything needs to be as compact as possible, so I've replaced the (relatively expensive) electrolytic capacitor in the module for that project with a tantalum cap and placed T1 under the TCD1304. Here's the slimmed down version:

    Here you see it from the back. C1 has been replaced with a cheap tantalum capacitor. Don't laugh at my SMD soldering skills..

    All in all it buys me the few extra mm that I need to keep the OtterVIS spectrograph inside the build volume of the 3D-printer.

  • The newer smaller CCD-pcb

    esben rossel06/02/2016 at 13:16 0 comments

    Being annoyed with myself that I'd made a PCB for the TCD1304 way larger than needed, I made a new SMD-version. It's slightly more than half the size of the original. I also did my best to keep the analog output away from the digital driving signals, and here is the result:

    Because of the re-routing the pin-out on the 10-pin connector is changed:

    With the new layout I was hoping to see an improvement in the noise-level, however if there's any improvement, I'm not able to see it. I also see no difference in noise whether or not I feed it 4V from a ultra low noise PSU, or directly from the nucleo's +5V. However I've not tried any very long integrations, so I cannot verify that 5V is as good as 4V.

    And of course: Here's an example of a reading of the CCD:

    It's a ruler. You can see the twenty nine 1mm marks and that there are two lightsources in the room it was made in.

View all 11 project logs

  • 1
    Step 1

    Setting up the cross-compiler on linux:

    Download the gcc-arm-none-eabi

    Unzip to a directory, and add the compiler to path by adding this line to .bashrc:

    export PATH=/home/user/gcc-arm-none-eabi-4_9-2015q1/bin:$PATH
    Download the standard peripherals library (SPL) for the STM32F4.


    Download the TCD1304 driver firmware for the Nucleo F401RE

    Unzip to the directory the SPL unzipped to. Enter directory and type 'make'.

    Upload the resulting .bin file to the nucleo board.

    NB: If you haven't got a 74HC04 or other inverter between the nucleo and the TCD1304 there are a couple lines in timer_conf.c you'll want to change. Specifically lines: 55, 209 and 221. Inverse the timer polarity registers.

  • 2
    Step 2

    Installing GUI on Raspberry Pi:

    Download and install raspbian.

    Update the system.

    Run raspi-config and enable SPI.

    Resize SPI buffer (by default it's too small). Append the following to the line in /boot/cmdline.txt:


    Install wiringPi.

    Install libgtk-3-dev

    Install gnuplot.

    Download the Otterly Raman GUI

    Unzip, enter directory, and type 'make'.

  • 3
    Step 3

    Connecting the TCD1304 board to the STM32F401RE:

    Or if you went with the new version:

    1. fM connects to PA6
    2. SH connects to PA0
    3. ICG connects to PA1
    4. Output connects to PC3

    Ideally the TCD1304 runs on 4.0 V, but connecting V+ to the +5V pin works fine.

View all 4 instructions

Enjoy this project?



onmohd wrote 08/07/2017 at 18:47 point

Hello Esben , I am trying to run your UART based GUI, however everytime i execute, and try to record, the GUI crashes immediately, and the terminal says "segmentation fault". Is there a way to fix thsi? I'm pretty new to linux, but from what i've seen this is an issue with unassigned integers . For what its worth the SPI version works perfectly, and I also tried Jens' version of the gui, but i get the same error as i do here.

Thank you

  Are you sure? yes | no

esben rossel wrote 4 days ago point

Hi Omar
Sorry for the late reply, your question somehow slipped past me.. You don't mention whether you've compiled the GUI yourself or used the precompiled binary. If the latter is the case, it could simply be that your problem is caused by 32/64-bit incompatability ..most of the stuff I've put online is made on a 12 year old ibm laptop and so the binaries are 32-bit..
Even if this is not the cause of the problem (I'm just guessing here), I would recommend you try and compile the program yourself. If nothing else you will get some compiler errors to show..
You are welcome to email me any screenshots and files. Use the contact form on then I will get back to you from my regular email address.

Last words: I don't really recommend the GUI, I think you should much rather stick to the CLI. Of course the GUI is convenient for testing, but I have a feeling it could have been programmed a lot better/elegantly..

  Are you sure? yes | no wrote 05/16/2017 at 21:14 point

Thanks for your answer Esben.  It seems to me that pixel rate would be too low for my project. If this limited speed is due to the ccd and the spi , I guess it would be a big work for me to move to a faster ccd and a faster bus. It would makes too much changes for my limited knowlegde about electronics . I will probably try another way, using a commercial scanner ,  hoping that using the driver is not too much complicated. 

  Are you sure? yes | no wrote 05/15/2017 at 07:15 point

Shape of the pixels would not be a problem for building the picture. I am more concerned about pixel rate. How to get a fast capture ? Wouls it be possible to get 500 or 1000 lines/seconde ?

The bigger the pixel, the faster the exposure time ?


  Are you sure? yes | no

esben rossel wrote 05/15/2017 at 07:48 point

There are some built-in restraints with the CCD. For instance, the maximum MCLK is 4.0 MHz and the pixels are clocked out at a rate of MCLK/4. So the very minimum time to capture a frame is 3694/1 MHz = 3.7 ms. Add this to the transfer-time which is 4.2 ms with SPI at 16 MHz (the maximum datarate of the rpi's SPI-peripheral) you end up with a frame-rate of 1/(4.2 ms + 3.7 ms) = 126 Hz

Changing the ADC-DMA to a double-buffering scheme one can read the CCD and transmit at the same time, giving a frame-rate of 1/4.2 ms = 238 Hz with an overhead of up to 0.5 ms for exposure. This however is not implemented and would require a bit of fiddling with the setup of the peripherals. It should not be very difficult to achieve though.

Someone speculated in having two or more CCD-modules working in parallel thus reducing the time significantly, but I've not seen any updates on this:

  Are you sure? yes | no wrote 05/14/2017 at 10:49 point

This project seems great ! Would it be possible to use it as a start for building a linescan camera , making pictures by addition of lines of pixels during a motion ?


  Are you sure? yes | no

esben rossel wrote 05/14/2017 at 18:23 point

Hi Roberto

I guess you could do that. In this case I would recommend to use it in conjunction with a raspberry pi to keep the transmission times low. I don't know if it's a problem or not, but the pixel size is 8x200µm, so I imagine you'll have to do some kind magic to get an undistorted image.
One solution (partly at least) to this problem could be to use the tcd1305 instead of the tcd1304. The tcd1305 has a pixel size of 8x64µm, but is otherwise identical (according to the datasheet) to the tcd1304.

  Are you sure? yes | no

Jens-Ulrich Fröhlich wrote 01/11/2017 at 13:19 point

I am very enthusiastic about this project. In the last few months I have built a OtterVIS-Spectrometer and connected it to a raspberry 3. I found out that setting the pulse_counter to 3 in the stm32F4xx_it.c improves the stability of the system. I put some pictures on

Caution the blog is under construction!

  Are you sure? yes | no

esben rossel wrote 01/11/2017 at 14:36 point

That's great. Thanks for reporting. I will try that out.
And nice blog btw, I will definitely keep myself updated on it.

  Are you sure? yes | no

esben rossel wrote 03/19/2017 at 16:57 point

In case anyone thinks my graphical-user-interface is crap, then take a look at Jens-Ulrich's blog . He has extended it with Octave and changed so much I can hardly take any credit for it any more.

  Are you sure? yes | no

Simon Merrett wrote 08/12/2016 at 12:37 point

Esben, I have received the PCB, hex inverter and transistor - thank you! My Nucleo is here and I realised you used a linux toolchain. Do you have a recommendation for a Windows-based way of getting the firmware onto the Nucleo? Sorry to be a burden but I'm branching out from my comfort zone with this project. 

Also, thanks for the recent updates on UART - I definitely want to use this without the Pi if possible.

I've had a look at the CCD datasheet and can't find any spectral sensitivity information. Do you have any data on this? I'd like to use this in a ranging application so choosing a wavelength that the CCD is sensitive to is quite important for me.

  Are you sure? yes | no

esben rossel wrote 08/12/2016 at 22:42 point

I believe there's a windows version of the gcc-arm-none-eabi compiler. I've not used windows for 10+ years, so I cannot help you with the setup, but I imagine it's not to dissimilar from setting it up on linux. Alternatively you could run the compiler off of raspbian. (but isn't there a precompiled .bin file in the firmware-zip that you can just copy to the nucleo?)

  Are you sure? yes | no

esben rossel wrote 08/13/2016 at 09:05 point

there's a spectral response curve in the datasheet. I have it here as well:
You should easily be able to use anything between 400-800 nm.

  Are you sure? yes | no

David H Haffner Sr wrote 08/09/2016 at 21:01 point

You know, I am thinking about this CCD module of yours with serious consideration for a more advanced project of mine, more within the realm of the Raman spectrometer type. 

  Are you sure? yes | no

Michael Shaub wrote 08/04/2016 at 23:49 point

Any idea if your work can easily be adapted to more high res linear CCDs? I found another Toshiba device that's at the high end of their offering, the TCD2964BFG. Would be awesome to work on a scanner camera from scratch. 

  Are you sure? yes | no

esben rossel wrote 08/05/2016 at 06:58 point

A quick look through the datasheet for the TCD2964BFG I'd say you'd need to rewrite the firmware quite a bit. There are more inputs, you have three outputs (so you'd probably need a faster ADC than the STM32F4's) and finally there are more timing requirements to meet.
   In any case, I would take a close look at the output data rate from the CCD (if I read the datasheet correctly the lowest data rate is 3x 150 kHz) and see if the ADC in the nucleo can keep up with this.

  Are you sure? yes | no

Simon Merrett wrote 08/02/2016 at 21:35 point

Hey, I was wondering if you think this ccd and reader setup could be persuaded to do the duty for a low cost neato-esque lidar based on triangulation. I'm particularly interested to get something that works in daylight for a horticultural robot (along the lines of  ardumower). If the processing of the brightest pixel can be done at the ARM processor, there should be a reasonably high resolution ranging system available here. I'd love to hear your thoughts on this. 

  Are you sure? yes | no

esben rossel wrote 08/04/2016 at 15:44 point

I honestly have no idea about that, but I can say that it's the MCU's peripherals who do all the work, so the processor is idling something like 99% of the time, so there's plenty of free horsepower to do calculations. 

  Are you sure? yes | no

Simon Merrett wrote 08/05/2016 at 21:16 point

Thanks Esben, I've messaged on your blog - interested if you have any spare PCBs left. 

  Are you sure? yes | no

Nik wrote 08/02/2016 at 19:01 point

Great work! But why not swap the microcontroller for a single-channel ADC with SPI? You can control the CCD via the RPi's GPIOs and take readings with it's SPI (that can reach speeds of 125Mhz). This will reduce costs, give other users flexibility, remove the need for firmware and solve your transfer speed issue. This will of course require the firmware be ported to RPi software, but this way you should be able to push the CCD to it's limits.

  Are you sure? yes | no

esben rossel wrote 08/04/2016 at 15:40 point

The rpi doesn't have timer peripherals, so it would (for me at least) be very bothersome to create driving pulses for the CCD. I believe the Beagle-what-ever-boards would be a better option, if you absolutely don't want the nucleo-board. I'm working on a UART-firmware to get rid of the rpi ..that would give even more flexibility at lower cost still.

  Are you sure? yes | no

A. M. Aitken wrote 08/01/2016 at 10:17 point

Hi Esben, you've had another shout out on the hackaday blog and this time it's a full post!  Congrats!

Thanks for the follow btw, small world, you don't know me but we have sciencemadness forums in common.

  Are you sure? yes | no

esben rossel wrote 08/04/2016 at 15:41 point

Thx. Yes, I do believe we know each from sciencemadness :)

  Are you sure? yes | no

David H Haffner Sr wrote 04/26/2016 at 09:48 point

Wow! This is quite amazing, I have been looking for a more sophisticated CCD camera for my next spectrometer project and this is very interesting!

  Are you sure? yes | no

Friedrich Menges wrote 04/23/2016 at 22:05 point

Hi Esben, what about adding the processing power of a complete spectroscopy software package to your hardware? I've just started working on this: Might be a useful addition?

  Are you sure? yes | no

esben rossel wrote 04/25/2016 at 07:00 point

Hallo Friedrich

That's a nice project, and it would certainly add functionality. So far the software I've written (I'm not very experienced at coding) is merely proof of concept.

I've only had a quick glance at your project. The SPEKWIN32 looks impressive, and I will certainly take a closer look at the Useful information section on your page. I will help you all I can if you're interested in writing a windows driver for the linear CCD module.


  Are you sure? yes | no

Friedrich Menges wrote 04/25/2016 at 10:55 point

Currently I am busy with driving my Kickstarter campaign besides my day job But hooking up spectrometer is definitely a direction I want to go. The benefit is just so huge: to combine a fully blown spectroscopy software with your DIY spectrometer:-) As I am quite dull with low-level electronics hacking, I have to rely on folks like you...

  Are you sure? yes | no

Andre Esteves wrote 07/01/2016 at 20:19 point

Windows? :P bleurgh...

  Are you sure? yes | no

skibulk wrote 03/14/2016 at 20:41 point

  Are you sure? yes | no

esben rossel wrote 03/14/2016 at 23:19 point

I'm not an expert in ARM-programming, but from a quick look at the datasheet for the STM32F103 I'd say it has enough timers (I use 4: two 16 bit for the high frequencies (fM and ADC-trigger, and two 32 bit timers for the SH- and ICG pulses that require very long periods for long integration times).

If I understand correctly the STM32F103 has seven 16 bit timers, and no 32 bit ones, however if you're going to do photography you might not need the time the extra 16 bit buys you.

The ADC's looks ok (again no guarantees) and there are DMA- and SPI-controllers as well.

In short it has all the peripherals my firmware for the STM32F401RE utilizes, so I would expect it'd work, of course you'd need to do a bit of tailoring to make it work on this device.

  Are you sure? yes | no

K.C. Lee wrote 08/04/2016 at 18:09 point

There is a 16-bit prescaler for each of the timers, so you can already get long time delays. You can also link 16-bit timers in master/slave to emulate 32-bit one.

  Are you sure? yes | no

skibulk wrote 03/14/2016 at 20:36 point

With a 3d printed enclosure and a quality camera lens, do you think this could be used as an alternative to an (expensive) industrial line scan camera?

  Are you sure? yes | no

esben rossel wrote 03/14/2016 at 23:07 point

Definitely. One thing to be aware of is that the pixels in the TCD1304 are not square. If I remember correctly they're 8 µm wide and 200 µm tall - check the datasheet.

You'd might also have to modify the firrmware to suit your needs, for instance a single line of your image would take up 7388 bytes. With a total of 512 kB of ram you're limited to an image size of max 70 lines if you don't transfer data between each reading.

As it is the data transfer between the rpi and the f401re takes around 4 ms for 3694 pixels.That should give you some indication of the minium exposure time for an image of a given size.

  Are you sure? yes | no

Films4You wrote 02/28/2016 at 00:47 point

Thermal camera to see heat :)

  Are you sure? yes | no

Henning Paul wrote 02/27/2016 at 18:28 point

Where did you get the CCD that cheap? Usually they're around 10$.

  Are you sure? yes | no

esben rossel wrote 02/27/2016 at 23:15 point

*bay. If you can find the TCD1304DG which is the older non-RoHS compliant version you should be able to get a better price than for the TCD1304AP. They have identical specifications.

  Are you sure? yes | no

esben rossel wrote 02/23/2016 at 17:13 point

I'm going to build several :D (different types)

First on the list is a Raman spectrometer. You can also follow the progress at

  Are you sure? yes | no

zakqwy wrote 02/23/2016 at 17:45 point

Cool! I'm sure you've done the research at this point, but if you haven't seen it, make sure to check out #ramanPi - Raman Spectrometer. TONS of great documentation..!

  Are you sure? yes | no

esben rossel wrote 02/23/2016 at 17:59 point

Yes the Ramanpi is a supercool project.  In fact it was what got me started in the first place. Then I sort of diverged from fl@tc@t's design.

  Are you sure? yes | no

zakqwy wrote 02/23/2016 at 17:10 point

Wow, I'm surprised how cheap those modules are online. What's your plan for this project? Building a spectrometer?

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates