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:

• as Modspec and Mark III slit viewers: In the summer of 2010, Yorke Brown (a consultant with ties to Dartmouth and the Sloan telescope) designed and implemented a simple slit-viewing port for the Modspec and Mark III spectrographs. Andor cameras have been dedicated to this port at both telescopes. These show very faint objects on the slit -- basically, you can see just about any object that you could get a spectrum of!
• as a primary scientific instrument: The Andors are well-suited to narrow-field, high-speed photometry. I tried the slit-viewing Andor for impromptu measurements of fast-changing objects for several seasons, and it worked so well that in 2013 January I used it as the main "science" detector at the 1.3m telescope. This manual reflects the experience from this and describes data reduction software I've put together for time series photometry.

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!

• Thinned, backside-illuminated CCD sensors, with over 60 percent QE from 4000 to 8500 A, and over 90 percent between 5000 and 7000 A.
• 512 pixel square active area; 13-micron square pixels, 6.6 millimeter square imaging area.
• Frame-transfer (i.e., data are shifted from the active region of the chip to a covered 512-square area for readout, eliminating the need for a shutter).
• Up to 2.5 MHz readout speed, resulting in 8 frames per second; something like 10 e- read noise at 2.5 MHz, down to 2.5 e- read noise at 50 kHz (which is too slow for most purposes).
• Thermoelectrically cooled (their cooling system is very capable).

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:

• If you're using the Andor as a science instrument, check the box that says "Frame Transfer". For slit viewing, leave it alone.
• Acquisition mode is "kinetic"
• Triggering is "internal" (default)
• Note the "Horizontal Pixel Shift". The chooser there lets you select "2.5 MHz at 16 bit", "1 MHz at 16 bit", or "50 kHz at 16 bit". 1 MHz seems to be a good all-round choice, but 50 kHz is useful for when you want to go as deep as possible, with some penalty in read time. In that case read a subarray.

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:

• no rotation
• Select both Flip Horizontally and Flip Vertically. The cartoon will show an "R" on its head, rotated by 180 degrees. This choice aligns the Brown slit viewer with North near the top and East near the left when the instrument rotator is at zero. The field is rotated by 18 degrees, and the field is about 122 arcsec square at the 2.4m.

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:

• Farther along the icon bar is one that has a red arrow pointing to the lower left and a blue one to the upper right -- this is the "Reset" (reset view) icon. It does two things: (1) restores the display to show the whole field being read (2) autoscales to min/max values. You'll use this a lot.
• Two icons to the right is a little thing that looks like two bold blue arrowheads, up and down. This toggles autoscaling; if it's on, the greyscale is adjusted image-by-image (which makes it look pretty crazy but can be good if you're moving onto a bright star) If it's off, the greyscale stays stable.
• There's a cursor on the image display. Clicking on the image moves the cursor to the spot you click on . X and Y cuts of the image through the cursor's location appear to the left and bottom of the image.
• Here's something really cool -- if you click on the image and hold the mouse down, you can drag out a rectangle. When you release the mouse, the rectangle pops out to fill the whole display. This lets you instantly blow up any region -- like the slit, or a star you're using for focus. The "reset" button described above (diagonal blue and red arrows) restores the whole area.
• At the top of the image is a slider bar for the greyscale. It only makes sense to use this with autoscaling off. Click-and-hold on the arrows on the left and right and you'll see how you can manipulate the greyscale (unfortunately, these move the greyscale range rather slowly). Also, if you click-and-drag the greyscale bar, it drag the interval up and down while keeping the separation of the black and white levels constant.
• If you right-click the mouse, it brings up a menu that includes "Palettes" -- you can choose various color schemes for the display. I find two of them to be useful: "Grey.pal" and "false1.pal". It defaults to grey. The false color can be helpful for seeing faint features, if you choose your levels carefully.
• The Display menu item at the top has a 'preferences' tag which you can use to set the color of the cursor to some contrasting color. Cyan works nicely on greyscale.

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:

• Slide exposure to very short (like 0.3 sec) (you can do this "on the fly" but it waits til the current exposure is done to take effect).
• Set the greyscale. This is best done by autoscaling, then turning off autoscaling (which gets you close), and then using the sliders to fine-tune. You don't want autoscaling on during focusing, because you want to see the peak level change rather than having it normalized away.
• draw a small box around the star to blow it up.

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.

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 . 

java -jar MDM13Logger.jar

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

• get in the habit of writing a log entry during each integration series.
• also, it will help later if you keep all the log files in one directory, ideally a directory called "logfiles" that is a subdirectory of where you'll be reducing the data..

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,

• Be sure that the Frame Transfer checkbox is selected
• You will almost certainly want to throttle down the horizontal pixel shift to 50 kHz. [This is based on the fairly high noise level I got in 2013 January, when I left it at 1 MHz). With 4x4 binning (see below), it should be possible to read full images in much less than 1 sec at 50 kHz, but I haven't tested this to be certain.
• Set the exposure time to the desired value (in seconds)
• Leave the number of accumulations at 1
• Set the Kinetic Series Length to the number of exposures you want; for example, for two hours of 10 second exposures, you'd enter 720.

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,

• Click to enable auto-save;
• Select file type Fits
• Give a file stem, e.g. the name of your object such as "myobject"
• Give a directory for your data. I was using C:\Users\Observer\thorimages, which I created; feel free to write in it.
• Set it up to automatically append numbers. This will make files like "myobject_1.fits", "myobject_2.fits", and so on. This can be a big help in sorting things out later. Note that each file will be a data cube -- a 3-d structure in which each plane is a single integration -- so there's no need for anything more elaborate.

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:

• Record a log entry
• If you haven't recently, watch for the timing error and make a note of it -- perhaps in a log entry.

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:

• Bias exposures Make sure the dome is reasonably dark in case of light leaks. In the Hardware menu, select the option that keeps the shutter closed permanently. Set the exposure time to be something very short, like 0.1 sec. Under the Auto-save tabe, set the image name to be something like "bias", and set up to take at least several dozen exposures. Then go ahead and expose (and keep the log).
• Dark exposures These are similar to biases, but with much longer exposures -- at least as long as your longest science exposure. A dark sequence may take a non-negligible time to execute. For dark exposures, the camera temperature must be at its set point.
• Flat exposures. These are a little more elaborate:
  • Well before sunset, point the telescope out the dome.
  • Be sure the MIS dark hatch is open.
  • Open the primary mirror cover.
  • Turn the tracking OFF.
  • Be sure the MIS find/guide mirror is OUT.
  • Select your least-sensitive filter.
  • Set Andor Hardware so shutter is permanently OPEN.
  • Be sure the camera is in your standard setup (binning, etc.)
  • Set up to acquire a series of 20 or 30 exposures, 2 sec each.
  • Set up the log entry in the MDM13Logger window.
  • Use the real-time display (green "RT" button) to monitor the counts until the sky fades to about 20,000 counts per integration. Typically, this is only a few minutes after sunset.
  • Start taking the data cube.
  • Don't forget to write the log entry during the exposures.
  • Repeat for more sensitive filters; increase exposure time if necessary.
  Normally one does flats with the telescope tracking, and moves between exposures, but with the Andor the deadtime is a couple hundredths of a second so one cannot do this. You'll see stars drifting through the exposures, but they'll median out. One good flat sequence per filter should suffice for the whole run.

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:

• lcd mydirectory will change into the local (windows) directory you're using for data (give its real name, of course; you may need to specify the whole Windows path, e.g. C:\Users\Observer\thorimages)
• open mdm13ws1 or whatever machine you're going to transfer the data to; you'll have to log on as obs13m and give the password.
• cd myremotedirectory to get into the directory on the target machine where you want to put the data; and
• put mydata.fits will transfer your file (obviously, use the real file name).
• quit (I think!) exits the program.

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

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:

• fillheaders.py [-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.

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

• makebias.py <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.
• makedark.py <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.
• makeflat.py <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.
• processcube.py <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

• cubephot.py [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.

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

viewtsphot.py [optional flags] <timeseries file name>

The default values for all the flags are set for cubets.py 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.