File perf-interface.spe, version 1.6, released 97/11/07 at 11:53:45. 971107 LRD RevD, extensive re-write, primarily for clarifications. 951121 LRD Change "WE" to give rel humidity rather than dew point. 951006 LRD Revised based on comments received. 950525 LRD Revised based on comments received. Added satellite-dependent formats for VSOP. 950217 LRD Original issue, draft for review. NATIONAL RADIO ASTRONOMY OBSERVATORY Green Bank, West Virginia SPECIFICATION: A34300N008D DATE: 7 November 1997 TITLE: Spacecraft/Station Performance Log Interface PREPARED BY: L. D'Addario APPROVED BY___________________ 1.0 GENERAL This specification describes an output file from the Green Bank Earth Station, and possibly from other OVLBI earth stations. It is created after the end of a satellite tracking pass by processing the real-time log file created during the pass. It is intended for use by other mission elements to determine how well the spacecraft and earth station performed. This interface is defined so as to provide a mechanism for reporting important information that is not available via the interfaces previously defined. The latter include the Data Processing Log, the Correlator Input Log, and the Header Data File. All of these, as well as the Performance Log defined here, are log-type files, in the sense that each records a time-ordered sequence of events. Some of the information specified for the Performance Log is redundant, in that equivalent data is included in the other interfaces; including that information here is optional, but may be convenient. The general concepts of log file generation are given in NRAO Specification A34300N006A, and the transfer of all interface files between mission elements is covered by Specification A34300N001. 2.0 FILE FORMAT The file contains only standard ASCII characters (7 bits), with each record terminated by . If any record contains the '#' character, then that character and everything following it in the same record is a comment for humans; comments should be ignored by machines. Records beginning with the '#' character and empty records (consisting of only) should also be ignored. Except for comments, each record consists of a sequence of FIELDS delimited by any number of or characters. Each field is either a decimal number in "g-format" (with optional decimal point and optional exponent subfield) or a character string enclosed in double-quote (") characters. The length of each field is variable, being whatever is required to represent the value with adequate precision. Each record contains the following fields: 2.1 DATE: Day of year, where January 1 is day 1. 2.2 TIME: UTC as six digits in the form HHMMSS. 2.3 STATION: Code for station generating this record, following conventions established elsewhere (5 character quoted string). 2.4 RECORD TYPE: Code specifying the meaning of the remainder of this record (2 character quoted string). The codes for various record types are given in section 3. 2.5 DATA: One or more fields specific to the record type, as given in section 3. Records should be in chronological order, according to their DATE and TIME fields. Some or all of the data fields may be omitted, indicating that the corresponding information is not available, but allowing the remaining information in the record to be recorded. A record may be terminated at any point to indicate omission of all remaining fields; to omit a field while including later fields, the omitted field must be replaced by an empty pair of double quotes (""), even if the field is normally numeric. Whenever a data field is a dimensioned quantity, the *unprefixed* rationalized MKS system of units will be used. (For example, frequencies are always in Hz, not MHz nor GHz; and distances, if needed, would be in m, not km.) 3.0 LOGICAL CONTENT The present specification defines several specific record types, as summarized in Table 1. The meaning of each record type's data is discussed in the following subsections. However, a given file need not contain all of these record types, but instead may contain any subset of them. Additional record types may be defined in the future. The most important record types are considered to be Acquisition, Timing Link, Wideband Data, and Anomalies; there contain information that is not reported via any other interface, so it is recommended that all stations include at least these record types in their performance logs. ======================================================================== Table 1: Summary of Record Types NAME TYPE DATA FIELDS CODE Acquisition "AC" Downlink flux "DF" Timing link "TL" Anomalies "AN" "" Satellite state "SS" ... [see 2.5] Wideband data "WD" <# invalid> Header quality "HQ" ... [see 3.7] Weather "WE" Uplink transmit "UL" New Tape "NT" Manual control "MC" "" Operator notes "OP" "" ========================================================================= 3.1 Acquisition records: When stable downlink signals are first acquired during a pass, or re-acquired after a dropout, the ground time, tape time, and assumed downlink delay at the clock setting epoch are reported. This record should be included for each logical clock setting event, regardless of whether it is created in real time or by post-pass software. Here is a one-character identifier, "R" for Radioastron, "V" for VSOP, "S" for SURFSAT. All time intervals are in seconds, and times of day are in seconds past midnight. 3.2 Downlink flux records: The earth station's best estimate of the received flux density on each active downlink, in W/m^2, is reported periodically after signal acquisition. The frequency is the *nominal* link frequency. The reporting interval is at the discretion of the earth station. The value is given as a flux density to allow comparison between stations with different antenna gains. If the antenna gain or receiver gain is not accurately known, the best available estimate should be used. If the received power is completely unknown, at least one of these records should be included at the beginning of the pass, with the field omitted, so as to specify the nominal downlink frequency. 3.3 Timing link records: This record gives a measure of the performance of the two-way time transfer process over a short interval of time. The record's date and time refer to the beginning of the interval. For all valid residual delay measurements within the interval, the least-squares fit of a straight line to the measured time series is computed; the residual delay at the start of the interval (seconds), the slope of the delay (dimensionless), and the rms deviation of the fit (seconds) are reported. For simplicity, the fit interval is fixed at 5.0 seconds. The residual delay is normally taken to be zero at each clock setting event, so the value reported here is relative to the last clock setting event. The slope contains no such assumption, so it provides a measure of the deviation of the range rate for the its predicted value at the given time; usually this can be taken as a measure of the accuracy of the predicted orbit. The rms deviation of the fit is intended to provide a measure of the noisiness of the measurement. The 5.0 sec interval is chosen to be long enough to include sufficient data for this to be statistically significant (assuming 10 measurements per second), while being short enough that the underlying residual maintains nearly constant slope over the interval. It is recognized that the latter might not always be true, especially if the predicted orbit accuracy is poor (but well within requirements). In that case, the computed rms will represent the deviation of the true residual from a straight line as well as the measurement noise. When such a situation is recognized by the earth station, it is recommended (but not required) that the "rms" field be omitted from the record. Timing Link records should be included periodically during a tracking pass. An interval of 5 minutes is recommended. 3.4 Anomaly records: Anomalous conditions detected by the earth station are reported here, regardless of whether they originate in the station or in the satellite. A record is included whenever the error level of a detectable anomaly *changes*. is a small integer with the following meaning: 0 - No error. 1 - Warning. This means that the condition is not likely to cause loss of station output data. 2 - Error. This means that the condition is significant enough that some or all of the station output data is likely to be bad, including either the signal recorded on the wideband tape or the two-way delay residuals or both. 3 - Severe. Some or all output data is certainly bad, and normal operation cannot continue. 4 - Emergency. The condition is so severe that the station has entered its automatic shutdown mode; operation has been discontinued. (Examples include power failure and very high wind.) Optionally, earth stations may choose not to report warning level anomalies by treating them as having level=0. is a short ASCII string, but it can optionally include a code that will allow users to obtain a more detailed explanation from a dictionary. This is a generalization of the "FLAG" record in the data processing log, allowing more complete reporting than that file permits. The anomaly types are intentionally not specified here, so as to allow each station to report the anomalies most appropriate to its design. 3.5 Satellite state records: Selected satellite payload status bits are reported after initial signal acquisition and whenever they change, regardless of whether they indicate an anomaly. The details are satellite dependent, and are given in Appendices A and B for VSOP and RadioAstron, respectively. 3.6 Wideband data records: This record provides statistics about the quality of the wideband astronomical data that is normally recorded on tape. One such record should be included near the end of each tracking pass, summarizing performance for the whole pass. Additional records may be included periodically during the pass, summarizing the performance up to that time. Each data field is the value of a counter that was set to zero after initial signal acquisition. 3.6.1 is the total number of downlink frames processed (and written to tape if recording was in progress), whether valid or not. 3.6.2 is the number of processed frames in which a valid sync word was not detected. 3.6.3 is the number of processed frames in which sync was detected at the wrong time, forcing re-synchronization. 3.6.4 is the number of frames marked invalid for any reason (and replaced by pseudo-random noise on tape). 3.7 Header Quality records: A set of error counters is maintained when processing the downlink header data. These are different for VSOP and Radioastron; details are given in Appendices A and B. The counters are set to zero after initial acquisition. Their totals are reported in a single record at the end of the pass, and optionally during the pass, similar to the wideband data statistics of 3.6. 3.8 Weather records: Ambient temperature, humidity, and pressure at the earth station antenna are reported periodically during a tracking pass. The suggested reporting interval is 10 minutes. 3.9 Uplink transmit records: One of these records should be included whenever the uplink transmitter is turned on or off. The transmitter is assumed to be off at the beginning of the file. Additional records should be included if there is a significant change in the transmitter power setting during a pass. The power is given as EIRP (equivalent isotropic radiated power) so that its value is well defined for all stations, regardless of the station's antenna gain and other parameters. If the station parameters needed to computer EIRP are not accurately known, the best available estimates should be used. 3.10 New tape records: One of these records should be included whenever tape recording is started for the first time in a tracking pass, or whenever the recording switches to a new tape. The only data field is the tape serial number. 3.11 Manual control records: One of these records indicates that some equipment in the station that is normally controlled automatically has now been temporarily placed under manual control by an operator; or that the equipment has been returned to automatic control after a period of manual control. The mode change and the equipment involved should be given in the string. 3.12 Operator notes: Messages entered by the operator, consisting of whatever text the operator typed. The date and time of the record are those when the entry was made. 4.0 EXAMPLE The following lines represent a short segment of a file conforming to this specification. 212 152008 "GBANK" "AC" "R" 55206.73102352 55207 5.731e-2 212 152500 "GBANK" "DF" 15.1e9 2.51e-13 212 152500 "GBANK" "DF" 8.47e9 3.14e-14 212 152500 "GBANK" "WE" 27.0 0.35 91730 These records indicate that on day 212 (July 31) at 15:20:08, acquisition of Radioastron occurred, causing the tape clock to be set to 55207 sec UTC (15:20:07) at station time 55206.73102352 sec. About 5 min later, the estimated received flux was 0.251 pW/m^2 on the 15.1 GHz link, and .0314 pW/m^2 on the 8.47 GHz link; the temperature at Green Bank was 27.0 C, relative humidity was 0.35 (35%), and pressure was 917.30 mb (91730 Pa). APPENDIX A: SATELLITE DEPENDENT DATA, VSOP A.1 The satellite state, record type "SS", consists of a list of the values of selected bytes of header data, reported just after initial acquisition and again whenever any of the values changes. A total of 10 bytes of data will be reported, each as an unsigned integer between 0 and 255, in the following order, where x:y represents ID=x, word=y in the downlink header format described in [1]. 0:8 - uplink received power (also 4:8, 8:8, 12:8) 3:8 - link status (also 7:8, 11:8, 15:8); 12:6, 12:7 - various on/off bits and IF switch positions; 13:6 - noise diode status; 13:7 - SSF status; 14:6, 14:7 - synthesizer A status; 15:6, 15:7 - synthesizer B status. A.2 The header quality statistics, record type "HQ", consists of the contents of 8 counters whose cumulative values are reported as unsigned integers in the following order. The respective counters are initialized to zero and incremented when: A.2.1 A header is discarded because its frame was out of sync; A.2.2 A header is discarded because its repeat count (W4) was invalid; A.2.3 A block is discarded because its ID bytes (W5) were inconsistent; A.2.4 An information byte is discarded because there was not enough agreement among the 25 frames in which it was repeated; A.2.5 A short block (<25 frames) is received; A.2.6 A long block (>25 frames) is received; A.2.7 A short group (<16 IDs) is received; A.2.8 A long group (>16 IDs) is received. Here a "block" is a set of consecutive frames with the same ID byte (normally 25 frames), and a "group" is a set of frames beginning with a block in which the ID decreases from that of the previous block (normally 16 blocks, covering all IDs). It should be noted that occasional short groups and long groups are normal, but all other counts represent errors. Further details of the processing needed to determine these values are given in [2]. APPENDIX B: SATELLITE DEPENDENT DATA, RADIOASTRON (To be added in a later revision of this specification.) REFERENCES [1] ISAS, "Muses-B Ku-band telemetry format." Document VSOP-5130, revision 4, dated June 30, 1993. [2] L. D'Addario, "VSOP Header Processing Design Document." NRAO internal document, last revised 94/12/02. Available via anonymous ftp from ftp.gb.nrao.edu:ovlbi/doc/vsopHeaderProc.doc.