Tape Recorder 1 Completes Dump And Resumes Recoroing

Fig. 8-14. Sequence of Events During Transmission of Data From RAE-2 to Ground Tracking Stations

The data are dumped at a rate five times the recording speed, so that data from the 225-minute orbit can be dumped* in 45 minutes. For this reason, the process is used even when continual station coverage is available. The data segment recorded between times /, and t2 in Fig. 8-14 is matched with the real-time segment received and time tagged during the same interval. The rest of the recorded data are then time tagged based on the tags during this segment and the values of the spacecraft clock contained in the remainder of the recorded data. During the next data transmission, the roles of the tape recorders are reversed.

Data Processing at the Receiving Station. Data are processed by the IPD at Goddard Space Flight Center at two major levels. The first consists of analysis by the input processing computer, which includes calculations to account for short-term (one-orbit) drift in the spacecraft clock; this step produces attached times of sufficient accuracy for rough calculations. The second step consists of analysis by the intermediate processing computer. During this process, calculations include the change in orbital position during the tracking station pass and the corresponding time-dependent spacecraft-to-Earth transmission delay, the tracking station-dependent hardware delay time (measured onsite at each tracking station), and the long-term (several orbits) drift in the spacecraft clock. Data are then processed by IPD software to validate the attached times. Incorrectly time-tagged data are detected and corrected. Time-tagged data from the IPD are hence more reliable than near-real-time data from the Multisatellite Operations Control Center. Time-ordered data are then transmitted to an attitude determination computer via a communication data link or on magnetic tape.

Summary. Attitude-related data are typically time tagged to the nearest millisecond, though timing capabilities exist at NASA STDN tracking and receiving stations to 25 ¿isec, with accuracies of ± 2.5 ¡isec expected by 1980. Time tags in definitive data are processed by the IPD, and incorrect tags are detected and corrected. Near-real-time data are time tagged by tracking stations or by the receiving station, and tagging errors are detected and corrected by attitude determination software.

8.4 Telemetry Processors

After telemetry data have been received by an attitude determination computer as described in Section 8.1, they are analyzed by an attitude determination software system. The first subsystem involved in this procedure is the telemetry processor. The functions performed by telemetry processors vary from mission to mission, but routinely include the following:

1. Reading telemetry records from a permanent telemetry disk data set or from a telemetry tape

7. Generating segments of valid data, usually corresponding to minor or major frames of telemetry data

Functions I, 2, and 7 are always performed; functions 3, 4, 5, and 6 are generally available, and are performed as necessary.

Reading and Unpacking Telemetry Data. Data are read and processed from the telemetry data set one record at a time; a record may contain several major frames of data (GEOS-3 records contain 3 major frames), or may contain only a portion of a major frame (SAS-3 records contain 8 minor frames; 32 records are required to complete a major frame of 256 minor frames). After each telemetry record is read into core, selected data items are extracted and placed into arrays for subsequent processing. Sometimes this process requires extracting and examining the values of one or more data items before the extraction of other items; e.g., a flag in the data may indicate which of several formats the data appear in, and the location of other data items within the record depends on this format. The method of reading data records depends on whether they are being read singly in near real time or in large groups in the batch processing mode. In the near-real-time mode, data from the spacecraft are received by a tracking station as they are being measured and transmitted. The data are relayed immediately to a receiving station and made available to attitude determination software on an as-available basis.

This means that the amount of data available for processing increases steadily with lime, record by record. The telemetry processor must read each new record, process the data, pass control to the attitude determination system for further processing, and upon receiving control again, read the next record and repeat the process. If the read attempt occurs before the next record is received, an end-of-file condition occurs. When this happens, the telemetry processor generally waits a brief interval (typically ~1 sec), and attempts to read the record again. If the record is still not available, the process is repeated until a specified limit on the number of attempts is reached, at which time the telemetry processor displays an appropriate message and waits for operator action.

In the batch processing mode, all data to be processed have already been received. The telemetry processor can read all the data desired, process them, and pass all results to the attitude determination system at one time. The amount of data to be read and processed is limited only by the size of the arrays to be filled or by the amount of telemetry data available.

Preread or quicklook features are often provided in the batch processing mode to read and unpack selected data items for display purposes for rapid determination of whether the data are suitable for processing. Several types of data items are examined in such a mode; an example of a quicklook display for SAS-3 is shown in Fig. 8-15, in which data are normalized to arbitrary units for common display. In

Fig. 8-15. Sample Quicklook Display for SAS-3

the figure, a bad GMT attached time occurred at record number 300 and an out-of-sequence minor frame number occurred at approximately record number 660. A spurious event apparently happened at these times, because the OCC attached quality flag is also bad for these two records. The telemetry format changed at approximately record 425. Record dropout occurred at approximately record 160.

Converting Telemetry Data. Data items telemetered to the ground or attached by ground software frequently require conversion to engineering units prior to processing by attitude determination software. For example, the time attached to the data samples frequently consists of milliseconds of year, or day of year and milliseconds of day, both of which are typically converted to seconds since 0 hour UT Sept. 1, 1957.* (See Section 1.4.) A second type of conversion is required when the bits representing the magnitude of a data item are inverted when the number is negative. This is frequently the case, for example, with magnetometer or other analog data. In this case, the first bit in the data represents its polarity, and is often assigned a value (0 for negative and 1 for positive) opposite to the sign convention on standard computers. The sign bit must be extracted and examined; if it implies a negative number, the remaining bits must be inverted and a negative sign inserted which the processing computer will recognize (see Section 8.2).

A third example of conversion is the application of a linear multiplicative scale factor, or an additive constant, to telemetered values. In this case the converted value, y, is related to the telemetered value, x, by y = ax+ b (8-5)

where the constants a and b are based on measurements performed prior to launch.

If the relation between the telemetered value and the converted value is nonlinear, some form of table lookup may be required. Examples of this type of conversion include infrared scanner pitch angle data, solar panel position data, and damper angle data for SAS-3 and Sun angle data for the SMS/GOES series.+ One common nonlinear relation is the conversion of a Gray code (see Section 6.1) to engineering units. Telemetry processors convert from Gray to binary code, and telemetry data simulators convert from binary to Gray code; algorithms for both processes are presented below.

To convert from Gray to binaiy code:

1. Invert the left-most bit or retain it as is, depending on the sensor.

2. Invert the next bit to the right if the left-most bit is now a 1.

3. Treat the remaining bits in a similar left-to-right pairwise manner, inverting each new bit if the preceding bit is now a 1.

To convert from binary to Gray code:

1. Perform a logical shift to the right on the binary bit string (i.e., delete the right-most bit, move each of the remaining bits one place to the right, and insert a 0 as the new left-most bit: 11101011 becomes 01110101).

2. Perform an exclusive or of the resulting bit string with the original binary

* These conversions are performed by subroutines TCON40 and TCON20. See Section 203.2. f See Section 22.1 for a discussion of linear and nonlinear calibration.

number. The result of the exclusive or operation is the Gray-coded representation of the original binary number.

These conversions are illustrated in Fig. 8-16 (see also Section 6.1).

Values obtained from the above conversions may require further conversion before they are suitable for processing by attitude determination software. For example, data obtained from Sun or magnetometer sensors may need to be transformed by a suitable Euler transformation from sensor coordinates to spacecraft body coordinates. (See, for example, Section 7.1.) As another example, Sun sensor data after being converted from Gray to binary code can result in a bit gray-to-binary conversion binarv-tdoaav conversion gray coded value leave left-most bit unaltered first bit 15 i . invert next bit second bit is i . invert next bit third bit is 1 . invert next bit fourth bit is 0 do not invert next bit fifth bit is 1 : invert next bit sixth bit ISO do not invert next bit seventh bit is 1 . invert next bit the result is 11101011 binary.or 23s,0