Chapter 2
The LuckyCam Data Acquisition System

2.1 Introduction

In this chapter I describe the LuckyCam data acquisition systems, from the optics and electronics to the realtime analysis and data storage software.

In the area of data acquisition, I have been responsible for all software used in the LuckyCam system once the camera electronics have passed pixel data to the data acquisition PC. The software includes a video display, realtime Lucky Imaging and other analysis, the data storage systems (which store 14MB/sec continuously for entire observation nights) and realtime data compression. I have also written the optics control system for the 2006 version of LuckyCam. The LuckyCam optical hardware was designed and built by Craig Mackay (and John Baldwin in 2000-2004); the LuckyCam control electronics were designed and built by Craig Mackay. The DSP camera control system was written by Ali Basden. The custom L3CCD clocking and readout electronics are described in detail in Mackay et al. (2004).

2.2 LuckyCam Optics

Since the initial experiments in July 2000, there have been several version of LuckyCam, the Cambridge Lucky Imaging system. All versions from 2000-2005 were designed for the Cassegrain focus of the 2.5m Nordic Optical Telescope (NOT) at La Palma, Canary Islands. The 2006 version is designed for the Naysmith focus of the 3.6m New Technology Telescope (NTT) at the La Silla observatory, Chile. Extensive details of the 2000-2003 LuckyCam versions are given in Tubbs (2004).

Although the details differ, the versions of LuckyCam have essentially the same optical layout – in almost all LuckyCam observations light from the telescope simply passes though a lens (to adjust the image scale) and a filter, before arriving at the CCD. No active optical elements are included, leading to a very elegant and cheap system. The evolution of the LuckyCam system was as follows:

2000. A standard front-illuminated frame-transfer CCD39, run by an AstroCam 4100 controller was used for initial testing of Lucky Imaging with bright stars. The f/11 beam from the telescope was converted to f/33 using a single achromat giving a pixel scale of 40 mas (milliarcseconds) per pixel.

2001-2. A 624×288 pixel E2V CCD65 L3CCD was used for faint guide star Lucky Imaging. The light path within the (~1 meter long) instrument was folded into a ’Z’ shape. One of the fold mirrors was formed from two mirrors butted together at a slight mutual angle. This allowed two stars separated by up to 30 arcsec to be imaged within a few arcsec on the L3CCD, for tests of the isoplanatic angle size at larger radii than would otherwise be possible.

2003. The CCD65 was replaced by a 536×528 pixel E2V front-illuminated frame transfer CCD87. The optics were adjusted to give a re-imaged aperture plane, into which circular aperture masks were introduced to test the effects of changing the telescope aperture size on the Lucky Imaging quality.

2004. The optics were redesigned to give a straight-though optical path. A grism was added for low-resolution spectroscopy (see below) and the CCD was replaced by a thinned back-illuminated E2V CCD97.

2005. The 2004 optical layout was maintained, with the addition of atmospheric dispersion correctors and electronically-controlled interchangeable optical elements. The instrument is shown in figure 2.1. The L3CCD clocking and readout electronics were upgraded (and are described in Mackay et al. (2004)), improving camera performance and allowing an LVDS interface to a standard Matrox frame-grabber PCI card (see section 2.4).

2006. This version is a complete redesign (LuckyCam HighRes) for aperture masking trials as well as conventional Lucky Imaging, at the Nasmyth focus of the NTT. The optical path is much the same as the 2005 version, but the addition of a re-imaged aperture plane and the different focal length of the NTT necessitated a much longer instrument. All components of the system are controllable in software (see section 2.4.5).

Most of the observations described in chapter 4 were performed using the 2001-2004 versions of LuckyCam. Chapters 6 and 7 are based on observations using the 2005 version of LuckyCam. I describe the 2005 LuckyCam in detail in the next section; most of the below discussion is applicable to the other versions of the system.

2.2.1 LuckyCam in 2005

Taking the optical path in order from the point of light entry, the principal components of the 2005 version of LuckyCam are listed below. Figure 2.2 shows LuckyCam at the NOT in November 2005, and figure 2.3 is a sketch of the optical layout.

1. Atmospheric Dispersion Corrector (ADC), to correct for the chromatic effects of atmospheric refraction, which become very significant for high resolution observations at large zenith distances (e.g. Stone (1996)). At 50^∘ from the zenith the relative dispersion between 700nm and 750nm wavelength light is ~ 0.1arcsec, the width of a diffraction-limited PSF, requiring correction for high-resolution imaging. The two ADCs are designed for correction at 30^∘ and 45^∘ degrees from the zenith for observations at the NOT, and give improvements for a large range of angles surrounding those values. The ADCs are mounted on a movable stage, and their orientation is controlled by a simple system of weights – the downward direction at the Cassegrain focus of the altitude-azimuth NOT always points in the direction of the atmospheric dispersion. The ADCs were designed by David King. Almost all observations presented in the thesis were performed without the ADCs but close to the zenith, where the relative dispersion is negligible.
2. Filter wheel 12 filter positions are available for quick changes during observation runs.
3. Lens Two lenses are selectable, for imaging at f/33 (0.04 arcsec per pixel) or f/22 (0.08 arcsec per pixel). A third position has no lens fitted, giving the raw f/11 NOT imaging at 0.12 arcsec per pixel. Because the focal length changes at the different magnifications, the CCD dewar is also mounted on a movable stage to give greater focus position changes than available from the telescope.
4. Grism. Two positions (in the beampath or out) are available, with the grism mounted on a movable stage. Approximately 90% of the light passing though the grism is dispersed into a spectrum ~ 100 pixels long. The remaining 10% of the light passes straight though, to serve as the guide star. Selecting and aligning the best frames of the guide star also selects and aligns the best spectrum frames, as they have passed though the same atmospheric turbulence. An example high-spatial-resolution spectrum produced by the grism is presented in chapter 4.
5. L3CCD chip and Dewar. The L3CCD chip is mounted in a liquid nitrogen dewar attached to a movable stage. The L3CCD chip is read out at a 7MHz pixel rate. When full frames (536×528 pixels) are read out, this corresponds to a frame rate of ~20 Hz. The vertical frame size can be reduced, to give smaller frames read out proportionally more often, at up to 100 frames per second for a 536×100 frame size.

Each optical element is mounted on a movable stage (wheel in the case of the filters), driven by motors controlled from a custom board located in the telescope control room (the board is shown at the top of figure 2.2).The LuckyCam optics are designed for the diffraction-limited resolution of the 2.5m NOT in the visible, but are otherwise fairly standard for CCD imagers. The main difference of LuckyCam from other CCD imaging systems lies in its L3CCD and custom CCD clocking and readout electronics.

2.3 L3CCDs

CCDs (Charge Coupled Devices) are very widely used in astronomy, and meet many of the properties of an ideal astronomical imager: they offer intrinsically linear performance, quantum efficiencies (the fraction of light detected) of >80 per cent over much of the visible spectrum, very low dark currents when cooled and are available in (very) large format arrays.

In a standard CCD (see Janesick (2001) for a review), light impinges on a set of pixels set up in a silicon wafer. Each absorbed photon produces a single electron, which is trapped in the nearest pixel. Once the selected integration time has been reached, the stored charge is transferred out of the chip one pixel at a time. The charge from each pixel is read out though a single amplifier; the number of detected electrons from each pixel directly gives the number of photons absorbed by that pixel.

Most astronomical CCD system are read out slowly (10s of seconds to read out full frames, 10s of KHz pixel rates), and still reach readout noises only little better than ~ 2 electrons per pixel (Jerram et al., 2001) – thus, 12 input photons are required in a single pixel for a detection of flux with a signal-to-noise ratio of 3.

Lucky Imaging systems (and other short-exposure systems) must run at MHz pixel rates to get sub-second readout times on reasonably large chips. The high-speed readout raises the readout noise to 10-100 electrons per pixel (Jerram et al., 2001), so only bright stars are detectable in each frame. If, as in Lucky Imaging, we require an estimate of the PSF of the guide star in every frame, many hundreds of photons from the guide star are thus required – limiting them to be unfeasibly bright. For example, the initial Lucky Imaging experiments performed by the Cambridge group, using a standard CCD camera, were limited to stars brighter than +6 mags (Baldwin et al., 2001).

L3CCDs Jerram et al. (2001) (Low Light Level CCDs, also known as Electron Multiplying CCDs) offer a solution to the CCD readout noise problem. The imaging area of an L3CCD has the same design as that of a standard frame-transfer CCD, but each pixel is read out though an electron multiplication register (figure 2.4).

In the multiplication register, one of the three electron transfer phases is clocked to a much higher level (20–40V) than is needed for electron transfer. This accelerates charge-carrier electrons to sufficiently high velocities to generate additional carriers by impact ionisation. Although the probability of an electron-multiplication event is low (typically 1-2%) in each transfer, the total gain can be very high after transfer though the hundreds of elements in a typical register.

Typical gains used on LuckyCam range from 1000-10000 output electrons per input electron. Each photon then presents a signal of several thousand electrons to be detected above a few hundred electron readout noise of standard CCD readout electronics – and L3CCDs give high-frame-rate photon counting with full CCD quantum efficiencies.

L3CCDs are manufactured by E2V Technologies^* and are available back or front-illuminated in a variety of image sizes. A second manufacturer, Texas Instruments, also produces CCDs with very similar electron-multiplication technology, under the trade name Impactron. In this thesis I refer to electron-multiplying chips as L3CCDs, but the discussion applies equally well to other electron multiplication register equipped CCD devices.

Because the multiplication register is run at very high voltages, care must be taken to avoid the spontaneous generation of charge carriers within the register. These appear as photon-like events in the camera data, and if present in large numbers effectively lead to an increase in the sky-background. Tests of the LuckyCam L3CCD camera show that the system produces a very small number of these events compared with other L3CCD systems currently available (Tulloch, 2004).

2.3.1 Multiplication noise

Because the generation of additional charge carriers is a stochastic process, the output signal from the multiplication register for a given input signal is spread over a wide range. For an input signal of n photons and a long multiplication register, an approximation to the probability distribution of the output signal p(x) is given by (Basden et al. (2003)):

(2.1)

where x is the output signal, g is the mean gain, the photon input level is relatively small (n < ~15) and the gain is large. The distributions for 1-4 input photons are shown in figure 2.5.

The output signal distribution has a mean of n × g (so simple signal averaging produces a linear response [figure 2.6]), and a variance of n × g² (Basden et al., 2003). The variance in the distribution introduces an extra noise into the output signal beyond the Poisson photon noise. The final signal-to-noise ratio (SNR) of the output in the absence of readout noise, but with Poisson photon noise thus becomes:

(2.2)

i.e. the L3CCD multiplication process introduces an extra factor of into the noise of a photometric measurement compared to a perfect photon counting imager.

2.3.2 Photon counting

(a) Raw data (cleaned using CLEANUP)   (b) Photon-counted Figure 2.8: Photon counting. The left panel shows a frame from the June 2005 LuckyCam run, taken with a gain of 190DN/photon and a readout noise of 11DN RMS per pixel. The right panel shows the image with a threshold level set at a 7σ deviation above the background noise. This threshold level leads to approximately 30% of the photons being rejected. Some of the detected events are likely to be spurious events generated on the L3CCD.

L3CCDs, when run at high gains, show an easily detectable signal for each input photon, allowing photon counting with the full quantum efficiency of a standard CCD. However, the S/N reduction produced by L3CCD multiplication decreases the effective quantum efficiency by a factor of two when integrating by simply summing the recorded frames. In addition, the CCD readout amplifiers introduce readout noise which, while it may be an order of magnitude lower than the average photon event level (figure 2.7), also decreases the S/N.

If the signal in one pixel is known to be very much less than one photon per frame, the L3CCD output signal can be thresholded to remove both problems (Basden et al., 2003). Each pixel is set only to contain a photon or not (figure 2.8), based on whether its data value is above or below a threshold level. The level is set such that each claimed photon is a significant detection above the readout noise. The L3CCD multiplication noise is therefore eliminated, by using the prior information that each pixel is only likely to contain at most one photon – and thus removing the overlap between photon input distributions.

However, photon-counting must be applied with care for two reasons:

1. Photon losses. Thresholding removes all those photon events which fall below the threshold level. The output signal probability distribution for a single input photon is an exponential decrease with signal level. The threshold level and/or system gain must therefore be set with care to avoid losses of possibly large numbers of photons multiplied to a level below the threshold level. In most observations we operate LuckyCam such that the mean single-photon signal is 5-10× the readout noise, a compromise value that avoids excessive dynamic range loss.
2. Non-linearity. If a thresholded pixel happens to actually contain more than one photon, it is still only counted as a single photon by the thresholding scheme. This leads to a large loss in signal for bright sources. The thresholding scheme can thus only be applied when the target in question is known to be faint. In practise this is not a significant limitation for most LuckyCam science observations, as sources which generate several-photon events in each of several thousand frames in a typical run are usually sufficiently bright that their S/N is dominated by other factors than multiplication noise.

More complicated thresholding schemes have been discussed, in which the signal is thresholded into a number of different photon event levels (Basden et al., 2003). However, each scheme introduces non-linearity into the output signal. While it easy to calibrate this problem out for a input signal known to have a constant light level, it is not clear how to apply these schemes to the continually varying fluxes in LuckyCam images. For this reason, photon counting is not used by default in the Lucky imaging pipeline; the vast majority of the data presented in this thesis is not photon counted, although LuckyCam was run at gains that would enable photon counting once the reduction strategies have been further developed.

2.3.3 Bias, flats & cosmic rays

Standard CCD reduction usually proceeds by first removing a pixel-dependant bias value (measured from an image integrated with no incident light) and then dividing out pixel-to-pixel sensitivity variations using a constant-illumination flat field. Cosmic rays are usually removed by comparing multiple pointings or multiple integrations of the same field.

Cosmic rays can be detected in L3CCD images as a “splash” of saturated pixels on a single frame. Their removal is trivial with Lucky Imaging images, as the masking of large sections of a single frame around a cosmic ray event does not significantly affect the statistics of a typical Lucky image constructed from tens to hundreds of frames.

I elected to generate L3CCD bias frames from on-sky data, as in most frames only a small percentage of pixels contain photons. The CLEANUP and BIASGEN portions of the Lucky Imaging data reduction pipeline (chapter 3) perform this step for both large-scale bias variations and the faint vertical line biases introduced by the camera electronics. Hot/stuck pixels can be detected by eye in summed images. In all the LuckyCam data none were present more than 10 pixels from the edge of the imaging area, and so were easily removed by masking.

Flat fields (flats) are made from twilight observations of the bright sky, in the same way as for standard CCD imaging. Depending on the calibration requirements, I generated flats from the sum of either a few hundred very bright frames, or a much longer integration at low enough light levels to ensure that each pixel had < 1 photon/pixel/frame.

Bright flat fields (with several photons per pixel per frame) give a high SNR flatfield measurements, but the zero level determination is particularly difficult because flux is present in each pixel. Measurement of an accurate zero level is critical for the production of flat fields, as it has a direct effect on the derived fractional amplitude of the flat field variations. LuckyCam zero levels change from frame-to-frame and row-to-row (chapter 3), complicating this determination.

The CCD87 & CCD97 chips used for the 2003+ LuckyCam observations have a set of three rows designated as dark – i.e. masked off from incoming light. I calibrated the bright flat fields such that these rows are set to zero average flux. However, because there is some light leakage (at the few per cent level) into the rows, the accuracy of calibration using bright flat fields is limited to the few percent level.

An ideal L3CCD flat field can be constructed from the sum of many frames imaged with a flat-field illumination constrained to be much less than one photon per pixel per frame. The zero level in each pixel can then be determined from those frames that do not contain photon events. However, this approach requires very long integrations to achieve a good SNR in each pixel. For example, with an average input photon rate of 0.2 photons/pixel/frame and added L3CCD multiplication noise, a 25,000 frame (1250 second) integration is required to reach a SNR of 50 in each pixel. When we attempted twilight flat observations with a sufficiently low photon event rate, faint stars in the skyflat field often became visible during the long integration.

Since these long integration flats are taken during times of relatively low background illumination compared to standard skyflats, the flatfield observing uses time that could have otherwise been used for science programmes. I would therefore recommend that future L3CCD observations take long-integration dome flats, if a sufficiently low illumination level can be achieved in the dome.

All the flat fields used for the data presented in this thesis are produced using the bright-sky method.

2.3.4 Gain calibration

During observations at the NOT in June 2005, the LuckyCam system gain varied by as much as 10% on timescales of a few minutes and up to 25% over a night, probably due to small temperature variations in the L3CCD. Although relative photometry of targets in the same field is not affected, if photometry taken at different times is to be compared the L3CCD gain must be measured. Because of the rather rapid variations in gain, this should ideally be performed on a per-target basis.

During the 2005 runs, the gain was measured in two independent ways, which were tested and used simultaneously during data reduction:

Bright calibrator stars. In these tests we targeted a bright star which was detectable are reasonable SNR without gain. Data was then taken both with and without gain, if necessary defocusing the star to avoid saturation. The gain in DN is measured from the factor of total signal increase when gain is engaged.

Single-photon event histograms. Sky-background areas in almost all LuckyCam observations have much less than one photon per pixel per frame. The distribution of pixel values in those areas consists of an exponential from the statistics of single electrons in the multiplication register convolved with a Gaussian from the readout-noise (figure 2.9, and below). As suggested in for example Tulloch (2004), the multiplier of the exponential decrease is simply -1∕g, where g is the gain in DN/photon. To measure the gain an exponential decrease can be fit to the histogram of pixel values, with the gain as a free parameter.

Both gain measurement techniques produced the same gain values (to within the ~10% measurement errors).

For the following reasons, I chose to use the event histogram method as the standard gain calibration technique:

1. Observing gain calibrator stars every few minutes would introduce an unacceptable time overhead.
2. The event histogram method is performed completely simultaneously with the observations, eliminating the need to compensate for any rapid gain drift.
3. Some variations in gain across the L3CCD chip were found. The histogram method allows the gain determination region to be customised to the location of each of multiple objects in the field, a procedure that would be very difficult using gain calibration stars.

Accurate gain determination using the event histogram method has a number of subtleties. To give more precise and accurate gain measurements than can be obtained by fitting the histogram in the simple way described above, I implemented the following procedures:

1. Area of image for event acquisition. To get the best signal-to-noise in the gain determination, the best strategy would be to use all the image areas which do not contain bright sources. However, tests on the June 2005 data also showed the gain can vary by as much as 10% horizontally across the LuckyCam field of view. For this reason, I restricted the aquisition areas to 100 pixel wide boxes centered directly below the sources that required photometric calibration.
2. Choice of fit region. In a linear-log plot the exponential decrease becomes a straight line (figure 2.9). Low data vales are affected by the readout-noise Gaussian shape, while the highest data values are affected by low event numbers, rare two-photon events, and saturation at the highest gains. The best region of the histogram for gain determination is the region of the graph which best corresponds to a straight line. The gain determination region can be selected automatically (based on the goodness-of-fit to a straight line) or manually.
3. CTE effects Charge transfer efficiency (CTE) is typically 70-90% in LuckyCam images (see figure 2.10). That is, each photon event has 70-90% of its total flux in its brightest pixel. A simple single pixel-value histogram thus underestimates the true gain by the 10-30% of flux missing from each event. Although this effect can be removed by summing 3-4 pixels in a line for each histogram event, this can lead to problems when multiple events occur in the 3-4 pixel window (such as in the high background cores of globular clusters). However, trials using the June 2005 data showed that the CTE does not vary at more than the 10 per cent level, and so single pixel gains can be used for calibration at that accuracy – with the caveat that they systematically underestimate the true gain.
4. Spurious events The L3CCD multiplication register can occasionally excite a spontaneous electron, which is then multiplied in the remaining portion of the register as if it were a photo-electron from the imaging area of the chip. Spurious events generated at the start of the register have gains identical to that of real photons. However, most spurious events are generated somewhere in the middle of the register. They thus pass though a smaller section of the register, and so have reduced gain. If there is a very low sky photon rate the apparent gain can thus be reduced by being weighted towards these low-gain events. Accurate gain determinations must thus be made using low-speed (≤~30 FPS) data, to ensure sufficient sky-photon numbers in each frame (the gain is not dependant on the frame-rate, as the pixels are read out at the same speed irregardless of the frame size). The current LuckyCam gives spurious events which would be detected as photons at about 1/2 of the dark-sky photon rate at 30 FPS. Although this level of events may affect the gain readings, the number of spurious events would have to vary widely and rapidly to affect the relative gain determinations, and that is not observed.

Figure 2.11 shows gain-calibrated LuckyCam photometry of SDSS standard stars. The photometric accuracy is about 10% RMS, even though the actual L3CCD gain values for the observations range between 25 and 81 DN/photon. Better (and more easily automated) fits may be obtained by fitting a model including the straight line component, the Gaussian read noise and other effects, and these models will be investigated in further work.

2.4 Data acquisition - PixCel LC

LuckyCam data acquisition is performed on a standard PC equipped with a frame grabber system and fast disk storage.

The LuckyCam data acquisition system has gone though two major versions.

2001-2004 This version was based on PixCel, a commercial package used to drive the AstroCam family of cooled CCDs, running on a standard PC equipped with fast RAID data storage. Camera control was via a custom ISA custom transputer card, and pixel data was received using a custom PCI card. Approximately 90 seconds of data (1000 full-frame images) could be recorded into main system memory; data recording was then halted while the system wrote the data to disk, taking a further 90 seconds. This two-step process led to a very low observing efficiency, while the need to split entire nights of observations into 90 second runs required an unacceptable observer workload.

2005+ I designed and implemented a new data acquisition system, offering continuous recording for entire nights, realtime data compression and realtime Lucky Imaging.

The 2005+ data acquisition system is based on a 3.4GHz Pentium 4 PC running the Windows XP Professional operating system, with custom software written in Microsoft Visual C++. Data is received from the camera using a standard frame-grabbing PCI card (the Matrox^{* *} http://www.matrox.com Meteor Digital II). Two fast Serial ATA hard drives are run in a software RAID-0 mode, striping data in 4 kilobyte chunks alternately between the drives to give 24 MB/sec sustained writing performance. Hot-swappable 300 GB Maxtor OneTouch-II external USB 2.0 hard disk drives provide secondary disk storage for data transfer and backup, as well as direct raw data storage when the realtime compression systems are enabled.

The graphical user interface and data acquisition software of the previous LuckyCam system – PixCel^* – was mature and well-suited to the data acquisition tasks. The LuckyCam team were given access to the source code to the system. For rapid development of a useful imaging system, I decided to replace the backend of the previous software (the hardware interface tasks) with my own code to interface to the 2005+ camera electronics. I also added many LuckyCam specific user interface sections.

The user interface (figure 2.12) includes a wide variety of tools to facilitate both data acquisition and camera development. I replaced references and calls to the previous hardware with either stub (do-nothing) functions or hooks to new code to interface to the Matrox hardware. The following section describes my upgrades to the camera software, now named PixCel LC (LuckyCam).

2.4.1 Interface upgrades

The Lucky Imaging specific PixCel interface upgrades I have implemented are labelled in figure 2.12 (next page) and discussed in order below.

1. Realtime Lucky Imaging display. The previous version of PixCel could not display images as they were recorded (although a live video display was available when not saving data). In PixCel LC, realtime images are displayed at up to 100 frames per second while frame recording is progressing, allowing easy monitoring of the integration’s progress. The display also shows the results of the realtime Lucky Imaging & other analysis subsystems, when enabled.
2. File storage settings. Various run storage settings unique to LuckyCam are set here, including the options to enable realtime compression and store frames to multiple removable hard disk drives simultaneously. Long runs can be automatically split into multiple directories containing several thousand files each.
3. Image quality analysis graph. This graph is continually updated during data acquisition, showing a number of statistics describing the image area within the (user-specified) red box. The standard deviation of the pixels within the box, and the total flux are particularly useful during camera calibration and testing, while the 10% Lucky-selected Strehl ratio graph assists in focusing the telescope by giving a continually updated estimate of the Lucky Imaging output image quality.
4. Realtime Processing. PixCel LC can calculate and display integrations, Lucky Imaging previews and summed power spectra in realtime. The implementation of this processing is described in section 2.4.3.
5. Status display and Saturation Warning. Some data in the 2004 run was affected by saturation of the guide stars. This is hard to see by eye, because the frame quality variations lead to the very best quality frames having more than 10× the light concentration of average frames. Those frames which offer the best resolution are therefore also more likely to be saturated, which can be a severe problem for Lucky Imaging observations. To avoid this problem I implemented a saturation watch system, which monitors the maximum pixel value within the user-selected red box and alerts the observer if saturation is detected in any frame.

2.4.2 The PIXEL LC backend

The Pixel LC data acquisition backend is completely self-contained, and could in principle be run without the GUI. The extreme data storage speed and size requirements of the LuckyCam system (14 MB/sec sustained for several hours, at frame rates of up to 100 FPS) required careful software design to ensure that all data is recorded, without skipping or losing frames.

In particular, a key capability of the new system is continuous recording sustained for several hours, requiring a robust buffering implementation to ensure that other processes on the computer cannot cause frame dropping or interruptions to data acquisition. To achieve this I designed a multi-stage pipeline (figure 2.13). Each stage runs in a separate program execution thread and so effectively runs simultaneously with the others, processing data as it becomes available from further up the pipeline. The allocation of a generous intermediate storage buffer eliminates the problems of transient hard disk recording speed reductions (due to, for example, file fragmentation or system load), which could otherwise lead to pauses in data acquisition.

The data from the camera passes though the following threads in the PixCel LC backend:

1. Initial gabbing The Matrox API is told to schedule a grab of the next frame, and return the data from the previous grab. This call is issued immediately on completion of the previous grab but does not return until new data is available. Data is rapidly transferred directly from the grabber board to main system memory by a DMA (Direct Memory Access) transfer, which does not involve any processing by the CPU. The initial grab thread has an ~3.0 MB circular frame buffer. Once a new frame has arrived, the next thread (number 2 below) is told to activate, while the grabbing thread waits for the next grab to complete.
2. Move to secondary memory storage This thread transfers frames from the small circular grabbing frame buffer to a much larger circular buffer, also stored in main memory but not accessible to DMA transfers. The grabber thread’s circular buffer can only store ~ 0.3 seconds of data. The secondary buffer is 1.0GB in size, and can store over a minute of data, sufficient to avoid the effects of all likely hard disk recording slowdowns.
3. Hard disk recording When new data is entered into the secondary buffer the hard disk recording thread is woken; it iterates though the new frames available and writes them to disk with optional realtime compression.

The separation into threads allows prioritisation of these processes. The Windows threading model passes execution control from one thread to another based on the thread’s priority. If a high priority thread signals that it is ready for activity (for instance, a grab is ready to be scheduled) while a lower priority thread is executing, system control is immediately passed to the high priority thread.

The grabbing thread is given the highest, near-realtime, priority to ensure that no chance of receiving a frame is lost. However, the grabbing instruction itself is very cheap in terms of execution time, so this thread remains paused waiting for a grab for most of its execution time. A just-grabbed frame’s move to secondary storage must occur before the grabbing thread’s circular buffer is full, i.e. within ~0.3 seconds, so the secondary memory storage thread is also given a high priority. Because of the large secondary buffer, the hard disk recording need only occur within approximately one minute; this lenient criterion allows this thread to be run at standard priority, so it cannot interfere with the grabbing process.

In addition, there are several further threads which run as part of the Pixel GUI, including the realtime Lucky Imaging capabilities. These are not critical to the data recording and are thus allocated very low priority. In times of high system load (for example, when running at very high frame rates) the GUI threads are often not activated for several frames, reducing the frame rate of the on-screen display but ensuring that sufficient time is allocated to the more important grabbing and data storage threads.

2.4.3 Realtime Lucky Imaging

At the telescope it is very useful have high-resolution imaging of the targets as they are being observed, allowing changes to be made in the observation programme to suit both conditions and newly revealed details of the objects under investigation. For this reason, I implemented a simple realtime Lucky Imaging system as part of the data acquisition software.

The full LuckyCam pipeline (described in chapter 3) runs at approximately 1/4-1/3 realtime on the 3.4GHz Pentium 4 used for development - i.e. a 1 minute run would be fully reduced in 3-4 minutes. However, a preview Lucky Imaging reduction can be produced in a far shorter time if lower quality is accepted. The realtime Lucky Imaging subsystem implemented in PixCel LC does not attempt to remove camera artifacts, do flat-fielding or bias removal, or employ the noise-reduction and sub-pixel shifting strategies used by the full pipeline. It does, however, run at less than 15% CPU utilisation on the data acqusition computer, and can thus run fully concurrently with the data recording system^{* *} A DSP (digital signal processor) based system is currently being designed to run the full Lucky Imaging pipeline in realtime. .

In use, a box containing the guide star is drawn on the realtime video display are by the user. When engaged, the realtime system tracks the brightness of the brightest pixel within that box, finding the average and standard deviation of that value. Frames with highest pixel brightnesses greater than one standard deviation above the average are selected, then shifted to align their brightest pixels, and added to a realtime preview image displayed to the user. Because the seeing is constantly changing, this procedure does not select a particular percentage of frames, but on-telescope trials gave selection fractions of usually 10-20%. Note that the procedure works best in constant atmospheric conditions; if the seeing becomes very much worse compared to the start of the integration the average and standard deviation pixel brightnesses must be reset, or all frames may be selected (or all rejected). Future versions of the software could use a running average to avoid this problem.

The system proved very effective during the November 2005 LuckyCam run, including the rapid discovery of a 0.12 arcsec binary star system during observations in ~0.6 arcsec seeing.

Several other realtime processing options are available in PixCel LC, including frame shifting only (no frame selection, giving a fast shift-and-add imaging system) and direct averaging of the input frames. The power spectrum of the area within a user selected box can also be calculated and displayed in realtime, for fringe visibility checks during the 2006 LuckyCam Hires experiments.

2.4.4 Realtime compression

The LuckyCam data storage requirements are extreme. A single night of observation often produces over 250GB of data. Hard disk technology available during the design of the 2005 system offered USB external hard disk capacities of up to 300 GB for ~£120. If all data is to be backed up onto two separate disks, a minimum of two hard disks are thus required per night, leading to significant extra costs during long observing runs. This number of (heavy) external hard disks also entails difficulty in safely shipping the data back from the telescope site. A reduction in the LuckyCam data storage requirements therefore has a direct benefit to the running costs and convenience of the system.

For those reasons I implemented a realtime lossless data compression system that reduces the storage and hard disk speed requirements by a factor of two. Because the speed requirement is greatly reduced, data acquisition can be performed directly and simultaneously to two USB external hard disks, fully backing up the data as it is acquired, instead of a much slower and more complicated two-step process with initial recording to a fast RAID array.

The compression system takes advantage of the structure of LuckyCam astronomical frames. Each pixel contains either no astronomical signal, or photon events from the sky, faint extended objects and a few bright stars. Each pixel also contains readout noise. For typical observations (excepting planetary imaging and skyflats), 90-99% of LuckyCam data consists of pixels containing only readout noise.

The LuckyCam electronics samples the images with 14-bit resolution, giving data values from 0 to 16,184, which for ease of processing are stored as 16-bit integers by the Matrox frame grabbing hardware. The previous LuckyCam software stored all pixels as 16-bit integers.

The readout noise is approximately Gaussian with a 1σ deviation of only ~10-14DN. Therefore, given a known average base level, pixels containing only readout noise need only be represented as 8-bit deviations from that average level (data values -128 to +127), while those containing photon events require the full 14-bit resolution.

The realtime compression system is implemented based on these observations. Each frame is first sampled to determine an approximate average base level. The system then loops though each pixel in the frame. Those that can be are stored as single signed 8-bit values (-128 to +127) compared to the zero level. One value, -128, is reserved as a flag. If a pixel value does not fit into the 8-bit range, most likely because it contains a photon event, the flag value is written, followed by the full 16-bit value of that pixel. Pixels containing photons therefore require three bytes of storage – while the other pixels, making up the vast majority of each frame (see figure 2.14), require only one byte. This compares very well with the 2 bytes per pixel required by uncompressed images.

In typical astronomical observations compression factors of 1.8-1.9 are achieved, relative to standard 16-bit storage method. The scheme is capable of losslessly encoding all images produced by LuckyCam, and does not give compression only if bright extended objects take up more than 3/4 of the field of view. The compression algorithm is also used throughout the LuckyCam pipeline; on cleaned images with reduced noise stored during analysis compression factors of 1.98 are usual.

2.4.5 LuckyCam control

The 2006 LuckyCam is designed for extensive aperture-masking trials, which requires customisable and repeatable optical alignment to greater precision than achieved by the previous LuckyCams’ systems. For this reason, it has a number of movable optical elements under software control, allowing automated recording of the camera setup used during observations, and easy camera configuration repeatability. Previous LuckyCams were controlled either by hand (2001-2004) or electronically from a custom control board located in the telescope control room (2005, depicted at the top of figure 2.2).

Following design and construction of the LuckyCam hardware and electronics by Craig Mackay, I wrote custom LuckyCam control software (figure 2.15), to be used on the data acquisition computer both during optical tests at Cambridge and at the telescope during observations.

The movable elements of the 2006 LuckyCam are controlled in two different ways. The filter wheel (close to the CCD dewar) and aperture mask wheel (at a replicated pupil plane) are purchased from Finger Lakes Instrumentation^{* *}http://www.fli-cam.com/ and controlled by a manufacturer supplied API (application programming interface). The remaining elements (the lens, grism, ADC and focal mask elements and the movable CCD dewar) are mounted on movable stages driven by stepper motors. The motors are controlled via an RS232 serial link to a programmable single axis controller board, connected to a custom multiplexer to allow the single controller to control all five motors.

The control software is written in Microsoft Visual C++. Because there is only a single motor controller, only one stepper motor can be moved at any time, although the filter and aperture wheels can be moved simultaneously. For maximum observing efficiency (and to reduce observer frustration) it is desirable to move as many elements simultaneously as possible. I therefore implemented each independent system in the software as a separate thread (figure 2.16). The user can issue any number of motor commands in one action, and those that cannot be executed simultaneously are queued.

The stepper motor’s positions are calibrated in the following manner. Each motor is first homed – returned to a known zero position. The motor in question is moved at a normal speed (~4 revs/sec) towards one of two limit microswitches, which stop the motor when triggered. The control software then drives the motor back a few revolutions (about 1cm of physical motion of the stage), and back to the switch trigger position at a very slow rate, to give a repeatable reference position.

The control software then tracks the current position of the motor, given all motion commands issued, and re-homing is only necessary if the motor is moved while not under the control of the software (for example, during manual optical realignment). All responses of the motor controller board are checked for error conditions, and each motor move is monitored to give visual feedback of the motion to the observer, who is usually located in the telescope control room, far from the instrument.

2.5 Summary

• The LuckyCam optics are passive and very simple, consisting essentially of a reimaging lens and a filter. The system is therefore very cheap.
• An L3CCD (EMCCD) gives LuckyCam the ability to perform photon counting at high frame rates with the full CCD quantum efficiency.
• I describe various calibration methods specific to the L3CCD, most importantly a way to calibrate the system gain using data taken during science exposures.
• My implementation of a new LuckyCam data acquisition system enables continuous recording of data from LuckyCam at 14MB/sec, sustained for entire observing nights.
• The data rate is reduced by a factor of two by a realtime compression system that takes advantage of the photon-detection capabilities of the L3CCD.
• The data acquisition system can also perform a realtime preview of the Lucky Imaging results during observations, as well as various tests and diagnostics.
• I also designed the software control system for the optics of the 2006 version of LuckyCam.