820-013 Deep Space Network External Interface Specification JPL D-16765 0172-Telecomm-CHDO DSN Created CHDO Structures Revision E: July 30, 2010 Document Owner: Harvy Soldan System Engineer for Telemetry, Tracking and Command Concurred by: Jeff Berner Development and Operations Chief Engineer Approved by: T. Pham Chief DSN System Engineer Approved by: J. Stipanuk Interface Engineer and Release Authority Prepared By: E. Wilson D Telemetry Engineer, Telecommunication Services Reviewed By: Mike Levesque DDOSO Chief Software Engineer Ana Guerrero Manager, DDOSO Telemetry, Tracking, Command, End-to-End Data Office Stephen Rogstad Radio Science Receiver Software (RSR) CDE R.D. Benson Mission Interface Manager John Louie TD SSE S. Kurtik Mission Interface Manager B. Raofi Mission Interface Manager Katherine Levister Monitor Interface Assembly Software (MIA) CDE & GCF Interface (GIF) CDE & Telemetry Interface Assembly (TIA) CDE Patricia Santos Simulation (SIM) CDE Sheila Garrett Telemetry Delivery Subsystem (TDS) CDE Richard Machuzak System Engineer for Observational Data Joe Diep Workstation Environment (WSE) CDE Raphael Solomon Telemetry Interface Subsystem (TIS) CDE E. Barkley System Engineer for Service Planning and Operations Carol Glazer TTC Engineering, Validation and Deployment PEM Michael Gan Data Accountability Subsystem (DAS) CDE Dana Flora-Adams Tracking Data Delivery Subsystem (TDDS) CDE Tracy Clark System (SYS) SW CDE M. Wilkerson PDSE F. Weisner PDSE K. Kipfstuhl PDSE J. Makihara PDSE D. Baca Test Engineer A. Ko MGSS S/W Architect C. Lush Cassini MSSO Subsystem and Test Engineer K. Rockwell MGSS SE Change Log Rev. Check if Minor Rev. Issue Date Affected Sections Change Summary New issue 08/18/2004 All Initial Release 0-1 x 3.8 CR 100278 -Better definition of anomalyrecords, not a change but an explanation. A 05/15/2005 3.10.3 Added 255 as modifier number in last_modifier field, and 121 for DTT (CR 100397 -to beimplemented when DTT creates SFDUs for DAS usage), added major type 22 to table 3-2 A-1 x 09/30/2005 3.10.3 Add 122 as "last_modifier" for Radio Metric Conditioning Team A-2 x 3.10.3 CR 100785 add 123 as last modifier for Radio Science Systems Groups. Section 1.6.2 updated to discuss bit/byte numbering in various documents and sub-modules A-3 x 05/31/2007 1.6.1 2-1, A-1 Added (1.6.1) paragraph explaining DSN, AMMOS, DTT and TTD nomenclature change.Added TTD and DTT to acronym list (A-1),updated incorrect figure reference (in section2.1). Changed references to DSMS, DSN and AMMOS to be correct as they are in 2007 B 12/27/2007 3.10.2 CR 101293 -Added new values for orig_source and curr_source fields C 12/10/2008 3.10.8 CR 101716 changed definition of lock_countfor out of sync SFDUs. CR 101725 added124=FDM to originator and last_modifier list. Added minor type of 3 (PDUs) to major type 7.Added information about use of anomaly_flags,bit "format" when turbo code rate changes. D 01/30/2009 3.10.2 CR 101826 added 24 (DCD) to orig_source list E 7/30/2010 3.10.5 3.10.7 3.10.8 3.11 decode_method values updated - CR102007LRN explanation updated, no significantchange - no CR.Lock Count changed - CR 102064Channels defined as legacy capability, no substantive change. MODCOMP floating point format removed,reference to obsolete doc is made. Section 1 Introduction 1.1 Purpose This interface module defines and controls the format and contents of most CHDO (Compressed Header Data Object) structured SFDU (Standard Formatted Data Unit) records created within the DSN (Deep Space Network). These SFDUs, as specified by this module, are self-identifying, self-delimiting data structures used to encapsulate data acquired (telemetry via radio frqquency or hardline) or produced by the DSN for delivery to a mission. An SFDU may also be referred to in this document as a "record". Note that some CHDOs are defined in other documents in DSN. The on-line site for this document contains links to CHDOs defined elsewhere. The scope of this module is limited to the format and contents of the CHDO structures. The enveloping SFDU is defined and controlled by reference document [9]. This module is to be used in conjunction with the reference document [9]. The communications interfaces and protocols used to effect delivery of these SFDUs from the DSN to a mission are outside the scope of this module. The SFDUs described in this module are compatible with a variety of transmission and storage media. For example, a given sequence of telemetry SFDUs may be delivered to the mission as a real-time data stream using a communications protocol such as TCP/IP (Transmission Control Protocol/Internet Protocol); or it may be stored as a file and delivered to the mission in non-real-time using a file transfer protocol such as FTP (File Transport Protocol). Communications interfaces and protocols are specified elsewhere (e.g., in other 820-013 modules). Reference document [9] lists, for each mission, the secondary, tertiary, quaternary and data CHDO types of all CHDO-structured SFDUs for each DSN mission. This document will define all CHDOs listed in reference document [9], or refer to other documents with those definitions, and will define the common structures of the CHDO-structured SFDU. Some CHDOs are multi-mission in nature, and some are mission-specific. The mission specific CHDOs may be used by another mission, as long as their format is not changed. The decision to format mission-specific data for a mission in accordance with the specifications of this module is the result of an agreement between the DSN and the mission. Such an agreement also must specify the mission-specific values of certain parameters referenced within CHDOs defined in sub-modules of this document (e.g., the spacecraft identifier); To use this document, first see section 2 for general information. Find the target SFDU in the proper mission-specific sub-module of reference document [9]. Look in the separate CHDO sub-modules of this document for each CHDO specified in the target SFDU. Note that some CHDOs and the enveloping SFDU are defined either in this document, or in reference [9]. Individual field types are defined in section 3 of this document, common fields in multiple CHDOs are also defined in section 3 of this document, and the CHDO definitions refer to these areas of section 3 rather than re-stating the formats. All fields that do not have a specific "format" or "type" are to be used as unsigned binary integers. Any other format will be explicitly stated. 1.2 Applicability Control of changes is as described is Section 1.3. Revision A-1 is equal to revision A in all ways, but an additional number has been added to a table, as per the Change Log in Section 1.3. This interface definition comprises this module and a set of supporting CHDO definitions, identified as sub-modules. This document contains general information on all CHDO definitions and their usage and each sub-module defines the details of a specific CHDO definition. This module is applicable to all CHDOs named within this module for all versions of TTC (Tracking, Telemetry and Command - a subsystem of DSN). The definitions in each version, unless explicitly stated otherwise, supercede previous version. Note that not all CHDOs defined in the DSN are sub-modules of this 820-013 interface module (1) some existing software interface specifications of CHDOs were released using a different scheme and may continue to be published that way; If for some reason a CHDO originally published in another module is later put under this module, the original document will be declared obsolete, and a reference will be provided to this module. (2) some CHDO definitions may just be referenced here as their definitions are included in and controlled by other 820-013 interface modules. Note that the on-line store contains obsolete CHDOs. This allows them to remain for future reference in case those missions need it, and to dis-allow re-use of the CHDO number. In general, an obsolete CHDO is one used for a no longer viable mission, and not for any current mission. Because this module assembles all CHDOs into one master list, the initial release of the 0172Telecomm-CHDO document accepts the CHDOs in the list below as part of its release. These CHDOs were approved previously in the indicated document. CHDO Number CHDO Name Approved in 000 Null Tertiary SFOC-5-SYS-*DU-NJPL 001 Aggregate SFOC-5-TIS-*DU-SFDU 002 Primary SFOC-5-TIS-*DU-SFDU 010 Data Area for Binary Data SFOC-5-TIS-*DU-SFDU 015 TIS TDM Telemetry Secondary SFOC-5-TIS-*DU-GLLSFDU, SFOC-5-TIS-*DU-ULSSFDU, SFOC-5-TIS-*DU-VGRSFDU 016 TDS Secondary Compressed SFOC-1-TDS-Any-QueryProt 017 TDS Secondary Compressed CHDO, Post V26, Expanded Time SFOC-1-TDS-ANY-QueryProt 018 GIF Raw Log Secondary SFOC-5-TIS-*DU-SFDU 020 Out of Sync Quaternary SFOC-5-TIS-*DU-SFDU 027 Channelized Data Quaternary SFOC-5-TIS-*DU-SFDU 029 Expanded Channel Data Record Data SFOC-1-DMD-Any-ExpChan 032 Expanded Channel Data Record Quaternary SFOC-1-DMD-Any-ExpChan 061 GIF Telemetry Secondary from TLM-3-20 missions SFOC-4-TIS-*DU-MOSFDU 062 Packet Telemetry Secondary SFOC-4-TIS-*DU-MOSFDU 063 Packet Telemetry Tertiary SFOC-4-TIS-*DU-MOSFDU 065 Mission-Specific Engineering Packet Quaternary SFOC-4-TIS-*DU-MOSFDU 070 DSN Telemetry Secondary SFOC-1-GIF-DSN-MOGCFTlm 081 Multi-Mission (old MMT) GIF Telemetry Secondary SFOC-5-TIS-*DU-MMSFDU 083 Multi Mission (MMT) Packet Telemetry Tertiary SFOC-5-TIS-*DU-MMSFDU 084 Multi-Mission (MMT) Time Correlation Packet Quaternary SFOC-5-TIS-*DU-MMSFDU 121 GIF Monitor/Tracking Secondary SFOC-5-TIS-*DU-SFDU 123 Standard Non-structured ASCII Data Area SFOC-5-TIS-*DU-SFDU 124 Monitor 5-15 GIF Processed Secondary SFOC-5-TIS-*DU-SFDU 125 Radio Science ODS Secondary SFOC-5-TIS-*DU-MMSFDU, SFOC-5-TIS-*DU-CASSFDU 126 Radio Science SSI/SCP Secondary SFOC-5-TIS-*DU-MMSFDU, SFOC-5-TIS-*DU-CASSFDU 220 MIPS QQC ICT Status Secondary 625-610 PROJECT GALILEO 221 NIMS QQC Rice Status Secondary 625-610 PROJECT GALILEO 1.3 Revision Control Revisions or changes to the information herein presented may be initiated according to the procedure specified in the Introduction to Document 820-013. This document and the individual CHDO definition sub-modules retain separate identities and control. (a) This document is called 820-013, 0172-Telecomm-CHDO. (b) Sub-modules of this module that identify individual CHDOs have identifiers such as 820-013, 0172-Telecomm-072, where the trailing 3-digit number is in the range 000 to 999, with the number matching the CHDO's number. Gaps in sub-module numbering will occur. Revisions to this module and sub-modules are indicated by a revision letter designator, such as 0172Telecomm-CHDO, Revision A or 0172-Telecomm-072, Revision A. Each individual CHDO definition sub-module has its own change log with release history and change summary. A CHDO definition can be added, deleted, or modified independently of the other definitions and this parent document. Documents controlling this version include DSN 813-109 Preparation Guidelines and Procedures for Deep Space Mission System (DSN) Interface Specifications [DSN internal] 1.4 Relationship to Other Documents This module is produced, approved, and revised in accordance with the policies and procedures specified in reference [2]. The structure and construction of all CHDO-structured SFDUs conforms to the SFDU specifications given in reference [4]. Certain fields within the CHDOs in an SFDU contain identifiers, codes, or other values that are specified in reference [3]. This module is intended to be used together with reference [9] to identify CHDO-structured SFDUs found in the DSN system. 1.5 Terminology and Notations 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 [4]). 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. As the SFDU concept evolved over time, the meaning of some terms also has evolved. The definitions provided here are intended to clarify the use of certain terms as they apply to this module: a) A label-value-object (LVO) is a data structure comprising 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 octets. In this module, LVO is used in a generic sense to refer to any data structure with these attributes. b) 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. The aggregation CHDO (001) is a compound LVO. c) 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 [4]. The term CHDO-structured SFDU refers to the SFDUs defined and controlled by this module. The CHDO-structured SFDU does not strictly conform to the internationally recognized SFDU structure and construction rules recommended by CCSDS in reference [4] d) A compressed header data object (CHDO), as defined herein, is an LVO. Its design is modeled on the SFDU concept, but a CHDO is not an SFDU. The CHDO derives its name from that fact that the label field of a CHDO is considerably shorter that the label field of an SFDU (four octets instead of twenty). The CHDO provides a means of structuring user data with less overhead than would be obtained 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. e) The term type attribute is used to refer to the subfield(s) of an LVO label field that effect 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 interpretation of the data contained in the value field of the LVO. For SFDUs, type attributes are assigned by a control authority, which is also responsible for maintaining the associated data descriptions. The CCSDS maintains a registry of control authorities. f) 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 octets, of the value field of the LVO. When interpreted in the context of the structure and construction rules specified in reference [4], the length attribute effects 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 [4], for example, provides several mechanisms that do not rely on an explicit length. g) The terms byte and octet are used interchangeably in this module to refer to an eight-bit quantity. The term word is used to refer to a sixteen-bit quantity. h) The terms "header", "sub-header", and "CHDO" are used throughout various documents in the DSN. area. This document attempts to remove the term "header" from all but one meaning. The meaning of "header", or "SFDU Header" should be taken to mean the entire front of a CHDO-structured SFDU, up to, but not including the data area. In the past, a primary, secondary, tertiary or quaternary CHDO was also called a primary, secondary, tertiary or quaternary header or sub-header. Both those term are now avoided in favor of merely using the word CHDO to denote the substructures of a CHDO-structured SFDU. The term "label" means only the first 20 bytes of information in a CHDO-structured SFDU, which means 12 bytes of ASCII and 8 bytes of binary length. The term "CHDO header", though rarely used, means the first 4 bytes of a CHDO. Those 4 bytes are the CHDO type and length of the value area. When reading about a telemetry packet or frame, the term "header" should mean the CCSDS packet telemetry headers downlinked with the data, as defined in reference document [14], not metadata added by DSN and defined in this document. i) In the CHDO sub-modules, because they were written and signed at different times, references to DSN, AMMOS, DTT and TTD will be found. Sometime before 2006 "AMMOS" merged with DSN, and some AMMOS subsystems were moved into a new area, thenceforward called AMMOS. But GIF, TIS, and TDS became part of the DSN. Because many CHDOs refer or referred to AMMOS and DSN, it became necessary to distinguish the subsystems inside of DSN. As of 2007, DTT (Downlink Tracking and Telemetry) is used instead of DSN, because it is DTT that creates the telemetry SFDUs, and TTD (Tracking and Telemetry Data) is used for the former AMMOS (GIF/TIS/TDS). DTT and TTD are both subsystems within the DSN. 1.5.2 Conventions The following conventions are used in this module and all sub-modules. a) All numbers are expressed in decimal unless explicitly indicated otherwise by means of a subscript designating another base (e.g., 4F16 for hexadecimal). b) Data structures in CHDO definitions are generally illustrated as sequences of 8-bit bytes, shown with 2 bytes together. 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, just to the right, is identified as "byte 1" and so on, to "byte N-1," which is drawn in the most bottom-justified, and right side position. Within each 2-byte pair, the most significant bit is drawn in the most left-justified position and is identified as "bit 0." The next most significant bit is identified as "bit 1" and so on, to "bit 15" which is drawn in the most right-justified position. Any bit in a data structure is uniquely identified by specifying the byte(s) within which it occurs and its position within that byte (e.g., "byte 5, bit 7, or "bytes 5-6 bits 5-14"). Note that this convention holds true for all sub-modules of this document, and occasionally other documents. However, in other documents of the 820-xx series, the MS bit of each one or two byte structure is bit number 1, instead of 0. Additionally, since this document represents two byte pairs with bits numbered continuously from 0 through 15, odd numbered bytes, represented singly in other documents, may comprise bits 1-8, whereas in this document, those bits would be numbered 8-15. c) Data structures are divided into fields, where a field is a sequence of bits. Fields are identified by specifying the starting and ending bits or bytes of the field (e.g., "bytes 3-5" would be bytes 3, 4, and 5. "Bits 10-15" would be a 6-bit field starting in bit 10 and ending in and including bit 15). For fields that cross byte boundaries, bit 7 of byte M is more significant than, and is immediately followed by, bit 8 of byte M+1, where M is always even. A field may be divided into subfields in a similar manner. Note that the hyphen is used instead of the word "to" because the individual CHDO files are used to create machine-readable files, and that is the convention necessary to make the conversion. d) 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 4-byte label field). In other contexts, a length may be given in bits or bytes, and the length may refer to the entire data structure or only a part of it. In all such cases, the units and meaning are explicitly stated. e) In the CHDO data structure descriptions, many fields are defined to contain a numerical value. Several different formats for expressing numbers are used. Each of these is defined in Section 3.8. f) 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 ASCII or RA (Restricted ASCII) and not so enclosed (e.g., 2) if the information is expressed in binary. g) Unless explicitly stated otherwise, fields defined as "reserved" or "spare" are to be set to binary zero by the originator and are to be ignored by the recipient. h) All CHDOs described here are in terms of a Global Data Representation (GDR). GDR signifies: All byte offsets are assumed to be relative to the beginning of a structure or substructure. The first byte of a structure is called offset 0 (normally shown as the left byte of two), the second byte is at offset 1 (normally shown as the right byte of two), etc. All words (16 bits, 2 bytes or octets) have their more-significant byte at the lower-number byte offset and less-significant byte at the higher-number byte offset. Words always occupy an even offset and succeeding odd offset in a structure or substructure. All long words (32-bits, four bytes or octets) have their most-significant byte at the lowest-number byte offset of four through their least-significant byte at the highest-number byte offset. Bits in a byte are labeled 0 through 7, where the 0th bit is the most-significant or sign bit (left-most bit) and the 7th bit is the least-significant bit (right-most bit). Bits in a word (16 bits) and long words (32 bits) are labeled 0 through 15 and 0 through 31 correspondingly. 1.6 References Documents The latest releases of the following published documents form a part of this document to the extent specified herein. In case of conflict between this document and those listed below, this document shall govern. However, for all CCSDS SFDU definitions, the governing document is the CCSDS document itself (ref [4]), parts of which are being replicated for the reader's convenience here. [1] This reference has been removed; its place has been kept blank to allow numbering to remain unchanged. [2] This reference has been removed; its place has been kept blank to allow numbering to remain unchanged. [3] DSN 820-013, Module OPS-6-21 DSN External Interface Specification-Standard Code Assignments [4] CCSDS 620.0-B-2 CCSDS Recommendation for Space Data System Standards-Standard Formatted Data Units- Structure and Construction Rules (Issue 2, May 1992) [5] ANSI T-49-12 ANSI/IEEE STD 754-1985-IEEE Standard for Binary Floating-Point Arithmetic (ANSI - American National Standards Institute) [6] ANSI X3.4-1986 (R1997) Information Systems - Coded Character Sets - 1 Bit American National Standard Code for Information Interchange (7-Bit ASCII) ((American Standard Code for Information Interchange)) [7] ISO/IEC 646-1991 Information Technology -ISO 7-bit Coded Character Set for Information Interchange [8] DSN 810-047, D23003 DSN Antenna and Facility Identifiers, DSN Standard Practice (DSN internal document, for reference only.) [9] 820-013, 0171Telecomm-NJPL JPL created SFDU structures [10] DSN On-line Interface Library http://jaguar.jpl.nasa.gov (valid as of this release) [11] CCSDS On-line Documentation http://www.ccsds.org/CCSDS/recommandreports.jsp http://ccsds.org/document_access.html (valid as of this release) [12] MIL-STD-1750A (USAF) Military Standard Sixteen-Bit Computer Instruction Set Architecture [13] 820-013, 0173Telecomm-Time Binary and ASCII Time structures in all CHDOs [14] CCSDS 102.0-B-5 CCSDS Packet Telemetry Recommendations, issue date November 2000 [15] MTIS0006-02-01-20 MOSO TIS Packet Frame Synchronization Software Requirements, August 15, 1994 [16] DSN 820-013, 0172Telecomm-001 This is a sub-module of this document, and is itself referenced in this document. [17] DSN 820-013, 0172Telecomm-002 This is a sub-module of this document, and is itself referenced in this document. Web Sites Most of the DSN documents are available online at http://jaguar.jpl.nasa.gov/. CCSDS documents are available online at http://www.ccsds.org/ (Consultative Committee on Space Data Systems) 1.7 Abbreviations Abbreviations and acronyms used in this document are defined where they first occur in the text. A complete list is provided here for the convenience of the reader. AMMOS Advanced Multi-Mission Operations System. Note that until 2006, this was a set of subsystems, including, but not limited to GIF, TIS, TDS, and DMD. In 2006, AMMOS was split off with the DMD to become a separate system, and the former AMMOS subsystems, not including DMD, were collectively called "TTD". AMPTE Active Magnetospheric Particle Tracer Experiment (a former mission) ANSI American National Standards Institute ASCII American Standard Code for Information Interchange BCD Binary-Coded Decimal CCITT International Consultative Committee for Telegraphy and Telephony, has now become ITU (International Telecommunication Union) on-line at http://www.itu.int/home/ CCSDS Consultative Committee for Space Data Systems CDA Common Data Access (TTD Subsystem) CDR Channel Data Record CFDP CCSDS File Delivery Protocol CHDO Compressed Header Data Object CMD Command (TTD Subsystem) CMI Commutation Map Identifier (from Galileo project) CRC Cyclic redundancy Check DACS Data Acquisition and Capture System (Pre-cursor of TTD) DMD Data Monitor and Display (AMMOS Subsystem (both current and former AMMOS)) DPS Data products Software (TTD Subsystem) DRS Data Records Software - pre-cursor to TTD Data Management Subsystem DSN Deep Space Network DTS Data Transport Software (TTD Subsystem) DTV Digital Television DTT Downlink Tracking and Telemetry Subsystem (When AMMOS changed to be only subsystems downstream of TIS and TDS, then what was called AMMOS became part of DSN. But to distinguish the part of DSN at the station, for telemetry proposes, the acronym used is now DTT, the subsystem that creates the SFDUs for telemetry) EAS Engineering Analysis Software (TTD Subsystem) ECDR Expanded Channelized Data Record EDR Experiment Data Record ERT Earth Received Time EUA External User Access (former AMMOS Subsystem, no longer in use) FEP Front End Processor FID Format Identifier FDM File Delivery Manager (part of TTC subsystem) FTP File Transport Protocol GDR Global Data Representation GIF GCF Interface Software (TTD subsystem) ID Identifier IDR Intermediate Data Record IND Interplanetary Network Directorate IPS Image Processing Subsystem ISO International Organization for Standardization JPL Jet Propulsion Laboratory LAN Local Area Network LVO Label-Value-Object MAS Mission Analysis Software (TTD subsystem, no longer in use) MDR Mission Data Record MGS Mars Global Surveyor MHR Magellan High Rate MO Mars Observer MRO Memory Readout (also Mars Reconnaissance Orbiter) MSN Map Sequence Number NASA National Aeronautics and Space Administration NASCOM NASA Communications NAV Navigation NJPL NASA/Jet Propulsion Laboratory (control authority identifier) PDU Protocol Data Unit QQC Quality, Quantity and Continuity RA Restricted ASCII RNS Reliable Network Service s/w software SAS Science Analysis Subsystem SCLK Spacecraft Clock SDR System Data Record (obsolete, pre-cursor to SFDU) SEDR Science Experiment Data Record SEQ Sequence SFDU Standard Formatted Data Unit SIM Simulation SIS Software Interface Specification SLE Space Link Extension (a CCSDS protocol, and the TTC instantiation of that protocol) SMC System Monitor and Control (TTD subsystem) TC Time Correlation (packet) TCA Telemetry Channel Assembly TCP/IP Transmission Control Protocol/Internet Protocol TDDS Tracking Data Delivery Services TDM Time Division Multiplexed - a form of telemetry before packet telemetry was used. TIS Telemetry Interface Software - a TTD subsystem TTACS Test Telemetry and Command Software TTD Telemetry and Tracking Data Subsystem (When AMMOS changed to be only subsystems downstream of TIS and TDS, then what was called AMMOS became part of DSN. But to distinguish the part of DSN at JPL that was GIF/TIS/TDS, it became the TTD. TTI Test Telemetry Interface TWS Test Workstation Software (obsolete AMMOS subsystem) VLBI Very Long Base Interferometry WSE Workstation Environment (TTD subsystem) Xfer Transfer Section 2 Functional Overview The data acquired or produced by the DSN for delivery to missions are encapsulated into DSN SFDUs. A detailed specification of the format and contents of each DSN CHDO is given in the sub-modules of this module. The list of all CHDO-structured SFDUs for any one mission is in reference [9]. The following paragraphs provide an overview and general description. 2.1 Description A CHDO-structured SFDU is a sequence of octets (bytes) that conforms to the SFDU structure and construction rules specified in reference [4]. A CHDO-structured SFDU is an LVO (Length Value Object). It comprises an SFDU label field and a value field. Viewed in a strict sense, the CHDO-structured SFDU is a simple SFDU in that its value field contains only user data; i.e., the value field of a CHDO-structured SFDU is not itself an SFDU or a sequence of SFDUs. However, the value field of a CHDO-structured SFDU does have structure in that it contains a sequence of CHDOs, each a form of LVO (albeit a non-standard, locally defined form). In that sense, the CHDO-structured SFDU is a compound LVO (i.e., its value field contains purely LVOs), and its LVO structure is depicted in Figure 2-1. Rules for interpreting Standard Formatted Data Units (SFDU): Assuming a non-data CHDO is present, then all CHDOs up to the present CHDO are also present and in their natural order. For example, if there is a tertiary CHDO in an SFDU, then the primary and secondary CHDOs are also present and in the following order: primary CHDO, secondary CHDO, and tertiary CHDO. +-------------------------------------------+ | CCSDS SFDU Label | | "NJPL2I00xxxx" | |-------------------------------------------| | Length of SFDU = L1 | + +-------------------------------------------+ | | CHDO aggregation chdo_type code | | |-------------------------------------------| | | Length of aggregated CHDOs = L2 | | +-------------------------------------------+ + | | Primary chdo_type code | | | |-------------------------------------------| | | | Length of primary CHDO = L3 | | | +|-------------------------------------------| | | || | | | L3| Primary CHDO data | | | || | | | ++-------------------------------------------+ | | | Secondary CHDO_type code | | | |-------------------------------------------| | | | Length of secondary CHDO = L4 | | | +|-------------------------------------------| | | || | | | L4| Secondary CHDO data | L2 | || | | | ++-------------------------------------------+ | | | Tertiary CHDO_type code | | L1 |-------------------------------------------| | | | Length of tertiary CHDO = L5 | | | +|-------------------------------------------| | | || | | | L5| Tertiary CHDO data | | | || | | | ++-------------------------------------------+ | | | Quaternary CHDO_type code | | | |-------------------------------------------| | | | Length of quaternary CHDO = L6 | | | +|-------------------------------------------| | | || | | | L6| Quaternary CHDO data | | | || | | | ++-------------------------------------------+ + | | Data CHDO type code | | |-------------------------------------------| | | Length of data CHDO = L7 | | +|-------------------------------------------| | || | | L7| Data CHDO data | | || | + ++-------------------------------------------+ Figure 2-1. LVO Structure of the CHDO-structured SFDU Viewed as a compound LVO, the value field of the SFDU contains two LVOs, an aggregation CHDO and a data CHDO. The CHDO aggregation CHDO is a compound LVO; its value field contains two or more simple LVOs, a primary CHDO and a secondary CHDO. A tertiary and quaternary CHDO are optional, depending on the type of SFDU. (It is possible in the future that an SFDU could be made that contains only a primary and no secondary, tertiary or quaternary, but as of the origin of this document, that has not happened.) The aggregation CHDO exists solely for the purpose of allowing the primary and secondary (and tertiary and quaternary, if present) CHDOs to be grouped together and treated as a single object. The value fields of the primary CHDO contains identification information, and the secondary, tertiary and quaternary CHDOs contain data specific to each type. The data CHDO is an LVO; although its value field may contain further structures, it will not contain further CHDOs. With the exception of the Aggregation CHDO (001), no other CHDO may contain another CHDO. 2.2 Size Constraints The size of any one CHDO in bytes may not exceed the 16 bits allotted to the length field of each CHDO, thus limiting any one CHDO to no more than 64K bytes, minus one, because we must have an even number of bytes. However, because the aggregate CHDO (001) contains the size in bytes of all other CHDOs except the data CHDO, not including itself, the aggregated size of all CHDOs (primary through quaternary) may also not exceed 64K bytes. Thus, given the following sizes, the maximum size for any CHDO-structured SFDU is 131,096 bytes SFDU ASCII label 20 bytes Aggregation CHDO 4 bytes Primary - Quaternary CHDOs 65,534 bytes Data CHDO 65,538 bytes Section 3 Detailed Interface Description 3.1 CCSDS SFDU Label The label field (bytes 0-19) of all CHDO-structured SFDUs is defined in reference [9], because it is the same label for all CCSDS SFDUs, not just CHDO-structured ones. It is mandatory in all CHDO-structured SFDUs. 3.2 Aggregation CHDO Bytes 20 to 23 of all CHDO-structured SFDUs always contain the aggregation CHDO (001), defined in document 0172-Telecomm-001. Because this CHDO is not found in the lists of CHDO-structured SFDUs (in reference document [9] sub-modules), it is specifically mentioned here that all CHDO-structured SFDUs contain, as the first CHDO, this aggregation CHDO. Although any one CHDO size must fit into 16 bits (64K bytes maximum), the aggregated size of all CHDOs (except for the data CHDO) in any one SFDU may not exceed the 16 bits allotted to the length of the aggregate. 3.3 Primary CHDO The Primary CHDO (002) is on all CHDO-structured SFDUs, in bytes 24-31. It is defined in document 0172-Telecomm-002. It differs from all other CHDOs except the Aggregation CHDO, in that it is always present in every CHDO-structured SFDU. That is, all primary CHDOs are CHDO 002. As opposed to this, Secondary, Tertiary and Quaternary CHDOs come in many formats. Each format is a separate numbered CHDO (in the field "chdo_type"). 3.3.1 Primary CHDO Values CHDO-structured SFDU records are identified by major/minor/format fields for each mission. These fields uniquely identify the structure and data content of an SFDU. Although this could be done with a single field, three fields are used to permit some mechanism of categorization (and thus easier recognition) of related data types. These fields are located in the primary CHDO Their meaning is described below. Note that over the years, these meanings and conventions have not always been strictly adhered to, so exceptions will exist. In future assignments, however, the intent of this document is to create greater adherence, thus making sense out of chaos. 3.3.1.1 Major Data Type The following major data type values are defined Table 3-1. Major Data Types Major Type Description 0 Unknown data. This data type should not be used by applications creating SFDUs 1 Raw mission telemetry 2 Spacecraft engineering telemetry frame or packet 3 Low-rate science telemetry frame/packet 4 High-rate science telemetry frame/packet 5 Playback telemetry transfer frame/packet 6 Ground station monitor data and Galileo Radio metric 7 TDM transport frame or packet transfer frame 8 Other (not type 2, 3, 4, or 5) telemetry frame or packet 9 Science instrument telemetry record 10 Other (not type 2) engineering telemetry record 11 Channelized data 12 Out-of-sync data 13 Summary and accountability data (e.g. QQC (Quality, Quantity and Continuity Records) 14 Telemetry processing parameters 15 Operator interface log (of commands, events, status, etc.) 16 Special processing events (link start-up, etc.) 17 Ancillary product data (MDR, EDR, CDR, SEDR, etc.) 18 Spacecraft command data 19 System configuration and routing control information 20 System configuration and routing status information 21 Radio Science Records 22 Expanded Channelized Data records (ECDR) -this was put into use in 2002 and applies to missions after that. 23-125 Reserved. Further assignments will be made if and when the need arises. 126 TTD debug aid/diagnostic data 127 Filler record 128 -255 available for mission-specific use 3.3.1.2 Minor Data Type Minor Data Type is used to further distinguish between data types within a major category. The interpretation of the minor data type field is unique for each major data type, although some parallel usage across multiple major types is possible. For some major data types, standard values for the minor type field are assigned. For others, specific values must be assigned according to mission-unique requirements. Values in the range "0" through "127" are used for standard values that are mission-independent. Values that are mission-unique are assigned from the range "128" through "255". Below in this document is a list of major/minor/format field combinations used in TTD. It shows assigned standard values and provides some guidelines for the non-standard use of the minor type and format fields. 3.3.1.3 Format The Format field is used to further distinguish between records of a given major and minor type. The conventions for the assignment of values are the same as those detailed above for the minor data type field. 3.3.1.4 Mission Identifier The Mission Identifier identifies the mission for which this record contains data. The values of the four fields: "major", "minor", "format", and "mission id" determine what additional CHDOs, if any, are present. Currently defined values for "mission id" are kept in 820-013, OPS 6-21 (ref [3], and will not be repeated here to avoid duplication. 3.3.1.5 Use of Major/Minor/Format Type The following list represents the standard template upon which the assignment of values for the Major Data Type, Minor Data Type, and Format fields in the primary CHDO are based. For each field the list specifies the decimal number and a brief description of the intended content of the record. Note that all records are specified in reference document [9]. The purpose of this list is to allow future assignments based on this "system". Also note that identifiers in the range 128 to 255 are assigned separately for each mission. The definitions for the three fields are shown indented in the form: major data type n minor data type 1 format 1 format 3 minor data type 2 minor data type 3 format a format b major data type m minor data type x format y When several minor data type descriptions appear in successive lines, the format description following the last line applies to all minor data types; i.e. "format a" and "format b" in the example above apply to both "minor data type 2" and "minor data type 3" of "major data type n". Note that obsolete types are still in this table for historical reasons. Table 3-2. Major, Minor, Format Organization Major Type Minor Type Format ID 1 = raw telemetry SFDUs and GCF/NASCOM blocks 1 = raw telemetry SFDU DSN (DTT) alignment attempted 0 = raw telemetry SFDU DSN (DTT) alignment not attempted 0 = DSN (DTT) formatted 1 = GIF formatted (GCF Interface) 2 = 1200bit GCF block 3 = 4800bit GCF block 4 = 4800bit NASCOM block 0 = block content unknown 1 = block containing raw telemetry bits 2 = block containing DSN (DTT) formatted raw telemetry SFDUs 3 = block containing DSN (DTT) formatted 820-013, MON-5-12 SFDUs 4 = block containing 820-013, MON-5-9 data 5 = GIF Processed Telemetry 6 = TIS In sync/Out of sync Transfer frames (sync = frame synchronization) 0 = In sync Transfer frame 1 = Out of sync Telemetry 2 = Invalid Transfer frame 7-9 = TBS 2 = engineering telemetry frame or packet 3 = low rate science telemetry frame or packet 4 = high rate science telemetry frame or packet 5 = playback telemetry frame or packet for TDM: frame length/data rate specific frame format/content for packets: packet ID mission specific 6 = ground station monitor data 0 = DSN 820-013, MON-5-12 and 820-013, MON-5-15 data 1 = DSN 820-013, MON-5-9 data 0 = DSN (DTT) formatted 1 = GIF formatted 2 = data extracted/derived from GCF monitor data 3 = NASCOM status block 4 = data extracted/derived from NASCOM status block format mission specific 12 = raw (unvalidated) uplink tracking data 13 = raw (unvalidated) downlink tracking data 14 = validated, raw or derived, up- and down-link tracking data 15 = invalid tracking data 7 = TDM transport frame or packet transfer frame for TDM: frame length/data rate specific frame format/content for packet transfer frames: virtual channel ID format mission specific 8 = other telemetry frame or packet data for TDM: frame length/data rate specific frame format/content for packets: packet ID mission specific 9 = science instrument telemetry record (TDM telemetry) instrument/experiment ID mission specific 10 = other engineering telemetry record mission specific mission specific 11 = channelized data 0 = channelized engineering frame data format mission specific 1 = DMD channel data record 2 = channelized ground station monitor data (Note 820-013 0158-Monitor exists ONLY in this form) 3 = channelized QQC data 4 = channelized memory readout data format mission specific 5 = TDS channel query record 1 = on sample query 2 = on change query 3 = frequency query 4 = time delta query other minor types mission specific format mission specific 12 = out of sync data (sync = frame synchronization) 0 = raw out of sync SFDU format identifies record length 1 = playback out of sync data format identifies length/data rate 13 = TTD summary and accountability data 0 = telemetry QQC data 1 = file status summary 2 = system/subsystem configuration summary 3 = directory information 4 = data catalogue 5 = processing summary format identifies format/content 14 = telemetry processing parameters 0 = decommutation map source text 1 = translated decommutation map 2 = decommutation map version control information format identifies map type 3 = time conversion information source text 4 = binary time conversion information format identifies specific content 5 = channel parameters source text 6 = binary channel parameters 7 = channel parameter version control information format identifies specific parameter types 8 = channel conversion/derivation information source 9 = channel conversion/derivation information binary format identifies specific content 15 = operator interface log (directives and events) 0 = directive and response log 1 = event log 2 = combined log 0 = system wide otherwise: subsystem ID (ID in "originator/last modifier" definition, this document) 16 = special processing events (not covered by anomaly records) 0 = system/subsystem configuration changes 0 = startup 1 = shutdown 1 = communication link change 0 = startup 1 = shutdown 2 = pausing 3 = resuming 2 = spooler file status information 0 = start spooling 1 = stop spooling 2 = end of data reached, no new data being added 3 = no data found with specified filters 4 = despooling overrun by spooling 17 = ancillary product data 0 = navigation data 1 = tracking data 2 = radio metric data format further identifies data 3 = PDUs (Protocol Data Units - a CCSDS CFDP term 18 = spacecraft command data 1 = CMD to GIF 2 = GIF to CMD 19 = system configuration and routing control information 20 = system configuration and routing status information minor type application specific - see 820-013 0171-NJPL sub-modules for specific project format application specific - see 820-013 0171-NJPL sub-modules for specific project 21 = volume/data set control information for magnetic tapes 0 = volume header/trailer information 1 = data set header/trailer information 2 = file header/trailer information 0 = begin/header 1 = end/trailer 2 = continuation 3 = SFDU aggregation control information 22 = Expanded Channelized Data Records (ECDR), used in newer mission (MER and later) and for ancillary data monitor and tracking, but not weather, for their ECDR forms 126 = TTD debug aid, diagnostic, and test data same as for major types 19/20 above subsystem specific record type - see 820-013 0171-NJPL sub-modules for specific project 127 = filler record 3.4 Secondary CHDO So far, all CHDO-structured SFDUs have a secondary CHDO. It tends to be a mission- or data-specific structure, though several missions may use the same one. Its purpose, for telemetry, is to identify the originating data stream processing parameters and equipment. For non-telemetry data, it tends to just be a more general CHDO than a tertiary or quaternary. In general, all telemetry SFDUs for one mission use the same secondary CHDO, though there are exceptions, mainly to conserve space. This is because all telemetry data for a single mission (indeed for most missions), has the same set of information necessary to trace it back to its origin and processing trail, and to give it unique identifiers. 3.5 Tertiary CHDO The tertiary CHDO is optional, not all CHDO-structured SFDUs have one. It tends to be mission and data specific. For instance, several types of telemetry data for the same mission using the same secondary CHDO will have different tertiary CHDOs. For instance, the SCLK (Spacecraft Clock) in telemetry data is always in the tertiary CHDO, because SCLK format is mission-specific. Any record that has a tertiary CHDO but not a secondary CHDO must have a Null secondary CHDO, that is, one with a length of 0. 3.6 Quaternary CHDO The quaternary CHDO is also optional. In fact, few CHDO-structured SFDUs have one. The few that exist tend to be very specific for a data type, and that data type tends to be a multi-mission type, e.g. channelized data, or expanded channelized data. It carries just a few pieces of information necessary to use that particular type of data. Any record that has a quaternary CHDO but not a tertiary CHDO must have a null tertiary CHDO, that is, one with a length of 0. Currently, no records ever have null secondary CHDOs. 3.7 Data CHDO The data CHDO is the final, bottommost level. In telemetry SFDUs it contains the telemetry bits themselves. All other CHDOs are meta-information. Some, CHDO-structured SFDUs have no data CHDO. For example TTD QQC (Quantity, Quality and Continuity) data has no data CHDO. All the information is in the secondary and tertiary CHDOs. The maximum size of any data CHDO is 64K bytes, as the size must fit into the 16-bit field allotted to it. 3.8 Anomaly Records Telemetry SFDUs called "anomaly records" have a null data CHDO (it is present, but has a data length of zero, consisting of just the length and type fields). Note that not all SFDUs with null data CHDOs are anomalies, however. The purpose of an anomaly record is to indicate a point in a telemetry stream where an anomaly or schism occurred. For instance, when data stopped temporarily, or a significant parameter changed. Anomaly records contain an exact copy of the entire SFDU header of the last SFDU produced in the stream of data that the anomaly is representing. The only differences between the SFDU headers of the last valid SFDU and the anomaly SFDU is the setting of the valid_data bit, and the setting of one or more anomaly flags, and a change in the record creation time (RCT field). All other fields in the primary, secondary, tertiary, and quaternary CHDOs should be the same. An anomaly record can be distinguished from a non-anomaly record by the setting of one or more bits in the "anomaly_flags" field, generally in the secondary CHDO of an SFDU. 3.9 Field Types The descriptions of the IEEE floating point formats below are taken from applicable document [5] the ANSI IEEE Std 754-1985, reaffirmed in 1991, reproduced here for your reading pleasure and convenience. 3.9.1 32-bit IEEE Floating Point Format Description 32 bit (single precision) floating point numbers are expressed in the ANSI/IEEE standard single precision format with a sign, 8-bit exponent, and 23-bit significand as illustrated in the figure below. BIT +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|13|14|15|16| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ BYTE 0|S | EXPONENT | SIGNIFICAND | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2| SIGNIFICAND (continued) | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|13|14|15|16| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Figure 3-1 32-Bit Floating Point Format The value v of the number expressed in this format is determined as follows: Let: s be the value (0 or 1) of the S (sign) field; e be the value in the EXPONENT field (interpreted as an unsigned integer); and f be the value in the SIGNIFICAND field (interpreted as an unsigned integer). Then: if e = 255 and f not eq. 0, then v is not a number (NaN) regardless of s, and are not used or accepted; if e = 255 and f = 0, then v =(-1)^S, (i.e., 1 or -1); if 0 < e < 255, then v =(-1)^S(2^e-127)(1Af); if e = 0 and f = 0, then v = (-1)^S 0, (i.e., +0 or -0). Bit strings of the form e = 0 and f not eq. 0 (denormalized numbers) are not permitted in this interface. 3.9.2 64-Bit IEEE Floating Point Format Description BIT +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|13|14|15|16| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ BYTE 0|S | EXPONENT |SIGNIFICAND| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2| SIGNIFICAND (continued) | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4| SIGNIFICAND (continued) | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6| SIGNIFICAND (continued) | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|13|14|15|16| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Figure 3-2. 64-Bit Floating Point Format Then: if e = 2047 and f not eq. 0, then v is not a number (NaN) regardless of s, and are not used or accepted; if e = 2047 and f = 0, then v =(-1)^S, (i.e., 1 or -1); if 0 < e < 2047, then v =(-1)^S(2^e-1023)(1Af); if e = 0 and f = 0, then v = (-1)^S 0 (zero) Bit strings of the form e = 0 and f not eq. 0 (denormalized numbers) are not permitted in this interface. 3.9.3 Bit MODCOMP Floating Point Format Description The MODCOMP format is no longer in use. The format may be seen by retrieving version D of this document in the DSN obsolete Interface Agreement storage area. This format and the next 2 (MIL32 and MIL48) is taken from MIL-STD-1750A. It was used on MGS and MO. |1| 7 bits | 8 bits | ----------------------- |s| mantissa | exp | ----------------------- Figure 3-5. MIL 16-Bit Floating Point Format 3.9.4 32 Bit MIL Floating Point Format Description |1| 23 bits | 8 bits | ----------------------- |s| mantissa | exp | ----------------------- Figure 3-6. MIL 32--Bit Floating Point Format 3.9.5 48 Bit MIL Floating Point Format Description |1| 23 bits | 8 bits | 16 bits | ---------------------------------------- |s| mantissa_ms | exp | mantissa_ls | ---------------------------------------- Figure 3-7. MIL 48-Bit Floating Point Format 3.9.6 Binary unsigned integer A non-negative integer 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 2^n - 1. This may also be referred to as merely an "unsigned integer". 3.9.7 Binary signed integer An integer is expressed in binary, using two's complement notation. For an n-bit field, the range of values that can be represented is from -2^(n-1) to 2^(n-1) - 1. 3.9.8 ASCII and Restricted ASCII The term ASCII refers to the American Standard Code for Information Interchange, a seven-bit code for representing letters, digits, and symbols that has been standardized by the American National Standards Institute (reference [6]). This code has been incorporated into the ISO (International Standards Organization) code of the same nature (reference [7]), 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-octet field, it implies that each octet in the field contains an ASCII code. The term restricted ASCII (RA) refers to the subset of ASCII consisting of the codes for the twenty-six uppercase letters ('A'-'Z') and the ten decimal digits ('0'-'9'). This is also explained in reference document [4]. When applied to a multi-octet field, it implies that each octet in the field contains an RA code. Each decimal digit of an integer is expressed by its corresponding RA code. The field must be an integral number of octets in length. For multi-digit fields, the first octet of the field contains the most significant digit, the second octet contains the next most significant digit, and so on. If the number of digits is less than the number of octets in the field, leading zeroes are used to fill the field. Negative quantities cannot be expressed. For an n-octet field, the range of values that can be represented is from 0 to 10^n - 1. 3.9.9 Binary-coded decimal (BCD) Each decimal digit of an integer is expressed in binary in a four-bit subfield. The length of the entire field, in bits, must be an integral multiple of four. For multi-digit fields, the first four-bit subfield contains the most significant digit, the second four-bit subfield contains the next most significant digit, and so on. If the number of digits is less than the number of four-bit subfields, leading zeroes are used to fill the field. Negative quantities cannot be expressed. For an n-bit field, the range of values that can be represented is from 0 to 10^(n/4) - 1. In certain rare cases, where it is known that a digit cannot be greater than three (e.g., the hundreds digit of the day-of-year), a BCD digit is allowed to occupy a two-bit subfield, and the length of the field and the range of values are adjusted accordingly. 3.9.10 Time The formats of the Earth Received Time (ERT) field, the Spacecraft Clock (SCLK), and all other time fields represented in CHDOs are described in module 820-013, 0173-Telecomm-TIME (ref [13]), GDR Binary representation. 3.10 Fields Common to Multiple CHDOs 3.10.1 Anomaly Flags Anomaly records are described in the "Data CHDOs" section, above. All SFDUs that have an anomaly_flags field use the same bit structure, although not all bits are valid for all originators. Below is the bit-level description of this field, named "anomaly_flags". Table 3-3. Anomaly Flags Bit 0 spare Bit 1 upstream Upstream anomaly. This is set only in conjunction with another anomaly flag. This indicates the generating program received an anomaly record in its input record stream and passed on the anomaly indication in its output stream. Note - Not valid in GIF-produced records, valid in TIS-produced records. Bit 2 other Any reason not identifiable by other anomaly flags. Note - Valid for GIF and TIS-produced records. Bit 3 spare Bit 4 format For TDM missions - (Voyager, Ulysses, Galileo) Frame format ID has changed (applies to MRO (memory readout) , CMI (commutation map identifier), MSN (map sequence number) parts of FID (format Identifier) for Galileo). For packet telemetry, turbo-encoded data, this identifies a change in turbo code rate without other previous loss of frame sync. Note - Not valid in GIF-produced records, valid in TIS-produced records. Bit 5 forced_resync Forced Resync. Sync is lost for the parent frame. The operator entered a Resync directive. Note - Not valid in GIF-produced records, valid in TIS-produced records. Bit 6 phase_change Phase Change. Sync is lost for the parent frame. A valid sync code is found at the proper place but in the wrong phase. Note - Not valid in GIF-produced records, valid in TIS-produced records. Bit 7 data_break Data Break. Sync was lost at frame level. Multiple reasons exist for sync loss. Reasons for sync loss are varied, and can be found in the appropriate out of sync SFDU CHDO and/or the relevant QQC SFDUs. DSN requirements document 884-177 "TTD Telemetry Frame Processing Software requirements" discusses sync acquisition and loss. Note - Not valid in GIF-produced records, valid in TIS-produced records. Bit 8 clock New spacecraft clock or extraction reference. (Valid only in TDM missions - Voyager, Ulysses, Galileo) Note - Not valid in GIF-produced records, valid in TIS-produced records. Bit 9 off The operator entered an OFF directive. Note - Valid for GIF and TIS-produced records. Bit 10 timeout Timed out and terminated. Note - Valid for GIF and TIS-produced records. Bit 11 sequence When set, means: in transfer frames, DSN (DTT) sequence numbers are not in sequence; in packets, the packet sequence count is not in sequence; in GIF it means a break or regression in input record sequence. GIF tests field "dsn_record_seq" (if present) for input received from the DSN (DTT). Sequence checks on TTD-generated SFDUs are always performed on field lrn (logical record number). Bit 12 overflow Data was lost in real time due to queue overflow. Note - Valid only on GIF-produced records. Bit 13 spare Bit 14 scid_fail spacecraft ID failure Frame sync was lost due to spacecraft ID check algorithm failure - this bit set only on frame anomaly records. Note - Valid only on TIS-produced records. Bit 15 spare 3.10.2 Current Source and Original Source The 2 fields "curr_source" and "orig_source", are used in most secondary CHDOs to show how the data was originally acquired by TTD, and how it came to the current processing. Both fields share the same possible values, shown below. Some values are obsolete but retained because old data for some missions will still have these values. 0 Not applicable 1 Router A 2 Router B 3 Wide band switch 4 IDR tape 5 DSN-GIF LAN I/F 6 CDA spooler file 7 SFDU tape. 8 DTS virtual circuit 9 CDA bytestream file 10 UNIX bytestream file 11 SIM extracted GLL SDR tape 12 DRS conversion (GLL) 13 DSN RNS 14 IDR file from CDR 15 S/C hardline during ATLO 16 Socket 17 UconX box 18 SIM DDL 19 SIM conversion from bit-stream data (packet or frame) 20 SIM conversion from other SFDUs 21 serial device not listed 22 broadcast channel 23 multicast channel 24 DCD - Data Capture and Delivery at DSS 3.10.3 Originator and Last_Modifier Secondary SFDU CHDOs, as currently implemented for TTD and Magellan, contain fields for "Originator ID" and "Last Modifier ID". The table below lists possible values for those fields. Note that a change to "Last Modifier ID" would be called for when data structures are re-aggregated, even if the data is not modified. 00 TTI - Test Telemetry Interface 48 DSN - Deep Space Network (DTT) 49 TDDS - Tracking Data Delivery Software 50 VLBI - Very Long Based Interferometry 66 FEP - Front End Processor (AMPTE/DACS) 100 CMD - Command Subsystem 101 DMD - Data Monitor and Display 102 CDA - Central Data Access 103 DPS - Data Products Software 104 DTS - Data Transport Software 105 DTV - Digital Television Software 106 EAS - Engineering Analysis Software 107 EUA - External User Access 108 GIF - GCF Interface 109 MAS - Mission planning and Analysis 110 IPS - Image Processing Subsystem 111 NAV - Multi-mission Navigation subsystem 112 SAS - Science Analysis Software 113 SEQ - Sequence Generation Softwaresubsystem 114 SIM - Simulation Software 115 SMC - TTD Monitor and Control 116 TCA - Telecommunications Analysis 117 TIS - Telemetry Input Software 118 TWS - Test Workstation 119 WSE - Workstation Environment 120 MHR - Magellan High-Rate processor 121 DTT - Downlink Tracking and Telemetry 122 JPL's Radio Metric Data Conditioning Team 123 JPL's Radio Science Systems Groups 124 FDM - File Delivery Manager 255 EXT - Any system external to JPL 3.10.4 Decode_Status All CHDOs that use the field "decode_status" (it may be called "dsn_decode_status" or "tis_decode_status") will use the following definitions, though not all will apply to each mission. These status levels are meant to be applicable to Reed-Solomon and CRC/checksum/CCITT decoding/checking. Reed-Solomon decoding actually involves 2 processes -decoding and compression. Decoding refers to correcting individual bits which the decoding process detects as being errors. Compression refers to removing the bits added to the data as part of the encoding process. 0 Decoding is turned off (the data is still compressed however). This is the uncoded condition described in Packet Frame Synchronization Requirements. When decoding is turned off, the frame sync algorithm relies entirely on sync markers for sync acquisition and maintenance. 1 The record does not match the format expected for records using this decoding method (the decoder did not alter the data). This is the suspect condition described in Applicable document [15]. This is only used for CRC, CCITT, or checksum, not Reed-Solomon, and means that the check did not "work", but the frame was made. A TIS s/w switch determines whether frames with valid sync markers but failed checks get made as "suspect" (and packets are extracted from them), or are made as invalid frames, and packets are not extracted from them (value of 6 for this field). 2 The record uses the correct format for this decoding method, but it cannot be corrected using this decoding method. This is the invalid condition described in Applicable document [15]. Correction bits are not removed. 3 The data is a valid frame (no corrections made). This is the valid condition described in Applicable document [15]. 4 The data has been corrected to be a valid frame. This is the corrected condition described in Applicable document [15]. Used for Reed-Solomon only. 5 For CRC/checksum, the CRC/checksum was correct and valid 6 CRC/checksum did not work, and the "suspect" switch was not set, so frames with this value will not be created, but this value is used in other record types and reports. 3.10.5 Decode_Method This field is used by TIS in several CHDOs. The valid values are: 0 Decode off 1 Reed-Solomon decoding 2 Spare 3 CRC/checksum 4 turbo unpack, CRC check OFF 5 turbo unpack, CRC check ON 3.10.6 AMMOS (now TTD) Version and Build The fields "version" and "build" were used prior to AMMOS V25. (AMMOS is now called TTD, and AMMOS is reserved for another area, but older documents may still refer to it with the former meaning. Starting in V25, a third field was added "sub_version". Prior to V25, the version field, although one byte, 0172-Telecomm-CHDO Rev E was logically in 2 parts. The first part was multiplied to by 10, then the "sub-version" was added to that. This created a "version" byte of a value such as 235, to be interpreted as V23.5. By V25, sub-version 6, the number was too big for one byte, so the entire 16-bit field was reconfigured to have the current three fields in it. Older stored data will have the older format, although if displayed by current browser templates it may not look correct. The current 3 fields together are usually displayed as Vxx.y Bz where x=version, y=subversion, z=build. All CHDO-structured SFDUs created by TTD's GIF and TIS have the TTD version/build of the software in use when they were created. In all CHDOs this has the same structure as below/ Table 3-4. Version/Build Fields 2 bytes version_build These fields reflect the TIS s/w. The entire version/build is usually displayed like "V25.1 B6" Bits 0-6 version Software version number (0-255) of the creating subsystem(GIF, TIS, etc.). (the left-most number of theversion/build display) Bits 7-10 sub_version Point build number (as in V25.1) (The middle number of the version/build display) Bits 1115 build Software build number (0-255) of the creating subsystem(GIF, TIS, etc). (The right-most number of theversion/build display) 3.10.7 Logical Record Number Logical record number, or LRN is set by the creator of an SFDU. It contains the 16-bit sequence number for all SFDUs with the same data type (same as record-ID which is major / minor / mission / format type). This counter starts with 1 for the first record of a given type after subsystem start-up, increments by 1 for each SFDU of the same type, and wraps to 0 from 65,535. After subsystem start-up, this counter is never reset by causes other than wrapping. Anomaly SFDUs will not have LRN incremented over the previous record. GIF keeps separate LRNs and lock counts for each distinct stream of data. In general an SFDU stream is defined by record ID, spacecraft ID, virtual stream ID, data source (DSS ID), telemetry equipment ID (DCC number), frequency band, and input device ID. For 0161-Telecomm SFDUs, GIF keeps LRN together for a "class" of records. Three classes exist: 1 - non-turbo (minor types 7-11), 2 - turbo (minor types 12-16), 3 - raw (minor type 17). That is, although a class encompasses multiple record IDs (because the minor types differ), the class uses a single LRN, and the LRN does not change when the minor type changes, unless it changes to a different class. For the first instance of a new class, the LRN is set to 1. Switches between classes will use the previously used LRN of that class, incremented by one from the last SFDU created for that class. Switches between classes will not reset the LRN unless wrapping occurs. On wrap LRN always wraps to zero (0). Thus within a same stream or class, the progression from startup is: 1, 2, 3...65534, 65535, 0, 1, 2... An LRN of zero is found only after an LRN of 65535. An LRN of 1 can be found at start-up, after an anomaly has been produced, or after an LRN of zero. Note that for SFDUs produced by various relay processes, the specific CHDO used in that relay data may contain relay-specific information on the LRN. 3.10.8 Lock Count This is an incrementing counter for all records with the same record ID (generally, see below for details), that have been produced without dropping "lock". The count starts at 1 and is incremented by 1 for each record. It wraps to 0 from 65,535. It resets to 1 in the first normal data record following an anomaly record. Even if anomaly record production is turned off, this count will reset if an anomaly would have been created. For frame synced frames, even if each separate virtual channel is given a separate record ID, this count does NOT follow the ID, but is maintained as a single count for all frame synchronized frames in the same TIS stream. If a stream is re-processed, the SFDUs produced may have a different lock count, it is not an intrinsic part of an SFDU, but an "of the moment" count. If invalid frames are created, or idle frames are received, they also do not have a separate lock count, but are in the same sequence as valid frame synced frames. Out of sync SFDUs have a separate lock count from frame synced SFDUs, and reset to 1 for each instance of going to out of sync from an in-sync or no-data condition. The lock count in anomaly SFDUs will not be incremented relative to the SFDU from which they were copied.. All SFDU types will have lock counts that start at 1. The only time a lock count for any SFDU type would be zero (0) is when it follows a previous SFDU of the same type whose lock count is 65535. GIF treats the data "classes" the same as it does for logical record number, see above. Note that VGR was not changed to this newer scheme, so after an anomaly, VGR lock counts go to zero. The change from resetting to zero, to resetting to 1 took place in V32.2, operationally in mid-2010. So before that time, it reset to zero following an anomaly. Note that for SFDUs produced by various relay processes, the specific CHDO used in that relay data may contain relay-specific information on the LRN. 3.11 Channel ID Definitions Channelization is a "legacy" capability for TTD. However, because some information, such as 820-013, 0158-MON is produced in channel form, and because several legacy missions still use the channelized format, this information is still in this document. A channel in TTD is a contiguous set of one or more bits from telemetry or non-telemetry data. In other non-JPL systems it may be called a "measurand" or some other word. Although channel identifiers are displayed as characters, when they exist in CHDO-structured SFDUs they are in binary form, not ASCII. Note that a "virtual channel" is not related to the type of "channel" discussed here. A 'virtual channel' is a means of differentiating groups of information being uplinked or downlinked from a spacecraft. The channels defined here are single pieces of information processed by TTD and AMMOS, and may come from telemetry frames, packets, or non-telemetry ancillary information such as, but not limited to, monitor, weather, or tracking data. Channel identifiers shall be limited to the form: A-nnnn where: A is the SOURCE identifier, normally shown as a capital letter with allowed range [A-Z], except for "Y" which is not allowed (it is used by DMD internally). Some TTD parsers do not need upper-case letters, but it is a good idea to use them anyway. nnnn is the channel ID NUMBER, shown as a decimal number with an allowed range of [0-4095]. The computer internal binary representation of a channel ID assigns the letter "A" to 1, and successive letters to successive integers, up to decimal 26 for "Z". The "nnnn" is a binary integer. The internal structure representing the entire ID can be seen in other documents (820-013, 0172-Telecomm-028, or ....029) showing it in a particular structure. Most useful of those documents may be the sub-module of this document for CHDO 028, the channelized data record data CHDO. This form of channel identifier also exists in the expanded channelized data record, (in data CHDO 029). Also, 820-013, 0158-Monitor uses CHDO 028 for all its data.