PDS_VERSION_ID = PDS3 RECORD_TYPE = FIXED_LENGTH OBJECT = TEXT PUBLICATION_DATE = 2002-12-15 NOTE = "Deep Space Mission System External Interface Specification for TRK-2-34 radio metric tracking data delivered to navigation and radio science. Document converted to text-only for PDS archiving by R. Simpson 2003-04-21. Editorial corrections 2003-05-02." END_OBJECT = TEXT END 820-013 Deep Space Mission System (DSMS) External Interface Specification JPL D-16765 TRK-2-34 DSMS Tracking System Data Archival Format Original Release: April 30, 2000 Revision B: December 15, 2002 Document Owner: Signature on File in DSMS Library ______________________________ ________ Jeff B. Berner Date Service System Development Engineer, Telecommunications Services Signature on File in DSMS Library ______________________________ ________ Tomas J. Martin-Mur Date Service System Development Engineer, Tracking & Navigation Services Approved by: Signature on File in DSMS Library ______________________________ ________ L.A. Cangahuala Date Service System Manager, Tracking & Navigation Services Signature on File in DSMS Library ______________________________ ________ Susan Kurtik Date Service System Manager, Telecommunications Services Signature on File in DSMS Library ______________________________ ________ Wallace Tai Date Manager, DSMS Systems Engineering and Standards Office Signature on File in DSMS Library ______________________________ ________ J. Stipanuk Date Interface Engineer and Release Authority Prepared By: Signature on File in DSMS Library ______________________________ ________ Jeff B. Berner Date Service System Development Engineer, Telecommunications Services Reviewed By: Signature on File in DSMS Library ______________________________ ________ Dana Flora-Adams Date Tracking Data Delivery Service CDE Signature not available ______________________________ ________ Charles Ruggier Date DSMS System Engineering Signature on File in DSMS Library ______________________________ ________ V.I. Altunin Date Telecommunications & Mission Services Manager (RADIOASTRON, 70m CoObsI, HALCA) Signature not available ______________________________ ________ R.D. Benson Date Telecommunications & Mission Services Manager Signature not available ______________________________ ________ P.E. Beyer Date Telecommunications & Mission Services Manager Signature not available ______________________________ ________ A.F. Chang Date Telecommunications & Mission Services Manager Signature not available ______________________________ ________ R.L. Gillette Date Telecommunications & Mission Services Manager Signature on File in DSMS Library ______________________________ ________ D.P. Holmes Date Telecommunications & Mission Services Manager Signature not available ______________________________ ________ K. Moyd Date Telecommunications & Mission Services Manager Signature not available ______________________________ ________ P.T. Poon Date Telecommunications & Mission Services Manager Signature not available ______________________________ ________ S. Waldherr Date Telecommunications & Mission Services Manager Signature not available ______________________________ ________ B.G. Yetter Date Telecommunications & Mission Services Manager Signature not available ______________________________ ________ David Reece Date DSMS Chief Operations Engineer Signature on file in DSMS Library ______________________________ ________ Michael Levesque Date Service System Development Engineer, Telecommunications Services Signature not available ______________________________ ________ Jeremy Jones Date Cassini Navigation Signature not available ______________________________ ________ Pat Esposito Date MSOP Navigation Signature not available ______________________________ ________ Jordan Ellis Date Multimission Navigation Signature not available ______________________________ ________ Steve Flanagan Date Project Element Manager (PEM), Next Generation Navigation Software Signature not available ______________________________ ________ Bobby Williams Date NEAR Navigation Signature on file in DSMS Library ______________________________ ________ Sami Asmar Date Radio Science Systems Group Signature not available ______________________________ ________ Michael Connally Date DSN Science Advisor |===========================================================================| | CHANGE LOG | |===========================================================================| | Revision|Issue Date| Pages/ | Change Summary | | | | Sections | | | | | Affected | | |=========+==========+============+=========================================| |New issue|04/30/2000| All | | |---------+----------+------------+-----------------------------------------| | A |05/31/2002| All |Updated data blocks, added/corrected text| | | | | descriptions | |---------+----------+------------+-----------------------------------------| | B |12/15/2002|Sections 1, |Corrected typos; added file header | | | |2 and 3; | description (Appendix B) | | | |Appendices | | | | |A and B | | |---------+----------+------------+-----------------------------------------| | | | | | |---------+----------+------------+-----------------------------------------| | | | | | |---------+----------+------------+-----------------------------------------| | | | | | |===========================================================================| CONTENTS Section Page 1 Introduction 1- 1 1.1 Purpose and Scope 1- 1 1.1.1 Applicability of This Release 1- 1 1.2 Revision and Control 1- 1 1.3 Relationship to Other DSMS Documents 1- 1 1.4 Applicable Documents 1- 2 1.5 Notation and Conventions 1- 2 1.5.1 Terminology 1- 2 1.5.2 Conventions 1- 4 1.6 Abbreviations 1- 5 2 Functional Overview 2- 1 2.1 General Description 2- 1 2.2 Operational Concept 2- 1 2.3 Equipment 2- 2 3 Detailed Interface Description 3- 1 3.1 Data Definition 3- 1 3.1.1 Tracking Data SFDU Label 3- 2 3.1.2 Aggregation CHDO Label 3- 3 3.1.3 Primary CHDO 3- 4 3.1.4 Secondary CHDOs 3- 5 3.1.4.1 Secondary CHDO 134 (Derived Data Types) 3- 6 3.1.4.2 Secondary CHDO 132 (Uplink Data Types) 3-10 3.1.4.3 Secondary CHDO 133 (Downlink Data Types) 3-13 3.1.4.4 Secondary CHDO 135 (Interferometric Data Types) 3-17 3.1.4.5 Secondary CHDO 136 (Filtered Data Types) 3-20 3.1.5 Tracking Data CHDOs 3-23 3.1.5.1 Uplink Data CHDOs 3-24 3.1.5.1.1 Uplink Carrier Phase CHDO (Data Type 0) 3-25 3.1.5.1.2 Uplink Sequential Ranging Phase CHDO (Data Type 2) 3-26 3.1.5.1.3 Uplink PN Ranging Phase CHDO (Data Type 4) 3-29 3.1.5.1.4 Ramp CHDO (Data Type 9) 3-32 3.1.5.2 Downlink Data CHDOs 3-34 3.1.5.2.1 Downlink Carrier Phase CHDO (Data Type 1) 3-34 3.1.5.2.2 Downlink Sequential Ranging Phase CHDO (Data Type 3) 3-39 3.1.5.2.3 Downlink PN Ranging Phase CHDO (Data Type 5) 3-44 3.1.5.3 Derived Data CHDOs 3-50 3.1.5.3.1 Doppler Count CHDO (Data Type 6) 3-50 3.1.5.3.2 Sequential Range CHDO (Data Type 7) 3-55 3.1.5.3.3 Angle CHDO (Data Type 8) 3-59 3.1.5.3.4 DRVID CHDO (Data Type 11) 3-61 3.1.5.3.5 PN Range CHDO (Data Type 14) 3-62 3.1.5.3.6 Tone Range CHDO (Data Type 15) 3-66 3.1.5.3.7 Carrier Frequency Observable CHDO (Data Type 16) 3-67 3.1.5.3.8 Total Count Phase Observable CHDO (Data Type 17) 3-69 3.1.5.4 Interferometric Data CHDOs 3-71 3.1.5.4.1 VLBI CHDO (Data Type 10) 3-71 3.1.5.5 Filtered Data CHDOs 3-72 3.1.5.5.1 Smoothed Noise CHDO (Data Type 12) 3-72 3.1.5.5.2 Allan Deviation CHDO (Data Type 13) 3-74 3.2 Dependencies 3-75 Appendix A Notes A- 1 Appendix B File Format B- 1 B.1 LVO Structure of Files B- 1 B.2 Physical Layout of Files B- 1 B.2.1 Primary SFDU Label B- 3 B.2.2 K-Header (or K-Object) B- 4 B.2.2.1 K-Header SFDU Label B- 4 B.2.3 I-Object SFDU Label B- 7 B.2.4 Binary Data Object B- 8 B.2.5 End of File (EOF) B- 8 Figure Page Figure 3-1 LVO Structure of the Tracking Data SFDU 3- 1 Figure 3-2 Physical Layout of the Tracking Data SFDU 3- 2 Figure B-1 LVO Structure of Files B- 1 Figure B-2 File Layout B- 2 Figure B-3 Sample Header of File B- 3 Table Page Table 3- 1 Tracking SFDU Label Definitions 3- 2 Table 3- 2 Aggregation CHDO Label Definitions 3- 4 Table 3- 3 Primary CHDO Definitions 3- 4 Table 3- 4 Secondary CHDO 134 Definitions 3- 6 Table 3- 5 Secondary CHDO 132 Definitions 3-10 Table 3- 6 Secondary CHDO 133 Definitions 3-13 Table 3- 7 Secondary CHDO 135 Definitions 3-17 Table 3- 8 Secondary CHDO 136 Definitions 3-20 Table 3- 9 Uplink Carrier Phase CHDO (Data Type 0) Definitions 3-25 Table 3-10 Uplink Sequential Ranging Phase CHDO (Data Type 2) Definitions 3-27 Table 3-11 Uplink PN Ranging Phase CHDO (Data Type 4) Definitions 3-29 Table 3-12 Ramp CHDO (Data Type 9) Definitions 3-33 Table 3-13 Downlink Carrier Phase CHDO (Data Type 1) Definitions 3-34 Table 3-14 Downlink Sequential Ranging Phase CHDO (Data Type 3) Definitions 3-40 Table 3-15 Downlink PN Ranging Phase CHDO (Data Type 5) Definitions 3-44 Table 3-16 Doppler Count CHDO (Data Type 6) Definitions 3-50 Table 3-17 Sequential Range CHDO (Data Type 7) Definitions 3-55 Table 3-18 Angle CHDO (Data Type 8) Definitions 3-60 Table 3-19 DRVID CHDO (Data Type 11) Definitions 3-61 Table 3-20 PN Range CHDO (Data Type 14) Definitions 3-62 Table 3-21 Tone Range CHDO (Data Type 15) Definitions 3-66 Table 3-22 Carrier Frequency Observables CHDO (Data Type 16) Definitions 3-67 Table 3-23 Total Count Phase Observable CHDO (Data Type 17) Definitions 3-69 Table 3-24 VLBI CHDO (Data Type 10) Definitions 3-71 Table 3-25 Smoothed Noise CHDO (Data Type 12) Definitions 3-72 Table 3-26 Allan Deviation CHDO (Data Type 13) Definitions 3-74 Table B- 1 Primary SFDU Label B- 3 Table B- 2 K-Header (or K-Object) SFDU Label B- 4 Table B- 3 Catalog Information (Value Field of the K-Object) B- 5 Table B- 4 I-Object SFDU Label B- 7 Section 1 Introduction 1.1 Purpose and Scope This module specifies the format and content of radio metric tracking data delivered to navigation and radio science customers from the Telecommunications Services. The method of delivery of the data is outside the scope of this document. TRK-2-34 is essentially a consolidation of the data that are currently contained in the TRK-2-15A, TRK-2-18, TRK-2-20, TRK-2-25, and TRK-2-30 products delivered to customers. 1.1.1 Applicability of This Release This module will supersede the TRK-2-15A module, as the MDAs are retired, and the TRK-2-25 module as the Radio Metric Data Conditioning (RMDC) process is retired. This release corrects typos and adds description of the file header format. Certain parameters may not be available in initial TRK-2-34 output. These parameters will be marked as invalid (using validity flags) in the data or not delivered (in the case of certain data types, such as Allan deviation and smoothed noise). 1.2 Revision and Control Revisions or changes to the information herein presented may be initiated according to the procedure specified in the Introduction to Document 820-013. 1.3 Relationship to Other DSMS Documents Currently, TRK-2-15A is generated by the Metric Data Assembly (MDA) of the DSCC Tracking Subsystem (DTK). In the Network Simplification Project (NSP) era, the MDAs will be replaced by the Uplink Tracking and Command Subsystem (UPL) and the Downlink Telemetry and Tracking Subsystem (DTT). As a result, TRK-2-15A will not be available. TRK-2-34 replaces TRK-2-25 as the archival format. TRK-2-20 and TRK-2-30 will continue to be available to the customers. 1.4 Applicable Documents [1] 820-062 DSMS Terms and Abbreviations (DSMS internal document, for reference only.) [2] 813-109, D-17818 Preparation Guidelines and Procedures for Deep Space Mission System (DSMS) Interface Specifications (DSMS internal document, for reference only.) [3] 820-013, D-16765 DSMS External Interface Specification (http://jaguar.jpl.nasa.gov) [3a] OPS-6-21A Standard Code Assignments [3b] 0171-Telecomm-NJPL SFDU Global Definitions [3c] 0180-Data_Manage DSMS DOM Electronic Access for External Users [3d] 0183-Telecomm-TDS TDS Query Protocol Specification [4] SFOC-5-SYS-*DU-NJPL NJPL SFDU Global Definitions (DSMS internal document, for reference only; to be replaced by Reference [3b].) [5] 820-013, Module DSMS External Interface Specification-DSMS Created 0172-Telecomm-CHDO CHDO Structures [6] CCSDS 620.0-B-2 CCSDS Recommendation for Space Data System Standards-Standard Formatted Data Units-Structure and Construction Rules (Issue 2, May 1992) [7] ANSI T-49-12 ANSI/IEEE STD 754-1985-IEEE Standard for Binary Floating-Point Arithmetic [8] ANSI X3.4-1986 Information Systems - Coded Character Sets - 1 Bit (R1997) American National Standard Code for Information Interchange (7-Bit ASCII) [9] ISO/IEC 646-1991 Information Technology - ISO 7-bit Coded Character Set for Information Interchange [10] 810-047 DSN Antenna and Facility Identifiers (DSMS internal document, for reference only.) 1.5 Notation and Conventions 1.5.1 Terminology Many of the terms used in this module are taken from the literature describing the Standard Formatted Data Unit (SFDU) concept (e.g., Reference [5] and Reference [6]). The SFDU concept was developed by the Consultative Committee for Space Data Systems (CCSDS) to provide a standardized and internationally recognized methodology for information interchange. Because the SFDU concept evolved over time, the meaning of some terms has evolved. The definitions provided herein are intended to clarify the use of certain terms as they apply to this module: a) The term ASCII refers to the American Standard Code for Information Interchange, a seven-bit code for representing letters, digits, and symbols which has been standardized by the American National Standards Institute (Reference [8]). This code has been incorporated into the ISO code of the same nature (Reference [9]) which includes other symbols and alphabets. Since the ISO code is an eight-bit code, the ASCII code is embedded in an eight-bit field in which the most significant bit is set to zero. In this module, ASCII always refers to the seven-bit ASCII code embedded, as described, in an eight- bit field. When applied to a multi-byte field, it implies that each byte in the field contains an ASCII code. b) The term restricted ASCII (RA) refers to the subset of ASCII consisting of the codes for the twenty-six upper-case letters ('A'-'Z') and the ten decimal digits ('0'-'9'). When applied to a multi-byte field, it implies that each byte in the field contains an RA code. c) A label-value-object (LVO) is a data structure that is comprised of a label field and a value field. The label field provides for the data structure to be self-identifying and self-delimiting. The value field contains user-defined data in any format. The LVOs themselves are made up of a sequence of bytes. In this module, LVO is used in a generic sense to refer to any data structure with these attributes. d) An LVO may be a simple LVO or a compound LVO. If the value field of the LVO contains purely user data, it is a simple LVO. If the value field of the LVO contains purely LVOs, it is a compound LVO. The value field of a compound LVO consists of a sequence of one or more LVOs, each of which can be a simple or compound LVO itself. e) A standard formatted data unit (SFDU) is an LVO that conforms to a defined set of structure and construction rules, namely the specification in Reference [5] or the specification in Reference [6]. Unfortunately, the two specifications are slightly different, leading to two different definitions of what an SFDU is. The term DSN tracking SFDU (or, more simply, tracking SFDU) refers to the SFDU defined and controlled by this module. The DSN tracking SFDU conforms to the structure and construction rules specified in Reference [5]. It does not strictly conform to the internationally recognized SFDU structure and construction rules recommended by CCSDS in Reference [6]. f) A compressed header data object (CHDO), as defined in Reference [5], is an LVO. Its design is modeled on the SFDU concept, but a CHDO is not an SFDU. The CHDO derives its name from the fact that the label field of a CHDO is considerably shorter than the label field of an SFDU (four bytes instead of twenty). The CHDO provides a means of structuring user data with less overhead than would be required if an SFDU were used. However, with respect to SFDU structure and construction rules, a CHDO (or a sequence of CHDOs) is merely user data contained in the value field of an SFDU. g) The term type attribute is used to refer to the subfield(s) of an LVO label field that affect the self-identifying property of the LVO. Within the applicable domain, the type attribute is a unique reference to a description of the format and meaning of the data contained in the value field of the LVO. h) All of the LVOs described in this module contain a length attribute in their label field. The length attribute is a subfield of the LVO label field; it contains the length, in bytes, of the value field of the LVO. When interpreted in the context of the structure and construction rules specified in Reference [5], the length attribute affects the self-delimiting property of the LVO. The use of a length attribute is not the only means by which an LVO can be self-delimiting; Reference [6], for example, provides several mechanisms that do not rely on an explicit length. i) The term data type refers to the SFDU format code. This term is used when distinguishing between different data blocks. 1.5.2 Conventions The following conventions are used in this module: a) LVOs are defined as being made up of a sequence of eight-bit bytes, so data structures in this module are illustrated as a sequence of bytes. All data structures defined in this module must be an even number of bytes in length. Given a data structure that is N bytes in length, the first byte in the structure is drawn in the most top justified position and is identified as "byte 0." The following byte is identified as "byte 1" and so on, to "byte N-1" which is drawn in the most bottom justified position. Within each byte, the most significant bit is drawn in the most left justified position and is identified as "bit 1." The next most significant bit is identified as "bit 2" and so on, to "bit 8" which is drawn in the most right justified position. Any bit in a data structure is uniquely identified by specifying the byte within which it occurs and its position within that byte (e.g., "byte 5, bit 8"). b) Data structures are divided into fields, where a field is a sequence of bits. Fields are identified by specifying the starting and ending bits of the field. For fields that cross byte boundaries, bit 8 of byte M is more significant than, and is immediately followed by, bit 1 of byte M+1. A field may be divided into subfields in a similar manner. c) Several conventions for expressing the length of a data structure, or a part of a data structure, are used in this module. The length attribute of an LVO is always given in bytes and always refers to the length of the value field of the LVO (i.e., excluding the label field). d) In the data structure descriptions in this module, many fields are defined to contain a numerical value. Several different formats for expressing numbers are used, as follows: 1) Unsigned integer. An integer number is expressed in binary, using all bits of the field as necessary. Negative quantities cannot be expressed. For an n-bit field, the range of values that can be represented is from 0 to 2n-1. The number of bytes in the unsigned integer (m) is represented by a "-m" after the format statement. 2) Integer. An integer number is expressed in binary, using two's complement notation. For an n-bit field, the range of values that can be represented is from -2n-1 to 2n-1-1. The number of bytes in the integer (m) is represented by a "-m" after the format statement. 3) Restricted ASCII. Each decimal digit of an integer number is expressed by its corresponding RA code. The field must be an integral number of bytes in length. For multi-digit fields, the first byte of the field contains the most significant digit, the second byte contains the next most significant digit, and so on. If the number of digits is less than the number of bytes in the field, leading zeroes are used to fill the field. Negative quantities cannot be expressed. In an n-byte field, the range of values that can be represented is from 0 to 10n-1. The number of bytes in the Restricted ASCII string (m) is represented by a "-m" after the format statement. 4) IEEE Single. A 32-bit, single precision, IEEE floating point- format is used to express real numbers. Single precision floating-point numbers are expressed in the ANSI/IEEE standard (Reference [7]) single precision format with a sign bit, 8-bit exponent, and 23-bit mantissa. 5) IEEE Double. A 64-bit, double precision, IEEE floating-point format is used to express real numbers. Double precision floating-point numbers are expressed in the ANSI/IEEE (Reference [7]) standard double precision format with a sign bit, 11-bit exponent, and 52-bit mantissa. e) For fields defined to contain a constant value, the constant value will be enclosed in single quotes (e.g., '2') if the information is expressed in RA, and not so enclosed (e.g., 2) if the information is expressed in binary. f) Unless explicitly stated otherwise, fields defined as "reserved" are to be set to binary zero by the originator, and are to be ignored by the recipient. g) Time tags are in UTC, as received from the Frequency and Timing Subsystem (FTS) of the DSN: * 00:00:00 is second 0.0. * 23:59:59 is second 86399.0. * Leap second is 86400.0. h) The term "UPL-DTT antenna" refers to antennas that have UPL and DTT equipment (currently 34m HEF, 34m BWG, and 70m antennas). The term "non-UPL- DTT antenna" refers to antennas that do not have this equipment (currently 26m antennas and DSS-27). 1.6 Abbreviations Abbreviations used in this document are defined with the first textual use of the term. Abbreviations and acronyms approved for use are listed in Document 820-062. Abbreviations appearing in this module are: ADID Authority and Description Identifier AMMOS Advanced Multimission Operations System ASCII American Standard Code for Information Exchange ANSI American Nation Standards Institute CHDO Compressed Header Data Object CCSDS Consultative Committee for Space Data Systems dB decibel dBm decibels above the reference level of 1 milliWatt deg degrees DOD Differential One-way Doppler DOR Differential One-way Ranging DRVID Differenced Range Versus Integrated Doppler DSCC Deep Space Communications Complex DSMS Deep Space Mission System DSN Deep Space Network DSS Deep Space Station DTK DSCC Tracking Subsystem DTT Downlink Telemetry and Tracking Subsystem EOF End of File FFT Fast Fourier Transform FOM Figure of Merit FSP Full Spectrum Processing Subsystem FTS Frequency and Timing Subsystem Hz Hertz ID Identifier IEEE Institute of Electrical and Electronics Engineers IF Intermediate Frequency JPL Jet Propulsion Laboratory K Kelvin LCP Left Hand Circular Polarization LNA Low Noise Amplifier LVO Label Value Object MDA Metric Data Assembly MFR MultiFunction Receiver MPA Metric Pointing Assembly MTA Metric Tracking Assembly N/A Not Applicable NASA National Aeronautics and Space Administration NOCC Network Operations Control Center NSP Network Simplification Project NVP NOCC VLBI Processor Subsystem PN Pseudo-Noise RA Restricted ASCII RCP Right Hand Circular Polarization RF Radio Frequency RMDC Radio Metric Data Conditioning RTLT Round-Trip Light Time RU Range Unit sec seconds SFDU Standard Formatted Data Unit SNT System Noise Temperature UPL Uplink Tracking and Command Subsystem UTC Universal Time Coordinated VLBI Very Long Baseline Interferometry W Watts Section 2 Functional Overview 2.1 General Description Radio metric data received from the DSCCs will be processed, validated, and corrected. The resulting data will be placed into the TRK-2-34 and TRK-2-18 products. Validated/corrected data are available to (a) remote customers as TRK-2-34 files, and (b) JPL AMMOS customers as files, stream-type queries, or broadcast streams. The file format is described in Appendix B. This interface does not describe the transfer mechanisms for the delivery of the data to the customers; they are described, respectively, in References [3c] and [3d]. This processing is done in the AMMOS system. It includes the software tools that are used to perform radio metric data processing, validation, correction, and visualization, and to generate the tracking data file products. The function of the processing is to process, generate, and deliver radio metric data to projects and end users to support spacecraft navigation and scientific study. Listed below are the documents and 820-013 interface modules that define specific fields in the TRK-2-34 headers: Reference [3a]: DSN spacecraft ID, AMMOS mission ID Reference [10]: station ID Reference [4]: originator ID, last modifier ID 2.2 Operational Concept Users provide spacecraft configuration data (such as transponder number, spacecraft oscillator frequency values, etc.) and light time data. The user also specifies data delivery options (such as data decimation rate). This data, along with the DSN physical data maintained in internal tables, are combined with the raw measurements from the DSN to generate the radiometric data described by this document. TRK-2-15A data will continue to be produced by DSSs until the Metric Data Assembly (MDA) has been completely retired. The existing Radio Metric Data Conditioning (RMDC) software will continue to be used until the TRK-2-15A data are no longer produced. Parameters and data types that require predicted values, such as prefit residuals and Allan deviation, will not be available if the trajectory data for generating the predicted values is not available. If this happens, the parameter status will be marked as invalid (using validity flags) and the data types will not be generated. 2.3 Equipment All equipment used in the measurement or generation of tracking data get their frequency and timing references from the Frequency and Timing Subsystem (FTS) of the DSN. The non-UPL-DTT antennas have a mixture of tracking equipment. The 26m subnet uses the Metric Pointing Assembly (MPA). DSS-27, a 34m antenna, uses the Metric Tracking Assembly (MTA). Arraying at a complex is done with the Full Spectrum Processing Subsytem (FSP). Section 3 Detailed Interface Description 3.1 Data Definition Viewed as a compound LVO, the value field of the tracking data SFDU contains two LVOs, an aggregation CHDO and a tracking data CHDO. The aggregation CHDO is a compound LVO; its value field contains two simple LVOs, a primary CHDO and a secondary CHDO. The aggregation CHDO exists solely for the purpose of allowing the primary and secondary CHDOs to be grouped together and treated as a single LVO. The value fields of the primary and secondary CHDOs contain annotation data (identification, configuration, status, and performance parameters) that pertain to the data in the tracking data SFDU. The tracking data CHDO is a simple LVO; its value field contains the actual tracking data. +---------------------------------------------+ L| Tracking Data SFDU | +-+ +---------------------------------------+| | L| Aggregation CHDO || | +-+ +---------------------------------+|| | | L| Primary CHDO ||| | | +-+ ||| | | V| ||| | V| +---------------------------------||| | | L| Secondary CHDO ||| | | +-+ ||| V| | V| ||| | +---------------------------------------|| | L| Tracking Data CHDO || | +-+ || | | || | | || | | || | V| || | | || | | || | | || +-------------------------------------------+ L = label field V = value field Figure 3-1. LVO Structure of the Tracking Data SFDU Figure 3-2 shows the physical layout of the tracking data SFDU. It is divided into the following sections: the tracking SFDU label, the aggregation CHDO label, the primary CHDO, the secondary CHDOs, and the tracking data CHDOs. There are five different types of secondary CHDOs, and 18 types of tracking data CHDOs. The following sections present the detailed definition of the tracking data SFDU. BIT +-----------------------------------------------+ |1 |2 |3 |4 |5 |6 |7 |8 |1 |2 |3 |4 |5 |6 |7 |8 | +-----------------------------------------------| BYTE 0| | +- -| ... SFDU LABEL ... ... ... +- -| 18| | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| 20| | +- AGGREGATION CHDO LABEL -| 22| | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| 24| | +- -| ... PRIMARY CHDO ... ... ... +- -| 30| | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| 32| | +- -| ... SECONDARY CHDO ... ... ... +- -| xx| | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| xx| | +- -| ... TRACKING DATA CHDO ... ... ... +- -| N-2| | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| |1 |2 |3 |4 |5 |6 |7 |8 |1 |2 |3 |4 |5 |6 |7 |8 | +-----------------------------------------------+ N Depends on Data Type Figure 3-2. Physical Layout of the Tracking Data SFDU 3.1.1 Tracking Data SFDU Label Bytes 0 through 19 of the tracking SFDU contain the SFDU label field. The format and content of the SFDU label are defined in Table 3-1. The concatenation of Bytes 0 through 3, and 8 through 11, constitutes the type attribute of the SFDU; in CCSDS parlance, this concatenated field is known as the Authority and Description Identifier (ADID). Bytes 12 to 19 constitute the length attribute. |===========================================================================| | Table 3-1. Tracking SFDU Label Definitions | |===========================================================================| | Identifier | Byte | Item Name and Description |Format|U/P| Range|Notes| | |Offset| | (1) |(2)| (3) | | |==============+======+=============================+======+===+======+=====| |control_auth_ | 0 |Control authority identifier.| RA-4 |N/A|'NJPL'| | | id| |'NJPL' indicates that the | | | | | | | |data description information | | | | | | | |for this SFDU is maintained | | | | | | | |and disseminated by NASA/JPL.| | | | | |--------------+------+-----------------------------+------+---+------+-----| |sfdu_version_ | 4 |SFDU label version ID. '2' | RA-1 |N/A| '2' | | | id| |indicates that the length | | | | | | | |attribute field in bytes 12 | | | | | | | |to 19 is formatted as a | | | | | | | |binary unsigned integer. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |sfdu_class_id | 5 |SFDU class ID. 'I' indicates | RA-1 |N/A| 'I' | | | | |that this SFDU contains data | | | | | | | |to be used by an application | | | | | | | |process. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |reserve2 | 6 |Reserved. Two bytes. | RA-2 |N/A| '00' | | |--------------+------+-----------------------------+------+---+------+-----| |data_ | 8 |Data description identifier. | RA-4 |N/A|'C123'| | |description_id| |Uniquely identifies the data | | |'C124'| | | | |description information held | | |'C125'| | | | |by the control authority | | |'C126'| | | | |identified in the 'Control | | |'C127'| | | | |authority identifier' item | | | | | | | |for this type of SFDU. | | | | | | | |C123 => Uplink types | | | | | | | |C124 => Downlink types | | | | | | | |C125 => Derived types | | | | | | | |C126 => Interferometric types| | | | | | | |C127 => Filtered types | | | | | |--------------+------+-----------------------------+------+---+------+-----| |sfdu_length | 12 |Length attribute of the | UI-8 | B | 124 | | | | |tracking data SFDU. | | | 160 | | | | |Indicates the length of the | | | 162 | | | | |data following this element. | | | 164 | | | | | DT0 => 162 | | | 178 | | | | | DT1 => 358 | | | 182 | | | | | DT2 => 194 | | | 194 | | | | | DT3 => 304 | | | 204 | | | | | DT4 => 218 | | | 218 | | | | | DT5 => 332 | | | 304 | | | | | DT6 => 320 | | | 320 | | | | | DT7 => 330 | | | 330 | | | | | DT8 => 178 | | | 332 | | | | | DT9 => 124 | | | 358 | | | | | DT10 => 204 | | |182+ | | | | | DT11 => 182 | | | 18*N| | | | | DT12 => 164 | | |194+ | | | | | DT13 => 160 | | | 22*N| | | | | DT14 => 304 | | | | | | | | DT15 => 194 | | | N<100| | | | | DT16 => 182 + 18 * num_obs | | | | | | | | DT17 => 194 + 22 * num_obs | | | | | |===========================================================================| (1) Abbreviated values in the Format column are: A-8: ASCII string, 8 bytes A-12: ASCII string, 12 bytes I-4: Integer, 4 bytes UI-1: Unsigned integer, 1 byte UI-2: Unsigned integer, 2 bytes UI-4: Unsigned integer, 4 bytes UI-8: Unsigned integer, 8 bytes RE-4: IEEE single precision (4 bytes) RE-8: IEEE double precision (8 bytes) (2) The 'U' column contains values of 'units/precision'. Abbreviated values include: B: Bytes dBH: dB-Hz K: (degrees) kelvin ms: milliseconds N&D: See Item Name and Description column for details N/A: Not applicable ns: nanoseconds Pct: Percentage/percent ps: picoseconds s: seconds S6: seconds at precision 1 microsecond U: unitless (none) W: watts Y: years (3) The 'Range' column includes possible values. ds1* 0.01 to 86400.99 ds2* 0 to 2^16 - 1 ds3* 0 to 86400999 ds4* 0.00 to 86400.9999 ds5* -31,536,000.0 to 31,536,000.0 ds6* 0.000000 to 86400.999999 ds7* 4.0 to 504,536.0 ds8* -32.3e9 to -2.0e9 ds9* 0.00 to 86400.99 N num_obs 3.1.2 Aggregation CHDO Label Bytes 20 through 23 of the tracking data SFDU contain the aggregation CHDO label field, which is defined in Table 3-2. The value field of the aggregation CHDO is composed of the primary CHDO and a secondary CHDO. The primary CHDO is described in Section 3.1.3. The secondary CHDOs, of which there are five types, are described in Section 3.1.4. |===========================================================================| | Table 3-2. Aggregation CHDO Label Definitions | |===========================================================================| | Identifier | Byte | Item Name and Description |Format|U/P| Range|Notes| | |Offset| | (1) |(2)| (3) | | |==============+======+=============================+======+===+======+=====| |chdo_type | 0 |Type attribute of the | UI-2 |N/A| 1 | | | | |aggregation CHDO. A value of| | | | | | | |1 indicates that this CHDO is| | | | | | | |an aggregation of CHDOs | | | | | |--------------+------+-----------------------------+------+---+------+-----| |chdo_length | 2 |Length attribute of the | UI-2 | B | 72 | | | | |aggregation CHDO. Indicates | | | 100 | | | | |the length of the sum of the | | | 110 | | | | |primary and secondary CHDOs. | | | 122 | | | | | CHDO 132 => 78 | | | 136 | | | | | CHDO 133 => 122 | | | | | | | | CHDO 134 => 136 | | | | | | | | CHDO 135 => 100 | | | | | | | | CHDO 136 => 110 | | | | | |===========================================================================| (1) Abbreviated values in the Format column are: A-8: ASCII string, 8 bytes A-12: ASCII string, 12 bytes I-4: Integer, 4 bytes UI-1: Unsigned integer, 1 byte UI-2: Unsigned integer, 2 bytes UI-4: Unsigned integer, 4 bytes UI-8: Unsigned integer, 8 bytes RE-4: IEEE single precision (4 bytes) RE-8: IEEE double precision (8 bytes) (2) The 'U' column contains values of 'units/precision'. Abbreviated values include: B: Bytes dBH: dB-Hz K: (degrees) kelvin ms: milliseconds N&D: See Item Name and Description column for details N/A: Not applicable ns: nanoseconds Pct: Percentage/percent ps: picoseconds s: seconds S6: seconds at precision 1 microsecond U: unitless (none) W: watts Y: years (3) The 'Range' column includes possible values. ds1* 0.01 to 86400.99 ds2* 0 to 2^16 - 1 ds3* 0 to 86400999 ds4* 0.00 to 86400.9999 ds5* -31,536,000.0 to 31,536,000.0 ds6* 0.000000 to 86400.999999 ds7* 4.0 to 504,536.0 ds8* -32.3e9 to -2.0e9 ds9* 0.00 to 86400.99 N num_obs 3.1.3 Primary CHDO Bytes 24 through 31 of the tracking SFDU contain the primary CHDO, which is defined in Table 3-3. Bytes 0 through 3 are the label field. Bytes 4 through 7 are the value field. The primary specifies the mission and the data type of the tracking data contained in the SFDU. |===========================================================================| | Table 3-3. Primary CHDO Definitions | |===========================================================================| | Identifier | Byte | Item Name and Description |Format|U/P| Range|Notes| | |Offset| | (1) |(2)| (3) | | |==============+======+=============================+======+===+======+=====| |chdo_type | 0 |Type attribute of the primary| UI-2 |N/A| 2 | | | | |CHDO. A value of 2 indicates| | | | | | | |that this CHDO is a primary | | | | | | | |CHDO. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |chdo_length | 2 |Length attribute of the | UI-2 | B | 4 | | | | |primary CHDO. Indicates the | | | | | | | |length, in bytes, of the | | | | | | | |value field (bytes after this| | | | | | | |item) of the primary CHDO. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |mjr_data_class| 4 |Major data class. A value of| UI-1 |N/A| 6 | | | | |6 indicates that the data in | | | | | | | |this SFDU is ground station | | | | | | | |monitor data. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |mnr_data_class| 5 |Minor data class. Indicates | UI-1 |N/A| 14 | | | | |data is processed tracking | | | | | | | |data. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |mission_id | 6 |Mission ID. Per Reference | UI-1 |N/A| 0- | | | | |[3a], Table 3-4. | | | 255 | | |--------------+------+-----------------------------+------+---+------+-----| |format_code | 7 |Format code. Also referred | UI-1 |N/A| 0-17 | | | | |to as the data type. | | | | | | | | 0 => Uplink Carrier Phase | | | | | | | | 1 => Downlink Carrier Phase | | | | | | | | 2 => Uplink Sequential | | | | | | | | Ranging Phase | | | | | | | | 3 => Downlink Sequential | | | | | | | | Ranging Phase | | | | | | | | 4 => Uplink PN | | | | | | | | Ranging Phase | | | | | | | | 5 => Downlink PN | | | | | | | | Ranging Phase | | | | | | | | 6 => Doppler | | | | | | | | 7 => Sequential Ranging | | | | | | | | 8 => Angles | | | | | | | | 9 => Ramps | | | | | | | |10 => VLBI | | | | | | | |11 => DRVID | | | | | | | |12 => Smoothed Noise | | | | | | | |13 => Allan Deviation | | | | | | | |14 => PN Ranging | | | | | | | |15 => Tone Ranging | | | | | | | |16 => Carrier Observable | | | | | | | |17 => Total Phase Observable | | | | | |===========================================================================| (1) Abbreviated values in the Format column are: A-8: ASCII string, 8 bytes A-12: ASCII string, 12 bytes I-4: Integer, 4 bytes UI-1: Unsigned integer, 1 byte UI-2: Unsigned integer, 2 bytes UI-4: Unsigned integer, 4 bytes UI-8: Unsigned integer, 8 bytes RE-4: IEEE single precision (4 bytes) RE-8: IEEE double precision (8 bytes) (2) The 'U' column contains values of 'units/precision'. Abbreviated values include: B: Bytes dBH: dB-Hz K: (degrees) kelvin ms: milliseconds N&D: See Item Name and Description column for details N/A: Not applicable ns: nanoseconds Pct: Percentage/percent ps: picoseconds s: seconds S6: seconds at precision 1 microsecond U: unitless (none) W: watts Y: years (3) The 'Range' column includes possible values. ds1* 0.01 to 86400.99 ds2* 0 to 2^16 - 1 ds3* 0 to 86400999 ds4* 0.00 to 86400.9999 ds5* -31,536,000.0 to 31,536,000.0 ds6* 0.000000 to 86400.999999 ds7* 4.0 to 504,536.0 ds8* -32.3e9 to -2.0e9 ds9* 0.00 to 86400.99 N num_obs 3.1.4 Secondary CHDOs There are five types of secondary CHDOs, all of which start at Byte 32 of the tracking data SFDU. The five types are organized as follows (data type is equivalent to format code): * CHDO 134: Derived data types - Doppler Count (data type 6), Sequential Range (data type 7), Angles (data type 8), DRVID (data type 11), PN Range (data type 14), Tone Range (data type 15), Carrier Frequency Observable (data type 16), and Total Count Phase Observable (data type 17). * CHDO 132: Uplink data types - Uplink Carrier Phase (data type 0), Uplink Sequential Ranging Phase (data type 2), Uplink PN Ranging Phase (data type 4), and Ramps (data type 9). * CHDO 133: Downlink data types - Downlink Carrier Phase (data type 1), Downlink Sequential Ranging Phase (data type 3), and Downlink PN Ranging Phase (data type 5). * CHDO 135: Interferometric data types - VLBI (data type 10). * CHDO 136: Filtered data types - Smoothed Noise (data type 12) and Allan Deviation (data type 13). The secondary CHDOs are defined in Tables 3-4 through 3-8. Bytes 0 through 3 are the label field. Bytes 4 through M-1 (M being the length of the secondary CHDO) comprise the value field. The secondary CHDO contains parameters that a user might want to sort or filter on. 3.1.4.1 Secondary CHDO 134 (Derived Data Types) Secondary CHDO 134 is used for the following derived data types (format codes): Doppler Count (data type 6), Sequential Range (data type 7), Angle (data type 8), DRVID (data type 11), PN Range (data type 14), Tone Range (data type 15), Carrier Frequency Observable (data type 16), and Total Count Phase Observable (data type 17). Secondary CHDO 134 is defined in Table 3-4. |===========================================================================| | Table 3-4. Secondary CHDO 134 Definitions | |===========================================================================| | Identifier | Byte | Item Name and Description |Format|U/P| Range|Notes| | |Offset| | (1) |(2)| (3) | | |==============+======+=============================+======+===+======+=====| |chdo_type | 0 |Type attribute of the | UI-2 |N/A| 134 | | | | |secondary CHDO. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |chdo_length | 2 |Length attribute of the | UI-2 |N/A| 124 | | | | |secondary CHDO. Indicates | | | | | | | |the length, in bytes, of the | | | | | | | |value field (bytes after this| | | | | | | |item) of the secondary CHDO. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |orig_id | 4 |Originator ID. Indicates | UI-1 |N/A| 0- | | | | |where this SFDU was | | | 255 | | | | |originated. Per Reference[4].| | | | | |--------------+------+-----------------------------+------+---+------+-----| |last_modifier_| 5 |Last modifier ID. Indicates | UI-1 |N/A| 0- | | | id| |where this SFDU was last | | | 255 | | | | |modified. Per Reference [4].| | | | | |--------------+------+-----------------------------+------+---+------+-----| |reserve1 | 6 |Reserved. For future | UI-1 |N/A| 0 | | | | |expansion of scft_id. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |scft_id | 7 |Spacecraft number. Per | UI-1 |N/A| 1- | | | | |Reference [3a]. | | | 255 | | |--------------+------+-----------------------------+------+---+------+-----| |rec_seq_num | 8 |Record sequence number (RSN).| UI-4 |N/A| 0 to | | | | |Begins with zero; increments | | |2^32-1| | | | |by one for each successive | | | | | | | |tracking SFDU of the same | | | | | | | |type; wraps around from | | | | | | | |2^32-1 to zero. Value is | | | | | | | |reset to zero when software | | | | | | | |is restarted. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |year | 12 |Time tag year. | UI-2 |N/A| 1958-| | | | | | | | 3000| | |--------------+------+-----------------------------+------+---+------+-----| |doy | 14 |Time tag day of year. | UI-2 |N/A| 1- | | | | | | | | 366 | | |--------------+------+-----------------------------+------+---+------+-----| |sec | 16 |Time tag seconds of day. | RE-8 | s/| ds1* | 1 | | | | | |.01| | | |--------------+------+-----------------------------+------+---+------+-----| |rct_day | 24 |Record creation time days. | UI-2 |day| ds2* | 74 | | | |Days since 1/1/1958. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |rct_msec | 26 |Record creation time | UI-4 | ms| ds3* | 74 | | | |milliseconds of day. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |stn_stream_src| 30 |Station stream source. | UI-1 |N/A| 1-3 | | | | | 1 => UPL/DTT | | | | | | | | 2 => non-UPL-DTT: TRK-2-30 | | | | | | | | 3 => non-UPL-DTT: TRK-2-20 | | | | | |--------------+------+-----------------------------+------+---+------+-----| |ul_band | 31 |Uplink frequency band. | UI-1 |N/A| 0-5 | 79 | | | | 0 => unknown or N/A | | | | | | | | 1 => S-band | | | | | | | | 2 => X-band | | | | | | | | 3 => Ka-band | | | | | | | | 4 => Ku-band | | | | | | | | 5 => L-band | | | | | |--------------+------+-----------------------------+------+---+------+-----| |ul_assembly_ | 32 |Uplink Assembly Number. | UI-1 |N/A| 0-2 | 79 | | num| |Note that this is to allow | | | | | | | |for potential future cases | | | | | | | |where there might be more | | | | | | | |than one uplink of the same | | | | | | | |band at the same antenna. | | | | | | | | 0 => Unknown/Not applicable | | | | | | | | 1 => S-/X-band uplink | | | | | | | | 2 => Ka-band uplink | | | | | |--------------+------+-----------------------------+------+---+------+-----| |transmit_num | 33 |Transmitter number. Value | UI-1 |N/A| 0-3 | 79 | | | |depends on transmitter used. | | | | | | | |A value of 0 means that the | | | | | | | |number is unknown or not | | | | | | | |applicable. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |transmit_stat | 34 |Transmit Status. | UI-1 |N/A| 0-2 | 79 | | | | 0 => not transmitting out | | | | | | | | the horn | | | | | | | | 1 => transmitting out | | | | | | | | the horn | | | | | | | | 2 => invalid or unknown | | | | | |--------------+------+-----------------------------+------+---+------+-----| |transmit_mode | 35 |Transmitter mode. | UI-1 |N/A| 0-2 | 79 | | | | 0 => low power | | | | | | | | 1 => high power | | | | | | | | 2 => invalid or unknown | | | | | |--------------+------+-----------------------------+------+---+------+-----| |cmd_modul_stat| 36 |Command modulation status. | UI-1 |N/A| 0-2 | 79 | | | | 0 => OFF | | | | | | | | 1 => ON | | | | | | | | 2 => invalid or unknown | | | | | |--------------+------+-----------------------------+------+---+------+-----| |rng_modul_stat| 37 |Ranging modulation status. | UI-1 |N/A| 0-2 | 79 | | | | 0 => OFF | | | | | | | | 1 => ON | | | | | | | | 2 => invalid or unknown | | | | | |--------------+------+-----------------------------+------+---+------+-----| |transmit_time_| 38 |Transmit time tag delay. | RE-8 | s | -1.0,| 2 | | tag_delay| |Value used to offset uplink | | / | 0.0- | 79 | | | |time tag (e.g., for Goldstone| |100| 1.0| | | | |Beam Waveguide antennas). | | ps| | | | | |A value of -1.0 indicates | | | | | | | |invalid (or not provided). | | | | | |--------------+------+-----------------------------+------+---+------+-----| |ul_zheight_ | 46 |Uplink Z-height correction. | RE-4 | s/|-99.0 | 60 | | corr| |Value of -99.0 indicates | |100|-1. to| 72 | | | |invalid. | | ps| +1. | 79 | |--------------+------+-----------------------------+------+---+------+-----| |dl_dss_id | 50 |Downlink antenna number. | UI-1 |N/A| 0-255| | | | |Per Reference [10]. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |reserve1a | 51 |Reserved. One byte. | UI-1 |N/A| 0 | | |--------------+------+-----------------------------+------+---+------+-----| |dl_chan_num | 52 |Downlink channel number. | UI-1 |N/A| 0-24 | | | | |Value of 0 implies unknown. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |prdx_mode | 53 |Predicts mode. Predicts | UI-1 |N/A| 0-4 | | | | |subset used by downlink | | | | | | | |channel. | | | | | | | | 0 => No Predicts | | | | | | | | 1 => One-way | | | | | | | | 2 => Two-way | | | | | | | | 3 => Three-way | | | | | | | | 4 => Unknown | | | | | |--------------+------+-----------------------------+------+---+------+-----| |ul_prdx_stn | 54 |Uplink station used for | UI-1 |N/A| 0-255| | | | |predicts. Valid only if | | | | | | | |prdx_mode is 2 or 3. Per | | | | | | | |Reference [10]. A value of 0 | | | | | | | |means that the number is | | | | | | | |unknown or not valid (e.g., | | | | | | | |no uplink). | | | | | |--------------+------+-----------------------------+------+---+------+-----| |ul_band_dl | 55 |Uplink frequency band | UI-1 |N/A| 0-5 | | | | |assumed by downlink. | | | | | | | |Uplink band value used by | | | | | | | |downlink for turn around | | | | | | | |computations. | | | | | | | | 0 => Unknown or not | | | | | | | | applicable | | | | | | | | 1 => S-band | | | | | | | | 2 => X-band | | | | | | | | 3 => Ka-band | | | | | | | | 4 => Ku-band | | | | | | | | 5 => L-band | | | | | |--------------+------+-----------------------------+------+---+------+-----| |array_delay | 56 |Array delay value. Time | RE-8 | s |0. to | 4 | | | |delay added to path by | | / | 1. | | | | |arraying equipment. Obtained| |100| | | | | | from arraying equipment. Any| | ps| | | | | | measurements include this | | | | | | | |delay. Valid only if Array | | | | | | | |Flag (array_flag) is | | | | | | | |non-zero. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |fts_vld_flag | 64 |Frequency and Timing (FTS) | UI-1 |N/A| 0,1 | | | | |validity. | | | | | | | |0 => Equipment is not synced | | | | | | | | with FTS | | | | | | | |1 => Equipment is synced | | | | | | | | with FTS | | | | | |--------------+------+-----------------------------+------+---+------+-----| |carr_lock_stat| 65 |Carrier lock status. | UI-1 |N/A| 0-5 | 83 | | | | 0 => Off | | | | | | | | 1 => Open (using only | | | | | | | | predicts) | | | | | | | | 2 => Acquiring, FFT Search | | | | | | | | 3 => Acquiring, Waiting for | | | | | | | | Lock Decision | | | | | | | | 4 => In Lock | | | | | | | | 5 => Out of Lock | | | | | |--------------+------+-----------------------------+------+---+------+-----| |array_flag | 66 |Array flag. | UI-1 |N/A| 0-2 | 87 | | | | 0 => Non-arrayed | | | | | | | | 1 => Arrayed with FSP #1 | | | | | | | | 2 => Arrayed with FSP #2 | | | | | |--------------+------+-----------------------------+------+---+------+-----| |lna_num | 67 |LNA Number. Value of 0 | UI-1 |N/A| 0-4 | | | | |indicates unknown. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |rcv_time_tag_ | 68 |Receive time tag delay. | RE-8 | s | -1.0,| 3 | | delay| |Value used to offset | | / | 0.0- | | | | |downlink time tag (e.g., for | |100| 1.0| | | | |Goldstone Beam Waveguide | | ps| | | | | |antennas). A value of -1.0 | | | | | | | |indicates invalid (or not | | | | | | | |provided). | | | | | |--------------+------+-----------------------------+------+---+------+-----| |dl_zheight_ | 76 |Downlink Z-height correction.| RE-4 | s/|-99.0,| 60 | | corr| |Value of -99.0 indicates | |100|-1.0- | 72 | | | |invalid. | | ps| 1.0| | |--------------+------+-----------------------------+------+---+------+-----| |vld_ul_stn | 80 |Validated uplink station. | UI-1 |N/A| 0-255| 61 | | | |Per Reference [10]. The | | | | 79 | | | |uplink station per the | | | | | | | |validation process. A value | | | | | | | |of 0 means that the antenna | | | | | | | |is unknown or not valid. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |vld_dop_mode | 81 |Validated doppler mode. | UI-1 |N/A| 0-3 | 61 | | | | 0 => Unknown or not | | | | 79 | | | | applicable | | | | | | | | 1 => One-way | | | | | | | | 2 => Two-way | | | | | | | | 3 => Three-way | | | | | |--------------+------+-----------------------------+------+---+------+-----| |vld_scft_coh | 82 |Validated spacecraft | UI-1 |N/A| 0-3 | 79 | | | | coherency. | | | | | | | | 0 => Unknown or not | | | | | | | | applicable | | | | | | | | 1 => Coherent | | | | | | | | 2 => Non-coherent | | | | | | | | 3 => Transponded, | | | | | | | | non-coherent | | | | | |--------------+------+-----------------------------+------+---+------+-----| |vld_dl_band | 83 |Validated downlink frequency | UI-1 |N/A| 0-6 | 82 | | | |band. | | | | | | | | 0 => unknown | | | | | | | | 1 => S-band | | | | | | | | 2 => X-band | | | | | | | | 3 => Ka-band | | | | | | | | 4 => Ku-band | | | | | | | | 5 => L-band | | | | | | | | 6 => S or X band | | | | | | | | (26m stations) | | | | | |--------------+------+-----------------------------+------+---+------+-----| |scft_transpd_ | 84 |Spacecraft transponder lock. | UI-1 |N/A| 0-2 | 5 | | lock| | 0 => Unknown | | | | | | | | 1 => Out-of-lock | | | | | | | | 2 => In Lock | | | | | |--------------+------+-----------------------------+------+---+------+-----| |scft_transpd_ | 85 |Spacecraft transponder | UI-1 |N/A| 0-5 | 5 | | num| |number. 0 if unknown, | | | | | | | |transponder number otherwise.| | | | | |--------------+------+-----------------------------+------+---+------+-----| |Reserve2 | 86 |Reserved. Two bytes. | UI-2 |N/A| 0 | | |--------------+------+-----------------------------+------+---+------+-----| |scft_osc_freq | 88 |Spacecraft oscillator | RE-8 |Hz/|0.0, | 6 | | | |frequency. Spacecraft one-way| |1.0|2.0E9-| | | | |frequency. 0.0 if unknown. | |mHz|32.3E9| | |--------------+------+-----------------------------+------+---+------+-----| |scft_transpd_ | 96 |Spacecraft transponder delay.| RE-8 | s/| -1.0,| 7 | | delay| |Coherent ranging delay. Value| |100| 0.0- | | | | |of -1.0 indicates invalid. | | ps| 1.0| | |--------------+------+-----------------------------+------+---+------+-----| |scft_transpd_ | 104 |Spacecraft transponder turn | UI-4 |N/A| 0 to | | | turn_num| |around ratio numerator. | | |2^32-1| | | | |A value of 0 indicates | | | | | | | |unknown. | | | | | |--------------+------+-----------------------------+------+---+------+-----| scft_transpd_ | 108 |Spacecraft transponder turn | UI-4 |N/A| 0 to | | | turn_den| |around ratio denominator. | | |2^32-1| | | | |A value of 0 indicates | | | | | | | |unknown. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |scft_twnc_stat| 112 |Spacecraft two-way | UI-1 |N/A| 0-2 | 5 | | | |non-coherent (TWNC) status. | | | | | | | | 0 => Unknown | | | | | | | | 1 => OFF | | | | | | | | 2 => ON | | | | | |--------------+------+-----------------------------+------+---+------+-----| |scft_osc_type | 113 |Spacecraft oscillator type. | UI-1 |N/A| 0-2 | 5 | | | | 0 => Unknown | | | | | | | | 1 => AUX OSC (auxiliary | | | | | | | | oscillator) | | | | | | | | 2 => USO (ultra-stable | | | | | | | | oscillator) | | | | | |--------------+------+-----------------------------+------+---+------+-----| |mod_day | 114 |Modification time days. Days| UI-2 |Day| 0 to | 73 | | | |since 1/1/1958. Last | |/1 |2^16-1| | | | |modification time. | |day| | | |--------------+------+-----------------------------+------+---+------+-----| |mod_msec | 116 |Modification time | UI-4 |ms/| ds3* | 73 | | | |milliseconds of day. | | 1 | | | | | |Last modification time. | | ms| | | |--------------+------+-----------------------------+------+---+------+-----| |cnt_time | 120 |Count time. Integration time | RE-4 | s/|0.0- | 88 | | | |of the counts. Value of 0 | |100|3600.0| | | | |indicates Not Applicable | | ms| | | |--------------+------+-----------------------------+------+---+------+-----| |Reserve4 | 124 |Reserved. Four bytes. | UI-4 |N/A| 0 | | |===========================================================================| (1) Abbreviated values in the Format column are: A-8: ASCII string, 8 bytes A-12: ASCII string, 12 bytes I-4: Integer, 4 bytes UI-1: Unsigned integer, 1 byte UI-2: Unsigned integer, 2 bytes UI-4: Unsigned integer, 4 bytes UI-8: Unsigned integer, 8 bytes RE-4: IEEE single precision (4 bytes) RE-8: IEEE double precision (8 bytes) (2) The 'U' column contains values of 'units/precision'. Abbreviated values include: B: Bytes dBH: dB-Hz K: (degrees) kelvin ms: milliseconds N&D: See Item Name and Description column for details N/A: Not applicable ns: nanoseconds Pct: Percentage/percent ps: picoseconds s: seconds S6: seconds at precision 1 microsecond U: unitless (none) W: watts Y: years (3) The 'Range' column includes possible values. ds1* 0.01 to 86400.99 ds2* 0 to 2^16 - 1 ds3* 0 to 86400999 ds4* 0.00 to 86400.9999 ds5* -31,536,000.0 to 31,536,000.0 ds6* 0.000000 to 86400.999999 ds7* 4.0 to 504,536.0 ds8* -32.3e9 to -2.0e9 ds9* 0.00 to 86400.99 N num_obs 3.1.4.2 Secondary CHDO 132 (Uplink Data Types) Secondary CHDO 132 is used for the following Uplink data types (format codes): Uplink Carrier Phase (data type 0), Uplink Sequential Ranging Phase (data type 2), Uplink PN Ranging Phase (data type 4), and Ramps (data type 9). Secondary CHDO 132 is defined in Table 3-5. |===========================================================================| | Table 3-5. Secondary CHDO 132 Definitions | |===========================================================================| | Identifier | Byte | Item Name and Description |Format|U/P| Range|Notes| | |Offset| | (1) |(2)| (3) | | |==============+======+=============================+======+===+======+=====| |chdo_type | 0 |Type attribute of the | UI-2 |N/A| 132 | | | | |secondary CHDO. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |chdo_length | 2 |Length attribute of the | UI-2 | B | 66 | | | | |secondary CHDO. Indicates | | | | | | | |the length, in bytes, of the | | | | | | | |value field (bytes after this| | | | | | | |item) of the secondary CHDO. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |orig_id | 4 |Originator ID. Indicates | UI-1 |N/A| 0- | | | | |where this SFDU was | | | 255 | | | | |originated. Per Reference[4].| | | | | |--------------+------+-----------------------------+------+---+------+-----| |last_modifier | 5 |Last modifier ID. Indicates | UI-1 |N/A| 0- | | | _id | |where this SFDU was last | | | 255 | | | | |modified. Per Reference [4].| | | | | |--------------+------+-----------------------------+------+---+------+-----| |reserve1 | 6 |Reserved. For future | UI-1 |N/A| 0 | | | | |expansion of scft_id. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |scft_id | 7 |Spacecraft number. Per | UI-1 |N/A| 1- | | | | |Reference [3a]. | | | 255 | | |--------------+------+-----------------------------+------+---+------+-----| |upl_rec_seq_ | 8 |Uplink record sequence number| UI-4 |N/A| 0 to | | | num| |(UPL RSN). This is the record| | |2^32-1| | | | |sequence number reported by | | | | | | | |the uplink subsystem (UPL) | | | | | | | |equipment. | | | | | |--------------+------+-----------------------------+------+---+------+-----| |rec_seq_num | 12 |Record sequence number (RSN).| UI-4 |N/A| 0 to | | | | |Begins with zero; increments | | |2^32-1| | | | |by one for each successive | | | | | | | |uplink tracking SFDU of the | | | | | | | |same data type; wraps around | | | | | | | |from 2^32-1 to zero. Value is| | | | | | | |reset to zero when the data | | | | | | | |processing system software is| | | | | | | |restarted. | | | | |