Using the Andor Cameras for Slit Viewing and Science
John Thorstensen, Dartmouth College

2013 January - rev. 2013 September


In early in 2010 we took delivery of three Andor Ikon DU 937-N cameras, to replace the old image tube guiders. These are mostly aimed at the laboratory microscopy market, which is much larger than astronomy in dollar terms, so they represent a lot of expensive research and development. They are also designed with laboratory scientists in mind -- scientists who have other things to worry about than tweaking their CCD systems -- so they're basically 'turnkey' systems.

The Andors proved to be "overqualified" for guiding the telescopes, so we bought some much less expensive Finger Lakes Instrument cameras to use as guiders (see Autoguiding and Acquisition at MDM for details on using the FLI cameras for guiding.) This freed the much more capable Andor cameras for spectrograph slit viewing (for modspec and MarkIII only) and as primary science detectors. So at present the main uses of the Andors are:

Solis software. The Andor cameras are generally operated using the manufacturer's Solis software. [It is also possible to run them under Maxim DL, which connects to the guider, but this has not been used since the FLI cameras were installed.] Solis runs under Windows. It works pretty well (with a few infelicities) but there are no astronomy-specific functions. In particular, it does not 'talk' to the telescope, so if you're taking science data you need to collect the header information separately. (I have written a logger for the 1.3m to help automate that chore.)

Note that you'll need the observer password to get onto the PC that controls the camera. This is not the same as the password to the Linux boxes, so -- be sure to get it from the staff!

Salient Features of the Andor Cameras

Viewing the Slit Using Solis

Modspec and Mark III only.The Andor camera is used to view the Modspec and Mark III slits, through the Yorke Brown transfer optics. CCDS has its own slit-viewing camera (which may soon be replaced with a spare FLI, or not), and OSMOS has no provision for viewing the slit from above.

Focus. The staff focuses the slit-viewing camera on the slit jaws as part of the instrument change, using using the focus ring on the lens attached to the camera. The focus ring has a locking screw on it, so the slit-viewing camera should remain in focus once they've set it up -- you shouldn't have to touch it. Once the slit-viewing camera is in focus, one can focus the telescope by acquiring a star, putting it near the slit (the jaws are tilted with respect to the focal plane, so the focus varies slightly across the field), and focusing the telescope until the star appears as sharp as possible. This obviously requires a star and can't be done until after sunset; there are instructions further down as to how to set up the program for focusing.

To start the cameras, simply log in to the control PC as observer and start up the Andor Solis control/analysis software by double-clicking on its icon. This will look for the camera and will not start up unless the camera is found.

If the software fails to start and immediately complains of a timeout, you may be able to solve the problem by power-cycling the camera. Unfortunately, it looks as if this requires unplugging the camera's power brick out at the telescope.

Once the program comes up, turn on the cooling (unless it's horribly humid and you're just playing around). This is in the Hardware menu, under Temperature. Minus-40 is a good operating temperature. A box at the lower left of the screen reports the temperature; it's red and turns blue when the operating temperature is reached. There's no reason not to take images when the camera is warm, but there will be substantial dark current (and hence noise).

Now open the Acquisition menu "Setup Acquisition" item. This brings up a window with lots of tabs, most of which you don't need. Important -- the tabs don't all fit at once, so you scroll left and right with little arrows at the upper right of the window.

The leftmost tab is "Setup CCD", which is obviously important. On this one:

The next tab is "Binning". For slit viewing I generally leave this as 1x1, which gives 0.24 arcsec pixels at the 2.4m. For very faint targets you might want to go to 2x2 to reduce read noise. It's easy to change on the fly. Note that the Solis software uses absolute pixel coordinates (512 square for whole frame) even if the pixels are binned.

You can also select a sub-image (measured in original pixels). If you do this you can move it around on the tiny display with the mouse. There's seldom a need for this.

The "Image orientation" tab: For the Yorke Brown Modspec/MkIII slit viewer choose:

Once you're set up, you can start looking at stuff. In the bar of icons just under the menu bar, there are little red and green circles -- these are the start/stop buttons. You want the one that says "RT" -- it starts the camera taking data continuously and reading it out. The red button stops this; you need to stop to reset the CCD parameters.

The exposure time is set by a control box that comes up when you click on the "run-time" icon, which looks like a little tv remote held diagonally. The Run time box that pops up has a slider that says "Exposure (seconds)". It starts at the fastest possible exposure, then you slide up and when you get to the top it trips over to a new range, and so on up -- when you start over, it reverts to the shortest time, which is a little awkward but not hard to get used to. You can also simply type your desired exposure in to the entry box at the bottom.

Note that you can make the picture bigger by dragging out the corners of the Solis window.

Much of the power of the Solis software comes from the speed and convenience with which you can control the display to optimize your view. These controls are as follows:

The power of the Solis software is evident when you're trying to focus the telescope on a star. Here's a procedure for this:

You get a rapidly dancing star, and the seeing is really dramatic. Note the starting telescope focus value, and focus the telescope on the dancing star. You don't have to worry about afterimages or gain like you would with the old TV.

For acquisition, you'll want to see the whole field, and set the exposure to something reasonable. Note that if you have faint targets, but also have some brighter stars in the field, it's best to use short exposures to get near the target (because the feedback is quick), and then set the exposure long to see the actual target.

Once your target is in or near the slit, you can use the drag-and-expand feature to get it dead-center, and so you can keep an eye on it without having to squint.

Fast Photometry with the Andor

In 2011 January I tried using an Andor for fast photometry - I'd discovered a system with a white dwarf eclipse, which basically made the star disappear in a couple of seconds, and reappear in a similarly short interval some 7 minutes later. This worked really well, so in 2013 January I did the first run with the Andor as a science instrument, on the 1.3m. These notes describe how to obtain and reduce such observations. More than most things, this is still a work in progress.

Basic operation Refer to the previous section for this; most of it is the same whether you're viewing a slit or doing science.

Timebase. Absolute timing had been an issue with this system, since native Windows handles this poorly, but software has been installed that syncs the clock to NTP frequently enough that this is no longer a problem.

Even so, it's wise to check that the computer's clock is indeed synched. To do so, bring up the control panel, look at date and time, and figure out the offset by comparing the Windows computer clock to something more reliable (e.g. the Linux system clocks, which have always been rigidly synched to real time using real NTP). If there is a significant offset, note it carefully; to be certain, check it every few hours during the night. The reduction software lets you correct for it later.

Header Information The Andor Solis software has no idea what the telescope and filter wheel (part of the MIS) are doing. I wrote a program called MDM13Logger to get around this (a 2.4m version doesn't exist yet but should not be difficult to write if it's needed). To use it, make a directory on mdm13ws1 (ideally in your own little directory tree), and copy the executable jar file from my directory:

mkdir myname
cd myname
mkdir logfiles
cd logfiles
cp /lhome/obs13m/thor/MDM13Logger.jar . 
To execute the program, type
java -jar MDM13Logger.jar
It should come up with a window like this:

Every time you press the Write to Log button, the program reads the telescope and MIS information and writes it to a log file, together with the information you fill into the relevant fields. You can add whatever notes you want in the box provided -- those also get written to the log. You might want to to comment on the weather, the clock error, and so on. The Help button has more detail.

The log file is easily machine-readable, and there is a program called that inserts the log file information into the headers semi-automatically. To match log entries to data files unambiguously, the best strategy is to be sure you write to the log file during the data-taking sequence. If you write the log entry before or after the sequence, fillheaders lets you match the log entry to the data more manually, but it can be a bit tedious.

Your life will be easier if you

Setting up the Camera for Science Acquisition

For longer science exposures, you'll want the camera colder than for casual slit-viewing, to minimize dark current. I ran at minus-50 C during the winter, and it had no trouble holding this temperature. In cold ambient temperatures you can probably do somewhat better than this, but when it's warm your mileage may vary. I have not experimented with this. Whatever you do, it's important for the temperature to be constant -- that is, something the camera can maintain.

Notice that all the instructions for slit-viewing (above) still apply -- for setting up observations, you can use the little "RT" button to place the camera in continuous-view mode, so you can center, adjust the telescope focus, etc. Just be aware that those real-time pictures are not recorded.

(In the instructions below, recall that the tabs in Acquistion are accessed using the left-right arrows toward the upper right.)

Setup. In Acquisition, under the Setup CCD tab,

Now turn to the Binning tab. At the 1.3m, the native Andor pixels subtend 0.27 arcsec, so you probably want to make this 4x4, which gives a 128 x 128 image with 1.1 arcsec/pixel. The advantages of such severe binning are (a) smaller data sets and (b) faster read times. Simply select 4x4 binning using the radiobuttons. (It's also possible to read a sub-array, but this is not allowed for in further reductions, and the field is already small).

Now select the Auto-save tab. In here,

You should be ready to go now. To take signal, go to the Acquisition menu and simply Take Signal. The images will be displayed as they come in, and you can play with the stretch, etc., without affecting the recorded data.

During the acquisition:

Once the operation finished, you'll have a 3-dimensional FITS file in the directory you specify. The file is time-stamped to the nearest second (only), and the time between frames is given in the header to five digits or so.

Caibration Exposures ..

For a good reduction of your data, you'll want bias, dark, and flat field exposures. Do these with exactly the same camera settings -- binning, read rate, sensor temperature, etc. -- as your science exposures. Here are some suggestions:

Retrieving and Viewing the Data

Between exposures (to be safe), run the Putty sftp (secure file transfer protocol) program on the windows machine. It has a little icon that looks like a terminal with a lightning bolt. It'll pop a little terminal with a command-line interface (this terminal updates oddly under VNC, but it works). I think it'll give you help if you type help, but the procedure is basically this:

If sftp doesn't work, a USB memory key works nicely, though that obviously requires physical access to the machine.

Viewing the data. As soon as you have any data to look at, use ds9 (in native mode, not IRAF!) to display the datacube:

	ds9 mydata.fits
It turns out ds9 has a wonderful and totally intuitive interface for data cubes. Photometry is a much more elaborate issue -- see the next section.

Data Reduction and Photometry

I have written a suite of python scripts to do the reductions. They use, pyraf, pyfits, and NumPy, and also my python-wrapped skycalc routines, called cooclasses. All of these are installed at MDM, but as of 2013 September, I don't have the reduction software running on the MDM workstations. I haven't had time to trace the incompatibilities yet.

Fully reducing the data involves these steps:

  • Getting the pointing, filter, etc. information into the data headers.
  • Subtracting the bias.
  • Subtracting the dark image, scaled by the exposure time.
  • Dividing by the appropriate flat field image.
  • Doing aperture photometry using
For quick look purposes, one can optionally dispense with the bias subtraction, dark subtraction, and flatfielding, and go right to the photometry. But once you're set up, it's so easy to include these steps that you might as well do them.

A disadvantage of the Andor camera is that one cannot do any photometry until the whole data cube is available, so quick-look reductions will be a little behind real time.

In these descriptions I use these rather standard notational conventions:

  • angle brackets around something mean "insert the specific value here", so if I say "<input image>" and you want to process a data file called "crab_30.fits", you'd put "crab_30.fits" there; and
  • square brackets like [this] surround optional arguments.

The reduction routines are as follows:

  • [-f] [-l <log data directory>] <input name>
    • The "-l < log data directory>" flag tells the software which directory contains the log files (generated by MDM13Logger). All the files in the directory get read in.
    • If the "-f" flag is specified, it assumes that the input name is the name of a file containing a list of images, one per line, and it processes all of these; if "-f" is not included, the input name is assumed to be a single file and only it is processed. is an elaborate program to match log entries to data files, and (in the end) to update the data file headers with the matched information. With a single file, you're asked whether to incude log entries from well before and well after the data file in question; the answer is usually no, but sometimes there will be a concluding comment or something that you typed after the integration was over, or a remark on clock error, or whatever, that would be good to include. This is a bit of a work in progress. In any case, when you've selected all your log entries, the header is updated, and comments from all the selected log entries are included.

    It's important to note that flatfield data should have header information updated, because the correct filter information is needed later.

  • <bias data cube> -- This runs a median average of the specified data cube and writes a two-dimensional image called biasavg.fits. Note that subsequent steps expect to find a bias image with exactly this name.
  • <dark data cube> -- This medians together the images in the specified dark data cube, subtracts biasavg.fits, and writes out a two-dimensional image called darkavg.fits. Again, subsequent steps expect the dark image to have exactly this name.
  • <flat data cube> -- This processes a flat data cube to make, e.g., flatV.fits where the part after "flat" is the filter name, taken directly from the header. You'll need to run this for each filter you take data in. The flat exposures in the data cube are individually scaled to account for the changing sky, then medianed together and normalized to near 1. Bias and dark are also subtracted.
  • <data cube>. This subtracts the biasavg, and the scaled darkavg, and divides by the appropriate flatfield based on the FILTER keyword in the header. The result is written into a file called "<image_name>_proc.fits".
That's all there is to the data processing -- once you're set up with bias, dark, and flatfields, it's just one command!

Doing photometry is slightly more elaborate. It requires the following setup files:

  • cubephot.config -- this contains only a few lines of configuration information -- here is an example:
    PIXSCALE | 1.10      # Andor 13-um pixels binned 4x4 at 1.3m f7.5
    APRADIUS | 3.0       # Photometry aperture radius in arcsec.
    Note the vertical bar separating the keyword from the value.
  • <object name>.tomeasure -- This lists XY coordinates of the stars you're measuring; note:
    • One pair per line, with space separating X and Y;
    • No line numbers (but in referring to these later, the first line is called line zero).
    • The program star must be listed on the first (zeroth) line, so it's star zero;
    • The main comp star goes on the next line (line 1, star 1);
    • As many other stars as you like go on subseqent lines.
The command to do the photometry is called
  • [options] <data cube> <object name> -- This looks up the appropriate <object>.tomeasure file, shifts the xy centers if you specify this in the options (see below), and measures the images. Optional parameters are:
    • -s <tracking star number> -- the index (zero-indexed) of the star to use to shift the first frame's coordinates (if -x and -y are specfied); also used to try to track centering drift. Defaults to star 1 (the main comparison star).
    • -x <x-value> -- the X-coordinate of the tracking star in the first frame. If specified, an X-shift is derived and applied to all the stars to be measured.
    • -y <y-value> -- the Y-coordinate of the tracking star in the first frame.
    • -c <clock fast> -- the number of seconds by which the system clock is fast compared to real time; defaults to zero.
    • -a <apradius> -- aperture radius in arcsec; use this if you want to override the default value in cubephot.config. runs daophot aperture photometry on the images using the aperture radius from cubephot.config, and produces a data file called <image name>.ts (for "timeseries"). If the header information is installed properly, the times given are barycentric Julian dates of mid-integration minus 2450000, derived using the data cube's recorded start time, the interframe interval, the clock error, and the telescope coordinates for the barycentric correction. The next column gives the magnitude of the program object minus the magnitude of the comp star. The next is the instrumental magnitude of the comp star. Subsequent columns give instrumental magnitudes for any other stars you have measured.

Some header information (including all the comments, etc.) is given at the beginning of the file, in lines starting with "#".

The timing assumes that the cycle time that Solis writes in the headers is accurate. I have run some tests on this and the timing interval is accurate enough so that 8 hours of 10-second integrations gives a drift smaller than 3 seconds (probably quite a bit smaller).

For poorly understood reasons, the 1.3m suffers from centering drift over long exposures, even when the guider is operating. As noted earlier, the software tries to compensate for the centering drift by following the tracking star (which is usually the comp star). This can go off the rails if (e.g.) a satellite trail obliterates the tracking star in one frame. I hope to make this more robust in future versions. However, one precaution is implemented: to avoid losing track during cloudy intervals, the software stops updating the centering if the tracking star fades by 1.5 mag from its first measurement.

A Quick-Look Data Viewer

Once you've reduced your data and done the photometry, you'll want to look at it. I've written a little viewing program which you invoke with [optional flags] <timeseries file name>
The default values for all the flags are set for output, so you can usually omit them.

If all goes well, it pops up a panel that looks like this:

The lower panel shows the program star's differential magnitudes, the top panel shows the instrumental (non-differential) magnitude of the comparison star, and the horizontal axis is the time, by default in units of the Julian date minus 2450000. If the data have been processed with the full header information, the plotted time is barycentric (i.e. 'heliocentric'). You can see that this was a poor night -- the comp star varied by over a magnitude due to very substantial high cloud.

If you type a ? you'll get a little menu of cursor commands. Here's a summary:

  • [left mouse button] : Click on a point to print out its coordinates, including the calendar date and time.
  • j and k, respectively set new left and right limits for both plots (the time axis for both plots is always the same).
  • t and b, respectively set new bottom and top limits for the currently active panel. The active panel has a white background, while the inactive is slightly grey.
  • p and c, respectively set the active panel to be that of the program star (bottom) or that of the comp star (top).
  • r restores the original auto-scaling of the plot.
  • q quits the program.

Here are the optional command-line flags, some of which are not implemented. In Unix-like fashion, these are indicated with minus signs. Some have values to go with them:

  • -h : print help
  • -q : print longer help
  • -d <diffcolumns> : Specify which columns of the photometry are differential magnitudes, in a colon-separated list (e.g., 1:3:4:5). The numbering is such that column 1 is the first photometry column (the very first column is the time or JD). Default is that column 1 is differential and the rest are not.
  • -c <comp column> : specify which column is the comp star. Default is column 2.
  • -p <program star col> : Specify which column is the program star. Default is column 1.
  • -z <JD zero point> : Specify the JD of the time zero point; default is 2450000. This is used to convert Julian date to real time when you pick a point with the mouse.
  • -g : Flag to indicate times are geocentric. At this point, not used for anything.
  • -m <metadata file name> : Specify a file of metadata. The mechanism for reading this exists, but at this point it's not used for anything.
  • -f : Indicates that the differential magnitudes are sign-reversed (i.e., comp minus program). This is not implemented.

In general, these options haven't been tested extensively; however, I have checked that -p <program star> will plot the differential light curve of a check star (e.g., column 3), so you can look for anything untoward.