Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.adass.org/adass/proceedings/adass96/hydep.html
Дата изменения: Tue Jun 23 21:15:54 1998
Дата индексирования: Tue Oct 2 01:27:33 2012
Кодировка:

Поисковые слова: comet tail
The Observatory Monitoring System: Analysis of Spacecraft Jitter

Next: Refining the Guide Star Catalog: Plate Evaluations
Previous: The ESO VLT CCD Detectors Software
Up: Instrument-Specific Software
Table of Contents - Index - PS reprint - PDF reprint


Astronomical Data Analysis Software and Systems VI
ASP Conference Series, Vol. 125, 1997
Editors: Gareth Hunt and H. E. Payne

The Observatory Monitoring System: Analysis of Spacecraft Jitter

Peter Hyde, Richard Perrine(CSC), and Kenneth Steuerman
Space Telescope Science Institute, Baltimore, Maryland

 

Abstract:

The Observatory Monitoring System (OMS) is part of the Hubble Space Telescope (HST) ground system at the Space Telescope Science Institute. OMS receives as inputs a file of commands for the HST and files of engineering telemetry data generated by the HST in response to those commands. This paper will discuss how, from its inputs, OMS software provides spacecraft jitter files during observations commanded in the input. Analysis of these jitter files helps astronomers assess the quality of science data obtained during the observations.

         

1. General Overview

The main purpose of the Observatory Monitoring System(OMS) is to produce files describing the ``jitter'' of the Hubble Space Telescope as a function of time, so that an astronomer using the telescope will know how much variation there is in the telescope pointing during a science observation. The telescope has its own rectangular coordinate system with three mutually-perpendicular axes-V1, V2, and V3-where V1 coincides with the main axis of the telescope. Since the jitter is the variation in the pointing of the V1 axis, its components can be along the V2 and V3 axes.

The OMS program will compute these components from two inputs. The first is an Event File, which indicates the times of events relating to the telescope's activity. The Event File is generated by parsing a schedule of planned events, which is provided every week to the Operations staff at the Space Telescope Science Institute. The second is a sequence of engineering telemetry files of data sent back by the telescope in response to events commanded (as indicated in the Event File). OMS reads telemetry from the data files and determines what telemetry goes with each observation indicated in the Event File.

The jitter is computed from telemetry data over the time range of the science observations, as indicated in the Event File. For each such observation, OMS produces a jitter table showing the computed jitter as a function of time and a jitter image showing the spread of the jitter during the observation. These will show the astronomer how stable the pointing of the telescope was during a given observation. OMS is run shortly after the science data processing is completed, so that the science data can be evaluated along with the jitter files. The jitter files are often referred to as ``observation logs.''

OMS can handle several observations in parallel. The present OMS provides for ten instruments, counting each of the three NICMOS detectors as a separate instrument. The only restriction is that OMS may not process two observations at once for the same instrument.

2. Inputs

The main inputs to the OMS program are the Event File and the engineering telemetry files. The Event File provides times for events such as guide-star acquisition, slew, beginning and end of observations, beginning and end of ``night,'' etc. An engineering telemetry file may be in any of several formats, and the format determines the rate of telemetry update and the set of possible telemetry items which may be read from that file. For each such file, the format and start/end times are read from the telemetry file header. Each engineering telemetry file is divided into minor frames, where a minor frame represents a set of telemetry items tagged with the same time.

3. Processing

Some of the telemetry in an engineering telemetry file may be bad, so OMS has a preprocessor which checks the items read from the telemetry and creates an error file to tell the OMS main program which telemetry items should be dropped. Every minor frame must have a valid time. As the data are read from telemetry, the telemetry times are coordinated with the times of the events read in from the Event File, marking beginnings and ends of observations, guide-star acquisitions, etc. At the beginning of each telemetry file, the start time is checked to see whether there is a significant time gap between that time and the last time in the previous engineering telemetry file. If there is, then special processing is done to account for any observations that should have occurred in the time gap, so that no planned observations will be unaccounted for. In addition, there is an array to accumulate the gap time for each observation.

Each minor frame in the telemetry file is processed, unless it is to be dropped (i.e., marked as ``bad''). Each telemetry parameter in the minor frames that are not dropped is checked to see whether its value is within range and suitable for use. Some parameters are used to determine guiding status, some to calculate position, some to calculate velocity, etc. As each good parameter is received, the appropriate routines are called in order to calculate or update appropriate items. These include routines handling guide-star acquisition and calculation of the jitter components.

When the guiding status is Fine Lock or Coarse Track, the jitter quantities are calculated and written out to the high-resolution and low-resolution jitter tables of all observations in progress. The high-resolution table has a record of the jitter quantities for every telemetry time during the observation. The low-resolution file has a record only once every three seconds, and some of the values in the record will be averages over the previous three-second interval. At the end of each observation a routine is called to update these files and create the jitter image file.

The jitter image file will be archived for the user. For any observation less than six seconds in length (a ``short'' observation) the high-resolution jitter table is archived as the jitter table file. For any observation at least six seconds long, the low-resolution jitter table is archived as the jitter table file.

Sometimes there will be minor frames with a valid time but no valid telemetry for computing the v2 and v3 jitter components. Sometimes we have not yet had guide-star acquisition, or a slew or recentering is in progress. In such cases, an item in the jitter table records may not have a valid value and will have ``INDEF'' entered as its value.

4. Outputs

For each science observation, OMS produces and archives a jitter table file and a corresponding jitter image file. OMS has recently been updated to satisfy the FITS standard, so that both the table files and the image files are being written in FITS format. The jitter image file produced by the OMS analysis program has a primary header followed by an image extension header followed by the image. All of the keywords and values in the .JIH files produced by the old OMS program are either in the primary header or in the image extension header.

For an ``internal'' observation, or for one which has no valid telemetry data, the image in the jitter image file will be empty. For an ``external'' observation (as with a normal target) where there is some telemetry, the image is a 64×64 image. In either case, the jitter image file will have complete primary and image extension headers. The jitter image is essentially a histogram of V2 and V3 jitter components. The ``brightness'' of the image at point (V2, V3) represents how often the telescope jitter value was (V2, V3). The jitter image may be used for PSF analyses or for image deconvolution. The image may be displayed in IRAF with SAOimage, if the IRAF has the FITS kernel. The image header file for each observation contains valuable summary data for that observation.

The jitter table files are in STSDAS binary table format, so that one may use the IRAF commands TREAD or TPRINT to read or copy them. OMS now produces these files in FITS format, so one needs a FITS-kernel version of IRAF to read them.

The jitter table files and jitter image files are archived via the DADS system at the Space Telescope Science Institute. Files no longer considered proprietary may be retrieved by any user. The Institute is creating a new WWW page to facilitate retrieval of these archived files. Meanwhile, these files may be retrieved via Starview. If you want to retrieve the OMS archived files for a science observation [obs-name], you will get the jitter table file and the the jitter image file for [obs-name]. Note that [obs-name] is an eight-character observation name associated with the science data.

The items listed in Table 1 are written to each record of the jitter table file. Some values may be three-second averages. Items marked * have no defined value for short observations. For short observations, items marked ** are current values, not averages.

Acknowledgments:

We acknowledge the work of Xuyong Liu (Space Telescope Science Institute) and Bruce Toth (formerly of Space Telescope Science Institute) for developing the algorithms and the original version of the OMS software.


© Copyright 1997 Astronomical Society of the Pacific, 390 Ashton Avenue, San Francisco, California 94112, USA

Next: Refining the Guide Star Catalog: Plate Evaluations
Previous: The ESO VLT CCD Detectors Software
Up: Instrument-Specific Software
Table of Contents - Index - PS reprint - PDF reprint


payne@stsci.edu