5. Guider System Software

5.0 Overview

The guider system, or simply "guider", consists of the guide camera(s) and related electronics, optics and software. For purposes of discussion here, we will refer to the optical system bringing light onto the detector as the "TV optics"; the detector and related controlling electronics as the "guide camera"; and the software and electronics for maintaining a position on the sky as the "autoguider". The guide camera, autoguider and the image display and analysis tools will be referred to collectively as the "TV image subsystem". The TV optics include elements such as filters, diaphragms, reticles and focusing mechanisms, and is considered part of an individual science instrument such as DEIMOS. The guider has two major and alternating functions:

target acquisition; and
holding a fixed position on the sky ("guiding").

In addition, the guider may be used for some other valuable, but sometimes non-traditional, functions including:

evaluating and monitoring observing conditions (eg, seeing, transparency);
approximate aperture photometry;
calibrating the telescope pointing and focus; and
at Keck, checking alignment of optics (eg, stacking of segments).

The guider software consists of these elements:

Control of the guide camera(s);
Image display for the guide camera images;
Analysis of the guide camera images for acquisition (image display);
Command of offsets to the DCS for acquisition;
Analysis of subimages for guiding (autoguider);
Command of corrective offsets to the DCS (autoguider);
Monitoring of sky and telescope conditions (eg, seeing; focus); and
Miscellaneous analysis functions (eg stellar photometry) available via the image display.

Control of the TV optics, as part of a science instrument, falls under "instrument control", although the status of such elements must be available to the guider.

5.1 The DEIMOS Guider Requirements

Guider requirements for slit-mask guiding are more stringent than for normal direct-imaging or long-slit observing, as both the x-y coordinates and the PA need to be held to a high precision. Furthermore, the mask alignment process requires more small-scale offsets (in three axes) than is typically required for single-slit spectroscopic observations. For these reasons, it is important that the observer have access to an easy-to-use control of the guider. As part of that access, we recommend a guider console that should be located between the Observing Assistant and the DEIMOS observer(s). More on the rational for a separate console can be found in the physical layout document.

For the remainder of this section, we will assume a single guide camera, of size 1K x 1K (or 1K x 0.5K) pixels and field-of-view about 3 arcmin across. The camera will look at either an offset field or at the slitmask (semi-polished) or polished long-slit jaws, as chosen by the observer. We assume a reticle (parfocal with the slitmask) in the offset position, and reference marks on the slitmask itself; these enable us to focus the camera independently of telescope focus, and to track guide-camera flexure. We will not discuss the design or requirements of the CCD control (guide camera), nor the TV optics. We have the capability of using this guider as a science instrument, and we choose to use it to provide supplemental information for the actual science observations. Such functions include monitoring ...

FWHM (that is, seeing and focus changes);
counts (that is, transparency);
sky background (very useful for beginning and end of nights);
autoguider offsets (history of motions as diagnostic).

In addition, we propose the option of coadding guider images during each science integration -- this summed image would be attached to the science image file, and would provide a record of the average conditions during the exposure. In a slit-viewing mode, this would also provide an unambiguous location of the slit across targets of interest. Depending on the ability to calibrate the guider throughput (particularly off the slitmask), it may be possible to derive photometric calibrations from these images as well.

Finally, since the DEIMOS TV optics will have some sort of reference objects at the telescope focal surface (ie a reticle in offset mode; the slitmask itself in slit-viewing mode), we will be able to focus the guide camera on the telescope focal plane. Once the camera is focused, we have a means of focusing the telescope. The guider should take advantage of this opportunity for real-time focus of the telescope -- perhaps even during a pause in a long science integration.

5.2 Figures

Fig. 5.5-1 -- Possible Guider Image Display

Fig. 5.5-2 -- Possible Guider GUI

5.3 Nomenclature

(See terms in Overview above, and in image display.)

5.4 Software Functional Requirements

Guide Camera Control

The user needs control of the following from the guider control interface:

binning
gain
read-out modes (eg subrasters)
integration time / frame rates

Guider Image Display

The image display is used for several purposes, including target identification and positioning, selecting a guide star and analyzing conditions. While it may or may not be the same image display tool that is used for display of full DEIMOS images, it is essential that the implementation of simple display functions (zoom, pan, LUT control) and analysis functions (eg distance measurement, coordinate system overlay, stellar image analysis) appear identical between the two. The necessary features for the guider image display are:

Full image display;
Zoom and pan capability;
Lookup table (LUT) and colormap control;
A "ruler" to measure distances (in various coordinate systems) on the display;
Compass rose;
Optional coordinate grid overlay on image;
Optional overlay of catalog object positions on image;
Stellar image statistics, including FWHM and approximate magnitudes;

It is necessary to have a default mode in which the transfer function limits (ie min, max) should be automatically selected to provide useful threshold and contrast for most applications. However, the user should also have the ability to adjust these limits (or reset them to default values).

We also propose that the most recent guide camera images (say up to 8) can be stored in memory so that they may be optionally averaged as a "leaky" memory. The images automatically displayed would then be either the most recent (ie "real-time") image or an average of the last two (or four or eight).

Object Acquisition (Offset Control)

Graphic "handpaddle" control (buttons for left, right, up, down, CW, CCW; two speeds);
Offsets by numerical value (eg, 8 arcsec N, 2.3 arcsec E). If the autoguider is on, the target position will be graphically indicated by a circle or box so that it is trivial to visually confirm that the expected offset was achieved;
Point-and-drag offsets: by this, we mean that a reference object is selected by mouse click, then the position where the observer wants it is selected, with the offset vector "dragged" out by the mouse. The target position is marked as above;
Identification of target object, for which the needed offsets to a nominal position -- eg, the center of the longslit -- are automatically derived (target position marked as above);
Optional centroiding during selection of reference object (target ID, "point-and-drag" above);
"Memory" of selected locations (eg, for alternating between two positions on the sky);
Graphical position marker(s) -- eg circles or crosses to mark positions of interest to the user.
Simple Autoguider ON/OFF switch;
All offsets for which the autoguider must be interrupted will perform the interruption/resume automatically. This primarily concerns rotations, in which case the autoguider should stop guiding, then calculate the offset introduced by the rotation about the instrument center, reposition, and then resume autoguiding.

In order to keep offset methods consistent and to have a reasonable degree of user verification, we propose the following rules for offsets:

Clicking on (and/or holding) the "handpaddle" buttons will instantly apply offsets;
Offsets entered by numerical value (or point-and-drag -- see below) will require an "apply" button to be pushed;
For this latter kind of offset, there will be three associated switches: "clear," "apply," and "reverse" (undo);
Offsets by numerical value will be specified by the three fields delta-Dec, delta-RA and delta-PA. However, a blank field implies an offset of 0. Thus, clicking on "clear" will clear all fields and values may be entered into one, two or three fields as desired.
The mask alignment program and the "point-and-drag" option will both talk to the "Numerical Offset" fields. Completion of the mask alignment analysis will place the calculated offsets into the numerical offset window, and the "apply" command must be sent to actually perform the offset.

Software for Autoguiding

Center on reference marks and update the guider coordinate system (see note 1);
Center on object image(s) (see notes 2,3), calculate and send correct incremental offsets to the DCS.
Keep a running record of applied offsets, and take corrective action if needed -- eg, adjust the "track rates" for repeated similar offsets, or slightly adjust integration times or offset rates if position is oscillating;
Perform stellar image analysis and keep a running record of count rates, FWHM and sky level; sound warning alarm (voice message) if count rates drop too low (ie, clouds; guide star lost).

Note 1: The reference marks at the focal plane serve as fiducial points, so that flexure in the guide camera system can be automatically removed.

Note 2: There are several possible algorithms for centering, and at least two should be available to the user. One is the "balanced quadrants" method, where the object is divided into four and the amount of light in each quadrant is equalized. This method is particularly useful if autoguiding on spilled light from an object in a slit. A cross-correlation algorithm would also be quite useful if the guide object is extended rather than stellar.

Note 3: Ideally, we should be able to autoguide on several objects simultaneously, by either coadding the images or averaging the offsets. This would enable the use of several fainter stars if a suitably bright guide star is not available. Also, it provides a "pass-off" mechanism for guide stars which move outside the camera field-of-view during offsets.

Miscellaneous Software

We will need software (as yet unspecified) to support image analysis for focusing of both the TV camera and the telescope.

We will need software to coadd the guider images during science integrations, and to communicate with the DEIMOS exposure control and data stream.

5.5 Possible designs

Two sketches of a possible image display and guider GUI are available.

5.6 Existing Software and Tools

The ESO image display widget may be modifiable for this component.

5.7 Other Resources Required

The hardware for the guide camera is yet TBD.

5.8 Dependencies on Other Components

(none)

5.9 Outstanding Issues

There is some concern that the read-out and display rates can be sufficiently fast.

5.10 Miscellaneous

The efficient functioning of the guider system requires "territorial" access (both in software and physically) by both the Observing Assistant and the Observer. Such access is discussed in "Control Room Layout."

5.11 Object Acquistion: Slitmask Alignment

This is described under "Slitmask Alignment."

Andrew C. Phillips / Lick Observatory

Last modified: 12 mar 96

phillips@ucolick.org