User's Guide to the Gemini Twin-Arrays Infrared Camera

Table of Contents

Quick Reference
What is Gemini?
Summary Table
Quick start - for the expert
Not so quick start - set-up
Graphical User Interface
More About Gemini
Signal-to-Noise Estimates
Sampling Modes
Writing Scripts
Observing Recipes
Computer Setup
Testing the Arrays
Instrument Maintenance and Trouble-Shooting

Mt. Hamilton Homepage

More About Gemini

In the fall of 1989, the Departments of Astronomy and Physics at UCLA established a new infrared astronomy program and research laboratory with the goals of developing array-based instrumentation to be used at the University of California Observatories, including Lick Observatory and the W. M. Keck Observatory.

Infrared arrays have revolutionized IR astronomy, but the array detectors are still relatively small and investigations which demand even moderately large fields of view on the sky must be done by constructing a mosaic, which is a slow process. Worst still, each mosaic must be repeated at other wavelengths to proved useful astrophysical constraints. Such circumstances led us to the inescapable conclusion that a multi-channel infrared camera system, although much more complex and expensive, would be the beast solution.

For reasons given below, we have designed a two-channel camera and have elected to maintain the full flexibility of normal IR cameras by placing filter wheels in each beam to allow the used of narrow band filters, grisms and polarizers. The heart of the Gemini camera is a pair of hybrid infrared array detectors. Our current design incorporates the SBRC 256x256 InSb array in the long wavelength (fast) channel and the Rockwell International 256x256 HgCdTe (NICMOS 3) array in the short wavelength (slow) channel.

To better understand the consequences of simultaneous observations at two wavelengths, especially in a regime in which the "background" flux entering the instrument is a very steep function of wavelength, we used a model to predict the background signal in each pixel and then calculated the signal-to-noise (S/N) ratio in each band as a function of integration time for typical infrared sources (treated as blackbodies of a given temperature). Assuming that observations are always made in a background-limited mode, we derive the integration time which gives the same S/N ratio in any two different bandpasses, such as J and K, and then form the ratio of these integration times as a function of the characteristic or effective temperature of the source. Results of this calculation show that simultaneous observations J, H, and K are only strictly compatible for effective temperatures around 2000 K, but the ratio remains within a factor of 10 of unity in either direction over quite a wide range. On the other hand, there is very poor compatibility with the L and M bands. The dependency on other factors was also examined including reddening and redshift. In most circumstances, the longest wavelength observation required the most integration time except for very cool or heavily obscured objects, suggesting that either the J, H and K measurements are "nested" within the L measurement time, or that the J and H integrations are nested within the K integration.

Block diagram and layout

A simplified block diagram showing the major components of the system is given in Layout 1. The system is in two parts: the camera and electronics at the telescope, and the instrument computer and display system in a remote control room. The telescope end includes all necessary electronics to operate the arrays, convert the analog outputs to digital data and co-add images. A motor control unit and a temperature control system are all packaged alongside the camera itself, with the entire assembly held in a frame which supports the instrument on the telescope and during handling. Observers interact with the camera system at the keyboard of a 486-based PC located in a remote control room. Images from one or both channels can be manipulated and displayed on a second screen. The two channels may be referenced as either "fast/slow" when discussing electronics, or as "long/short" when discussing the wavelength ranges.

Layout 1: A block diagram of the UCLA 2-channel infrared camera system (Gemini)

To control the camera and collect data from the arrays, we have designed and constructed a front end system based on the Inmos transputer. Use of this microprocessor for similar applications in astronomy has been described elsewhere. The transputer is a microprocessor with on-chip RAM and four high-speed serial links which allow it to be easily networked for use in parallel applications. In addition, the transputer is capable of running multiple parallel processes, and can be programmed in its own high-level language, Occam, which has many constructs to facilitate development of parallel applications.

One transputer (the "root" processor) is situated on a PC-bus card in our host computer where it receives commands from the PC, passes them over the serial links to the three front end subsystems: the long-wavelength (fast) channel, the short wavelength (slow) channel, and the stepper motor controller.

Each of the two channels consists of a clock generator transputer and a number of data acquisition transputers. The clock generator is responsible for producing the waveforms required to drive the array and triggering the A/D converters at the appropriate points in the clock sequence. The acquisition transputers collect the data from the A/D converters and perform operations such as co-adding of successive frames and correlated sampling.

The stepper motor control transputer accepts commands from the root transputer and feeds the required pulses to stepper motor driver chips to move the various mechanisms in and around the camera.

Operation of each of the control and acquisition sections is completely independent. An observation on one channel can be started or completed at any time regardless of what the other channel is doing. In the event there is significant crosstalk between the two arrays inside the dewar, the software can prevent the two detectors from being read out simultaneously.

Optics and Mechanics

The optical design is described in detail elsewhere. Briefly, the main constraint is to match typical pixel sizes of 30 um to the f/15 images scale of the W. M. Keck telescope (1.375 arcsec/mm) to yield 0.25 arcsec per pixel and 64 x 64 arcsec field size. Our design employs transmission optics to provide the following features.

  1. An image of the telescope primary mirror is formed inside the cryostat to provide a location for a cold stop with a diameter of 16 mm.
  2. The focus of the telescope falls about 160 mm inside the cryostat to ensure that focal plane apertures, including slits and occulting spots are cold.
  3. A collimated beam is formed to feed the 45 degree dichroic beam-splitter and allow both narrow and broad band filters of different optical thicknesses to be placed in the beam using a filter wheel; two dichroics provide the option to select a split at either 1.9 or 2.9 um.
  4. Telecentric re-imaging optics give a uniform plate scale in each beam and an achromatic focus on the detector with spot sizes well within the constraints of current pixel sizes.
  5. The multiplets used in the collimator and imagers are low index fluorides with each optical channel anti-reflection-coated for the waveband of interest to give good throughput.
  6. A polarimeter module with a rotatable waveplate is located immediately in front of the large entrance window, and a second aperture wheel carries polarizing components.
The approach adopted was to build the instrument from the "inside-out" by customizing the vacuum chamber around the optical design rather than folding the design to fit a given cryostat. Essentially, the basic concept is that of an optical bench or Optical Base Plate, large enough to accommodate the optical layout, with each identifiable unit, such as Detector Assembly, Filter Wheel, Aperture Wheel, Dichroic Slide, Collimator lens and Camera lens, being treated as a "module" with a discrete location on the plate. To minimize mechanical flexure, the Optical Base Plate is an exceptionally flat, 1 inch thick slab of 6061-T6 aluminum which is 28 inches long by 15.5 inches wide. A weight relief pattern consisting of a rectangular grid of 1 inch diameter x 0.625 inch depth bores on 1.5 inch centers was applied to the underside of the plate with negligible effect on the structural integrity. The unloaded weight of the Base Plate is 15 kg and with all modules installed the total weight becomes 27 kg.

The optical plate is mounted directly to one wall (top plate) of the vacuum enclosure and is surrounded by a light-tight radiation shield. To thermally isolate the optical bench from heat conduction from the outer wall of the chamber, a mounting arrangement is used which consists of four G-10 fiberglass rods attached to four corresponding "A" frame trusses of aluminum located at the center of the four sides of the plate. This structure is rigid yet allows motion in the required direction due to thermal contraction of the base plate.

All vacuum fittings, electrical connections (vacuum feedthroughs for detectors, motors and status lines) and cooling systems (CCR head, LN2 ports) are located on the same top surface plate that supports the internal optical bench. The entire optical assembly, sealed with a single o-ring by the top plate, fits within a large chamber with a single opening at one end for the entrance window. The vacuum enclosure is constructed of 1/2 inch thick 6061-T6 aluminum plate welded into a box-shape with dimensions of 33.0 x 20.5 x 13.25 inches. Except for the window, the five remaining sides of the chamber are a single unit, with no openings, which can be lowered away when the tip plate is supported by the handling rig therefore providing easy access to all components of the instrument, both interior and exterior.

Low temperature operation of the camera system is achieved by a combination of a closed-cycle refrigerator and a 3.5 liter LN2 can. The CCR head is specified to give 25 W at 77 K from the first stage and 7 W at 20 K from the second stage. Although this is adequate under equilibrium conditions, it is insufficient to achieve the initial cool down of the entire mass; and therefore, the liquid nitrogen reservoir is essential. The first stage of the CCR is coupled to the optical base plate by a ring of flexible copper braids, and the second stage has two copper rods which extend from it to the back of each Detector Module where they terminate in an "isolation" stage constructed of G-10 fiberglass: one of these rods can be eliminated if the short wavelength channel employs a NICMOS 3 detector operating at 77 K. Each detector module is identical. The detector is mounted in a modified zero insertion force (ZIF) socket, which itself is part of a small printed circuit board, such that the back of the detector is cooled by contact with a cold block. The cold block is part of a hollowed-out aluminum chamber which contains the circuit board and has electrical connectors for bias, clock lines, and four outputs; a heater resistor and a temperature diode are embedded in the cold block. This complete unit is isolated from the optical base plate on pillars of G-10. In other words, the 2nd stage cools the detector and its small housing to the same temperature, and that temperature is controlled by the (A/L) ratio of the G-10 components and the servo-loop with the heater resistor. With the cold shield at 77 K, the heat input to the detector assembly is about 110 mW (conduction and radiation), and the thermal contact to the 2nd stage of the CCR provides a heat flow of 325 mW.


The Gemini control software consists of a large number of discrete processes running on separate processors, but can be divided first into two broad categories: the low-level programs running on the various transputers of the front end system, and the high-level control program running on the host PC. The most important design goal was complete modularity of the two channels of the front end. There is no interdependence (but a lot of similarity) between the software running on the transputers for each channel. The high-level software on the PC must satisfy the usual requirements of being easy and efficient to use, while coordinating control of the separate channels. An overriding design goal for the transputer systems was sufficient processing speed to be able to generate clock signals and acquire digitized data at the required pixel rates. All but one of the transputers in our system run single processes, the exception being the motor control transputer which has multiple interleaved processes controlling separate motors.

The transputers are controlled from the PC program via a simple message-passing protocol. The message protocol is based on that used by the Inmos program, Iserver, which is supplied as part of the transputer development system. Messages consist of a single command byte followed by an optional parameter. Before the system takes data, a number of such messages are passed to tell the transputers the parameters (e.g. sampling mode, integration time) for the observation, followed by a GO command. Messages destined for each channel have unique command codes, simplifying the operation of the root transputer program, which merely examines each message to determine where it should be sent. Data packets coming back to the PC have a byte denoting their source, a block size and a block of data words.

At instruction from the PC to a data taking channel first reaches the clock generator transputer and, depending on its contents, may then be passed on to the ADC board transputers. For instance, the A/D transputers need to know how many frames of data they are to co-add, but not the integration time. When a GO message is sent, it is passed to all the transputers in the channel, then echoed back to the clock generator board to tell it that the ADC board transputers are ready to start taking data. This kind of coordination must be set up carefully so that there is never a case of deadlock where two transputers each wait endlessly for a message from the other.

Once one of the channels has all the needed parameters for an observation, the observation can be repeated with those same parameters with a single GO command. Only parameters which change need to be resent.

All transputer processes are written in Occam, the high-level parallel-processing language designed especially for the transputer. Occam is ideal for real-time applications because it maps easily into transputer machine language, producing very efficient code, and because it contains constructs to facilitate communication between different processes running on the same of different transputers. The transputers are connected in a simple topology with each wavelength channel a simple daisy-chain. The root transputer process is responsible for communication between the PC and the other transputers. Commands are sent to it from the PC, and interpreted and routed to the appropriate transputer; messages from other transputers are relayed back to the PC. At the end of a frame, the data packets from each data acquisition transputer arrive here in turn. The pixels are rearranged into complete 256x256 frames, the arrangement depending on the array type in the sending channel. Completed frames of data are then transferred to the PC.

The motor control programs are responsible for the operation of the camera's many stepper motors. Information about each motor's current position is stored by these processes, which decode high-level commands (such as "move filter wheel to filter position 3") into the necessary number of motor pulses. The step pulses are then sent via memory-mapped output ports on the transputer to the driver electronics. The software includes ramp-up/ramp-down sequences for smooth start and stop of the mechanisms.

The clock generator boards (one for each channel) are responsible for controlling the sequence of events during an integration, and producing the waveforms needed to reset or read out the array. Integration timing is performed here using the transputer's internal clock (accurate to 1 millisecond in normal mode or 1 microsecond in a special high-priority mode). Waveforms for various sampling modes are generated by the program and output directly or through the FIFO clock buffer. The waveform-generation routines have been written to be very high-level and easy to modify to change waveforms or add new ones. The program supports any sampling rate up to the limit of the data acquisition boards. Finally, at the end of a series of co-added integrations, this process relays data from the data acquisition boards back to the root transputer.

To perform an observation, the processes on the ADC board transputers first initialize the on-board hardware, then send back and echo of the GO command, indicating to the clock generator transputer they are ready to begin data-taking. Once this is done, the sequence of events is controlled solely by the arrival of data, under the control of the "convert" pulses arriving from the clock generator board. Each process monitors the status of the FIFO data buffer and reads pixels from this buffer whenever a block of 256 data values becomes available. On the fast channel, the two transputers fed from each ADC operate in turn taking alternate blocks of data. All co-adding of frames, subtraction of pedestal level s in correlated-double-sampling, or similar arithmetic operations are performed here. The software also supports multiple-readout schemes, and the considerable processor power available will make it possible to explore even more sophisticated readout modes. At the end of an integration sequence, each transputer will contain in its memory a co-added portion of the entire frame, which is sent back to the root transputer for re-assembly.

The current host computer is a 486-based PC, programmed in C using the Watcom compiler (Waterloo, Ontario). The Watcom compiler is a 32-bit compiler and includes a DOS extender, so we can use the full memory space of the PC. The PC program is responsible for the user interface, image display, image analysis, and communicating with the root transputer. An important feature of the program is that the observer may use any of th data display or analysis functions while integrations take place in the front-end system. When an integration is complete, operation pauses for a second or two, while the FITS data file is written to disk, then resumes. This is achieved by subverting the normal PC timer interrupt to poll the PC-transputer link, for incoming messages or data, several times a second.

In addition to a simple command-line interface, the program will have a graphical user interface designed for easy operation by inexperienced observers, using the HiScreen Pro software package (Softway Inc, San Francisco, CA). The most important control functions will be accessible with a single mouse click, or (for inexperienced users) a single keystroke; less-frequently used functions will be accessed through pull-down menus. The command-line interface is also used as the basis of a third command mode, a script interpreter, which allows standard, repetitive observing tasks to be stored as script files and executed repeatedly. This script language allows access to all camera functions, telescope control functions at sites that permit our software to move the telescope, and simple loops and iterations.

A dual-SVGA board manufactured by Industrial Computer Source allows the PC to support two independent video monitors. One carries the user interface and all text output, while the other is used for display of the images from the two channels side-by-side. The images gathered from the two channels can also be superimposed in a red-blue pseudocolor mode.

The program supports quick-look image analysis, including automated background subtraction and flat-fielding. Simple aperture photometry is also included. The program will also estimate signal-to-noise ratios and limiting magnitudes to allow observers to plan integrations.

Frames are stored in FITS format on the PC hard disk, with archival storage orginially being on read/write optical disks. Now data are ftp'ed to gouda for archival storage on a RAID. In addition, the PC runs network software to allow us to plug in to observatory computer networks, making data accessible to observatory workstations running IRAF and for network file transfer of data back to UCLA.

Last modified: Mon Nov 10 12:04:46 PST 2008 by Elinor Gates