\table
- Introduction
- High-level description of the hardware-firmware-software architecture
- Getting it all up and running
- On Linearity and reproducibility in CCD spectrometers
- Setup for linearity testing
- Spectrometer design and construction
- Electrical design (a tutorial)
- Appendix A - quick command list
This repo offers a Linear-CCD (LCCD) sensor device based on the TCD1304DG that is designed specifically for reproducible linear response. For a spectrometer, as will be shown, linear response becomes a prerequisite for producing data that can be reproduced by other researchers.
The sensor device is offered in three versions (high-end 16 bit, lower cost 12 bit, and analog), along with firmware ("sketch" file and header library), a user interface program (with graphics) and class library (Python) and an offline data processing program and class library (Python) to read and graph the ASCII files saved by the controller. All three versions of the hardware, when used with the provided firmware and a Teensy 4.x, are able to provide reproducible linear response. With the 16 bit system we have obtained linear reproducible results over 5 orders of magnitude in exposure time (from 10usec) in clocked and triggered data collection.
Reproducibility is fundamental to doing science, and especially so when it comes to collecting data that we plan to include in a paper. Other researchers should find the same spectra, the same ratios of peak heights, the same yields, and so forth. As is well known, meeting these basic criteria has been a challenge for CCD spectrometers since their inception in the late 1980's. (We will show examples of this in a widely used commercial instrument.) Needless to say, this touches on the basic question of whether a dataset is meaningful. But if these issues were addressed, CCD spectrometers with their "all at once" spectral capability and potentially low cost, would be an important contribution to the scientist's toolbox. The goal of this project was to finally and fully address these issues and produce a definitive design for the TCD1304 that provides data that is linear and highly reproducible.
In our studies leading to the present design, the TCD1304 itself proved to be remarkably linear. (Some vendors attribute their non-linearities to the sensor. As you will see, it is not true.) Rather, the challenge is in electrical design to account for both the nature of the signals produced on reading a spectrum or technical image from the CCD and the stricter requirements on linearity for purposes of a scientific instrument. There is a second challenge described as a phantom or "carry-over" that has to be addressed in how the sensor is operated. These challenges are perhaps not too complicated, but they do require experience in having actually used these instruments as a scientist, and meticulous attention to detail and careful analysis in designing an instrument to do the job properly. In other words, design of a scientific instrument should proceed with at least the same uncompromising exactitude with which it will be used. We offer the present design with the hope that this will "set a new bar" for CCD based spectrometers.
In this README we cover a lot of ground, from getting and working with the boards, to documenting what linearity and non-linearity look like in real instruments and why it is important, explaining why the problem is especially tied to spectrometers, and providing a tutorial in electrical design with example circuits. We use SPICE models to illustrate key points and we include a collection of these in this repo so that you can explore the ideas for yourself.
This repo provides (a) fab files and BOM for making the boards, (b) firmware as an Arduino "sketch" and a header-only C++ library, (c) host software in Python that can be used as a class library or command line interface with realtime graphics, (d) this README with test results and tutorials for electrical and optical design, and (e) a collection of SPICE models as referred to in the text and including those we used to develop and test the design.
We begin with a summary of what is contained in the rest of the readme and repo.
We provide three implementations of the sensor system hardware (see the following figures); (a) a two board implementation comprising the sensor board and our Teensy 4 based instrument controller, (b) a single board "All-In-One" implementation with sensor and MCU on back and front of the same board, and (c) an Analog board with the sensor, signal conditioning circuit and gate drivers with analog output of the inverted and amplified sensor signal. The firmware and Python codes provided in this repo, can be used with any of the three hardware implementations.
In the following we provide a high level description of each of the three implementations For each we also describe the cost and choice to build or buy. The costs include the sensor and microcontroller, currently running at $40 and $24 respectively and the PCB which generally runs around $18 per board in small quantities (including tariffs).
The high end sensor system, shown here, is a two board system comprising sensor board and controller. It offers very low electrical noise with a 16 bit 1MSPS ADC and good mechanical isolation of the sensor from the controller. The ribbon cable carries logic signals and power for the SPI interface (1.7V-5.1V). The two wire connection (red and black) is 5V power. Internally, there are separate low noise power circuits and ground planes for the analog section and gate drivers. We observe 0.6mV dark noise, electrical noise is more than 10 times lower (less than 1 LSB with the sensor removed). And the board is able to linearly follow peaks to full scale in one pixel. Fiduciary marks on both sides of the sensor board facilitate optical alignment.
TCD1304 Sensor system, (a) sensor board bottom showing sensor and fiduciary marks, (b) sensor board top showing circuits, interconnects and baseline trim, and (c) sensor board and controller showing geometry and interconnection (control and data plus 5V power).
Component costs for the high end 16-bit system are currently \$110 for the sensor board and \$88 for the controller, or \$198 for the set, plus the time it takes to do the assembly work. The passives are generally 0603, some are 0402 and two of the ICs are 0.5mm pitch. It takes us a few hours per board for hand assembly, or about one day per board set.We recently switched to using a PCBA service for the SMT parts (we prefer ALLPCB for their customer service). Normally this would bring our costs to $290. With tariffs our cost per set is now $395 to $422 depending on the clearance agent. We feel that compared to hand assembly it is still a bargain.
The following shows the single board "all-in-one" device with sensor, electronics and controller all on one board. This device offers similar performance in terms of linearity to the two board system, but with 12 bit precision. It has a single ended analog signal path and uses the built-in analog input of the Teensy 4.0 (and therefore has fewer parts, costs less and is easier to hand assemble).
TCD1304 All-In-One Board, (a) bottom showing the sensor, (b) top showing the microcontroller board and pins for auxiliary functions, and (c) view showing the overall geometry.
The component costs are currently \$86 including TCD1304 and Teensy, plus \$18 for the PCB, for a total of \$104. We generally assemble these in house. The passives are 0603 or larger. The two IC's are 8 pin, 0.65mm pitch. It takes us a few hours or about half of a day.The following shows our analog-output sensor board. This also has the single ended analog circuit as in the all-in-one board, and similar gate drivers. The board can be powered from 4V to 5.5V and accepts 3.3V to 5V logic to operate the CCD gates. We developed this board to provide a better and actually useful alternative to the analog boards offered on some DIY sites. The output is intended to be compatible with the inputs of typical processor boards in the Arduino ecosystem, but linearity and ability to meet the clocking requirements for the CCD sensor will depend on which Arduino ecosystem board and firmware you choose to use. Running the board from our Teensy 4.0 controller and firmware, we found that it has very good linearity and, similar to the above, it is able to track peaks to full scale in one pixel.
TCD1304 Analog Board, (a) top showing the circuits and connectors, (b) bottom showing the sensor.
Parts costs are currently \$65 including the TCD1304, plus \$18 for the PCB per the above, for a total of \$83. The passives are 0603 and the ICs are SOT23 packages to make it a little easier for hand assembly. It takes us perhaps 3 hours to build.As noted, reproducibility is vitally important for any instrument and for a spectrometer linearity is a pre-requisite for reproducibility (as well as for basic capabilities such as signal averaging). And CCD spectrometers are historically challenged for both linearity and reproducibility. We discuss this at length in the section titled Linearity and Reproducibility in CCD Spectrometers. We show examples in data collected from a commercial instrument and compare this to data from the present design where the results are linear. The data illustrate the relationship between linearity, reproducibility and being able to produce meaningful data.
Construction of the spectrometer used for testing the new sensor is described below (here). We use a 1200/mm grating and 200μm entrance slit with a focal length of 2 1/4". Total cost of materials for the spectrometer is under $400, including the electronics (this repo), optics and mechanical parts.
As noted, we operate the sensor board using our newly updated Instrumentation Controller based on the Teensy 4, with its NXP i.MXRT 1060 ARM7 MCU (please click here). The T4/NXP platform is somewhat unique among MCU boards in the Arduino ecosystem for both its speed at 600MHZ and its high speed USB at 480Mhz. Additionally it provides a flexible timing generator (FlexPWM) which we feel is better suited to the task of operating the TCD1304 compared to the PWM peripherals offered in other MCU boards. In the present system, including firmware and software, we are able to produce well controlled exposure times to as short as 10usec and frame rates a little faster than 100fps.
The firmware (here), written for the T4, includes a header-only library to operate the sensor, and a "sketch" file (Arduino source code, similar to C++) that implements human readable commands and responses, operates the sensor to produce frames by clock or hardware trigger, and sends the data back to a host computer.
We expect that the firmware provides all of the functionality you may want for almost any sort of experiment. However, we provide the TCD1304 library and the complete source code so that you can modify it if you wish. We work with the code using the Arduino IDE for compilation and Emacs as an external editor.
The Python code (here) can function as a user interface or as a class library. When invoked directly, the code presents a graphical monitor and command line interpretor with human readable commands. When used as a library from another program (see "import"), the spectrometer is available as an instance of a class object. The Class provides both high and low level functions to work with the device. The design emphasizes simplicity and performance, again with anticipation that scientist users can modify the Python code to their purposes. The command "help" lists detailed help text from the controller and from the Python code.
A tutorial on electrical design for CCD sensors and spectroscopy is included here. The section begins with the datasheet and characteristics of the sensor, proceeds to signal condition and driving an ADC and finishes with a section on the gate drivers. SPICE files are included in a subdirectory of the repo. You can modify the SPICE files to investigate your own designs.
The fab files and code provided in this repo, and in the controller repo, plus some cabling and a host computer, should be sufficient to assemble the boards and get your detector system up and running. Feel free to contact me for consultation or pre-assembled boards (time permitting). And needless to say, donations are very much appreciated, please find and "click" the sponsorship button above.
The contents of this repo are part of our effort in Open Instrumentation for Open Science.
We believe that access to doing great science should not be limited to those privileged in funding and affiliation nor held ransom to the extractive practices of the market in scientific instruments. And anyway, you may feel better served by instruments developed by other scientists who actually use them and have decades of experience designing professional instrumentation. The designs we provide can often be built at about 1/10 of the cost of the commercial instrument. In our own research, we are typically able to do more with these boards than we can with the expensive commercial instruments.
At this writing, we have received requests and helped scientists working in Europe, Africa, India, Canada and the USA.
One very important way that you can help underfunded scientists is by clicking the "Sponsor" button at the top of this repo. The funds go to helping to make more instruments more available to more scientists around the world.
If you would like to sponsor or receive boards, please contact me.
Permission is hereby granted for you to build and use these boards and codes in your lab and for your personal use. Please cite appropriately if you use these in your published work.
Please contact me if you need/want:
- Pre-assembled boards
- Customization, advice, etc.
- Permission for use in a product or other commercial effort
And of course, no warranty or guarantee is given whatsoever. We did our best.
If you have questions, please feel free to contact me. And of course, don't forget to click the "Sponsor" button (or contact me directly).
The sensor is operated through four input pins, a clock and two gates plus a fourth for the "convert" pin of the ADC, and an SPI interface which retrieves the data from the ADC. These connect to the controller and the controller in turn connects to the host as a serial port device over USB. The controller also provides a trigger input and sync output and additional pins that can be used to interact with other equipment.
The controller operates the sensor device with its FlexPWM module programmed to serve as timing generator for the clock, gates and ADC convert signals, and its SPI module to read the ADC. A small set of interrupt service routines maintain frame counters, measure exposure times, and so forth. At the end of the readout, the data record and the various parameters that accompany the data record are organized into a C struct as a "frame" and put onto a ring buffer. In the main thread, the function loop() checks the ring buffer, sends pending data frames to the host, and processes command inputs from the host computer. Every command is acknowledged by sending "DONE" back to the host.
The Python code running in the host, represents the sensor device and its controller through a class object, TCD1304CONTROLLER. A multiprocessing thread TCD1304port listens to the port to receive data frames and messages sent in response to commands, and interacts with the main thread through a set of queues; the data queue, a queue for commands to send to the controller and a graphics queue for real time display. The graphics window runs in a separate thread also.
Thus we have two levels of buffering, one in the controller and one in the host software, and commands and data are serialized on both ends of the interconnection between the host and controller. The commands and responses are all simple human readable ASCII. Data can be transferred as binary or ASCII.
The sensor board internals include the TCD1304DG sensor, gate drivers, analog signal conditioning and ADC. The external interface comprises the three gate inputs, an input to command the ADC and SPI to retrieve the data.
Achieving linearity and reproducibility is to a large extent a function of hardware and firmware. The analog subsystem and ADC provide linear response to spectroscopic signals, the gate drivers enable effective retrieval of charge and the firmware provides effective operation.
This sensor board is intended to be used with our new Teensy 4 (T4) based controller. The files provided here (gerbers and code) and in the controller repo, plus some trivial cabling and a host computer (we recommend Linux for the best frame rate perfomance) should be sufficient to build and operate the boards.
If you are using the "All-In-One", then you have the TCD1304 and circuitry and the Teensy 4.0 all on one module. The gerbers are provided in their own directory in this repo. There is one macro switch in the firmware that you need to uncomment to compile for the "All-In-One" board.
You can assemble the boards yourself, or if you prefer, please feel free to contact me for pre-assembled boards.
If you want to assemble your boards, and this is your first time assembling an SMT board, search for an introduction to DIY SMT assembly, for example here.
Here are some notes on how we do assembly in our shop. We order PCBs from AllPCB, JPLPCB, and PCBWay. We usually order parts from Digikey, but we also use Mouser and Newark. We use Chip Quik no-clean solder paste in a syringe dispenser with fine needle tips that we order separately. And we use a reflow oven that we purchased through ebay for about $200, and sometimes we use a temperature controlled rework heating stage that we purchased through Amazon.
We recommend using a powered USB hub with switches to turn individual USB devices off and on. When you shop for this, make sure it supports high-speed (at least USB2.0) and can supply at least 1A per port. For example, a powered 7-port USB hub should be able to supply at least 1A x 5V x 7 ports = 35W.
After the boards are assembled, you will need to install the Teensy board in the controller, and compile and load the code into the Teensy. You will most likely want to use the Arduino IDE for this. Teensy is well integrated into the IDE. See here for setup instructions. The Teensy needs to be connected by USB to your host computer for this step.
The firmware codes are found in the repo in the Firmware subdirectory
(In the following, the "251208" in the directory and file name, is the date of this version of the firmware. If there is a newer version when you read this, use that one.)
TCD1304Device_Controller_251208/
TCD1304Device_Controller_251208.ino - The controller program with CLI
TCD1304Device2.h - A header-only C++ library for the TCD1304 and Teensy4.x (iMXRT106x)
parselib.cpp - A string parsing library for the CLI
parselib.h
Doxyfile - Doxygen configuration file
TCD1304Device_Controller_refman.pdf
- Listing generated by doxygen
The Arduino IDE requires that the "ino" file and directory have the same name.
To load firmware into the "All-In-One" board, open the file TCD1304Device2.h in a text editor or find its "tab" in the Arduino IDE, and un-comment the following line. It is at line 23 in the current version of the file.
//#define ALLINONEBOARD
If you want to customize the firmware, it is recommended to create a new directory, copy the files to that directory and rename the ino file per the above.
After installing the Arduino IDE and Teensy package, you should be able to double click on the ino file to start an IDE session, or start the IDE and navigate to the directory and open the file.
Python codes and Bash scripts for operating the TCD1304DG sensor and working with the data, all under Linux, are provided in the repo under the subdirectory Python/.
The codes have been used with the Fedora Cinnamon Spin, which you can download from here. This uses xorg rather than Wayland, the desktop is Win7-like and it is easy to work with terminal windows. We have also done some preliminary testing in Ubuntu.
The command to install the Python environment and libraries used by the codes is as follows (in Fedora, use apt-get or aptitude in Ubuntu):
\$ sudo dnf install python python-numpy python-scipy python-matplotlib python-pyserial
To setup the Python codes from this repo, unpack or download the files from the repo's Python subdirectory to a directory on your Linux machine; somewhere under your personal user directory works just fine. And, set the permissions to allow execute (chmod a+x *.py, and chmod a+x *.sh).
Here is a list of the files provided in the Python directory
TCD1304Controller.py - User interface and Class library
GraphicsWindow.py - Libraries used by TCD1304Controller.py
GUIWindow.py
TextWindow.py
DataReader.py - Offline library and graphics utility
SetupPATH.sh - Adds the code directory to PATH
GraphTCD130Spectrum.sh - Offline graphics using DataReader.py
Calibration2 - example wavelength calibration
You will want to add the directory for the Python and bash scripts to your PATH. You can do this by adding the following line to your .bashrc. Alternatively you can run this from a command terminal, but you would then need to do it each time. Note that the command begins with ". "
$ . pythoncodesdirectory/SetupPATH.sh
After all of the above, make sure that your sensor controller is connected to your compute with a USB cable, that the cables are connected correctly if you are using the two board implementation, and then turn on the power and wait about 1/2 minute.
Now you can run the controller program.
$ TCD1304Controller.py
The controller should open a grahics window. The desktop will look something like this.
Notice that in the console window, we have a prompt. This is the command line interface presented by the Python program. The Python CLI provides commands to wait, save to disk, run commands from a file, run shell commands, and etc., and passes all other commands to the hardware. The command help, produces a listing of the commands recognized by the hardware and Python CLIs. A listing of the help output can be found in the repo here. A summary of some of the most often used commands can be found at the bottom of this readme.
The firmware provides commands at three levels. The high level commands include the following to collect clocked or triggered data.
tcd1304cli> read <n frames> <exposure>
tcd1304cli> read <n frames> <exposure> <frame interval>
tcd1304cli> trigger <n frames> <exposure>
tcd1304cli> trigger <n frames> <exposure> <frame interval>
The first form collects "back-to-back" frames with exposure time congruent with the frame interval. This accommodates intervals as short as about 8-10 msecs (the time it takes to read the sensor).
Dark noise has a minimum at about 10-20 msecs.
There is no effective upper limit on exposure time in this mode, apart from the increase in registering cosmic rays. Signal averaging can be done on line (see add) or after data is save to a file.
The second form collects fast "frame sets" with short exposure times. The exposure time in this mode can be as short as 10 μsecs depending on pulse widths. The frame interval needs to be at least the readout time plus the exposure time, c.f. 10msec for a 1msec exposure. The maximum frame interval in this node is about 55 msecs. Signal averaging is available for this mode, too.
The trigger input can be configured as follows, where <option> can be any of rising, falling or change, pullup or nopullup, or pin <pin-number>.
tcd1304> configure trigger <option>
For kinetic studies using back to back exposures, the following command can be used to configure the pulse sequence to run "cleaning pulses" before each exposure. You can read more about this here.
tcd1304cli> configure clearing pulses <n>
Middle level commands including setup pulse.., setup frameset..., setup timer, start and trigger, provide data collection capabilities with detailed control of the timing for the pulse sequence that operates the sensor. There is also a complete set of low level commands for register level access to the FlexPWM timing generator in the MCU.
The Python controller program saves incoming data onto a queue. The command save <filespec> retrieves and writes the data to disk. The command clear empties the data queue without writing to disk. The saved data includes the "0" frame. The first exposure interval is frame 1.
Data frames can be added using add all which sums all of the data into one frame, or add all after n which sums all the frames after the first "n" frames, or add framesets which sums the data at each index in the frame set. After adding the frames, you can use save as above, or collect more data and add again. (See the next section "On Linearity and Reproducibility...")
Following is an example that shows the data produced with a single frame at low intensity compared to that produced by adding 100 frames collected at the same signal intensity. The signal to noise ratio increases by a factor of 10 as expected (√N). Aside, being able to add data frames and obtain meaningful data is possible only when your instrument is linear. We will discuss this in further detail in the next section.
The program and class library DataReader.py can be used to work the offline data. The command line accepts python language statements and can produce graphs. Setting variables x, y, y2, etc., generates a 2-d graph. Setting surface or image generates a 3d surface or heatmap.
The following example generates a simple 2-d graph of electron counts divided by exposure time. Omitting --output sends the graph to the screen. More examples are included in the bash scripts in the distribution.
bash# DataReader.py mydatafile \
d=dataset[0] \
x=d.xdata \
y="d.frames[-1].dataCounts()/d.exposure" \
xlabel="\"Wavelength(nm)\"" \
ylabel="\"Counts/sec\"" \
--output mydatafile.png
To list all of the available variable names and data associated with a file,
bash# DataReader.py mydatafile --dump
The data files are in ASCII and human readable. If you wish, you can work with the files using a spreadsheet program. The advantage of DataReader.py, whether you use it from the command line or as a library, is that it parses the file into Class objects and you can use the full power of the Python libraries to work with the data.
In this section we illustrate some of the challenges in linearity and reproducibility as observed in CCD spectrometers. After defining some terms, we show examples that compare the performance of the present design and that of a widely used commercial instrument. These also help to illustrate basic concepts and why this is important for reproducibility.
Linear response, for a spectrometer, means that the measured response S is proportional to the number of photons P impinging on the detector. For a change in intensity at pixel "n", we expect that ΔSn = cn ΔPn where cn is a constant.
When a system is linear we should see that (a) spectra collected with different exposure times agree with each other (S1/t1 = S2/t2), (b) ratios of peak heights are constant (Sλa/Sλb at t1 = Sλa/Sλb at t2), and when summed the result agrees with that obtained by a single measurement with the combined exposure time S = St1 + St2 = St1+t2.
Notably our linearity criterion was expressed as a change in P and S. Normally we would apply the above rules after subtracting a noise or background signal. Conveniently, for this kind of sensor, the dark noise SD is proportional to exposure time in the range of exposure times greater than 20msec and for this sensor system the electrical noise is several orders of magnitude smaller than the dark noise. Therefore, for these longer exposure times, the total intensity (S = SP + SD) should also be linear.
That said, there are a few ways in which spectrometer response can be non-linear. Some of these can be corrected numerically provided the non-linearity meets certain mathematical criteria. For example, measured values should at least be monotonically increasing in exposure time so that there can exist a unique mapping between a measurement and its corrected value.
However, some non-linearities involve bandwidth or line shape. And while a valid correction might exist, it is most often far easier and far more reliable to start with an instrument that has linear response.
So far we have talked about linear reproducible response to the signal produced by the sensor. We will next show some examples, give mention to another class of behaviours associated with the physics of moving charge within the sensor, and then finish with some further discussion of linearity and electrical characteristics of signals in spectroscopy. Detailed discussion of anomalies associated with charge distribution, is included at the end of the section on gate and clock drivers.
Let's look at some data.
The following are fluorescent lamp spectra, from the present design and from a commercially produced spectrometer (Flame-S, Ocean Optics). Notice that in each instrument the lines at 546nm and 611nm are similar in height. But whereas the line at 436nm which in the new instrument is about twice the height of the 546 nm line, in the commercial instrument it is attenuated by a factor of 4. The lines at 436nm and 546nm correspond to well known lines of Hg I and their tabulated intensity ratio is actually 2:1 ("Strong lines of Mercury", NIST).
Fluorescent lamp spectrum, (a) new sensor and (b) commercial instrument.
This seems like a simple test. But it is important to look closely. One way to alter the spectrum is to simply misalign the sensor. But then the effect should be systematic. In this instance the intensities of the other lines seem inconsistent with the large difference in the 436nm line. (For example, see the 487nm line compared to the other lines.)
Though it requires some care in interpretation, if you are considering a spectrometer or sensor board, we feel that you should always insist on seeing a well resolved fluorescent lamp spectrum.
The following shows the spectrum from the new instrument with the y axis expanded so that we can see the structure in the region around 590nm. We see that the lines are a little sharper compared to the commercial instrument.
Spectrum from the new instrument with expanded intensity scale to show detail around 590nm and 615nm.
The following shows the raw intensities versus exposure time for four of the peaks that appear in the above spectra for the present design and the commercial instrument. We select the strongest two lines, at 435nm and 546nm, and the smaller peak at 542nm and the wider peak at 487nm. The vertical scale for the present design is volts read from the sensor.
In a linear instrument, all of these intensities should rise linearly with exposure time or overall intensity. In the present design, the curves are indeed straight lines from near the origin until near the limiting output voltage of the sensor. For the commercial instrument, most of the range is not linear. We will see more explicitly how this effects relative peak heights.
Intensity versus exposure time for four spectral lines for (a) the present design and (b) the commercial instrument. The present design demonstrates linear response.
We reasonably expect that in a reliable instrument ratios of intensity should not change when we change intensity or exposure time. We expect that spectra should look the same when we repeat a measurement. On a more serious level, quantitative comparison of intensities is a basic element of many experimental protocols.
The following shows ratios among three of the peaks as a function of exposure time. The present design shows roughly constant peak height ratios until one of the peaks in the ratio reaches saturation. The data from the commercial instrument does not seem to provide a useful peak ratio measurement.
Peak height ratios for (a) the present design and (b) the commercial instrument versus exposure time.
In the present design (a) the line at 546nm clips at 0.6 sec, see the "Intensity" graph above.
(The first few points are effected by noise for this incident intensity.)
The above are examples of non-linearity in the conventional sense of linear response of a circuit and digitizer to an analog signal. There are two further issues that can effect linearity in a different way.
Baseline or background subtraction is often a necessary step in extracting intensity data from spectra. There are a number of ways to do this, for example using dark spectra or regions of spectra where the experiment produces little intensity. The former assumes the background is independent of the signal of interest and the latter assumes background is dominated by the dark noise of the detector rather than light.
The following shows a fluorescent lamp spectrum from Wikipedia.
Notice the anomalous baseline to the blue side of the sharp peak at 631nm. The shape is not like dark noise nor any sort of room lighting. The important point about this for the present discussion is that it is not easily corrected.
Fluorescent lamp spectrum.
Original: Deglr6328 at English WikipediaDerivative work: H Padleckas, CC BY-SA 3.0,
via Wikimedia Commons
In studies of dynamic phenomenon, we are interested in the intensity registered in the detector during the time of a particular exposure. In CCD detectors there is always some charge that is carried over to the next frame. The magnitude of this carry-over effect depends on how the shift gate is driven. In steady state phenomenon this effect can balance out after a few frames. As noted above, a detailed discussion is included at the end of the section on gate and clock drivers.
The following provides some insight into how the above phenomena may emerge in a CCD spectrometer (or imaging system) and how this can be addressed. For simplicity of exposition, we can think in terms of a simplified notional CCD sensor architecture. (The TCD1304 architecture is described further in a later section.)
The following depicts a circuit model for our simplified linear CCD, an array of pixels each compromising a photodiode and capacitor connected by a switch to one element of an analog shift register.
(From an archived application note, Toshiba)
The following shows a pixel in our simplified notional CCD, pink indicates n-doping. The shift gate (SH) opens a channel and biases the shift register to harvest charge from the photodiode. The electrode labeled φ belongs to the readout register.
The following depicts the process for moving charge along the readout register (in the direction orthogonal to the plane of the above diagram). At the completion of each clock cycle (typically 2 or 4 clock pulses) charge has been shifted one step to the right. The charge at the last element is converted to a voltage and presented at the output.
An important point for the present discussion is that the CCD records a discrete patten of light in space (or wavelength) and on readout this pattern becomes a discrete series of voltages in time. Accordingly, a sharp spectral line becomes a short pulse in time. This is what makes spectroscopy different from other signal acquisition scenarios.
In designing circuits for acoustics or radio frequency work, we might think in terms of a Nyquist frequency and we might accept some small non-linearity for signals approaching this "cutoff". But in a CCD spectrometer (or imaging system) a full scale step in voltage from one sample to the next can be a legitimate feature that has to be rendered to a meaningful digital representation. We can think of this in terms of bandwidth (units of 1/t) or in terms of dV/dt (units of V/t).
The following graph shows the Fourier transform of the above spectrum (blue) and the response curve (orange, y2 axis) for a simple single pole low pass filter with cutoff frequency at 1/2 of the sample rate. Naive filtering of this sort results in about 10% attenuation for the high frequency components that may be important for linear response to narrow spectral lines.
Fourier transform of the fluorescent lamp spectrum (blue) and single pole f/2 filter (orange).
Now let's look at dV/dt. Here we graph the spectrum as dV/dt versus time (as read from the sensor). The spectral line at 436nm that is markedly stronger in the present design instrument also has the largest dV/dt. In electronics, dV/dt is related to slew.
First derivative (dV/dt) of the fluorescent lamp spectrum.
Circuits can be slew-limited through the choice of OPAMP and by any of several ways of current starving the sampling capacitor in the input stage to the ADC. Maximum slew and output current are characteristics usually listed in the datasheet for an OPAMP. But circuit design can limit slew as well.
For purposes of a scientific instrument, we require linear behavior for dV/dt spanning the full range of lines that we might see in our measurements. There are some surprising challenges to accomplishing this which we discuss in the section on electrical design.
The equipment list for our linearity study is as follows. Construction of the spectrometer is described here
- Spectrometer
- Fluorescent lamp
- Neutral density wheel filter for attentuation (individual filters can be used instead)
- 200μm optical fiber
- Miscellaneous mechanicals to hold the lamp, ND filter and fiber.
Once set up and aligned, the mechanical configuration remains fixed through the duration of the measurements. The ND filter wheel is adjusted and left in a fixed setting for each dataset, each comprising a set of exposure settings.
The following describes a simple approach to designing a spectrometer, and in particular the instrument that we used to test the new sensor device. We will see that the choice of lenses and grating emerge in a simple way from the choice of spectral range and the size and pixel density of the sensor.
For our design, we use a transmission grating rather than a reflecting grating and folded geometry. The transmission geometry is simpler and provides good performance with reasonable cost. The following pictures show (a) the inside of the instrument, sometimes referred to as the "optical bench" and (b) the cover which is constructed of black opaque plastic. The base is aluminum plate. The sensor can be seen mounted after the second lens and the controller can be seen at the top rear of the cover with a blue USB cable running to the computer. For the present design we chose a center wavelength at 500nm. The wavelength range is 450nm. Optical resolution is about 0.5nm with a 50um slit.
The parts list for the above is:
- Grating, 1200 grooves/mm, Thorlabs GT50-12, $250
- 200μm entrance slit, DIY-Optics.com, ~$30
- Plano Convex lenses (50mm to 70mm bfl), ebay, ~$20
- SMA905 fitting, Amazon, Digikey, Mouser, Ebay ~$15
- Aluminum plate, OnlineMetals.com or Amazon
- Mounts produced with a 3-d printer
- Opaque black plastic sheets and black PVC tape, Amazon
- TCD1304 sensor board and controller from this repo, with cables
The following diagram shows the transmission geometry. Two lenses sandwich a grating with an aperture at the focal point of the input and the sensor at the focal point of the output and oriented parallel to the grating.
A productive way to think of this is that the optical system images the aperture onto the sensor, the grating transforms wavelength to angle, and the sensor samples the resulting spatial pattern.
If there can be said to be a "master equation" for a CCD spectrometer, it would likely be the following
δλ/Δλ = M wslit/LD
wherein the ratio of spectral resolution δλ to range Δλ, is equal to that of the widths of the slit wslit and detector LD multiplied by the optical magnification M.
The optical magnification contains a factor for the geometry multiplying the ratio of the two focal lengths,
M = (cos(θin)/cos(θout)) x (LF/LC)
For a CCD detector, we have a fixed number of pixels Npixels with which to sample our spectra. Quite obviously it serves little use to have a peak of width δλ occupying less than a few pixels. In practice a good choice is 5 pixels. Therefore we want that
δλ/Δλ > 5/Npixels
For the TCD1304 we have 3648 active pixels in approximately 30nm of length. Therefore we want Δλ/δλ < 729.
Example:
For 0.5nm resolution, our spectral range can be as large as 364.8nm. To accomplish that with a 50um slit we need a magnification of 0.82.
We noted in the above that the magnification term is simply the normal magnification (ratio of focal lengths) multiplied by a term for the geometry as the ratio of the two angles.
The geometry follows from our choice of the center wavelength, and our choice of grating, through the following equation,
G λ0 = sin θin + sin θout.
where G is the line density for our grating.
Example:
For G = 1200 l/mm and a center wavelength of 500nm, we find that the sum of the sines is 0.6. If we set the exit angle to 0, then we have θin = 37 degrees. (A 1200 lines/mm, 500 nm glass transmission grating will usually be blazed at 37 degrees. See Thorlabs or eBay.)
The spectral range to be covered by the instrument is a function of the geometry, the size of the detector and the focal length of the output (focusing) lens,
G Δλ = cos(θout) LD/LF
Example:
We want a range of 364.8nm. Therefore the right focusing lens will have a focal length LF = 1 x 30mm/(1200 l/mm x 364.8mm) ≈ 68mm.
The spectral resolution is a function of the geometry, the size of aperture, and the focal length of the input (collimating) lens,
G δλ = cos(θin) wslit / LC
Example:
We want a spectral resolution of 0.5nm with a 50um slit. Therefore the right collimating lens will have a focal length LC = 50um x 0.8/(1200 l/mm x 0.5nm) ≈ 66mm.
Notice that our angles and focal lengths agree with our expected magnification factor, (0.8/1) x (68/66) = 0.82
One more thing to check is that we are not asking for resolution that is better than our diffraction limit. For the focus the diffraction limit is
δλdiff = 1.03 λ0 M Δλ / 2 LD tan(NA)
and for the grating we haveδλdiff = 0.84 λ0 cos(θin) / 2 G LC tan(NA)
where NA = n θ is the numerical aperture, n is the index of refraction and θ ≈ λ0/wslit is the angular spread at the entrance and focus spot. Both of the diffraction limit formulae reduce to approximately δλ/2. In other words, for this instrument δλdiff ≤ δλ/2.
That completes the design, for our purposes.
After settling on the parameters and digging through our box of lenses and gratings and aluminum plate, and perhaps ordering a few thing from ebay or Thorlabs, it is time to build the spectrometer. We start with our Al plate and draw two lines intersecting at the selected angle for the incoming and outgoing optical axes. The vertex is where the grating will be mounted. Then holes are drilled to mount the lenses, each at about 20 to 30 mm from that vertex to leave space for the grating housing. We 3-d printed the mounts for the grating and lenses. Then, mounting one lens at a time, we use a flash light to find the location of the focus of each lens along its line. That is where the aperture and sensor will be located. Note that the sensor is actually 0.7mm behind the face of its window. We drill the remaining mounting holes, install everything, apply black tape to dampen stray reflections, and connect the cables to the sensor. We tweak the location of the sensor while monitoring the spectrum with the software with a fluorescent lamp as input. Now we cover the instrument with a non reflective case, save a fluorescent spectrum and calculate the coefficients to convert pixel number to wavelength and load them into the instrument (see the firmware command "coefficients").
We now describe some of the elements of circuit design for a CCD based spectrometer (or imaging system). This will be something of a tutorial. The idea is to support open science. That includes being open about what you need to know to design something like this for yourself. We assume some basic knowledge of electronics. The "attentive reader" will note that we make extensive use of SPICE models.
We include a set of SPICE models in the SPICE subdirectory. These form the basis of most of the illustrations shown in this README.
We start with characteristics of the TCD1304DG and then proceed through signal conditioning to the ADC, gate drivers, and power architecture.
The reader may also be interested in reading the description in our repo for the original "All-In-One" board, here.
The TCD1304DG datasheet can be downloaded here. The device architecture is shown in the following figure found on page 2 and labeled "Circuit Diagram". We see a photodiode array, shift gate (SH), integration clear gate (ICG), CCD analog shift register and signal output buffer (OS), with pins SH, ICG, master clock ΦM, and OS plus power and ground.
TCD1304DG "circuit diagram", from page 2 of the datasheet.
Operation of the device is shown in the following timing diagrams which can be found on pages 6 and 7,
TCD1304DG timing diagrams, (a) coherent shutter and exposure, (b) "electronic shutter function", from page 6 and 7 of the datasheet.
As depicted, exposure begins and ends on the trailing end of pulses asserted on the SH pin, readout begins following assertion of SH and ICG together, and thereafter, data is clocked out at 1 pixel per four cycles of the master clock ΦM.
A table of capacitances for these pins is found on page 5. Without going into the details of how CCDs are constructed (see here), we can infer that the large capacitance of the SH and ICG pins are consistent with these playing an important role in harvesting charge in the device. Four clock cycles per pixel readout further indicates a 4 cycle type CCD register.
We discuss how to drive the gates, and in particular the shift gate here. The present discussion focuses on the analog signal conditioning part of the design.
TCD1304DG "gate capacitance", from page 5 of the datasheet.
Electrical characteristics of the TCD1304 output are described on page 3 of the datasheet (excerpted here). We include the diagram from "Note 8" to indicate the origin and direction of the signal in volts. The output is a negative going signal from fixed DC level VOS typically 2.5 volts (var 1.5V to 3.5V) to VOS -0.6V at saturation (min -0.450V) and the output impedance is typically 500Ω (max 1kΩ).
The TCD1304DG datasheet reports dark noise as 2mV (typ, max 5mv) with 10 ms exposure. The following shows our measurement of the dark noise as a function of exposure time using our 16 bit sensor board. As expected, dark noise is linear in exposure time. But there appears to be a floor for dark noise at about 0.6mV, which it approaches for exposure times less than 20ms.
Dark noise vs exposure time in the new sensor device. (Electrical noise with sensor removed is ~14uV)
Removing the chip from the board, the electrical noise is about 14uV. So it seems that the dark noise signal at 0.6mV really does originate in sensor chip.
Dark noise is known to be related to temperature with the usual Boltzmann dependence. Some have reported reductions in noise by a factor of 4 with modest cooling to around 4C.
For best performance we want to match the output of the TCD1304DG to the input range of our ADC. For the two board configuration, this will be a 16 bit high precision ADC with a differential input and 4V reference. For the "all-in-one" board this will be the 12 bit analog input of the MCU with a range of 0 to 3.3V. In either case we need to shift, flip and amplify the output from the sensor to match the input range of the ADC.
The following shows a reasonable approach for a simple shift, flip and amplify while accommodating the wide variation in output impedance of the sensor. We use a dual OPAMP, the ADA4807-2, slew 225μV/s, input noise 3.1nV/√Hz, 0.1pA/√Hz, and input capacitance 1pf. The first unit is configured as a voltage follower to take care of the large variation in source impedance and the second is setup as an inverting amplifier with offset. This gives us reproducible gain and it provides linear response with good noise performance. We use this approach for our 12 bit systems including the "all-in-one" and analog boards.
We use the following approach for 16 bit precision. Similar to the above, the first unit is configured as a follower but the second is configured as an inverter with offset and unity gain. The two outputs together provide a differential signal. In implementation we follow this with a fully differential amplifier (FDA) and a differential input ADC. For gain we get a factor of 2 for free and make up the rest in the FDA. Cancellation between the differential pair improves noise performance for our mixed signal environment.
The following shows a design that appears from time to time in DIY postings. The inventor typically omits the voltage-follower and instead goes straight to the inverting amplifier. This of course makes the sensor part of the gain equation, G = R2/(R1+Rsensor). But the sensor impedance as we noted above, varies from 500Ω to 1kΩ. If the inventor is aware of the issue, they might make R1 very large to drown out the contribution from the sensor. But to have gain, R2 has to be even larger, typically 2 to 5 times R1. Now come the problems.
With large values for R1 and R2 there is a large parallel resistance that dominates the noise density at the input, vn ≈ 0.13 √R// [units nV/√Hz] (see "Johnson noise"). This creates a trade-off between bandwidth and precision. And with a very large R2, the pole formed with the input capacitance of the OPAMP at fp = 1/(2πR2Cinp) moves to lower frequency and can be within the bandwidth needed for readout. The amplifier may be unstable and the data unreliable. All of this is for a net savings of about $3 for leaving out the voltage-follower. If you need to report spectra with reproducible intensities, it might be best to avoid devices that take this approach.
This another circuit that shows up in the DIY ecosystem. In many textbooks it is the first transistor circuit that we encounter. There we typically learn about their non-linearities and asymmetries in sinking and sourcing current and what happens when driving a capacitive load. This is what we need to think about when we try to build a spectrometer with an emitter follower as the in-between for the sensor and ADC.
The following shows the emitter follower with a PNP transitor (left) and with an NPN (right). The datasheet for the sensor shows the circuit on the left. This is the least circuit that could be provided and it is not a good match for our use case, to drive an ADC for a spectrometer.
PNP and NPN followers.
Let's first consider this basic circuit with a slow signal (or DC) and with only RE as the load. The output is simply the input offset by the base-emitter diode, Vout = Vin +/- VBE. There is a non-linearity in this in that the base-emitter voltage varies with the emitter current, VBE = VTln(IE/IS), and the emitter current varies with the output, IE = (VEE - Vout)/RE. (The thermal voltage VT (~25meV @RT) and saturation current IS (10-15-10-12A) can be treated as constants after things have warmed up.) The variation in gain over our range of signal can be order 1 percent.
Now let's connect this to an analog input, which we represent in the following figure as a series resistor and switched capacitor. The curves illustrate the behaviors when sourcing and sinking current. The PNP(NNP) is a good current sink(source) but not as good as a current source(sink). Recall that accuracy in an ADC depends on the sampling capacitor charging or discharging to its input voltage within its sampling window in time.
PNP and NPN followers driving the ADC sampling capacitor.
Compounding the above, the above holds true provided we are not asking for too much current. As we approach the quiescent emitter current, the transistor begins to turn off and we increasingly current-starve the sampling capacitor and reduce the maximum slew rate. This is summarized in the following table.
| PNP | NPN | |
|---|---|---|
|
|
|
|
|
|
|
|
Now the question is, how well does (or, can) this work in a practical case? For 16 bits of accuracy and a 0.5usec sampling window, we need a maximum slew of at least 16 x ln(2) x 0.6V/0.5usec = 14V/usec (or 10V/usec for 12 bits). In practice we should use a circuit with a larger maximum slew to avoid the roll-off region.
Let's consider a notional 16 bit ADC with a 30pf sampling capacitor and let's power the system from the quiet 3.3V power provided by the LDO built into the microprocessor board. We can set RL = 1K and our maximum slew is then 6V/usec.
For a 12 bit ADC with a 10pf sampling capacitor, and RL = 2K we have a maximum slew of 10V/usec . And for a more specific example, the UNO R4 processor datasheet lists 2.5K and 8pf. This means the maximum slew would be 10V/usec. But it also lists the ADC error as +/4LSB.
So, the approach with a single transistor follower is marginal at best for these parameters. We can power it at a higher voltage, and perhaps choose values to get it to work better. But the cost for a dual ADA4807 which has a slew rate of 225V/usec is only $5.
The present application requires analog to digital conversion at rates from 200KSPS to 1MSPS and between 12 and 16 bit precision depending on your specific needs. This put us in the domain of the SAR type ADC (successive approximation register) see here. There are some important details to using a SAR type ADC and moreso for our application. This involves some nuance, so we start from the basics.
The SAR architecture comprises a sample and hold (S-H) circuit followed by a comparator and DAC which are operated by internal logic to implement the successive approximation algorithm. The S-H circuit is seen by the driving circuitry as the input to the ADC. In a simplified sense, it looks something like the following but with the switch driven by a clock.
We can implement this in a SPICE model as follows. For purposes of illustration, we include an ideal voltage source as the input. C1 is the sampling capacitor, S1 is the switch that connects C1 to the input, and S1 is controlled by the clock V1. When S1 opens, the voltage on C1 is converted to a digital representation by the SAR engine. The time during which S1 is closed, is called the sampling window. (Values for the internal resistance (Ron) and capacitance (C1) for a given ADC are usually available in its datasheet.)
ADC model with ideal voltage source.
Green = input, blue = sampling capacitor, grey = sampling window.
For n bits of precision and full scale range Vfs, the voltage on C1 at the end of the sampling window has to be within 1 part in 2n of Vfs. The input always has some series resistance, in this case Ron. Therefore the sampling window has to be at least as long as n x ln(2) x Ron x C1.
Voltage noise of a capacitor is vc = √(kT/C). For n bits of precision, we need vc < Vfs/2n. The 30 pF sampling cap shown in the model produces about 11μV of noise and 1/216 = 15μV.
When you select an ADC, make sure to look for these parameters in the table of electrical characteristics or the equivalent circuit for the input in the datasheet. Also don't forget to look at the graphs for SNR. Often the SNR quoted in the beginning of the datasheet is less than the whole story. And don't forget to look at PSRR. And do follow the guidelines for selecting the voltage reference and for layout.
Kickback describes what happens when the switch closes to connect the input to the driving circuit.
In the following we drive the S-H from a voltage follower instead of the ideal voltage source. Now when S1 opens or closes we see spikes (circled) on both voltages and in the current through R1. This is the famous "ADC kickback". It arises in the current needed by C1 with the sudden change in voltage when the switch closes.
ADC model driven by OPAMP follower.
Green = out, blue = sar cap, grey = sampling window, red = current through R1.
In the often recommended solution for kickback, we provide a charge reservoir in the form of a capacitor in front of the input to the switched capacitor network, as in the following illustration. Now, when the switch closes, current flows from the charge reservoir, which is replenished on a somewhat slower time scale by the driver (the opamp).
The following shows the implementation of this scheme in our SPICE model. A cap C2 is added in front of the ADC to act as the charge reservoir for C1. We see in the traces that charge for C1 now comes from C2 and the voltage on C2 is managed by a much smaller current through R1. There is no discernible kickback in V(out) nor in the current through R1.
ADC model with recommended driver, charge reservoir C2.
Green = out, turquoise = adc in, blue = sar cap, grey = sampling window, red = current through R1, orange = current through C2.
The charge reservoir and series resistor together look like a low pass filter, but the components are chosen a little differently. C2 needs to be large compared to C1 and R1 needs to be tuned between the current capacity of the OPAMP and allowing C2 to track the input. We make extensive use of SPICE modeling to check designs for response and precision.
You may recall our discussion about dV/dt and sharp spectra lines near the top of the README. Here is what happens when a large dV/dt meets the charge reservoir that we added to support the sampling capacitor in the ADC. The circuit in this example is a "full feature" single ended model from CCD to ADC. The input is a pulse, and a little bit extreme with a 2ns rise time.
Notice that we now have a large current through R1 coincident with the leading and trailing edge of the pulse. The current through C2 is as before. So, large dV/dt meets cap serving as charge reservoir and produces a new kind of kickback.
Effect of dV/dt in charge reservoir.
Green = out, turquoise = sar cap, blue = sar cap, grey = sampling window, maroon = current through C2, red = current through R1.
The following shows a method for mitigating the new kickback. We simply slow the pulse a little bit with a low pass filter in the feedback loop. This has to be tuned somewhat to put the current within the capabilities of the OPAMP but still allow C2 to recover fast enough to meet the design requirements for precision. We are able to get 18 bit precision in models. Real spectra are less demanding and our precision spec is 16 bits.
The following are screens from two of the spice models that we used in designing the sensor board.
This is the SPICE model for the analog signal path with ADC. The input is configured as a short pulse to stress the kickback management. The second graph shows the voltage on the sampling capacitor converging to the input voltage within the sampling window. Convergence is better than 1 part in 16 bits.
SPICE model for the 16 bit sensor board, analog section.
Red = sensor, Green = adc inp, turquoise = Cs+ (sar cap), blue = current through R11.
Convergence of V(Cs+) to input voltage for the 16 bit sensor board.
Red = sensor, Green = adc inp, turquoise = Cs+ (sar cap).
Issues that require careful attention in designing the gate drivers, include the fact of the very large capacitance of the SH gate, the role of this gate in collection charge from the photodectors into the readout CCD register, and then an electrical effect in the rest of the circuit wherein noise from the gate drivers appears on the power rails.
Recalling the table at the top of the discussion on electrical design, we saw that the shift pin has a capacitance of 600pF. As we will see in a moment, the shift pulse needs to be driven with a rise time that is short compared to the duration of the shift pulse, generally a factor of 20 can be appropriate. This means that for a 1 usec shift pulse, we need at least 4V x 600 pf/ 50 nsec = 48mA.
A suitable way to drive the gate would look like the following. We use a SN74LVC1T45 and an 82ohm series resistor.
The following shows a SPICE model for the gate drivers. These generate a pulse on their power rails, so we power these from a separate voltage regulator. The model includes a current limited supply for the LDO with inductor, in place of the filtered current limited 5V supply on the actual board.
Gate drivers and pulse generation on the power rails.
Blue = V(sh), Green is V(icg), Red = (V(ccb)-4.0492) x 1000, Grey = I(R6)
Note that the trace for voltage pulse on the supply side of the gate drivers is scaled times 1,000. Using this model we confirm that the amplitude of the pulse is well within our power supply noise budget for the analog signal path.
Now lets take a look at another way in which the gate driver effects performance in the analog section. In our earlier discussion of linearity we briefly described the architecture of a simplified notional pixel comprising a photodector region and an element of the shift register. The following shows what that looks like in action. Light produces charge, pulsing the shift gate moves charge to the shift register, which is then shifted away by clocking the shift register. But, some charge necessarily remains behind in the photodector region. The quantity depends on material properties, dimensions and temperature and the voltage and duration of the pulse applied to the shift gate.
We will now what this effect can look like in practice. The data in this section were collected using the analog sensor board so that we can vary the voltage on shift gate. The sensor is operated by the controller with the standard firmware included in the repo. We use the low level pulse commands to vary the pulse width. We coded a timing generator into another Teensy to turn on a red LED in every other frame. The LED is on for 1.8msec starting 1msec into the first of each pair of rames, each frame is 10msec exposure back to back.
The following shows data obtained with the LED turned on (in blue) and then off (orange) per the above description. The data is collected with a 1usec 4V shift pulse. Numerically, we find that the carry-over image is a faithful copy of the preceding frame though noisier and on a reduced scale.
LED spectrum, orange curve is with LED off.
In the following figure we measure the carry-over intensity as a function of the width of the pulse applied to the shift gate and at several voltages. We find that the "carry-over" signal decreases with an exponential time constant similar to that of the charging curve for the shift gate and its driving circuit. In this case we have a 100ohm series resistor in series and the 600 pf capacitance of the SH gate, and thus a time constant of 60 nsec.
Initial carry-over is reduced with adequate SH pulse width.
In the next figure we pulse the shift gate a few times before we start the exposure. Effectively this is like a series of short exposures, each leaving a percent or so of residual charge. In other words absent confounding effects it is reasonable to expect that the carry-over should decrease exponential in the number of pulses and approach an asymptote. The data suggests that in principle we might reduce the carry over to 0.1%. In practice we use 4-8 clearing pulses to reduce the carry-over to 1% to 1/2%.
Carry-over decreases with number of SH (clearing) pulses.
We can see that carry-over, in most instances will be a necessary part of the physics of the CCD detector device. But the effect is linear and reproducible and it can be made small. Nonetheless, there are situations where we need to take this into account, for example in studying kinetics.
In our lab we typically setup our triggered data collections to include a few blank exposures, a small carry-over from a dark frame is smaller than the dark signal by definition. For a timed series of exposures we might configure clearing pulses, depending on the time scale, and if needed we can calibrate the carry-over and remove it in post processing. Other mitigation strategies are possible depending on how you design your experiment.
Following the dictum "always preserve primary data" we refrain from doing data manipulation inside the instrument. This is easily done off line, using the program and class library DataReader.py.
The following is a subset of the commands implemented in the TCD1304 firmware and in the Python user utility (indicated as CLI). Enter the command "help" for a more complete listing and consult the source code for further information.
Quick command reference
See help for more details
| Operation: | commands: |
|---|---|
| Timed exposures | read <n><exposure (secs)> → [wait read] |
| read <n> <exposure (secs)> <interval (secs)> → [wait read] | |
| Triggered timed exposures | trigger <nframes><exposure (secs)> → [wait trigger] |
| trigger <nframes> <exposure (secs)> <interval (secs)> → [wait trigger] | |
| trigger <nsets> <nframes> <exposure (secs)> <interval (secs)> → [wait trigger] | |
| (The CLI receives data frames onto its data queue. See CLI save, add and clear) | |
| Configure trigger | configure trigger [ rising|falling|change | (no)pullup | pin <n> ] |
| Configure clearing pulses | configure clearing pulses <n> |
| Mid level operations: | command sequence: |
| Timed exposures | setup pulse → setup timer <secs> <n> → start timer |
| Triggered timed | setup pulse → setup timer ... → setup trigger [options] → start trigger |
| Triggered/gated | setup pulse → setup trigger ... → start trigger |
| Manual exposure | setup pulse → start pulse (2x to form an exposure) |
| Short exposures | setup frameset <exposure> <frame interval> <n> ... → start frameset |
| Triggered frame sets | setup frameset ... → setup trigger → start trigger |
| Configure trigger | configure trigger [ rising|falling|change | (no)pullup | pin <n>] |
| CLI functions: | command: |
| Data summing | add frameset - add queued data collating by frame number |
| add all - adds all of the queued data resulting in a single frame | |
| add all after - adds all of the queued data after the first n frames | |
| Clear data and text queues | clear |
| Wait for completion | wait |
| Save to disk | save <filenameprefix> |
| Print help text | help [report|coefficients|pulse|frameset|timer|trigger] |
| Execute from script | @<filename> [args] |
| Pass command to shell | !command |
| Exec in Python | [leftside]=[rightside] |
| List name space | = |
| Loop (example) | for a_ in [0,.1,.2]: @testscript "%.2f"%(a_)" |
| Print configured i/o pins | pins |
| Digital I/O | set pin <pin> hi| lo| output| input| pullup |
| pulse pin <pin> <usecs> | |
| read pin <pin> | |
| toggle pin <pin> | |
| Quit | quit | exit | ctrl-c |