625-205, GLL-3-280, Phase 2 Telemetry Measurements and Data Formats CONTENTS Section GLL Online Docs 1.0 SCOPE 2.0 APPLICABLE DOCUMENTS 3.0 TELEMETRY SYSTEM FUNCTIONAL REQUIREMENTS D-16 3.1 GENERAL 3.1.1 Engineering Subsystems 3.1.2 Science Subsystems 3.1.3 Document Conventions 3.2 DATA MANAGEMENT 3.2.1 Engineering Data 3.2.2 Memory Readout Data 3.2.3 Low-Rate Science (LRS) 3.2.4 High-Rate Science (HRS) Data 3.2.5 Intermediate-Rate Science (XRS) Data - Deleted 3.2.6 Medium-Rate Science (MRS) Data 3.2.7 S-band Back-up Science (BUS) Data - Deleted 3.2.8 Playback (PB) Data 3.3 DATA ACQUISITION 3.3.1 Analog Engineering Measurement Resolution 3.3.2 Analog Engineering Measurement Accuracy 3.4 DATA FLOW AND TRANSMISSION 3.4.1 STS Attached Phase - Deleted 3.4.2 STS Detached Phase - Deleted 3.4.3 Low-Rate Channel 3.4.4 High-Rate Channel 3.5 DATA PROCESSING 3.5.1 Science Subsystem Processor Telemetry Functions 3.5.2 AACS Processor Telemetry Functions 3.5.3 CDS Processor Telemetry Functions 3.5.4 Data Forms 3.6 SOURCE ERROR PROTECTION CODING 3.6.1 Golay Coding Function - Deleted 3.6.2 Code Operation - Deleted 3.6.3 Interleaving Depth - Deleted 3.6.4 Reed Solomon Coding 3.6.5 Convolutional Coding 3.7 DATA STORAGE 3.7.1 Data Recording 3.7.2 Data Playback GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.8 TDM TELEMETRY MODES AND RATES 3.8.1 Engineering Telemetry Modes 3.8.2 Memory Readout 3.8.3 Science Telemetry Modes 3.8.4 TDM Playback 3.9 TDM TELEMETRY DATA FORMATS 3.9.1 General 3.9.2 TDM Header 3.9.3 ENG - Engineering 3.9.4 LRS - Low-Rate Science - Deleted 3.9.4A LPW - Low-Rate Science plus PWS 3.9.4B LPR Frame - Deleted 3.9.4C LNR - Low-Rate Science plus NIMS 3.9.4D LPU - Low-Rate NIMS plus UVS & PPR 3.9.4E BPT - PPR Burst to Tape 3.9.4F BDT - Buffer Dump to Tape 3.9.4G EOTR-End of Track 3.9.4H BOPTR-Beginning of Track 3.9.5 MPW - Medium-Rate Science, PWS Data 3.9.5A MPP - Medium-Rate Science, PWS Data without NIMS 3.9.6 MPB - Medium-Rate Playback - Deleted 3.9.7 XED - Intermediate Rate Science, Compressed and Edited Imaging - Deleted 3.9.8 XCM - Intermediate Rate Science, Compressed Imaging - Deleted 3.9.9 XPW - Intermediate Rate Science, PWS - Deleted 3.9.10 XPB - Intermediate Rate Playback - Deleted 3.9.10A XRW - Intermediate Rate Real Time PWS at 80.64 Kbps - Deleted 3.9.10B XPN - Intermediate Rate Playback with NIMS at 80.64 Kbps - Deleted 3.9.11 HIM - High-Rate Science, 1perRIM 800x788 Imaging 3.9.12 HCM - High-Rate Science, Compressed Imaging - Deleted 3.9.12A HCJ - High-Rate Science, Compressed Imaging and PWS - Deleted 3.9.13 HPW - High-Rate Science, PWS 3.9.14 HPB - High-Rate Playback - Deleted 3.9.14A HRW - High-Rate Real Time PWS at 134.4 Kbps - Deleted 3.9.14B HPJ - High-Rate Playback with NIMS and PWS at 134.4 Kbps - Deleted 3.9.14C HMA - High-Rate Science, 7perRim 400x788 Imaging 3.9.14D HCA - High-Rate Science, 7per Rim 200x800 Compressed Imaging 3.9.14E HIS - High-Rate Science, 4perRIM 400x394 Summed Imaging 3.9.15 IM8 - High-Rate Science, 7perRIM 800x800 Imaging 3.9.15A AI8 - High-Rate Science, 26perRIM 400x400 Summed Imaging 3.9.16 PW8 - PWS Recorded at 806.4 Kbps - Deleted 3.9.17 IM4 - High-Rate Science, 7perRIM 800x800 Compressed Imaging 3.9.18 PW4 - PWS Recorded at 403.2 Kbps - Deleted 3.9.19 BPB - Backup Science, Playback - Deleted 3.9.20 MPR - Medium Rate Science, Probe Data - Deleted 3.9.21 KPR - Keep-alive Power On Reset 3.9.22 LMF - Launch Memory Failure 625-205, GLL-3-280, Phase 2 Telemetry Measurements and Data Formats 3.10 PACKETIZED TELEMETRY 3.10.1 Overview 3.10.2 Downlink Data Rates 3.10.3 Transfer Frame Format 3.10.4 Virtual Channel Data Unit (VCDU) Format 3.10.5 Telemetry Packet Formats 3.10.5.1 Engineering Packets 3.10.5.1.1 ENG1-Engineering Real-Time Data 3.10.5.1.2 ENG2-Engineering Data Playback 3.10.5.2 AACS Packets 3.10.5.2.1 AACS1-AACS Real-Time Data 3.10.5.2.2 AACS2-AACS Data Uncompressed PB 3.10.5.2.3 AACS3-AACS Data Compressed PB 3.10.5.2.4 AACS4-AACS Record Rate Chg Coverage 3.10.5.3 DDS Packets 3.10.5.3.1 DDS1-DDS Real-Time Data Packet 3.10.5.3.2 DDS2-DDS Data PB Packet 3.10.5.3.3 DDS3-DDS Record Rate Chg Coverage 3.10.5.4 EPD Packets 3.10.5.4.1 EPD1--EPD RT Data Packet 3.10.5.4.1.1 EPD1 (Rate Data) RT Packet 3.10.5.4.1.2 EPD1 (Event Data) RT Packet 3.10.5.4.2 EPD2--EPD Data PB Packet 3.10.5.4.3 EPD3--EPD RRCC Data Packet 3.10.5.5 HIC Packets 3.10.5.5.1 HIC1--HIC RT Rate, PHA & Status Data 3.10.5.5.2 HIC2--HIC Data PB Packet 3.10.5.5.3 HIC3--HIC RRCC Data Packet 3.10.5.6 EUV Packets 3.10.5.6.1 EUV1--EUV RT Data Packet 3.10.5.6.2 EUV2--EUV Data PB Packet 3.10.5.7 MAG Packets 3.10.5.7.1 MAG1--MAG RT Data Packet 3.10.5.7.2 MAG2--MAG PB Data Packet (Uncompressed) 3.10.5.7.3 MAG3--MAG PB Data Packet (Rice Compressed) 3.10.5.7.4 MAG4--MAG RRCC Data Packet 3.10.5.8 NIMS Packets 3.10.5.8.1 NIMS1-- NIMS Real-Time Data Packet 3.10.5.8.2 NIMS2--NIMS 11.52 Kbps Data PB Packet (Uncompressed) 3.10.5.8.3 NIMS3--NIMS 6.168 Kbps Data PB Packet (Uncompressed) 3.10.5.8.4 NIMS4--NIMS 2.592 Kbps Data PB Packet (Uncompressed) 3.10.5.8.5 NIMS5--NIMS 11.52 Kbps Data PB Packet (Rice Compressed) 3.10.5.8.6 NIMS6--NIMS 6.168 Kbps Data PB Packet (Rice Compressed) 3.10.5.8.7 NIMS7--NIMS 2.592 Kbps Data PB Packet (Rice Compressed) 3.10.5.8.8 NIMS Subpacket Types 3.10.5.8.8.1 NIMS PB Subpacket Format 0 Count 3.10.5.8.8.2 NIMS PB Subpacket Format 1 3.10.5.8.8.3 NIMS PB Subpacket Format 2 3.10.5.8.8.4 NIMS PB Subpacket Format 3 625-205, GLL-3-280, Phase 2 Telemetry Measurements and Data Formats 3.10.5.9 PLS Packets 3.10.5.9.1 PLS1--PLS Real Time Data Packet 3.10.5.9.2 PLS2-- PLS Data PB Packet (Uncompressed) 3.10.5.9.3 PLS3--PLS Data PB Packet (Rice Compressed) 3.10.5.9.4 PLS4--PLS RRCC Data Packet 3.10.5.10 PPRR Packets 3.10.5.10.1 PPR1--PPR Data Playback (Uncompressed) 3.10.5.10.2 PPR2--PPR Data PB Compressed Packet 3.10.5.10.3 PPR3--PPR Burst To Tape Data (Uncompressed) 3.10.5.10.4 PPR4--PPR Burst To Tape Compressed Packet 3.10.5.11 PWS High Rate Packets 3.10.5.11.1 PWH1--PWS High Rate Data Fill Packet 3.10.5.11.2 PWH2--PWS High Rate Data Playback (MPW) 3.10.5.11.3 PWH3--PWS High Rate Data Playback (MPP) 3.10.5.11.4 PWH4--PWS High Rate Data Playback (HPW) 3.10.5.11.5 PWH5-- PWS High Rate Playback (LPW) Data 3.10.5.12 PWS Low Rate Packets 3.10.5.12.1 PWL1--PWS Low Rate Data RT ECO 3.10.5.12.1.1 ICT Compression PWS Data Strip 3.10.5.12.2 PWL2--PWS Low Rate Data RT BCO Packet 3.10.5.12.3 PWL3--PWS Low Rate Data PB Packet 3.10.5.12.4 PLW4--PWS Low Rate RRCC Packet 3.10.5.13 SSI Packets 3.10.5.13.1 SSI1 - SSI Imaging Data ICT Packet 3.10.5.13.1.1 ICT Compressed Image Data Format 3.10.5.13.2 SSI2--SSI Image Data BARC Compressed 3.10.5.13.3 SSI3--SSI Housekeeping Data Packet 3.10.5.13.3.1 Standard Mode Housekeeping 3.10.5.13.3.2 2-1/3 Second Mode Housekeeping Packet 3.10.5.13.3.3 SSI Housekeeping Data Word 3.10.5.14 OPNAV Packets 3.10.5.14.1 OPN1--OPNAV R/T Extended Body Limb/Terminator Packet 3.10.5.14.2 OPN2--OPNAV R/T Star Window Data Pack 3.10.5.14.3 OPN3--OPNAV P/B Extended Body Limb/Terminator Packet 3.10.5.14.4 OPN4--OPNAV P/B Star Window Packet 3.10.5.15 UVS Packets 3.10.5.15.1 UVS1--UVS Real Time Data Packet 3.10.5.15.2 UVS2--UVS Data PB Packet (Uncompressed) 3.10.5.15.3 UVS3--UVS Data PB Packet Rice Compressed) 3.10.5.16 FILL Packet 3.10.6 Packetized Telemetry Operating Modes 3.10.6.1 Packetized Real- Time Data Operations 3.10.6.1.1 Real-Time Engineering (RTE) 3.10.6.1.2 Real-Time Science (RTS) 3.10.6.1.3 Real-Time Optical Navigation (RTO) 3.10.6.2 Playback Operations 3.10.6.3 Record Rate Change Coverage Operations GLL-3-280 Rev. D, Appendix D (PHASE 2) FIGURES Number Title 1 Functional Telemetry Data Flow Block Diagram 1A Internal Data Flow & Transmissions Overview (Phase 2) 2 Golay Code Block Construction - Deleted 3 TDM Telemetry Header 4 TDM Format Identifier 5 Spacecraft Clock (SCLK) 6 TDM ENG Frame 7 LRS Frame - Deleted 7A LPW Frame 7B LPR Frame - Deleted 7C LNR Frame 7D LPU Frame 7E BPT Frame 7G BDT Frame 7H EOTR Frame 7I BOTR Frame 8 MPW Frame 8A MPP Frame 9 MPB Frame - Deleted 10 XED Frame - Deleted 11 XCM Frame - Deleted 12 XPW Frame - Deleted 13 XPB Frame - Deleted 13A XRW Frame - Deleted 13B XPN Frame - Deleted 14 HIM Frame 15 HCM Frame - Deleted 15A HCJ Frame -Deleted 16 HPW Frame 17 HPB Frame - Deleted 17A HRW Frame - Deleted 17B HPJ Frame - Deleted 17C HMA Frame 17D HCA Frame 17E HIS Frame 18 IM8 Frame 18A AI8 Frame 19 PW8 Frame - Deleted 20 IM4 Frame - Deleted 21 PW4 Frame - Deleted 22 BPB Frame - Deleted 23 MPR Frame - Deleted 24 Intentionally Left Out 25 PKT Telemetry Transfer Frame Received On The Ground 26 PKT Telemetry Transfer Frame Generated On-Board S/C 27 Virtual Channel Data Unit, Fixed Size (446 Bytes) 28 Telemetry Packet, Variable Size (Maximum 519 Bytes) 29 Real-Time Data Flow 30 Playback Data/Process Paths GLL-3-280 Rev. D, Appendix D (PHASE 2) TABLES Number Title 1 GLL Telemetry Modes 1A GLL Telemetry Modes Record Formats 2 Allowable Combinations of Real-time and Record Formats 3 GLL TDM TLM Bit Rate Allocations (Kbps) 4 TDM Telemetry Header Format 5 TDM Format Identifier 6 Commutation Map Identifier (CMI) Assignment 7 Spacecraft Clock (SCLK) Progression (1.2 Kbps and Higher TDM TLM) 7A Spacecraft Clock (SCLK) Progression (40 bps TLM 7B Spacecraft Clock (SCLK) Progression (16 bps TLM) - Deleted 7C Spacecraft Clock (SCLK) Progression (10 bps TLM 7D Spacecraft Clock (SCLK) Progression (8 bps TLM) - Deleted 7E Spacecraft Clock (SCLK) Progression (2 bps TLM) 8 ENG Format and Timings 9 EHR Subcommutation Index (SI) Progression 10 LRS Format - Deleted 10A LPW Format 10AA LPW SCLK Progression 10B LPR Format - Deleted 10C LNR Format 10D LPU Format 10E BPT Format 10F BPT SCLK Progressions 10G BDT Format 10H EOTR Format 10I BOTR Format 11 MPW Format 11a MRS SCLK Progression 11b MRS Frame & Embedded LPW Frame Relationship 11A MPP Format 12 MPB Format - Deleted 13 XED Format - Deleted 14 XCM Format - Deleted 15 XPW Format - Deleted 16 XPB Format - Deleted 16A XRW Format - Deleted 16B XPN Format - Deleted 17 HIM Format 17A HIM Image Data Structure 18 HCM Format - Deleted 18A HCJ Format - Deleted 19 HPW Format 20 HPB Format - Deleted 20A HRW Format - Deleted 20B HPJ Format - Deleted 20C HMA Format 20D HMA SSI Image Data Structure 20E HCA Format 20F HCA SSI Image Data Structure 625-205, GLL-3-280, Phase 2 Telemetry Measurements and Data Formats TABLES (Cont'd) Number Title 20G HIS Format 20H HIS SSI Image Data Structure 21 IM8 Format 22 SCLK Progression for Single MOD8 Interval 22a IM8 SSI Imaging Data Structure 22A AI8 Format 22B Deleted 22C AI8 SSI Imaging Data Structure 23 PW8 Format - Deleted 24 IM4 Format 24a IM4 SSI Imaging Data Structure 25 PW4 Format - Deleted 26 BPB Format - Deleted 27 MPR Format - Deleted 27a Summary of GLL PHASE 2 Data Compression Algorithms 28 GLL Telemetry Packet Summary Table 29 Commandable RTE/RTS Telemetry Configurations 30 Real-Time Science (RTS) Telemetry Mode Definitions GLL-3-280 Rev. D, Appendix D (PHASE 2) (Insert in 625-205, Galileo Orbiter Functional Requirements Book) APPENDIX D No. GLL-3-280 Appendix D to Revision D 15 August 1995 PHASE 2 FUNCTIONAL REQUIREMENT GALILEO ORBITER TELEMETRY MEASUREMENTS AND DATA FORMATS Revised and Rewritten _____________________________________________________ Custodian: ____________________ R. Johansen GLL-3-280 Rev. D, Appendix D (PHASE 2) ******************************************************************************************** * 12/21/94 CHANGE NOTES This first fully integrated issue of the GLL Phase 2 3-280 Telemetry Specification encompasses the sequential implementation of ECRs 35557, 35565, 35566, 35567, 35581, 35582, 35587 and 35593 to the 09/03/93 issue of the GLL Phase 1 3-280 Telemetry Specification. Because these ECRs resulted in changes to 80+ percent of the pages in the baseline 3-280 document, no change line indications have been utilized in this initial phase 2 3-280 release. ******************************************************************************************** * 08/15/95 This issue retires all versions for Appendix C and supersedes previous distribution for Appendix D. The major area of change in this update lies in Section 3.10 which provides the details of GLL Phase 2 Packetized Telemetry. Within 3.10 the sub-areas of interest are: p. D-90 thru D-98 - Overview and Downlink Descriptions p. D-99 thru D-137o - Detailed Packet Definitions p. D-137p thru D-137u - Operating Modes & Controls ******************************************************************************************** 02/23/96 This update package in addition to fixed decom changes and several typographical corrections, contains the changes required by the Phase 2A design as of this 02/23/96 date (see pages D-62A and D-62B). GLL-3-280 Rev. D, Appendix D (PHASE 2) 1.0 SCOPE This document establishes the Galileo (GLL) Phase 2 telemetry measurements and data formats. Included are functional requirements and descriptions of the telemetry format structure characteristics for Engineering, Science and Playback data. For the purpose of this document, Telemetry Handling is defined as those on-aboard functions required to prepare and process either science or engineering data for the GLL Phase 2 mission. 2.0 APPLICABLE DOCUMENTS The following documents form a part of this functional requirement. NOTE GLL-3-100, Galileo Orbiter Requirements and Constraints, applies to this document. Requirements of other GLL level 3 documents may also be applicable. It is the responsibility of the user to adequately acquaint himself with the organization and pertinent contents of the level 3 documents, as well as with the material contained herein. REQUIREMENTS Jet Propulsion Laboratory GLL-3-100 Functional Requirement, Galileo Orbiter Requirements and Constraints GLL-3-110 Functional Requirement, Galileo Orbiter Functional Block Diagram and Interface Listings GLL-3-290 Functional Requirement, Galileo Orbiter Command Structure and Assignments GLL-3-300 Functional Requirement, Galileo Orbiter Telecommunications GLL-3-310 Functional Requirement Galileo Orbiter Software Requirements DOCUMENTS Jet Propulsion Laboratory PD 625-53 End-to-End Information System PD 625-59 GLL/STS System Requirements Document GLL-3-280 Rev. D, Appendix D (PHASE 2) National Aeronautics and Space Administration NASA Planetary Program Flight/Ground Data System Standards Johnson Space Center ICD-2-1F001-002 Shuttle Orbiter/IUS Cargo Element Interfaces (GLL Annex) Lewis Research Center ICD-65-69001 Interface Control Drawing STS/IUS/GLL Spacecraft Ames Research Center JP-530 Probe System/Orbiter System Interface Specification 3.0 TELEMETRY SYSTEM FUNCTIONAL REQUIREMENTS 3.1 GENERAL The GLL Orbiter shall contain hardware and software to perform the telemetry functional requirements as defined in this document. The data flow block diagram, depicted in Figure 1, shows the functional flow of all Galileo Orbiter telemetry data. 3.1.1 Engineering Subsystems The Orbiter engineering subsystems consist of the following: Subsystem a. Structure subsystem (STRU) 01 b. Radio frequency subsystem (RFS) 02 c. Modulation demodulation subsystem (MDS) 03 d. Power/pyro subsystem (PPS) 04 e. Command and data subsystem (CDS) 06 f. Attitude and articulation control 07 subsystem (AACS) GLL-3-280 Rev. D, Appendix D (PHASE 2) National Aeronautics and Space Administration NASA Planetary Program Flight/Ground Data System Standards Johnson Space Center ICD-2-1F001-002 Shuttle Orbiter/IUS Cargo Element Interfaces (GLL Annex) Lewis Research Center ICD-65-69001 Interface Control Drawing STS/IUS/GLL Spacecraft Ames Research Center JP-530 Probe System/Orbiter System Interface Specification 3.0 TELEMETRY SYSTEM FUNCTIONAL REQUIREMENTS 3.1 GENERAL The GLL Orbiter shall contain hardware and software to perform the telemetry functional requirements as defined in this document. The data flow block diagram, depicted in Figure 1, shows the functional flow of all Galileo Orbiter telemetry data. 3.1.1 Engineering Subsystems The Orbiter engineering subsystems consist of the following: Subsystem a. Structure subsystem (STRU) 01 b. Radio frequency subsystem (RFS) 02 c. Modulation demodulation subsystem (MDS) 03 d. Power/pyro subsystem (PPS) 04 e. Command and data subsystem (CDS) 06 f. Attitude and articulation control 07 subsystem (AACS) GLL-3-280 Rev. D, Appendix D (PHASE 2) g. Cabling subsystem (CABL) 09 h. Retro Propulsion Module (RPM) 10 I. Temperature control subsystem 11 (TEMP) j. Mechanical devices subsystem (DEV) 12 k. Data memory subsystem (DMS) 16 l. S/X-band antenna subsystem (SXA) 17 m. Heavy ion counter (HIC) 28 n. X/S downconverter subsystem (XSDC) 42 o. Orbiter purge equipment (OPE) 71 Shuttle engineering subsystems consist of the following: Subsystem a. IUS -- b. Shuttle orbiter (SO) -- 3.1.2 Science Subsystems The GLL science subsystems consist of the following: Subsystem a. Plasma wave subsystem (PWS) 23 b. Extreme ultraviolet subsystem (EUV) 24 c. Energetic particles detector 25 subsystem (EPD) d. Photopolarimeter radiometer 27 subsystem (PPR) e. Dust detector subsystem (DDS) 29 f. Plasma subsystem (PLS) 32 g. Ultraviolet spectrometer subsystem 34 GLL-3-280 Rev. D, Appendix D (PHASE 2) (UVS) h. Magnetometer subsystem (MAG) 35 i. Solid state imaging subsystem (SSI) 36 j. Near infrared mapping spectrometer 37 subsystem (NIMS) k. Science calibration subsystem (SCAS) 40 l. DELETED FOR PHASE 2 m. DELETED FOR PHASE 2 3.1.3 Document Conventions Within this document, the following conventions are followed: a. All numbers shall be decimal (base 10) unless otherwise indicated. b. The leftmost bit in any group of bits shall be the most significant bit (MSB) and shall be assigned bit number 1. The rightmost bit in any group of bits is the least significant bit (LSB) and shall be assigned bit "N". Unless otherwise indicated, all data shall be transferred MSB first. c. The viewable portion of SSI data will start its numbering at Line 1 (first line) and will increment according to the image structure up to a maximum Line Number of 800. SSI prepare cycle lines which precede the viewable image will be numbered in a negative direction from the start of the viewable image data, i.e. Line 0 is the last image prepare cycle line, Line -1 is the one just before Line 0. 3.2 DATA MANAGEMENT The GLL Orbiter shall process the following types of data: a. Engineering b. Memory Read Out c. Low-Rate Science (LRS) d. Medium-Rate Science (MRS) e. DELETED FOR PHASE 2 f. High-Rate Science (HRS) g. DELETED FOR PHASE 2 GLL-3-280 Rev. D, Appendix D (PHASE 2) h. Playback (PB) i. Time Divisible Multiplexed Down-link (TDM) j. Packetized Downlink (PKT) 3.2.1 Engineering Data Engineering data are those measurements required to monitor the executing sequence, the status and performance of engineering subsystems, and the science instrument critical temperatures without prior knowledge of previous state. Redundant measurements for selected critical parameters shall be permitted. The priority in selecting engineering telemetry measurements for inclusion in the engineering frame is listed below. This order of priorities shall be used in the assignment of measurements to the downlink telemetry frames. a. Measurements necessary for flight operations or safety, such as S/C pointing, fault identification, and state vector for sequence verification. 1) Measurements that give positive indication of onboard status and actions (both hardware and software). 2) Measurements required for selecting between alternate modes of operation or redundant elements. b. Measurements of subsystem parameters directly affecting spacecraft system performance. c. Measurements necessary to evaluate the performance of subsystems not previously flown. d. Measurements necessary to evaluate the performance of a subsystem previously flown. 3.2.2 Memory Readout Data Memory readout data is the data derived from the memories of the command and data subsystem (CDS), attitude and articulation control subsystem (AACS), or from the science subsystems. 3.2.3 Low-Rate Science (LRS) Data Low-Rate Science Data consists of engineering, all fields and particles, UVS, EUV, and PPR science instrument sensor data, instrument status/housekeeping data and scan platform pointing vectors. Critical instrument temperatures, used to monitor the instrument health, are located in the engineering data frame. The Low-Rate Science also provide modest amounts of hi-rate PWS and NIMS data in some formats. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.2.4 High-Rate Science (HRS) Data High-Rate Science Data shall consist of LRS Data, all data produced by the solid state imaging (SSI) and the near infrared mapping spectrometer (NIMS) subsystems and one format with extended hi-rate PWS coverage. 3.2.5 Intermediate-Rate Science (XRS) Data DELETED FOR PHASE 2 3.2.6 Medium-Rate Science (MRS) Data Medium-Rate Science data shall consist of LRS Data and hi-rate PWS, with and without NIMS. 3.2.7 S-band Back-up Science (BUS) Data DELETED FOR PHASE 2 3.2.8 Playback (PB) Data Playback data shall consist of any and all data that can be recorded to the Spacecraft DMS recorder. 3.3 DATA ACQUISITION All data generated by engineering or science subsystems shall be initially routed to the CDS for conditioning and processing before being sent to the IUS Connector Port, the modulation/demodulation subsystem (MDS) telemetry modulation unit (TMU), and/or the data memory subsystem (DMS). 3.3.1 Analog Engineering Measurement Resolution Each temperature and (0-3 volt) analog engineering measurement converted to a digital number within the CDS shall result in an 8-bit word with a data number (DN) ranging from 0 to 255. Therefore, each measurement digitized by the CDS shall have a maximum resolution of 1/256 (0.39%). 3.3.2 Analog Engineering Measurement Accuracy The accuracy with which the CDS shall convert each temperature and (0-3 volt) analog engineering measurement into an 8-bit digital number shall be as specified below: a. Standard Range Temperature Measurement (-78 deg. C to +100 deg. C): + 3% (of full scale) + 1/2 DN GLL-3-280 Rev. D, Appendix D (PHASE 2) b. Electrostatic Discharge Protected Temperature Measurement (-102 deg. C to +74 deg. C): + 4% (of full scale) + 1/2 DN c. Other Temperature Measurements (special ranges): + 5% (of full scale) + 1/2 DN d. Other Analog Measurements: + 1% (of full scale) + 1/2 DN 3.4 DATA FLOW AND TRANSMISSION Figure 1A gives an overview of the internal data flows and transmission options for the Phase 2 GLL Spacecraft. The major new item for Phase 2 is the addition of the Packetized TLM (See right side of diagram). Secondarily, the TDM downlink has been reduced to four modes, two of which (1200 bps EHR and 7.68 Kbps LPB) are expected to be exercised only in the GLL Testbed. The details of the spacecraft's TDM-based formats (the TDM real-time and the TDM-based recording formats) are described in Section 3.9; Details of the new PKT telemetry operation and formats follow in Section 3.10. The GLL Orbiter shall be capable of data transmission under one or more of the following basic modes: a. Deleted b. Deleted c. Deleted d. Deleted e. Via a low-rate channel over S-band. f. Via a high-rate channel over S-band. g. Via the IUS Connector for access by the GLL Testbed. 3.4.1 STS Attached Phase Deleted 3.4.2 STS Detached Phase Deleted GLL-3-280 Rev. D, Appendix D (PHASE 2) b. Electrostatic Discharge Protected Temperature Measurement (-102 deg. C to +74 deg. C): + 4% (of full scale) + 1/2 DN c. Other Temperature Measurements (special ranges): + 5% (of full scale) + 1/2 DN d. Other Analog Measurements: + 1% (of full scale) + 1/2 DN 3.4 DATA FLOW AND TRANSMISSION Figure 1A gives an overview of the internal data flows and transmission options for the Phase 2 GLL Spacecraft. The major new item for Phase 2 is the addition of the Packetized TLM (See right side of diagram). Secondarily, the TDM downlink has been reduced to four modes, two of which (1200 bps EHR and 7.68 Kbps LPB) are expected to be exercised only in the GLL Testbed. The details of the spacecraft's TDM-based formats (the TDM real-time and the TDM-based recording formats) are described in Section 3.9; Details of the new PKT telemetry operation and formats follow in Section 3.10. The GLL Orbiter shall be capable of data transmission under one or more of the following basic modes: a. Deleted b. Deleted c. Deleted d. Deleted e. Via a low-rate channel over S-band. f. Via a high-rate channel over S-band. g. Via the IUS Connector for access by the GLL Testbed. 3.4.1 STS Attached Phase Deleted 3.4.2 STS Detached Phase b. Deleted GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.4.3 Low Rate Channel The low-rate channel (40 bps only) functions on S-band only and transmits real- time Low-rate Snapshot Engineering (ESS) data exclusively. It is possible to remove low-rate channel telemetry modulation from the downlink by CDS command to the MDS. The low-rate channel is uncoded. 3.4.4 High-Rate Channel The high-rate channel shall be the primary mode of data transmission during the mission. This channel may contain any of the following types of data: a. TDM format DMS-recorded Low-Rate Science (LRS) data. b. TDM format DMS-recorded Medium-Rate Science (MRS) data. c. DELETED FOR PHASE 2 d. TDM format DMS-recorded High-Rate Science (HRS) data. e. TDM format DMS-recorded CDS-Internal Data (CID). f. TDM format Real-time 10 bps Engineering (ELS). g. TDM format Real-time 1200 bps Engineering (EHR). h. DELETED FOR PHASE 2 i. Deleted j. TDM format Real-time 40 bps Engineering (ESS). k. DELETED FOR PHASE 2 l. DELETED FOR PHASE 2 m. Packetized format Real-time Engineering (RTE). n. Packetized format Real-time Science (RTS). o. Packetized format Real-time Optical Navigation (RT OPNAV). p. Packetized format Optical Navigation (PB OPNAV). q. Packetized format General Playback (PB). GLL-3-280 Rev. D, Appendix D (PHASE 2) It shall be possible to remove high-rate channel telemetry modulation from the downlink by CDS command to the MDS. The telemetry rates and modes available on the high rate channel shall be as specified in paragraph 3.8 herein. All TDM data on the high-rate channel shall employ a constraint length = 7, rate = 1/2 convolutional code and shall operate on S-band. All Packetized data on the high-rate channel shall employ an additional coding in addition to that described for the TDM data in the form of Reed-Solomon, and convolutional code (constraint length K = 11, R=1/2). Transition density requirements shall be met in order to permit Ground decoding as specified in GLL-3-300, Telecommunications and GLL-3-100, Requirements and Constraints. 3.5 DATA PROCESSING The GLL Orbiter contains a number of on-board computers, peripheral processors and analog or digital interfaces. Collectively these computers, processors, and interfaces shall be defined as the GLL Orbiter data system. Each of the on-board processors shall be assigned dedicated functions described in the following paragraphs and in GLL-3-310, Software Requirements. 3.5.1 Science Subsystem Processor Telemetry Functions Except for selected subsystem temperature measurements processed by the CDS, each science subsystem shall be responsible for its data collection, analog to digital (A/D) conversion, processing, formatting, and buffering. The instrument data shall be output under control of the CDS. General science subsystem telemetry data requirements shall include the following items: a. All status/housekeeping data needed to monitor the subsystem status and sequence performance in real-time shall be placed at the start of the subsystem's bit allocation in each telemetry frame and shall have a deterministic relationship to the spacecraft clock. b. Science sensor data shall be output in at least one known format within the instruments bit allocation. c. The low rate science data frame shall include status information for all science instruments (including the high rate science instruments whose data may not exist in the low rate science frame). GLL-3-280 Rev. D, Appendix D (PHASE 2) d. Each science instrument shall output sufficient status/housekeeping to determine all critical and/or controllable instrument performance states or parameters (including mode, memory checksums, processor self-test results, counters for commands accepted, bus parity errors detected, rejected commands, entries to fault routines, last command received, time of last sync discrepancy, voltages, currents, power on reset). All status values shall represent an absolute value (rather than change). All mode identification status shall precede or be concurrent with the output of the sensor data to which it refers. e. Instrument data taking cycles shall be governed by and synchronous to the following equation: n t = m t s i where: tS = Science instrument cycle time ti = Imaging (SSI) picture frame time (60-2/3 seconds) n = 1, 2, 3 .......... n m = 1, 2, 3, 4, 5 f. All instrument data mode changes shall occur when the downlink spacecraft clock MOD 91 is 0, 13, 26, 39, 52, 65, or 78 and the MOD10, and MOD8 are both zero. The data contained within the instrument downlink allocation shall be valid for the new mode beginning concurrently with the change to the new mode. 3.5.2 AACS Processor Telemetry Functions d. Except for selected subsystem temperature measurements processed by the CDS, the AACS shall be responsible for its data collection, A/D conversion, processing, formatting and buffering. The AACS data shall be output under control of the CDS from a buffer area in AACS memory. The data in this buffer will be updated once each minor frame (2/3 seconds) during RTI 0. The data contained in the buffer will include Low Rate Science (LRS) telemetry, fixed telemetry, and variable packet telemetry. The LRS data shall consist of the rotor and platform pointing vectors in Earth Mean Equator 1950.0 coordinates, rotor spin position angle in Ecliptic 1950.0 coordinates, cone and clock position in spacecraft relative coordinates, the rotor spin rate, and platform cone and cross cone rates. The LRS data shall be predicted ahead to the correct value for RTI 0. e. GLL-3-280 Rev. D, Appendix D (PHASE 2) d. Each science instrument shall output sufficient status/housekeeping to determine all critical and/or controllable instrument performance states or parameters (including mode, memory checksums, processor self-test results, counters for commands accepted, bus parity errors detected, rejected commands, entries to fault routines, last command received, time of last sync discrepancy, voltages, currents, power on reset). All status values shall represent an absolute value (rather than change). All mode identification status shall precede or be concurrent with the output of the sensor data to which it refers. e. Instrument data taking cycles shall be governed by and synchronous to the following equation: n t = m t s i where: tS = Science instrument cycle time ti = Imaging (SSI) picture frame time (60-2/3 seconds) n = 1, 2, 3 .......... n m = 1, 2, 3, 4, 5 f. All instrument data mode changes shall occur when the downlink spacecraft clock MOD 91 is 0, 13, 26, 39, 52, 65, or 78 and the MOD10, and MOD8 are both zero. The data contained within the instrument downlink allocation shall be valid for the new mode beginning concurrently with the change to the new mode. 3.5.2 AACS Processor Telemetry Functions Except for selected subsystem temperature measurements processed by the CDS, the AACS shall be responsible for its data collection, A/D conversion, processing, formatting and buffering. The AACS data shall be output under control of the CDS from a buffer area in AACS memory. The data in this buffer will be updated once each minor frame (2/3 seconds) during RTI 0. The data contained in the buffer will include Low Rate Science (LRS) telemetry, fixed telemetry, and variable packet telemetry. The LRS data shall consist of the rotor and platform pointing vectors in Earth Mean Equator 1950.0 coordinates, rotor spin position angle in Ecliptic 1950.0 coordinates, cone and clock position in spacecraft relative coordinates, the rotor spin rate, and platform cone and cross cone rates. The LRS data shall be predicted ahead to the correct value for RTI 0. GLL-3-280 Rev. D, Appendix D (PHASE 2) It shall be possible to remove high-rate channel telemetry modulation from the downlink by CDS command to the MDS. The telemetry rates and modes available on the high rate channel shall be as specified in paragraph 3.8 herein. All TDM data on the high-rate channel shall employ a constraint length = 7, rate = 1/2 convolutional code and shall operate on S-band. All Packetized data on the high-rate channel shall employ an additional coding in addition to that described for the TDM data in the form of Reed-Solomon, and convolutional code (constraint length K = 11, R=1/2). Transition density requirements shall be met in order to permit Ground decoding as specified in GLL-3-300, Telecommunications and GLL-3-100, Requirements and Constraints. 3.5 DATA PROCESSING The GLL Orbiter contains a number of on-board computers, peripheral processors and analog or digital interfaces. Collectively these computers, processors, and interfaces shall be defined as the GLL Orbiter data system. Each of the on-board processors shall be assigned dedicated functions described in the following paragraphs and in GLL-3-310, Software Requirements. 3.5.1 Science Subsystem Processor Telemetry Functions Except for selected subsystem temperature measurements processed by the CDS, each science subsystem shall be responsible for its data collection, analog to digital (A/D) conversion, processing, formatting, and buffering. The instrument data shall be output under control of the CDS. General science subsystem telemetry data requirements shall include the following items: a. All status/housekeeping data needed to monitor the subsystem status and sequence performance in real-time shall be placed at the start of the subsystem's bit allocation in each telemetry frame and shall have a deterministic relationship to the spacecraft clock. b. Science sensor data shall be output in at least one known format within the instruments bit allocation. c. The low rate science data frame shall include status information for all science instruments (including the high rate science instruments whose data may not exist in the low rate science frame). GLL-3-280 Rev. D, Appendix D (PHASE 2) d. Each science instrument shall output sufficient status/housekeeping to determine all critical and/or controllable instrument performance states or parameters (including mode, memory checksums, processor self-test results, counters for commands accepted, bus parity errors detected, rejected commands, entries to fault routines, last command received, time of last sync discrepancy, voltages, currents, power on reset). All status values shall represent an absolute value (rather than change). All mode identification status shall precede or be concurrent with the output of the sensor data to which it refers. e. Instrument data taking cycles shall be governed by and synchronous to the following equation: n t = m t s i where: tS = Science instrument cycle time ti = Imaging (SSI) picture frame time (60-2/3 seconds) n = 1, 2, 3 .......... n m = 1, 2, 3, 4, 5 f. All instrument data mode changes shall occur when the downlink spacecraft clock MOD 91 is 0, 13, 26, 39, 52, 65, or 78 and the MOD10, and MOD8 are both zero. The data contained within the instrument downlink allocation shall be valid for the new mode beginning concurrently with the change to the new mode. 3.5.2 AACS Processor Telemetry Functions Except for selected subsystem temperature measurements processed by the CDS, the AACS shall be responsible for its data collection, A/D conversion, processing, formatting and buffering. The AACS data shall be output under control of the CDS from a buffer area in AACS memory. The data in this buffer will be updated once each minor frame (2/3 seconds) during RTI 0. The data contained in the buffer will include Low Rate Science (LRS) telemetry, fixed telemetry, and variable packet telemetry. The LRS data shall consist of the rotor and platform pointing vectors in Earth Mean Equator 1950.0 coordinates, rotor spin position angle in Ecliptic 1950.0 coordinates, cone and clock position in spacecraft relative coordinates, the rotor spin rate, and platform cone and cross cone rates. The LRS data shall be predicted ahead to the correct value for RTI 0. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.5.3 CDS Processor Telemetry Functions 3.5.3.1 General. The CDS shall be responsible for the A/D conversion of all analog measurements, sampling digital and bi-level measurements attached to the CDS; collection, conversion, buffering, formatting CDS telemetry data; source error protection); collecting and formatting other subsystem data into telemetry frames for transmission to the DMS and/or to earth as specified in paragraphs 3.8, 3.9, and 3.10. The CDS shall output sufficient information such that detailed bit- level ground simulation of on-board events are not required for spacecraft sequencing or ground analysis of on-board activity. 3.5.3.2 Command Accountability. The following requirements shall apply to command transmission both from the ground to the Orbiter (Uplink) and from the CDS to the other subsystems (Onboard). 3.5.3.2.1 Uplink command accountability a) The following information about the last message received at the CDS shall be inserted into the downlink at least once in every Engineering major frame transmission. 1. Message number. 2. Message type. 3. Number of frames in message. 4. Presence or absence of start word error. 5. acceptance or rejection of message. b) In Orbiter system test, an echo of each uplink command bit shall be sent from the CDS to the CDS support equipment. c) Separate 8-bit counters for each function described below shall be downlinked at least once in every Engineering major frame transmission. 1. Uplink messages received and accepted (1 counter for each message type). 2. Uplink messages received and rejected. 3. Command frames detected in error. 4. Data frames corrected. 5. Uncorrectable data frames. 6. DAC rejected because of elapsed time. 7. DAC rejected because of invalid message number. 8. DAC rejected because of occupied buffer slot. 9. CDU lock changes. d) The active/inactive status of each DAC buffer slot shall be indicated in the downlink at least in once every full RIM transmission time. GLL-3-280 Rev. D, Appendix D (PHASE 2) e) The most recently commanded state of CDS critical controller registers and critical enable relays shall be placed in the downlink at least once in every Engineering major frame transmission. f) A list of messages found missing by the CDS from the last message sequence shall be downlinked at least once in every Engineering major frame transmission, or upon receipt of the terminator message of the message sequence. 3.5.3.2.2 Orbiter (Onboard) command accountability shall consist of: 1) Periodic readout counters for each of the following: a) Number of commands issued from stored CDS sequences b) Number of Real Time Commands c) Number of commands resulting from interactive requests from other Orbiter subsystems (i.e., error correction routines and alarms) d) Number of power code commands. e) Heart beat NOTE: counters must count commands as they are issued by the CDS 2) Identification of executing sequence elements. 3) Buffer for downlink transmission of the latest 16 commands distributed consisting of CCs, DCs, PCs, and the first four bytes of BCs issued to another subsystem. Prepared commands, spacecraft time and sector data commands shall not be buffered. Command activity which exceeds the buffering capability shall overwrite the oldest nontransmitted command. Error routine commands shall be included in the 16 buffer and shall be given priority over the other commands. There is no requirement to specially format or add fill for CC or DC commands. However, to ensure that commands are not written before downlinking, a lockout function shall be implemented when reading out a command. Commands from the active or primary HLM shall be input to the 16 command buffer unless a critical sequence is being executed from both HLMs, in which case commands from both HLMs should be input to the buffer. 3.5.4 Data Forms Data shall be presented to the CDS in either analog or digital form. Digital data may consist of discrete event pulses, bi-levels, or serial Non-Return to Zero (NRZ) data; except for data provided to the CDS over the data bus which shall be serial Return to Zero (RZ), and data sent to the CDS from the PWS and SSI via the high speed interfaces where the serial stream is split between two lines with data appearing in RZ format on each. Analog data shall consist of variable voltages. All analog engineering data shall be consistent with the ranges specified in paragraph GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.3 for the appropriate transducer. Data presented to the MDS or DMS shall be in the form of serial NRZ data, MSB first. Data presented to the CDS as analog voltages shall be converted to 8- bit digital words with leading zeros where the data does not fill all 8 bits. All status data shall represent absolute value (rather than change to previous value). 3.6 SOURCE ERROR PROTECTION CODING Long constraint length convolutional codings are applied to the down link telemetry to increase link margin at given downlink data rate. The nature of the convolutional code makes any error in the transmission bursty. Data interleaving and Reed Solomon (RS) encoding shall be used to provide an inner code for Error Detection and Correction. 3.6.1 Golay Coding Function DELETED FOR PHASE 2 3.6.2 Code Operation DELETED FOR PHASE 2 3.6.3 Interleaving Depth DELETED FOR PHASE 2 3.6.4 Reed Solomon Coding The data area of the transfer frame, consisting of four VCDUs (446 bytes each) and a 2-byte sequence counter, shall be interleaved to a depth of eight. The interleaved transfer frame shall be Reed-Solomon encoded. The eight codewords are: (255,161), (255, 245), (255, 225) (255, 195), (255, 2456), (255, 225), (255, 245). Refer to Figure 3.10.1 for details. 3.6.5 Convolutional Coding The Phase 2 convolutional code is applied in two steps: the CDS applies a (11, 1/2) code implemented in software to the Reed-Solomon encoded data, which produces 2 symbols for each bit. The MDS then applies a (7,1/2) convolutional code implemented in hardware to the encoded symbol and produces an equivalent (14,1/4) convolutional symbol stream. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.7 DATA STORAGE Data storage (DMS) shall be provided by a single digital tape recorder whose capacity is 9 x 10 8 bits. The Phase 2 GLL mostly utilizes the DMS recorder as an intermediate storage medium between the data acquisition and the extensive on-board processing that prepares the packetized down-link to the ground. As such, the DMS will be subject to on-board data recoveries requiring short-length tape positionings in both backward and forward directions. 3.7.1 Data Recording The DMS shall be capable of recording at any of the following data rates on command from the CDS. a) 806.4 kbps b) 403.2 kbps c) 115.2 kbps d) 28.8 kbps e) 7.68 kbps 3.7.2 Data Playback The DMS shall be capable of playing back data to the CDS at any of the following rates on command from the CDS. a) DELETED FOR PHASE 2 b) DELETED FOR PHASE 2 c) DELETED FOR PHAS GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.8 TDM TELEMETRY MODES AND RATES The TDM real-time and record formats shall be as shown in Tables 1 and 1A. These tables provide telemetry name, data rates, the 5-bit code that identifies it and a general description. Each data frame contains two of these ID codes, one for the real-time format and one for the record format; Together these two codes define the operating TDM Telemetry Mode. Table 2 shows the allowable operational modes, i.e. the allowable combinations of TDM real-time and record formats. Packetized Telemetry Modes and Rates are documented in 3.10. 3.8.1 Engineering Telemetry Modes It shall be possible to generate engineering data frames at 2, 10, 40, or 1200 bps rates and to transmit them in real-time (Note: 1200 bps engineering only to be available at the IUS Connector in the GLL Testbed). Additionally, it shall be possible to record engineering data at 1200 bps by including it as an integral part of other telemetry formats that are recordable. In the GLL Testbed, the EHR 1200 bps engineering mode available at the IUS Connector shall be used during Phase 2 System Test and Flight Sequence qualifications. As an embedded item in most of the recorded formats, the 1200 bps engineering shall be used in spacecraft operations for in-flight performance monitoring and as an aid in the diagnosing anomalies. It shall be possible to transmit at 2 bps every 600th frame of the 1200 bps engineering. This 2 bps transmission shall be known as "Engineering Extremely Low Rate Snapshot". The 2 bps coded telemetry (EXS) shall only be transmitted over the high rate channel as an element of the Packetized telemetry (2 bps RTE). It shall be possible to transmit at 10 bps every 120th frame of the 1200 bps engineering. This 10 bps transmission shall be known as "Engineering Low Rate Snapshot". The 10 bps coded telemetry can be transmitted over the high rate channel as TDM telemetry (ELS) or as an element of the Packetized telemetry (10 bps RTE). The capability to transmit the engineering data as 10 bps TDM telemetry shall be available using real time commands from the ground.E 2 d) 7.68 kbps GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 1. GLL TDM (Real-Time) Telemetry Formats Mnemonic Downlink Data Rate Primary Data Type Bits 1-5 of FTD Reference Paragraph NONE N/A No TDM data being generated N/A N/A ELS ESS #* EHR 10 bps 40 bps 1200 bps Engineering 10 bps snapshot of 1200 bps engineering data 40 bps snapshot of 1200 bps engineering data Engineering data at 1200 bps 1 1 1 1 0 1 1 1 0 1 0 0 0 0 1 3.9.3 3.9.3 3.9.3 Low Rate Science None Medium Rate Science None Intermediate Rate Science None High Rate Science None * LPB 7.68 Kbps Recorder Playback Serial bit-for-bit recorder playback at 7.68 Kbps 0 0 0 0 0 N/A KPR LMF 40 bps 600 bps Miscellaneous Keep-alive power on reset mode (alternate 1's and 0's) Keep-alive power on reset mode (indeterminate data)N/A N/A 3.9.21 3.9.22 ? - Intended for Testbed use only # - IUS Connector full-time format also GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 1A. GLL Telemetry Record Formats Mnemonic Data Rate to DMS Primary Data Type Bits 12-16 of FTD Reference Paragraph NONE N/A No data being recorded 0 0 0 0 0 N/A BDT 7.68 Kbps CDS-Internal Buffer Dump to Tape - fixed structure, format and content are internal to CDS operation 0 1 0 0 1 3.9.4F LPW 7.68 Kbps Low Rate Science Low Rate Science (incl Eng) at 4.944 Kbps and hi- rate PWS at 2.592 Kbps 1 0 0 1 1 (See Note)3.9.4A LNR 7.68 Kbps Low Rate Science (incl Eng) at 4.944 Kbps and NIMS at 2.592 Kbps 0 0 0 11 3.9.4C LPU 7.68 Kbps NIMS at 6.168 Kbps, UVS at 1.008 Kbps, PPR at 216 bps and AACS P&R at 144 bps 0 0 1 0 0 3.9.4D BPT 7.68 Kbps (effectively 274.29 bps)PPR Burst to Tape - PPR and 1/6th AACS from 14 LPW frames (effectively PPR at 216 bps, AACS Posn at 48 bps)0 1 0 0 0 3.9.4E MPW 28.8 Kbps Medium Rate Science LPW(Eng) at 7.68 Kbps, NIMS at 11.52 Kbps, and PWS at 7.68 Kbps 1 0 1 0 0 3.9.5 MPP 28.8 Kbps LPW(Eng) at 7.68 Kbps, and PWS at 19.2 Kbps 0 1 1 1 0 3.9.5A Intermediate Rate Science None ? Note: Hex 13 is the LPW FID value for Phase 2 recording; Phase 1 recordings retrieved by Phase 2 FSW will encounter an LPW FID value of hex 1B. GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 1A. GLL Telemetry Record Formats (Cont'd) Mnemonic Data Rate to DMS Primary Data Type Bits 12-16 of FTD Reference Paragraph HPW HIM HMA HCA HIS 115.2 Kbps 115.2 Kbps 115.2 Kbps 115.2 Kbps 115.2 Kbps High Rate Science 1/10th LPW(Eng) at 7.68 Kbps, NIMS at 11.52 Kbps, and PWS at 94.56 Kbps 1/10th LPW(Eng) at 7.68 Kbps, NIMS at 11.52 Kbps, and SSI at 94.56 Kbps (1perRIM 800x 788 images) 1/10th LPW(Eng) at 7.68 Kbps, NIMS at 11.52 Kbps, and SSI at 94.56 Kbps (2perRIM 400x 788 images) 1/10th LPW(Eng) at 7.68 Kbps, NIMS at 11.52 Kbps, and SSI at 94.56 Kbps (7perRIM 200x 800 compressed line images) 1/10th LPW(Eng) at 7.68 Kbps, NIMS at 11.52 Kbps, and SSI at 94.56 Kbps (4perRIM 400x 394 summed images)10 0 0 0 1 0 0 0 1 0 0 1 1 0 0 0 1 1 1 0 0 1 0 1 3.9.13 3.9.11 3.9.14C 3.9.14D 3.9.14E IM4 403.2 Kbps 1/80th LPW(Eng) at 7.68 Kbps, 1/8th NIMS at 11.52 Kbps, and SSI at 311.04 Kbps (7perRIM 800x800 compressed line images)1 1 0 0 1 3.9.17 IM8 AI8 806.4 Kbps 806.4 Kbps 1/80th LPW(Eng) at 7.68 Kbps, 1/8th NIMS at 11.52 Kbps, and SSI at 768.0 Kbps (7perRIM 800x800 images) 1/80th LPW(Eng) at 7.68 Kbps, 1/8th NIMS at 11.52 Kbps, and SSI at 768.0 Kbps (26perRIM 400x400 summed images)1 0 1 1 0 1 0 1 1 1 3.9.15 ? 3.9.15A GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 2. Allowable Combinations of Allowable Real-time/Record Formats R/T Format Rec Format * None ELS ESS LPB KPR LMF NCG None, LPW, LNR, LPU, BPT, BDT, MPW, MPP, HPW, HIM, HMA, HCA, HIS, IM4, IM8, AI8, NCG None, LPW, LNR, LPU, BPT, BDT, MPW, MPP, HPW, HIM, HMA, HCA, HIS, IM4, IM8, AI8, NCG None, LPW, LNR, LPU, BPT, BDT, MPW, MPP, HPW, HIM, HMA, HCA, HIS, IM4, IM8, AI8, NCG None None None None, LPW, LNR, LPU, BPT, BDT, MPW, MPP, HPW, HIM, HMA, HCA, HIS, IM4, IM8, AI8 # PKT None, LPW, LNR, LPU, BPT, BDT, MPW, MPP, HPW, HIM, HMA, HCA, HIS, IM4, IM8, AI8 * - Downlink telemetry data is not being radiated from S/C ? # - Packetized telemetry is being down-linked (See 3.10 for specific combinations of Packetized downlink formats) GLL-3-280 Rev. D, Appendix D (PHASE 2) It shall be possible to transmit at 40 bps every 30th frame of the 1200 bps engineering. This 40 bps transmission shall be known as "Engineering Snapshot". The 40 bps telemetry can be transmitted over the low rate channel as TDM telemetry (ESS) or over the hi-rate channel as an element of the Packetized telemetry (40 bps RTE). The capability to transmit the engineering data as 40 bps as TDM telemetry shall be available using real time commands from the ground. It shall be possible to transmit every frame of the 1200 bps engineering. This 1200 bps transmission shall be known as "Hi-rate Engineering". The 1200 bps coded telemetry (EHR) can only be real-time transmitted through the IUS Connector. The full EHR stream is an embedded item on all but three of the fifteen recordable TDM telemetry formats (See "ENG" column of Table 3). 3.8.2 Memory Readout Memory readout shall be accomplished by replacing a portion of the variable area data in the Engineering frame with any of the following: CDS memory readout data, the attitude and articulation control subsystem (AACS) memory data or the science subsystem memory data. 3.8.3 Science Telemetry Modes The Galileo Orbiter shall be capable of operation in the science telemetry modes as described in the following paragraphs. Table 3 summarizes the Science data bit allocations provided by each of the TDM telemetry formats. 3.8.3.1 Low-Rate Science (LRS) . Three of the four LRS telemetry modes shall be used for real-time acquiring of data at 7.68 Kbps with the option of concurrently recording the data to the DMS recorder. The fourth mode, BPT, gathers data at 1/14 of the 7.68 Kbps rate and once a CDS internal buffer (nominally 12K bytes) is filled, the data in frames is (again optionally) written to the DMS recorder at 7.68 Kbps until the accumulate buffer has been emptied down to the last full BPT data frame. The LPW and LNR modes shall contain the fields and particles experiment data, AACS Position/Rate data, the full 1200 bps EHR engineering data, and a section of hi-rate science data (hi-rate PWS for LPW, and hi-rate NIMS for LNR). The LPW format is included in all of the TDM telemetry modes that operate at rates higher than 7.68 Kbps, i.e., all of the MRS and HRS telemetry modes. The third LRS mode, LPU, is a specialized NIMS-intensive (82% of data space) with PPR and AACS Position-only (no engineering) format. GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 3. (See Library for hard copy Pg D-37) GLL-3-280 Rev. D, Appendix D (PHASE 2) The fourth LRS mode, BPT, accumulates PPR and AACS Position Data to an internal buffer (at 274.3 bps) and upon buffer fill, writes the buffer contents in an LRS physically compatible format (5120 bits at 7.68 Kbps) to the DMS recorder. 3.8.3.2 Medium-Rate Science (MRS). The two MRS telemetry modes shall be used for real-time acquiring of data at 28.8 Kbps with the option of concurrently recording the data to the DMS recorder. Both MRS data modes contain LPW data at 7.68 Kbps and hi-rate PWS at 7.68 Kbps; Of the two modes, one contains an additional 11.52 Kbps of hi-rate PWS and the other contains 11.52 Kbps of NIMS. 3.8.3.3 Intermediate-Rate Science (XRS). DELETED FOR PHASE 2 3.8.3.4 High-Rate Science (HRS). The eight HRS telemetry modes shall be used for real-time acquiring of data at 115.2 Kbps, 403.2 Kbps, and 806.4 Kbps with the option of concurrently recording the data to the DMS recorder. All eight contain LPW data at 7.68 Kbps and NIMS data at 11.52 Kbps. The additional contents of these modes are as follows: - 115.2 Kbps modes (5) : 94.56 Kbps of either hi-rate PWS or SSI imaging - 403.2 Kbps mode (1) : 372.44 Kbps of SSI imaging - 806.4 Kbps modes (2) : 768.0 Kbps of SSI imaging 3.8.3.5 Deleted 3.8.3.6 DELETED FOR PHASE 2 3.8.3A CDS-internal Telemetry Mode The is a single format in an LRS construct (5120 bits with writes to and reads from the DMS recorder at 7.68 Kbps) that the CDS uses to offload and re-access VCDUs whenever it needs to. 3.8.4 TDM Playback (PB) For the Phase 2 GLL Spacecraft, direct Playback from the DMS to the down-link is a single option of exercising the TDM LPB mode. This mode is a 7.68 Kbps bit- for-bit transmission of the DMS serial stream bits over the hi-rate channel. Because of transmission rate limitations of the spacecraft in flight, this capability will probably be exercised only in the GLL Testbed. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9 TDM TELEMETRY DATA FORMATS The details of the TDM telemetry formats are given in the following 3.9.X sections. Where it is considered relevant to the description being given for the TDM descriptions, those details of the Packetized telemetry will be provided in these 3.9.X sections (Example: the internal details & timings for the 2 bps Engineering) Full details of the GLL Packetized telemetry however are contained in the 3.10.X sections. 3.9.1 General The GLL TDM, i.e. real-time telemetry frames, are structured in accordance with the NASA Planetary Data Standards; specifically, a. All frame lengths shall be multiples of 16 bits. b. All data subsets within the frame shall be multiples of 8 bits. Unused bits shall be zero filled with the data portion right justified within the field. c. Frame synchronization codes shall be 32 bits. d. Convolutional Code (K = 7, R = 1/2) shall be used. e. Experimental convolutional Code (K=15, R=1/4) may be used during portions of the mission. Specifics of the GLL Packetized telemetry standards and conventions are provided in 3.10. In an attempt to track and to retain flexibility to change in the TDM structures, bit rate allocations among the various GLL subsystems are provided. This practice separately documents each subsystem's allocation in each of the TDM frame formats. All Orbiter and ground software shall be designed to easily accommodate changes to allocations and position in these formats. 3.9.2 TDM Header The first 96 bits of each TDM telemetry frame except KPR shall consist of those necessary fields which enable frame synchronization, identification, and decommutation of the received data. The format of the header is shown in Figure 3 and is described in greater detail by Table 4. The individual fields are described in paragraph 3.9.2.1 through 3.9.2.3. The KPR exception is described in paragraph 3.9.21. GLL-3-280 Rev. D, Appendix D (PHASE 2) FRAME SYNCHRONIZATION CODE I FORMAT IDENTIFICATION SPACECRAFT CLOCK (FSC) 32 (FID) 16 (SCLK) 48 Figure 3. TDM Telemetry Header Table 4. TDM Telemetry Header Format Bits Offset to Data Description Frame DatData Start Paragraph Frame Synchronization Code Format Identification Spacecraft Clock 32 16 48 0 32 48 3.9.2.1 3.9.2.2 3.9.2.3 3.9.2.2 3.9.2.1 TDM Frame Synchronization Code (FSC). The TDM frame synchronization code shall be comprised of 32 bits with the following pattern: MSB (Binary) 0000 0011 1001 0001 0101 1110 1101 0011 (Hexadecimal) 03915ED3 3.9.2.2 TDM Telemetry Format Identification (FID). Each TDM telemetry frame shall contain a format identification word which identifies the TDM data being processed and formatted by the Orbiter. All data within the frame shall be completely and unambiguously identifiable by the format identification, the S/C clock, and the pre-established frame commutation sequence. The data output concurrently with the change of the FID shall be immediately valid. The structure of the FID is shown in Figure 4 and described in greater detail in Table 5. GLL-3-280 Rev. D, Appendix D (PHASE 2) Real-time Identifier Memory Readout Commutation Map Identifier Map Sequence Number Record Identifier| 5 1 2 3 5 Figure 4. TDM Format Identifier Table 5. TDM Format Identifier Data Description Bits Allocated Offset to Data Start Paragraph Real-time identifier Memory Readout Commutation Map Identifier Map Sequence Number Record Identifier 5 1 2 3 5 0 5 6 8 11 3.9.2.2.1 3.9.2.2.2 3.9.2.2.3 3.9.2.2.4 3.9.2.2.5 3.9.2.2.1 TDM Real-time Identifier (RT) . Bits 1 through 5 shall indicate the active real-time TDM rate and format, as shown in Table 1. On all data being placed onto the DMS, this field shall contain all zeros. The real time identifier shall be permitted to change only when the MOD91 count is 0, 13, 26, 39, 52, 65, or 78 and the MOD10 and MOD8 counts are zero. 3.9.2.2.2 Memory Readout (MRO) . Bit 6 of the FID shall identify the fact that memory readout data has replaced the 56th through 90th bytes of the engineering frame. 0 = Normal engineering data is present 1 = Memory readout data is present Details of the Memory readout process are given in paragraph A2.3. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9.2.2.3 Commutation Map Identifier (CMI) . Bits 7 and 8 shall identify the commutation map currently being used to sample the S/C engineering subsystem data. The assignment of these bits shall be as shown in Table 6. The actual assignment of the mission phase commutation maps shall be to one of the four available map allocations. The commutation map shall identify the variable engineering packets, their timing relationships, and their placement into the engineering format. The details of these commutation maps are found in paragraph A2.2. In the event that any on-board detected anomaly occurs which is permitted to cause automatic changing of commutation maps, the change shall be to map 0. In the event that any on-board detected anomaly occurs which is permitted to cause automatic changing of commutation maps, the change shall be to map 0. The CMI shall change only concurrently with the start of a RIM cycle. Table 6. Commutation Map Identifier (CMI) Assignment Bits 7, 8 Commutation Map Identifier Assigned Map Purpose 00 01 10 11 0* 1 2 3 Anomaly Investigation Calibration Maneuvers Cruise/Encounter/ Orbital Operations *This CMI shall be used for any on-board detected anomaly which causes an automatic CMI change. 3.9.2.2.4 Map Sequence Number (MSN) . Bits 9 through 11 shall represent the number of times the specified commutation map (in bits 7-8) has changed since the map was loaded in the S/C memory. The contents of this field shall increment by one each time the map is used to transmit data in real-time where one or more changes have occurred since the last use of the map. The MSN shall change only concurrently with the start of a RIM cycle. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9.2.2.5 Record Identifier (REC) . Bits 12 through 16 shall indicate the rate and format of data being placed on to the DMS, as shown in Table 1. In the event there is no data being placed on the tape recorder, this field will contain all zeros. The Record Identifier shall be permitted to change only when the MOD91 count is 0, 13, 26, 39, 52, 65, or 78 and the MOD10 and MOD8 counts are zero. 3.9.2.2.6 R/T and REC Allowable Combinations . Allowable combinations of real- time and record identifiers are shown in Table 2. 3.9.2.3 Spacecraft Clock (SCLK). Each GLL telemetry frame shall contain a S/C time field. The SCLK shall have the characteristic that it can be directly used to determine time, identify all measurements, and to correlate events to within the time resolution of the S/C clock. The SCLK shall mark the first bit of the frame synchronization code time and shall represent the time interval in which the CDS collected the instrument data contained within the frame. The SCLK is shown in Figure 5 and is described in paragraphs 3.9.2.3.1 through 3.9.2.3.4. 1 24 25 32 33 40 41 48 REAL-TIME IMAGE COUNT (RIM) MOD 91 COUNT (MOD 91) MOD 10 COUNT (MOD 10) MOD 8 COUNT (MOD 8) Figure 5. Spacecraft Clock (SCLK) 3.9.2.3.1 Real-Time Image Count (RIM). This field is a 24 bit counter which shall be incremented each 60-2/3s (corresponding to a real-time image cycle). This clock shall keep unambiguous account of time for 32 years. The starting value of the counter shall be initialized at launch and shall not be reset after launch except from the ground after an interruption of power to the CDS memories. The maximum value of the SCLK shall not roll-over until attaining the value 16777215. 3.9.2.3.2 Mod 91 Count (MOD91). The MOD91 counter is an 8 bit counter which shall be incremented once every 2/3 s. This field shall range in value from 0 through 90, with 0 corresponding to the start of the real-time solid state imaging cycle. This field shall increment by one every LRS frame. 3.9.2.3.3 Mod 10 Count (MOD10). The MOD10 counter is an 8 bit counter which shall be incremented once each 66-2/3 msec. This field shall range from 0 through 9, with the change to zero synchronous to the incrementing of the MOD91 count. This field shall increment by l for each frame transmitted or recorded at a telemetry rate greater than 7.68 Kbps. The MOD10 count is synonymous with the Real-Time Interrupt (RTI) in the CDS. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9.2.3.4 Mod 8 Count (MOD8). The MOD8 counter is an 8 bit counter which shall be incremented once each 8-1/3 ms. The field shall range from 0 through 7. With the change to 0 synchronous to the incrementing of the MOD10 count. The MOD8 field shall normally be zero in any frame being created at telemetry rates less than or equaling 115.2 kb/s. For those frames being routed to the DMS at rates exceeding 115.2 kb/s, the counter shall increment by one for each frame placed onto the DMS. 3.9.2.3.5 Spacecraft Clock Progression. The SCLK shall increment as shown in Tables 7 through 7E for each of the various telemetry rates, except the KPR mode at 40 bps and the LMF mode at 600 bps. The KPR mode consists exclusively of alternate 1-0 data, i.e. no header; therefore, the SCLK progression of Table 7 does not apply to this mode. See 3.9.21 for additional detail. The LMF mode consists exclusively of indeterminate data, i.e. no header; therefore, the SCLK progression Table 7 does not apply to this mode. See 3.9.22 for additional detail. The 2 bps and 10 bps coded telemetries shall be enforced two MFs after the receipt of telemetry mode change command. The first engineering frame at 2 bps and 10 bps will be the current MOD91 position within the RIM. GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 7. Spacecraft Clock (SCLK) Progression (1.2 Kbps and Higher TDM TLM) Minor Frame Time Telemetry Rate** (kb/s) Real-Time Record RIM MOD91 MOD10 MOD8 2/3 sec 1.20 7.68 #Yes NO Yes* Yes I i+1 0,1,...,90 0,1,...,90 0 0 0 0 1/15 sec 28.8 115.2 No No Yes Yes i i+1 . . i . i 90 0 . . 1 . 0 0,1,...,9 0,1,...,9 0,1,0 0 0 1/120 sec 403.2 806.4 No No Yes Yes i I . . . i i . . . i i+1 0 0 . . . 0 1 . . . 90 0 0 1 . . 9 0 . . . 9 0 0,1,...,7 0,1,...,7 . . . 0,1,...,7 0,1,...,7 . . . 0,1,...,7 0,1,...,7 ? To tape recorder as an embedded element of most higher rate streams ** 600 b/s rate (LMF mode) described in 3.9.2.3.5 # IUS connector only GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 7A. Spacecraft Clock (SCLK) Progression (40 bps TLM) Minor Frame Time Telemetry Rate (kb/s) Real-Time Record RIM (Modulo 30) MOD91 MOD10 MOD8 20 sec 0.040*** #Yes No 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 0,30,60,90 29, 59, 89 28, 58, 88 27, 57, 87 26, 56, 86 25, 55, 85 24, 54, 84 23, 53, 83 22, 52, 82 21, 51, 81 20, 50, 80 19, 49, 79 18, 48, 78 17, 47, 77 16, 46, 76 15, 45, 75 14, 44, 74 13, 43, 73 12, 42, 72 11, 41, 71 10, 40, 70 9, 39, 69 8, 38, 68 7, 37, 67 6, 36, 66 5, 35, 65 4, 34, 64 3, 33, 63 2, 32, 62 1, 31, 61 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 *** - KPR mode exception described in 3.9.2.3.5 % - Real-time for both TDM and Packetized RTE Returns ? NOTE: TABLE 7B HAS BEEN DELETED FOR PHASE 2. GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 7C. Spacecraft Clock (SCLK) Progression (10 bps TLM) Minor Frame Time Telemetry Rate (kb/s) Real-Time Record RIM (Modulo 120) MOD91 MOD10 MOD8 80 sec 0.010 % Yes No n + 0 * n + 1 n + 2 n + 3 n + 5 n + 6 n + 7 n + 9 n + 10 n + 11 n + 13 n + 14 n + 15 n + 17 n + 18 n + 19 n + 21 n + 22 n + 23 n + 25 n + 26 n + 27 n + 29 n + 30 n + 31 n + 32 n + 34 n + 35 n + 36 n + 38 n + 39 n + 40 n + 42 n + 43 n + 44 n + 46 n + 47 n + 48 n + 50 n + 51 n + 52 n + 54 n + 55 n + 56 n + 58 n + 59 0 29 58 87 25 54 83 21 50 79 17 46 75 13 42 71 9 38 67 5 34 63 1 30 59 88 26 55 84 22 51 80 18 47 76 14 43 72 10 39 68 6 35 64 2 31 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ? * - RIM and MOD91 are asynchronous for 10bps ELS % - Real-time for both TDM and Packetized RTE Returns GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 7C. Spacecraft Clock (SCLK) Progression (10 bps TLM) (Cont'd) Minor Frame Time Telemetry Rate (kb/s) Real-Time Record RIM (Modulo 120) MOD91 MOD10 MOD8 80 sec (co nt) 0.010 % Yes No n + 60 n + 61 n + 63 n + 64 n + 65 n + 67 n + 68 n + 69 n + 71 n + 72 n + 73 n + 75 n + 76 n + 77 n + 79 n + 80 n + 81 n + 83 n + 84 n + 85 n + 87 n + 88 n + 89 n + 90 n + 92 n + 93 n + 94 n + 96 n + 97 n + 98 n + 100 n + 101 n + 102 n + 104 n + 105 n + 106 n + 108 n + 109 n + 110 n + 112 n + 113 n + 114 n + 116 n + 117 n + 118 60 89 27 56 85 23 52 81 19 48 77 15 44 73 11 40 69 7 36 65 3 32 61 90 28 57 86 24 53 82 20 49 78 16 45 74 12 41 70 8 37 66 4 33 62 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ? NOTE: TABLE 7D HAS BEEN DELETED FOR PHASE 2. GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 7E. Spacecraft Clock (SCLK) Progression (2bps TLM) Minor Frame Time Telemetry Rate (kb/s) Real-Time Record RIM (Modulo 600) MOD91 MOD10 MOD8 400 sec 0.002 # Yes No n + 0* n + 6 n + 13 n + 19 n + 26 n + 32 n + 39 n + 46 n + 52 n + 59 n + 65 n + 72 n + 79 n + 85 n + 92 n + 98 n + 105 n + 112 n + 118 n + 125 n + 131 n + 138 n + 145 n + 151 n + 158 n + 164 n + 171 n + 178 n + 184 n + 191 n + 197 n + 204 n + 210 n + 217 n + 224 n + 230 n + 237 n + 243 n + 250 n + 257 n + 263 n + 270 n + 276 n + 283 n + 290 n + 296 0 54 17 71 34 88 51 14 68 31 85 48 11 65 28 82 45 8 62 25 79 42 5 59 22 76 39 2 56 19 73 36 90 53 16 70 33 87 50 13 67 30 84 47 10 64 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ? * - RIM and MOD91 are asynchronous for 2bps EXS # - Real-time for Packetized RTE Return only; there is no TDM EXS GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 7E. Spacecraft Clock (SCLK) Progression (2 bps TLM) (Cont'd) Minor Frame Time Telemetry Rate (kb/s) Real-Time Record RIM (Modulo 600) MOD91 MOD10 MOD8 ? 400 sec (cont) 0.002 # Yes No n + 303 n + 309 n + 316 n + 232 n + 329 n + 336 n + 342 n + 349 n + 356 n + 362 n + 369 n + 375 n + 382 n + 389 n + 395 n + 402 n + 408 n + 415 n + 421 n + 428 n + 435 n + 441 n + 448 n + 454 n + 461 n + 468 n + 474 n + 481 n + 487 n + 494 n + 501 n + 507 n + 514 n + 520 n + 527 n + 534 n + 540 n + 547 n + 553 n + 560 n + 567 n + 573 n + 580 n + 586 n + 593 27 81 44 7 61 24 78 41 4 58 21 75 38 1 55 18 72 35 89 52 15 69 32 86 49 12 66 29 83 46 9 63 26 80 43 6 60 23 77 40 3 57 20 74 37 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9.3 ENG - Engineering The ENG frame shall be the carrier of S/C engineering data and the carrier of a selected subset of the GLL Science engineering data. ENG frames can reach the ground in two forms, that of the TDM (Time Divisible Multiplexed) modes and that of the PKT (Packetized) mode. Except for having different frame headers, the TDM and PKT Engineering data frames have identical formats and contents. While the details of Packetized telemetry are given in 3.10, some information (most notably the 2 bps ENG which is a PKT only capability) is included in the following 3.9.3 section where comparisons (timings, etc.) to the TDM telemetry are relevant. The schematic of the ENG frame in its TDM (Time Division Multiplexed) form is shown in Figure 6 and described in greater detail in Table 8. HEADER 96 ENGINEERING DATA 704 Figure 6. TDM ENG Frame Table 8. ENG Format & Timings Data Description Bits Frame Bits <-------- sec -------> * 2 10 40 1200 Offset to Start of Data Paragraph Header Engineering 96 704 800 0.24 1.76 2.00 1.2 8.8 10.0 4.8 35.2 40.0 144 1056 1200 0 96 3.9.2 A2.2 Frame time (seconds) = 400 80 20 0.666 2/3 ? * - Packetized telemetry only GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9.3.1 Source. The ENG frame shall exist in the downlink telemetry as a result of: a. Being transmitted as TDM TLM in real-time at 10 bps or 40 bps on the S-band hi-rate channel of the MDS b. Being transmitted as TDM TLM in real-time at 40 bps on the S-band low rate channel of the MDS c. Being transmitted as TDM TLM in real-time at 1200 bps on the IUS hardline connector (Note: The real-time FID in the frame header is not a valid EHR indicator for this data path) d. Being real-time encoded at 2 bps, 10 bps or 40 bps into Packetized telemetry and then being transmitted on the hi-rate channel of the MDS e. Being played back from the DMS recorder (having been previously recorded as an embedded 1200 bps stream within the LPW, LNR, MPW, MPP, HPW, HIM, HMA, HCA, HIS, IM4, IM8 or AI8 TLM data frames). This playback can take the two following forms: 1) CDS retrieval, then packaged, que'ed, and transmitted as Packetized Playback data on the S-band hi-rate channel of the MDS 2) direct playback at 7.68 Kbps (LPB TDM TLM mode) on the S-band hi-rate channel of the MDS 3.9.3.2 Contents. Each engineering frame shall contain data of the following types: a. Engineering subsystem analog, digital, and software measurements. b. Spacecraft system level status measurements. c. Selected science subsystem analog, digital, and software measurements. 3.9.3.3 Spacecraft Clock Progression. SCLK values for successive EHR frames shall increment as shown in Table 9 below. Note that the Subcommutation Index (SI) always equates to the SCLK MOD91 value. Table 9. EHR Subcommutation Index (SI) Progression SI RIM MOD91 MOD10 MOD8 0 1 2 . . . 90 i i i . . . i 0 1 2 . . . 90 0 0 0 0 0 0 0 0 0 0 0 0 0 0 SI = MOD91 SCLK sequences for the Snapshot Engineering modes are given in Tables 7A, 7C, and 7E for modes ESS, ELS, and EXS, respectively. 3.9.3.4 ENG Stream Characteristics. ? The 40 bps ENG stream (ESS) exists in real-time as a series of "plucked" frames taken from the CDS's internally maintained 1200 bps stream of EHR frames. After transmission at 40 bps, the standing available EHR ENG frame is "plucked" as the next ESS frame to be transmitted. This TLM mode is labelled "Snapshot Engineering". In GLL-3-280 Rev. D, Appendix D (PHASE 2) this mode, every 30th EHR frame can be downlinked either as a TDM stream or as an RTE element of the Packetized telemetry. Similarly, a 10 bps ENG stream exists in real-time (ELS) as a series of frames that are "plucked" at an every 120th rate from the 1200 bps EHR stream. This stream is labelled "Low-rate Snap-shot Engineering", and like the ESS stream, it can be downlinked either as a TDM stream or as an element of the RTE Packetized telemetry. A 2 bps option (EXS for "Extremely Low-rate Snap-shot" ?) exists in real-time only for the Packetized Telemetry path. At 2 bps, every 600th EHR frame is "plucked" and packaged for the downlink. For all three Snap-shot options, the receipt of 91 consecutive transmitted frames will provide a complete read-out of the Engineering Commutator. For the ESS, ELS, and EXS modes, the completed Commutator read-out will take 30m20s, 2h1m20s, and 10h6m40s, respectively. 3.9. 4 LRS - Low-Rate Science DELETED FOR PHASE 2 3.9.4A LPW - Low-Rate Science plus PWS The LPW frame shall be a carrier of the low-rate science and housekeeping data, engineering data at 1200 bps, and hi-rate PWS data at 2.592 Kbps. The schematic of the LPW frame is shown in Figure 7A and described in greater detail in Table 10A. The frame is identical to the prior phase LRS format except for hi-rate PWS data supplanting the four 432-bit fields of Golay coding in the LRS format. LPW is a record-only format. |ENGI- | | | | | | | | | | | | | | | | | | |NEER- | | | SSI | | NIMS | | | CODED | | | | | | | | | | HEADER |ING |UVS |HIC |STATUS |PLS |STATUS | PWS | DDS|RESERVE |EPD |PWS|EPD |PPR |MAG |PWS |MAG |PWS|AACS| PWS | | / | | | | | | | | | | | | | | |(LR) | | | |EUV | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 96 | 704 |672 | 96 | 96 |408 | 24 |432 | 16 | 16 |400 |432 |208 |144 | 80 |432 |80 |160 |192 |432 ? Figure 7A: LPW Frame GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 10A. LPW Format Date Description Bits Frame Bits Sec Offset to Start of Data Paragraph Header Engineering Data UVS HIC/EUV SSI Status PLS NIMS Status PWS Hi-Rate (1of4) DDS Coded Reserve EPD (1of2) PWS Hi-Rate (2of4) EPD (2of2) PPR MAG (1of2) PWS Hi-Rate (3of4) MAG (2of2) PWS Lo-Rate AACS Posn & Rate PWS Hi-Rate (4of4)96 704 672 96 96 408 24 432 16 16 400 432 208 144 80 432 80 160 192 432 5120 144 1056 1008 144 144 612 36 2592 24 24 912 - - - - 216 240 - - - - 240 288 - -7680 0 96 800 1472 1568 1664 2072 2096 2528 2544 2560 2960 3392 3600 3744 3824 4256 4336 4496 4688 3.9.2 A2.2 A2.13 A2.6A/A2.6B A2.12 A2.9 A2.8 A3.11.1A A2.5 A2.6 A2.10 A2.7 A2.11 A2.4 Frame Accumulate/DMS Write Time = 1 MOD91 (0.666 2/3 second) GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9.4A.1 Source. The LPW frame shall exist in the downlink telemetry only as the result of an LPB mode DMS playback of a previously recorded frame that contains the whole or segmented portions of an LPW frame. The circumstances under which LPW frames are written to the DMS recorder are as follows: a. Being recorded as an LPW frame on the DMS recorder b. Being multiplexed in 512-bit groups (1/10 LPW) into the MPP, MPW, HPW, HIM, HMA, HCA and HIS telemetry frames and being recorded to the DMS recorder c. Deleted d. Being multiplexed in 64-bit groups (1/80 LPW) into the IM4, IM8, and AI8 telemetry frames and being recorded to the DMS recorder Because of transmission rate limitations on the spacecraft in flight, direct playback via the TDM LPB mode will probably be exercised only in the GLL Testbed. Previously recorded LPW frames (including its embedded forms) can be accessed from the DMS recorder by the CDS as needed to generate selected packets for downlinking as PKT telemetry. 3.9.4A.2 Spacecraft Clock Progression. SCLK values for successive LPW frames shall increment as shown in Table 10AA below. Table 10AA. LPW SCLK Progression LPW Minor Frame RIM MOD91 MOD10 MOD8``````````````` _____________________________________________________________________________ _ 0 i 0 0 0 1 i 1 0 0 2 i 2 0 0 3 i 3 0 0 . . . . . . . . . . . . . . . 89 i 89 0 0 90 i 90 0 0 0 i+i 0 0 0 1 i+1 1 0 0 2 i+i 2 0 0 . . . . . . . . . . . . . . . _____________________________________________________________________________ _ Frame Accumulate/DMS Write Time = 1 MOD91 (0.666 2/3 second) 3.9.4B LPR - Low Rate Probe DELETED FOR PHASE 2 GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9.4C LNR - Low-Rate Science plus NIMS The LNR frame shall be used for the 7.68 Kbps real-time acquisition of low-rate fields and particles data, engineering data at 1200 bps, and NIMS data at 2.592 Kbps, and for the real-time recording of that data on the spacecraft's DMS recorder. The schematic of the LNR frame is shown in Figure 7C and described in greater detail in Table 10C. The frame is identical to the LPW format except for NIMS data supplanting the four 432-bit fields of hi-rate PWS data in the LPW frame. |ENGI- | | | | | | | | | | | | | | | | | | |NEER- | | | SSI | | NIMS | | | CODED | | | | | | | | | | HEADER |ING |UVS | HIC |STATUS |PLS |STATUS |NIMS | DDS|RESERVE | EPD|NIMS| EPD |PPR | MAG |NIMS| MAG| PWS |AACS| NIMS | | / | | | | | | | | | | | | | | |(LR) | | | |EUV | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 96 | 704 |672 | 96 | 96 |408 | 24 | 432 | 16 | 16 | 400 |432 | 208 |144 | 80 |432 | 80 | 160 |192 | 432 Figure 7C. LNR Frame GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 10C. LNR Format Date Description Bits Frame Bits Sec Offset to Start of Data Paragraph Header Engineering Data UVS HIC/EUV SSI Status PLS NIMS Status NIMS Data (Part 1) DDS Coded Reserve EPD (Part 1) NIMS Data (Part 2) EPD (Part 2) PPR MAG (Part 1) NIMS Data (Part 3) MAG (Part 2) PWS Lo-Rate AACS Posn & Rate NIMS Data (Part 4)96 704 672 96 96 408 24 432 16 16 400 432 208 144 80 432 80 160 192 432 5120 144 1056 1008 144 144 612 36 2592 24 24 912 - - - - 216 240 - - - - 240 288 - -7680 0 96 800 1472 1568 1664 2072 2096 2528 2544 2560 2960 3392 3600 3744 3824 4256 4336 4496 4688 3.9.2 A2.2 A2.13 A2.6A/A2.6B A2.12 A2.9 A2.8 A2.?? A2.5 A2.6 A2.10 A2.7 A2.11 A2.4 GLL-3-280 Rev. D, Appendix D (PHASE 2) Frame Accumulate/DMS Write Time = 1 MOD91 (0.666 2/3 second) 3.9.4C.1 Source. LNR frames shall exist in the downlink telemetry only as the result of an LPB mode DMS playback of previously recorded LNR frames. Because of transmission rate limitations on the spacecraft in flight, this capability will probably be exercised only in the GLL Testbed. Previously recorded LNR frames can be accessed from the DMS recorder by the CDS as needed to generate selected packets for downlinking as PKT telemetry. 3.9.4C.2 Spacecraft Clock Progression. The SCLK Progression for LNR frames is the same as it is for LPW frames (Refer to 3.9.4A.2) 3.9.4D LPU - Low-Rate NIMS plus UVS & PPR The LPU frame shall be used for the 7.68 Kbps real-time acquisition of NIMS, UVS, PPR and AACS Posn/Rate data and for the real-time recording of that data on the spacecraft's DMS recorder. The schematic of the LPU frame is shown in Figure 7D and described in greater detail in Table 10D. AACS HEADER NIMS UVS PPR P&R 96 4112 672 144 96 Figure 7D. LPU Frame Table 1OD. LPU Format Bits Bits Offset to Data Description Frame Sec Data Start Paragraph Header 96 144 0 3.9.2 NIMS 4112 6168 96 A2.8 UVS 672 1008 4208 A2.13 PPR 144 216 4880 A2.10 AACS Posn/Rate 96 144 4880 A2.4 5120 7680 ___________________________________________________________________________ Frame Accumulate/DMS Write Time = 1 MOD91 (0.666 2/3 second) 3.9.4D.1 Source. LPU frames shall exist in the downlink telemetry only as the result of an LPB mode DMS playback of previously recorded LPU frames. Because of GLL-3-280 Rev. D, Appendix D (PHASE 2) transmission rate limitations on the spacecraft in flight, this capability will probably be exercised only in the GLL Testbed. Previously recorded LPU frames can be accessed from the DMS recorder by the CDS as needed to generate selected packets for downlinking as PKT telemetry. 3.9.4D.2 Spacecraft Clock Progression. The SCLK Progression for LPU frames is the same as it is for LPW frames (Refer to 3.9.4A.2). 3.9.4E BPT - PPR Burst to Tape The BPT frame shall be used for real-time accumulation of PPR and AACS Position data and for the real-time recording of that data on the spacecraft's DMS recorder. The BPT frame accommodates PPR data from the equivalent of 14 LPW frames; The AACS Position data fields,in like manner, provide for 14 LPW-held Platform position values for the same 14 LPW frame interval. The SCLK contained in the frame header is the clock value of the first PPR/AACS entry in the frame's data section. The schematic of the BPT frame is shown in Figure 7E and described in greater detail in Table 10E. HEADER PPR AACS PPR AACS PPR AACS 1 1 2 2 <---1936 bits---> 14 14 96 144 32 144 32 144 32 Figure 7E. BPT Frame GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 10E. BPT Format Date Description Bits Frame Bits Sec Offset to Data Start Paragraph Header PPSR (mf 1) AACS Posn/Rate (mf 1) PPR (mf 2) AACS Posn/Rate (mf 2) PPR (mf 3) AACS Posn/Rate (mf 3) PPR (mf 4) AACS Posn/Rate (mf 4) PPR (mf 5) AACS Posn/Rate (mf 5) PPR (mf 6) AACS Posn/Rate (mf 6) PPR (mf 7) AACS Posn/Rate (mf 7) PPR (mf 8) AACS Posn/Rate (mf 8) PPR (mf 9) AACS Posn/Rate (mf 9) PPR (mf 10) AACS Posn/Rate (mf 10) PPR (mf 11) AACS Posn/Rate (mf 11) PPR (mf 12) AACS Posn/Rate (mf 12) PPR (mf 13) AACS Posn/Rate (mf 13) PPR (mf 14) AACS Posn/Rate (mf 14)96 144 32 144 32 144 32 144 32 144 32 144 32 144 32 144 32 144 32 144 32 144 32 144 32 144 32 144 32 2560 144 216 48 216 48 216 48 216 48 216 48 216 48 216 48 216 48 216 48 216 48 216 48 216 48 216 48 216 48 7680 0 96 240 272 416 448 592 624 768 800 944 976 1120 1152 1296 1328 1472 1504 1648 1680 1824 1856 2000 2032 2176 2208 2352 2384 2528 3.9.2 A2.10 A2.4 A2.10 A2.4 A2.10 A2.4 A2.10 A2.4 A2.10 A2.4 A2.10 A2.4 A2.10 A2.4 A2.10 A2.4 A2.10 A2.4 A2.10 A2.4 A2.10 A2.4 A2.10 A2.4 A2.10 A2.4 A2.10 A2.4 Frame Data Accumulate Time = 14 MOD91 (4.666 2/3 seconds Frame DMS Write Time = 5 MOD10 (0.333 1/3 second) GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9.4E.1 Source . BPT frames shall exist in the downlink telemetry only as the result of an LPB mode DMS playback of previously recorded BPT frames. Because of transmission rate limitations on the spacecraft in flight, this capability will probably be exercised only in the GLL Testbed. Previously recorded BPT frames can be accessed from the DMS recorder by the CDS as needed to generate selected packets for downlinking as PKT telemetry. 3.9.4E.2 Spacecraft Clock Progression . The SCLK Progression for successively accumulated BPT frames that contain contiguous packets is illustrated in the Table 10F below. Note that: 1) each successive BPT frame's SCLK is a MOD91 jump of 14 from the previous frame's MOD91 value (Modulo 91), and 2) that the MOD91 portion of the SCLK cycles back on itself every 14 BPT frames, and 3) that there are 14 possible MOD91 sequencings (See below) NOTE: There will and can be occasions when the PPR/AACS P&R packet sets within the BPT data frame will not be contiguous. Under these conditions the "normal" SCLK progression shown here will not occur. The fact that the 1st byte of each PPR packet contains the packet's MOD91 value may be of some help in establishing the SCLK value for each packet under these conditions. Table 10F. BPT SCLK Progressions LPU Minor Frame RIM MOD91 MOD10 MOD8 0,1,2,3,4,5,6,7 i 0,14,28,42,56,70,84 0 0 8,9,10,11,12,13 i+1 7,21,35,49,63,77 0 0 14 i+2 0 0 0 or 0,1,2,3,4,5,6,7 i 1,15,29,43,57,71,85 0 0 8,9,10,11,12,13 i+1 8,22,36,50,64,78 0 0 14 i+2 1 0 0 or 0,1,2,3,4,5,6,7 i 2,16,30,44,58,72,86 0 0 8,9,10,11,12,13 i+1 9,23,37,51,65,79 0 0 14 i+2 2 0 0 . . or 0,1,2,3,4,5,6,7 i 12,26,40,54,68,82 0 0 8,9,10,11,12,13 i+1 5,19,33,47,61,75,89 0 0 14 i+2 12 0 0 or 0,1,2,3,4,5,6,7 i 13,27,41,55,69,83 0 0 8,9,10,11,12,13 i+1 6,20,34,48,62,76,90 0 0 14 i+2 13 0 0 GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9.4F BDT - Buffer Dump to Tape The BDT frame is a data structure that the CDS utilizes internally to record and later access blocks of formatted VCDUs; although physically possible to playback this format in the GLL Testbed, it is not specifically intended to be downlinked there. The BDT frame has the header data structure of the standard Low-rate Science formats (96-bit header complete with all header fields and a 5024-bit data area). The SCLK contained in the frame header, though a valid clock value set there by the CDS, has no defined use or known progression. The schematic of the BDT frame is shown in Figure 7G and described in greater detail in Table 10G. HEADER | DATA | 96 | 5024 Figure 7G. BDT Frame Table 10G. BDT Format Bits Bits Offset to Data Description Frame Sec Data Start Paragraph Header 96 144 0 3.9.2 Data 5024 7536 96 A2.8 5120 7680 ___________________________________________________________________________ Frame Data Accumulate Time = only the CDS knows Frame DMS Write Time = 1 MOD91 (0.666 2/3 second) 3.9.4F.1 Source. The GLL CDS creates, records and re-accesses BDT frames as is needed to support its directed tasks. 3.9.4F.2 Spacecraft Clock Progression. Not applicable GLL-3-280 Rev. D, Appendix D (PHASE 2) D-63 3.9.4G EOT R - End of Track The EOTR frame is a data structure that the CDS utilizes internally to mark the end of track; although physically possible to playback this format in the GLL Testbed, it is not specifically intended to be downlinked. The EOTR frame has the header data structure of the standard Low-rate Science formats (96-bit header complete with all header files and a 5024-bit data area). The SCLK contained in the frame header contains the fill pattern of AAh with the least significant Rim byte being an up counter from 1 to 4 for the last four frames (closest to center of tape). The schematic of the EOTR frame is show in Figure 7H and is described in greater detail in Table 10H. Header 96 Data 5024 Figure 7H. EOTR Frame Table 10H: EOTR Format Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Frame Synchronization 0 32 =03915ED3h APID 32 16 001Ch Spacecraft Clock 48 48 =6 bytes of AAh * Fill Pattern 96 5024 =628 bytes of AAh End of Track fill pattern * The least significant Rim byte is an up counter from 1 to 4 for the last four frames (closest to center of tape). 3.9.4G.1 Source . The GLL CDS creates, records and re-accesses EOTR frames as needed to support its directed tasks. 3.9.4G.2 Spacecraft Clock Progression . The spacecraft clock contains the fill pattern AAh with the least significant Rim byte being an up counter from 1 to 4 for the last four frames (closest to center of tape). GLL-3-280 Rev. D, Appendix D (PHASE 2) D-64 3.9.4H BOT R - Beginning of Track The BOTR frame is a data structure that the CDS utilizes internally to mark the beginning of track; although physically possible to playback this format in the GLL Testbed, it is not specifically intended to be downlinked. The BOTR frame has the header data structure of the standard Low-rate Science formats (96-bit header complete with all header files and a 5024-bit data area). The SCLK contained in the frame header contains the fill pattern of AAh with the least significant Rim byte being an up counter from 1 to 4 for the last four frames (closest to center of tape). The schematic of the BOTR frame is show in Figure 7I and is described in greater detail in Table 10I. Header 96 Data 5024 Figure 7I: BOTR Frame Table 10I: BOTR Format Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Frame Synchronization 0 32 =03915ED3h APID 32 16 001Dh Spacecraft Clock 48 48 =6 bytes of AAh * Fill Pattern 96 5024 =628 bytes of AAh Beginning of Track fill pattern * The least significant Rim byte is an up counter from 1 to 4 for the last four frames (closest to center of tape). 3.9.4H.1 Source . The GLL CDS creates, records and re-accesses BOTR frames as needed to support its directed tasks. 3.9.4H.2 Spacecraft Clock Progression . The spacecraft clock contains the fill pattern AAh with the least significant Rim byte being an up counter from 1 to 4 for the last four frames (closest to center of tape). GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9.5 MPW - Medium-Rate Science , PWS Data The MPW frame shall be used for the 28.8 Kbps real-time acquisition of LPW (with full Engineering), a NIMS Bus-Transfer Unit, and hi-rate PWS data and for the real-time recording of that data on the spacecraft's DMS recorder. The schematic of the MPW frame is shown in Figure 8 and described in greater detail in Table 11. HEADER 1/10 LPW NIMS PWS FILLER 96 512 768 512 32 Figure 8. MPW Frame Table 11. MPW Format Bits Bits Offset to Data Description Frame Sec Data Sta rt Paragraph Header 96 1440 0 3.9.2 1/10 LPW 512 7680 96 3.94A NIMS 768 11520 608 A2.8 Medium Rate PWS 512 7680 1376 A2.11 Filler 32 480 1888 1920 28800 ___________________________________________________________________________ Frame Data Accumulate Time = only the CDS knows Frame Accumulate/DMS Write Time = 1 MOD10 (0.066 2/3 second) 3.9.5.1 Source. MPW frames shall exist in the downlink telemetry only as the result of an LPB mode DMS playback of previously recorded MPW frames. Because of transmission rate limitations on the spacecraft in flight, this capability will probably be exercised only in the GLL Testbed. Previously recorded MPW frames can be accessed from the DMS recorder by the CDS as needed to generate selected packets for downlinking as PKT telemetry. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9.5.2 Spacecraft Clock Progression. The SCLK Progression for successive MPW frames shall increment as shown in Table 11a below. Table 11a. SCLK Progression for single MOD10 interval i.e. 0.066 2/3 second, telemetry frames (MPW,MPP,HPW,HIM,HMA,HCA,HIS) RIM MOD 91 MOD10 MOD8 ______________________________________________________ i (i=any) 0 0 0 i 0 1 0 . . . . . . . . . . . . i 0 9 0 i 1 0 0 i 1 1 0 i . . . i . . . i . . . i 90 8 0 i 90 9 0 i+i 0 0 0 . . . . . . . . . . . . 3.9.5.3 Embedded Frame Build Up. The MPW frame and all other single MOD10 interval telemetry format/modes, contain 1/10 of an LPW data frame. Upon receipt, the 512 bits of embedded LPW data from successive MPW frames (and other MOD10 incrementing frames) shall be re-assembled into the full 5120-bit structure of the LPW frame (For LPW frame description, see 3.9.4A). There is a delay of one LPW frame time between the collection and embedding of the LPW data. As a result of this delay, the relationship between the SCLK in the frame and the SCLK in the embedded LPW frame is as shown below in Table 11b. GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 11b. TLM Frame & Embedded LPW Frame Relationship for single MOD10 interval, i.e. 0.066 2/3 second, telemetry frames (MPW,MPP,HPW,HIM,HMA,HCA,HIS) Frame Containing 1/10 LPW Frame Embedded LPW Frame RIM MOD 91 MOD10 MOD8 RIM MOD 91 MOD10 MOD8 i 0 0 0 i-1 90 0 0 i 1 0 0 i 0 0 0 i 2 0 0 i 1 0 0 . . . . . . . . . . . . . . . . . . . . . . . . i 90 0 0 i 89 0 0 The expressions for computing the embedded LPW minor frame and segment number within the frame are: _ _ | 900 + 10*MOD 91 + MOD10 | S = Remainder of |_ 910 _| LPW Minor Frame = Integer portion [S/10] LPW Segment Number = Remainder of [S/10] 3.9.5A MPP - Medium-Rate Science, PWS Data Without NIMS The MPP frame shall be used for the 28.8 Kbps real-time acquisition of LPW (with full Engineering) and hi-rate PWS data and for the real-time recording of that data on the spacecraft's DMS recorder. The schematic of the MPP frame is shown in Figure 8A and is described in greater detail in Table 11A. HEADER 1/10 LPW PWS FILLER 96 512 1280 32 Figure 8A. MPP Frame GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 11A. MPP Format Bits Bits Offset to Data Description Frame Sec Data Start Paragraph Header 96 1440 0 3.9.2 1/10 LPW 512 7680 96 3.9.4A Medium Rate PWS 1280 19200 608 Various Filler 32 480 1888 1920 28800 ___________________________________________________________________________ Frame Accumulate/DMS Write Time = 1 MOD10 (0.066 2/3 second) 3.9.5A.1 Source. MPP frames shall exist in the downlink telemetry only as the result of an LPB mode DMS playback of previously recorded MPP frames. Because of transmission rate limitations on the spacecraft in flight, this capability will probably be exercised only in the GLL Testbed. Previously recorded MPP frames can be accessed from the DMS recorder by the CDS as needed to generate selected packets for downlinking as PKT telemetry. 3.9.5A.2 Spacecraft Clock Progression. The SCLK Progression for MPP frames is the same as it is for all other single MOD10 interval telemetry modes (See Table 11a in Paragraph 3.9.5.2) 3.9.5A.3 Embedded Frame Build Up. The MPP frame contains 512 bits of embedded LPW data (1/10 of an LPW frame). These LPW segments from successive MPP frames are to be reassembled into full 5120-bit LPW frames according to the relationship described in 3.5.9.3. 3.9.6 MPB - Medium Rate Playback DELETED FOR PHASE 2 3.9.7 XED - Intermediate-Rate Science, Compressed and Edited Imaging DELETED FOR PHASE 2 3.9.8 XCM - Intermediate-Rate Science, Compressed Imaging DELETED FOR PHASE 2 GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9.9 XPW - Intermediate-Rate Science, PWS DELETED FOR PHASE 2 3.9.10 XPB - Intermediate Playback DELETED FOR PHASE 2 3.9.10 AXRW - In termediate-Rate Real Time PWS at 80.64 kbps. DELETED FOR PHASE 2 3.9.10 BXPN - Intermediate-Rate Playback with NIMS at 80.64 Kbps. DELETED FOR PHASE 2 3.9.11 HIM - High-Rate Science, 1perRIM 800x788 Imaging The HIM frame shall be used for the 115.2 Kbps real-time acquisition of 1/10 LPW (with Engineering), a NIMS Bus-Transfer Unit, and SSI 1perRIM 800x788 imaging data and for the real-time recording of that data on the spacecraft's DMS recorder. The schematic of the HIM frame is shown in Figure 14 and described in greater detail in Table 17. HEADER 1/10 LPW NIMS IMAGING 96 512 768 6304 Figure 14. HIM Frame GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 17. HIM Format Bits Bits Offset to Data Description Frame Sec Data Start Paragraph Header 96 1440 0 3.9.2 1/10 LPW 512 7680 96 3.9.4A NIMS 768 11520 608 A2.8 Imaging 6304 94560 1376 A2.12 7680 115200 ___________________________________________________________________________ Frame Accumulate/DMS Write Time = 1 MOD10 (0.066 2/3 second) 3.9.11.1 Source. HIM frames shall exist in the downlink telemetry only as the result of an LPB mode DMS playback of previously recorded HIM frames. Because of transmission rate limitations on the spacecraft in flight, this capability will probably be exercised only in the GLL Testbed. Previously recorded HIM frames can be accessed from the DMS recorder by the CDS as needed to generate selected packets for downlinking as PKT telemetry. 3.9.11.2 Spacecraft Clock Progression. The SCLK Progression for HIM frames is the same as it is for all other single MOD10 interval telemetry modes (See Table 11a in Paragraph 3.9.5.2) 3.9.11.3 Embedded Frame Build Up. The HIM frame contains 512 bits of embedded LPW data (1/10 of an LPW frame). These LPW segments from successive HIM frames are to be reassembled into full 5120-bit LPW frames according to the relationship described in 3.5.9.3. 3.9.11.4 HIM SSI Imaging Data Structure . The 910 HIM frames within each RIM are designed to contain one 800-line by 788-pixel image. Table 17A portrays the relationship between the HIM frame's MOD91/MOD10 counters and the HIM image data structure. Note: Each HIM contained image consists of 110 HIM frames of SSI Preparation Cycle followed by 800 image bearing frames. GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 17A: HIM SSI Image Data Structure RIM MOD91 MOD10 Image Image Comments # Line #s i 0 0 1 -109 Prep Cycle start i 0 1 1 -108 | . . . | i 10 8 1 -1 | i 10 9 1 0 Prep Cycle end i 11 0 1 1 Image start i 11 1 1 2 | . . | i 90 8 1 799 | i 90 9 1 800 Image end i+1 0 0 next -109 Prep Cycle start 3.9.12 HCM - High-Rate Science, Compressed Imaging DELETED FOR PHASE 2 3.9.12A HCJ - High-Rate Science, Compressed Imaging and PWS DELETED FOR PHASE 2 3.9.13 HPW - High-Rate Science, PWS The HPW frame shall be used for the 115.2 Kbps real-time acquisition of 1/10 LPW (with Engineering), a NIMS Bus-Transfer Unit, and hi-rate PWS data and for the real-time recording of that data on the spacecraft's DMS recorder. The schematic of the HPW frame is shown in Figure 16 and described in greater detail in Table 19. HEADER 1/10 LPW NIMS PWS 96 512 768 6304 Figure 16. HPW Frame GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 19. HPW Format Bits Bits Offset to Data Description Frame Sec Data Start Paragraph Header 96 1440 0 3.9.2 1/10 LPW 512 7680 96 3.9.4A NIMS 768 11520 608 A2.8 PWS 6304 94560 1376 A2.11 7680 115200 ___________________________________________________________________________ Frame Accumulate/DMS Write Time = 1 MOD10 (0.066 2/3 second 3.9.13.1 Source. HCM frames shall exist in the downlink telemetry only as the result of an LPB mode DMS playback of previously recorded HCM frames. Because of transmission rate limitations on the spacecraft in flight, this capability will probably be exercised only in the GLL Testbed. Previously recorded HCM frames can be accessed from the DMS recorder by the CDS as needed to generate selected packets for downlinking as PKT telemetry. 3.9.13.2 Spacecraft Clock Progression. The SCLK Progression for HPW frames is the same as it is for all other single MOD10 interval telemetry modes (See Table 11a in Paragraph 3.9.5.2) 3.9.13.3 Embedded Frame Build Up. The HPW frame contains 512 bits of embedded LPW data (1/10 of an LPW frame). These LPW segments from successive HPW frames are to be reassembled into full 5120-bit LPW frames according to the relationship described in 3.5.9.3. 3.9.14 HPB - High-Rate Playback DELETED FOR PHASE 2 3.9.14A HRW - High-Rate Real Time PWS at 134.4 kbps DELETED FOR PHASE 2 3.9.14B HPJ - High-Rate Playback With NIMS and PWS at 134.4 Kbps DELETED FOR PHASE 2 GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9.14C HMA - High-Rate Science, 2perRIM 400x788 Imaging The HMA frame shall be used for the 115.2 Kbps real-time acquisition of 1/10 LPW (with Engineering), a NIMS Bus-Transfer Unit, and SSI 2perRIM 400x788 imaging data and for the real-time recording of that data on the spacecraft's DMS recorder. The schematic of the HMA frame is shown in Figure 17C and described in greater detail in Table 20C. HEADER 1/10 LPW NIMS IMAGING 96 512 768 6304 Figure 17C. HMA Frame Table 20C. HMA Format Bits Bits Offset to Data Description Frame Sec Data Start Paragraph Header 96 1440 0 3.9.2 1/10 LPW 512 7680 96 3.9.4A NIMS 768 11520 608 A2.8 Imaging 6304 94560 1376 A2.12 7680 115200 ___________________________________________________________________________ Frame Accumulate/DMS Write Time = 1 MOD10 (0.066 2/3 second) 3.9.14C.1 Source. HMA frames shall exist in the downlink telemetry only as the result of an LPB mode DMS playback of previously recorded HMA frames. Because of transmission rate limitations on the spacecraft in flight, this capability will probably be exercised only in the GLL Testbed. Previously recorded HMA frames can be accessed from the DMS recorder by the CDS as needed to generate selected packets for downlinking as PKT telemetry. 3.9.14C.2 Spacecraft Clock Progression. The SCLK Progression for HMA frames is the same as it is for all other single MOD10 interval telemetry modes (See Table 11a in Paragraph 3.9.5.2). GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9.14C.3 Embedded Frame Build Up. The HMA frame contains 512 bits of embedded LPW data (1/10 of an LPW frame). These LPW segments from successive HMA frames are to be reassembled into full 5120-bit LPW frames according to the relationship described in 3.5.9.3. 3.9.14C.4 HMA SSI Imaging Data Structure . The 910 HIM frames within each RIM are designed to contain two 400-line by 788-pixel images. The 400 lines may be either 1) the first 400 lines of the SSI 800-line image or 2) the 400 odd- numbered lines of the SSI 800-line image. Table 20D portrays the relationship between the HMA frame's MOD91/MOD10 counters and the HMA image data structure. Note: Each HMA contained image consists of 55 HMA frames of SSI Preparation Cycle followed by 400 image bearing frames. Table 20D: HMA SSI Imaging Data Structure RIM MOD91 MOD10 Image Image Comments # Line #s i 0 0 1 -54 Prep Cycle start i 0 1 1 -58 | . . . | i 5 3 1 -1 | i 5 4 1 0 Prep Cycle end i 5 5 1 1 Image start i 5 6 1 2 | . . . | i 45 3 1 399 | i 45 4 1 400 Image end i 45 5 2 -54 Prep Cycle start i 45 6 2 -53 | . . . | i 50 8 2 -1 | i 50 9 2 0 Prep Cycle end i 51 0 2 1 Image start i 51 1 2 2 | . . . | i 90 8 2 399 | i 90 9 2 400 Image end i+1 0 0 next -54 Prep Cycle start 3.9.14D HCA - High-Rate Science, 7perRIM 200x800 Compressed Imaging The HCA frame shall be used for the 115.2 Kbps real-time acquisition of 1/10 LPW (with Engineering), a NIMS Bus-Transfer Unit, and SSI 7perRIM 200x800 Reed-Solomon compressed imaging data and for the real-time recording of that data on the spacecraft's DMS recorder. The schematic of the HCA frame is shown in Figure 17D and described in greater detail in Table 20E. GLL-3-280 Rev. D, Appendix D (PHASE 2) HEADER 1/10 LPW NIMS COMPRESSED IMAGING REED SOLOMON PARITY SYMBOLS COMPRESSED IMAGING REED SOLOMON PARITY SYMBOLS FILL 96 512 768 2592 512 2592 512 96 Figure 17D. HCA Frame Table 20E. HCA Format Bits Bits Offset to Data Description Frame Sec Data Start Paragraph Header 96 1440 0 3.9.2 1/10 LPW 512 7680 96 3.9.4A NIMS 768 11520 608 A2.8 Compressed Imaging #1 2592 38880 1376 A2.12 Reed/Solomon Coding #1 512 7680 3968 A2.12 Compressed Imaging #2 2592 38880 4480 A2.12 Reed/Solomon Coding #2 512 7680 7072 A2.12 Filler 96 1440 7584 7680 115200 _________________________________________________________________________ Frame Accumulate/DMS Write Time = 1 MOD10 (0.066 2/3 second) 3.9.14D.1 Source. HCA frames shall exist in the downlink telemetry only as the result of an LPB mode DMS playback of previously recorded HCA frames. Because of transmission rate limitations on the spacecraft in flight, this capability will probably be exercised only in the GLL Testbed. Previously recorded HCA frames can be accessed from the DMS recorder by the CDS as needed to generate selected packets for downlinking as PKT telemetry. 3.9.14D.2 Spacecraft Clock Progression. The SCLK Progression for HCA frames is the same as it is for all other single MOD10 interval telemetry modes (See Table 11a in Paragraph 3.9.5.2). GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9.14D.3 Embedded Frame Build Up. The HCA frame contains 512 bits of embedded LPW data (1/10 of an LPW frame). These LPW segments from successive HCA frames are to be reassembled into full 5120-bit LPW frames according to the relationship described in 3.5.9.3. 3.9.14D.4 HCA SSI Imaging Data Structure . The 910 HCA frames within each RIM are designed to contain seven 200-line by 800-pixel Reed-Solomon compressed images. The 200 lines may be either 1) the first 200 lines of the SSI 800-line image or 2) every 4th line of the SSI 800-line image starting with Line 1 and ending with Line 797. Table 20F portrays the relationship between the HCA frame's MOD91/MOD10 counters and the HCA image data structure. Note: Each HCA contained image consists of 30 HCA frames (60 image line data spaces) of SSI Preparation Cycle followed by 100 image bearing HCA frames (200 image lines). Because SSI delivery of Reed-Solomon compressed lines lag by one line buffer over SSI delivery of un-compressed lines, the HCA data structure is shifted across the RIM boundary. As such, the first HCA data frame in the RIM contains the last line from the 7th image from the previous RIM and the 1st line of this RIM's first HCA image. It follows that the last HCA data frame in the RIM will hold the 198th and 199th lines of the RIM's last (7th) image. Table 20F. HCA SSI Imaging Data Structure RIM MOD91 MOD10 Image Image Comments # Line #s i 0 0 Prev/1 200,-59 Image end/Cycle i 0 1 1 -58,-57 | start . . . | i 2 9 1 -2,-1 | i 3 0 1 0, 1 Cycle end/Image i 3 1 1 2, 3 | start . . . | i 12 9 1 198,199 | i 13 0 1/2 200,-59 Image end/Cycle i 13 1 2 -58,-57 | start . . . | i 16 0 2 0, 1 Cycle end/Image i 16 1 2 2, 3 | start . . . | i 26 0 2/3 200,-59 Image end/Cycle i 26 1 2 -58,-57 | start i . . . | i 29 0 3 -0, 1 Cycle end/Image i 29 1 3 2, 3 | start . . . | GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 20F. HCA SSI Imaging Data Structure (Cont) RIM MOD91 MOD10 Image Image Comments # Line #s i 39 0 3/4 200,-59 Image end/Cycle i 39 1 3 -58,-57 | start . . . | i 42 0 4 -0, 1 Cycle end/Image i 42 1 4 2, 3 | start . . . | i 52 0 4/5 200,-59 Image end/Cycle i 52 1 5 -58,-57 | start . . . | i 55 0 5 -0, 1 Cycle end/Image i 55 1 5 2, 3 | start . . . | i 65 0 5/6 200,-59 Image end/Cycle i 65 1 6 -58,-57 | start . . . | i 68 0 6 -0, 1 Cycle end/Image i 68 1 6 2, 3 | start i . . . | i 78 0 6/7 200,-59 Image end/Cycle i 78 1 6 -58,-57 | start . . . | i 81 0 7 -0, 1 Cycle end/Image i 81 1 7 2, 3 | start . . . | i 90 9 7 198,199 i+1 0 0 7/next 200,-59 Image end/Cycle i+1 0 1 next -58,-57 | start 3.9.14E HIS - High-Rate Science, 4perRIM 400x394 Summed Imaging The HIS frame shall be used for the 115.2 Kbps real-time acquisition of 1/10 LPW (with Engineering), a NIMS Bus-Transfer Unit, and SSI 4perRIM 400x394 summed imaging data and for the real-time recording of that data on the spacecraft's DMS recorder. The schematic of the HIS frame is shown in Figure 17E and described in greater detail in Table 20G. HEADER 1/10 LPW NIMS IMAGING (line n) IMAGING (line n+1) 96 512 768 3152 3152 Figure 17E. HIS Frame GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 20G. HIS Format Bits Bits Offset to Data Description Frame Sec Data Start Paragraph Header 96 1440 0 3.9.2 1/10 LPW 512 7680 96 3.9.4A NIMS 768 11520 608 A2.8 Imaging (line n) 3152 47280 1376 A2.12 Imaging (line n+1) 3152 47280 4528 A2.12 7680 115200 _________________________________________________________________________ Frame Accumulate/DMS Write Time = 1 MOD10 (0.066 2/3 second) 3.9.14E.1 Source. HIS frames shall exist in the downlink telemetry only as the result of an LPB mode DMS playback of previously recorded HIS frames. Because of transmission rate limitations on the spacecraft in flight, this capability will probably be exercised only in the GLL Testbed. Previously recorded HIS frames can be accessed from the DMS recorder by the CDS as needed to generate selected packets for downlinking as PKT telemetry. 3.9.14E.2 Spacecraft Clock Progression. The SCLK Progression for HIS frames is the same as it is for all other single MOD10 interval telemetry modes (See Table 11a in Paragraph 3.9.5.2) 3.9.14E.3 Embedded Frame Build Up. The HIS frame contains 512 bits of embedded LPW data (1/10 of an LPW frame). These LPW segments from successive HIS frames are to be reassembled into full 5120-bit LPW frames according to the relationship described in 3.5.9.3. 3.9.14E.4 HIS SSI Imaging Data Structure. . The 910 HIS frames within each RIM are designed to contain four 400-line by 394 pixel summed images. Each image pixel in the 400x394 image is a summed average of a 2x2 pixel block from the SSI's line-shortened 800x788 image space. Table 20H portrays the relationship between the HIS frame's MOD91/MOD10 counters and the HIS image data structure. Note: Each HIS contained image consists of 27.5 HIS frames (55 image line data spaces) of SSI Preparation Cycle followed by 200 image bearing HIS frames (400 image lines). Note that the image separation line between HIS RIM images 1 & 2 and 3 & 4 occur internal to HIS data frames 22:7 and 68:2, respectively. GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 20H. HIS SSI Imaging Data Structure RIM MOD91 MOD10 Image Image Comments # Line #s i 0 0 1 -54,-53 Prep Cycle start i 0 1 1 - 52,-51 | . . . | i 2 6 1 -2,-1 Prep Cycle end i 2 7 1 0, 1 Cycle end/Image i 2 8 1 2, 3 | start . . . | i 22 6 1 398,399 | i 22 7 1/2 400,-54 Image end/Cycle i 23 8 2 -53,-52 | start . . . | i 24 4 2 -1, 0 Prep Cycle end i 25 5 2 1, 2 Image start . . . | i 44 4 2 399,400 Image end i 45 5 3 -54,-53 Prep Cycle start i 45 6 3 -52,-51 | . . . | i 48 1 3 -0,-1 Prep Cycle end i 48 2 3 0, 1 Cycle end/Image i 48 3 3 2, 3 | start . . . | i 68 1 3 398,399 | i 68 2 3/4 400,-54 Image end/Cycle i 68 3 4 -53,-52 | start . . . | i 70 9 4 -1, 0 Prep Cycle end i 71 0 4 1, 2 Image start . . . | i 90 9 4 399,400 Image end i+1 0 0 next -54,-53 Prep Cycle start 3.9.15 IM8 - High-Rate Science, 7perRIM 800x800 Imaging The IM8 frame shall be used for the 806.4 Kbps real-time acquisition of 1/80 LPW (with Engineering), 1/8 of a NIMS Bus-Transfer Unit, and SSI 7perRIM 800x800 imaging data and for the real-time recording of that data on the spacecraft's DMS recorder. The schematic of the IM8 frame is shown in Figure 18 and described in greater detail in Table 21. GLL-3-280 Rev. D, Appendix D (PHASE 2) HEADER 1/80 LPW 1/8 NIMS FILLER IMAGING 96 64 96 64 6400 Figure 18. IM8 Frame Bits Bits Offset to Data Description Frame Sec Data Start Paragraph Header 96 11520 0 3.9.2 1/80 LPW 64 7680 96 3.9.4A 1/8 NIMS 96 11520 160 A2.8 Filler 64 7680 256 Imaging 6400 768000 320 A2.12 6720 806400 _________________________________________________________________________ Frame Accumulate/DMS Write Time = 1 MOD8 (0.008 1/3 second) Table 21. IM8 Format 3.9.15.1 Source. IM8 frames shall exist in the downlink telemetry only as the result of an LPB mode DMS playback of previously recorded IM8 frames. Because of transmission rate limitations on the spacecraft in flight, this capability will probably be exercised only in the GLL Testbed. Previously recorded IM8 frames can be accessed from the DMS recorder by the CDS as needed to generate selected packets for downlinking as PKT telemetry. Both the Real-time and Playback OPNAV Packetized Down-link telemetry modes are based on the IM8 TDM telemetry format. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9.15.2 Spacecraft Clock Progression. The SCLK Progression for successive IM8 frames shall increment as shown in Table 22 below. Table 22. SCLK Progression for single MOD8 interval i.e. 0.008 2/3 second, telemetry frames (IM8,AI8,IM4) RIM MOD91 MOD10 MOD8 i i . . . i i . . . i i+1 0 0 . . . 0 1 . . . 90 0 0 1 . . . 9 0 . . . 9 0 0,1,2, ..., 7 0,1,2, ..., 7 . . . 0,1,2, ..., 7 0,1,2, ..., 7 . . . 0,1,2, ..., 7 0,1,2, ..., 7 3.9.15.3 Embedded Frame Build Ups. The IM8 frame contains two embedded data types: LPW and NIMS. Each of these data types shall be built into structures identical to their full-frame equivalents. 3.9.15.3.1 LPW. Each IM8 frame contains 64 bits of embedded LPW data (1/80 of an LPW frame). These LPW segments from successive IM8 frames are to be reassembled into full 5120-bit LPW frames according to the relationship described below. There shall be a delay of one LPW frame-time between the collection and embedding of the LPW data into the frame. As a result of this delay, the relationship of the SCLK in the frame and the SCLK in the embedded LPW frame shall be as shown below. Frame Containing 1/80 LPW Frame Embedded LPW Frame RIM MOD91 MOD10 MOD8 RIM MOD91 MOD10 MOD8 i 0 1 0 i+1 90 0 0 i 1 1 0 i 0 0 0 i 2 1 0 i 1 0 0 . . . . . . . . . . . . . . . . . . . . . . . . i 90 1 0 i 89 0 0 GLL-3-280 Rev. D, Appendix D (PHASE 2) D-82 The expressions for computing the LPW minor frame and segment number with the minor frames are: 7194 + 8(10*MOD91 + MOD10) + MOD8 S = Remainder of 7280 LPW Minor Frame = Integer [S/80] LPW Segment Number = Remainder of [S/80] 3.9.15.3.2 NIMS. Each IM8 frame contains 96 bits of embedded NIMS data (1/8 of a NIMS Bus-Transfer Unit). These NIMS data segments from successive IM8 frames are to be reassembled into full 768-bit NIMS BTUs according to the relationship described below. The S/C clock of the frame which contains the first of 8 segments of the embedded NIMS frame is shown below. Frame Containing 1/80 LPW Frame Embedded LPW Frame RIM MOD91 MOD10 MOD8 RIM MOD91 MOD10 MOD8 i 0 0 0 i-1 90 9 0 i 0 1 0 i 0 0 0 i 0 2 0 i 0 1 0 . . . . . . . . . . . . . . . . . . . . . . . . i 0 9 0 i 0 8 0 i 1 0 0 i 0 9 0 i 1 1 0 i 1 0 0 . . . . . . . . . . . . . . . . . . . . . . . . i 90 9 0 i 90 8 0 The expressions for computing the NIMS data packet and segment number within the packet are: 7272 + 8(10*MOD91 + MOD10) + MOD8 S = Remainder of 7280 NIMS Minor Frame = Integer Portion of [S/8] NIMS Segment Number = Remainder of [S/8] GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9.15.4 IM8 SSI Imaging Data Structure . The 7280 IM8 frames within each RIM are designed to contain seven 800-line by 800-pixel images. Table 22a portrays the relationship between the IM8 frame's MOD91/MOD10/MOD8 counters and the IM8 image data structure. Note: Each IM8 contained image consists of 240 IM8 frames of SSI Preparation Cycle followed by 800 image bearing IM8 frames. Table 22a. IM8 SSI Imaging Data Structure RIM MOD91 MOD10 MOD8 Image Image Comments # Line #s i 0 0 0 1 -239 Prep Cycle start i 0 0 1 1 -238 | . . . . | i 2 9 6 1 -1 | i 2 9 7 1 0 Prep Cycle end i 3 0 0 1 1 Image start i 3 0 1 1 2 | . . . . | i 12 9 6 1 799 | i 12 9 7 1 800 Image end i 13 0 0 2 -239 Prep Cycle start . . . . | i 15 9 7 2 0 Prep Cycle end i 16 0 0 2 1 Image start . . . . | i 25 9 7 2 800 Image end i 26 0 0 3 -239 Prep Cycle start . . . . | i 28 9 7 3 0 Prep Cycle end i 29 0 0 3 1 Cycle end/Image . . . . | i 38 9 7 3 800 Image end i 39 0 0 4 -239 Prep Cycle start . . . . | i 41 9 7 4 0 Prep Cycle end i 42 0 0 4 1 Image start . . . . | i 51 9 7 4 800 Image end i 52 0 0 5 -239 Prep Cycle start . . . . | i 54 9 7 5 0 Prep Cycle end i 55 0 0 5 1 Image start . . . . | i 64 9 7 5 800 Image end i 65 0 0 6 -239 Prep Cycle end . . . . | i 67 9 7 6 0 Prep Cycle end i 68 0 0 6 1 | . . . . | i 77 9 7 6 800 Image end i 78 0 0 7 -239 Prep Cycle start . . . . | i 80 9 7 7 0 Prep Cycle end i 81 0 0 7 1 Image start . . . . | i 90 9 7 7 800 Image end i+1 0 0 0 next -239 Prep Cycle start GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9.15A AI8 - High-Rate Science, 26perRIM 400x400 Summed Imaging The AI8 frame shall be used for the 806.4 Kbps real-time acquisition of 1/80 LPW (with Engineering), 1/8 of a NIMS Bus-Transfer Unit, and SSI 26perRIM 400x400 summed imaging data and for the real-time recording of that data on the spacecraft's DMS recorder. The schematic of the AI8 frame is shown in Figure 18A and described in greater detail in Table 22A. HEADER 1/80 LPW 1/8 NIMS FILLER IMAGING IMAGING 96 64 96 64 3200 3200 Figure 18A. AI8 Frame Table 22A. AI8 Format Bits Bits Offset to Data Description Frame Sec Data Start Paragraph Header 96 11520 0 3.9.2 1/80 LPW 64 7680 96 3.9.4A 1/8 NIMS 96 11520 160 A2.8 Filler 64 7680 256 Imaging 3200 384000 320 A2.12 Imaging 3200 384000 3520 A2.12 6720 806400 _________________________________________________________________________ Frame Accumulate/DMS Write Time = 1 MOD8 (0.008 1/3 second) 3.9.15A.1 Source. AI8 frames shall exist in the downlink telemetry only as the result of an LPB mode DMS playback of previously recorded AI8 frames. Because of transmission rate limitations on the spacecraft in flight, this capability will probably be exercised only in the GLL Testbed. Previously recorded AI8 frames can be accessed from the DMS recorder by the CDS as needed to generate selected packets for downlinking as PKT telemetry. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9.15A.2 Spacecraft Clock Progression . The SCLK Progression for AI8 frames is the same as it is for the other single MOD8 interval telemetry modes (See Table 22 in Paragraph 3.9.15.2). 3.9.15A.3 Embedded Frame Build Ups . The AI8 frame contains two embedded data types: LPW and NIMS. Each of these data types shall be built into structures identical to their full-frame equivalents. 3.9.15A.3.1 LPW . The AI8 frame contains 64 bits of embedded LPW data (1/80 of an LPW frame). These LPW segments from successive AI8 frames are to be reassembled into full 5120-bit LPW frames according to the relationship described in 3.9.15.3.1. 3.9.15A.3.2 NIMS . The AI8 frame contains 96 bits of embedded NIMS data (1/8 of a NIMS Bus-Transfer Unit). These NIMS segments from successive AI8 frames are to be reassembled into full 768-bit NIMS BTUs according to the relationship described in 3.9.15.3.2. 3.9.15A.4 AI8 SSI Imaging Data Structure . The 7280 AI8 frames within each RIM are designed to contain twenty-six 400-line by 400-pixel summed images. Each image pixel in the 400x400 image is a summed average of a 2x2 pixel block from the SSI's 800x800 image space. Table 22C portrays the relationship between the AI8 frame's MOD91/MOD10/MOD8 counters and the AI8 image data structure. Note: Each AI8 contained image consists of 80 AI8 frames (160 image line data spaces) of SSI Preparation Cycle followed by 200 image bearing AI8 frames (400 image lines). GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 22C. AI8 SSI Imaging Data Structure RIM MOD91 MOD10 MOD8 Image Image Comments # Line #s i 0 0 0 1 -159,-158 Prep Cycle start i 0 0 1 1 -157,-156 | . . . . | i 0 9 6 1 -3,-2 | i 0 9 7 1 -1,0 Prep Cycle end i 1 0 0 1 1,2 Image start i 1 0 1 1 3,4 | . . . . | i 3 4 6 1 397,398 | i 3 4 7 1 399,400 Image end i 3 5 0 2 -159,-158 Prep Cycle start . . . . | i 4 5 0 2 1,2 Image start . . . . | i 7 0 0 3 -159.-158 Prep Cycle start . . . . | i 8 0 0 3 1,2 Image start . . . . | i 10 5 0 4 -159,-158 Prep Cycle start . . . . | i 11 5 0 4 1,2 Image start . . . . | i 14 0 0 5 -159,-158 Prep Cycle start . . . . | i 15 0 0 5 1,2 Image start . . . . | i 18 5 0 6 1,2 Image start . . . . | i 22 0 0 7 1,2 Image start . . . . | i 25 5 0 8 1,2 Image start . . . . | i 29 0 0 9 1,2 Image start . . . . | i 32 5 0 10 1,2 Image start . . . . | i 36 0 0 11 1,2 Image start . . . . | i 39 5 0 12 1,2 Image start . . . . | i 43 0 0 13 1,2 Image start . . . . | i 46 5 0 14 1,2 Image start . . . . | i 50 0 0 15 1,2 Image start . . . . | i 53 5 0 16 1,2 Image start . . . . | i 57 0 0 17 1,2 Image start . . . . | i 60 5 0 18 1,2 Image start . . . . | GLL-3-280 Rev. D, Appendix D (PHASE 2) i 64 0 0 19 1,2 Image start . . . . | Table 22C. AI8 SSI Imaging Data Structure (Cont) RIM MOD91 MOD10 MOD8 Image Image Comments # Line #s i 67 5 0 20 1,2 Image start . . . . | i 71 0 0 21 1,2 Image start . . . . | i 74 5 0 22 1,2 Image start . . . . | i 78 0 0 23 1,2 Image start . . . . | i 81 5 0 24 1,2 Image start . . . . | i 85 0 0 25 1,2 Image start . . . . | i 87 5 7 26 -159,-158 Prep Cycle end . . . . | i 88 4 7 26 -1,0 Prep Cycle end i 88 5 0 26 1,2 Image start . . . . | i 90 9 7 26 399,400 Image end i+1 0 0 0 next -159,-158 Prep Cycle start 3.9.16 PW8 - PWS Recorded at 806.4 kbps DELETED FOR PHASE 2 3.9.17 IM4 - High-Rate Science, 7perRIM 800x800 Compressed Imaging The IM4 frame shall be used for the 403.2 Kbps real-time acquisition of 1/80 LPW (with Engineering), 1/8 of a NIMS Bus-Transfer Unit, and SSI 7perRIM 800x800 Reed-Solomon compressed imaging data and for the real-time recording of that data on the spacecraft's DMS recorder. The schematic of the IM4 frame is shown in Figure 20 and described in greater detail in Table 24. HEADER 1/80 LPW 1/8 NIMS COMPRESSED IMAGING REED SOLOMON PARITY SYMBOLS 96 64 96 2592 512 Figure 20. IM4 Frame GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 24. IM4 Format Bits Bits Offset to Data Description Frame Sec Data Start Paragraph Header 96 11520 0 3.9.2 1/80 LPW 64 7680 96 3.9.4A 1/8 NIMS 96 11520 160 A2.8 Compressed Imaging 2592 311040 256 A2.12 Reed Solomon Parity 512 61440 2848 Symbols 3360 403200 _________________________________________________________________________ Frame Accumulate/DMS Write Time = 1 MOD8 (0.008 1/3 second) 3.9.17.1 Source . IM4 frames shall exist in the downlink telemetry only as the result of an LPB mode DMS playback of previously recorded IM4 frames. Because of transmission rate limitations on the spacecraft in flight, this capability will probably be exercised only in the GLL Testbed. Previously recorded IM4 frames can be accessed from the DMS recorder by the CDS as needed to generate selected packets for downlinking as PKT telemetry. 3.9.17.2 Spacecraft Clock Progression . The SCLK Progression for IM4 frames is the same as it is for all other single MOD8 interval telemetry modes (See Table 22 in Paragraph 3.9.15.2) 3.9.17.3 Embedded Frame Build Ups . The IM4 frame contains two embedded data types: LPW and NIMS. Each of these data types shall be built into structures identical to their full-frame equivalents. 3.9.17.3.1 LPW . The IM4 frame contains 64 bits of embedded LPW data (1/80 of an LPW frame). These LPW segments from successive IM4 frames are to be reassembled into full 5120-bit LPW frames according to the relationship described in 3.9.15.3.1. 3.9.17.3.2 NIMS . The IM4 frame contains 96 bits of embedded NIMS data (1/8 of a NIMS Bus-Transfer Unit). These NIMS segments from successive IM4 frames are to be reassembled into full 768-bit NIMS BTUs according to the relationship described in 3.9.15.3.2. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9.17.4 IM4 SSI Imaging Data Structure . The 7280 IM4 frames within each RIM are designed to contain seven 800-line by 800-pixel Reed-Solomon compressed images. IM4 has a similar image line structure to the IM8 telemetry format, namely 7 images per rim, each consisting of 240 frames of SSI Preparation Cycle followed by 800 image bearing frames. However, because SSI delivery of Reed-Solomon compressed lines lag by one line buffer from that of un-compressed lines, the image data structure is shifted across the RIM boundary. As such, the first IM4 data frame in the RIM contains the last line from the 7th image from the previous RIM if that image was an IM4 image. It follows that the last IM4 data frame in the RIM will hold the 799th line of the RIM's last (7th) IM4 image. Table 24a shows this SCLK to IM4 image data relationship. Table 24a. IM4 SSI Imaging Data Structure RIM MOD91 MOD10 MOD8 Image Image Comments # Line #s i 0 0 0 Prev 800 Prev Image end i 0 0 1 1 -239 Prep Cycle start . . . . | i 2 9 7 1 -1 | i 3 0 0 1 0 Prep Cycle end i 3 0 1 1 1 Image start i 3 0 2 1 2 | . . . . | i 12 9 7 1 799 | i 13 0 0 1 800 Image end i 13 0 1 2 -239 Prep Cycle start . . . . | i 16 0 0 2 0 Prep Cycle end i 16 0 1 2 1 Image start . . . . | i 26 0 0 2 800 Image end i 26 0 1 3 -239 Prep Cycle start . . . . | i 29 0 0 3 0 Prep Cycle end i 29 0 1 3 1 Image start . . . . | i 39 0 0 3 800 Image end i 39 0 1 4 -239 Prep Cycle start . . . . | i 42 0 0 4 0 Prep Cycle end i 42 0 1 4 1 Image start . . . . | i 52 0 0 4 800 Image end i 52 0 1 5 -239 Prep Cycle start . . . . | i 55 0 0 5 0 Prep Cycle end i 55 0 1 5 1 Image start . . . . | GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 24a. IM4 SSI Imaging Data Structure (Cont) i 65 0 0 5 800 Image end i 65 0 1 6 -239 Prep Cycle start . . . . | i 68 0 0 6 0 Prep Cycle end i 68 0 1 6 1 | . . . . | i 78 0 0 6 800 Image end i 78 0 1 7 -239 Prep Cycle start . . . . | i 81 0 0 7 0 Prep Cycle end i 81 0 1 7 1 Image start . . . . | i 90 9 7 7 799 | i+1 0 0 0 7 800 Image end i+1 0 0 1 next -239 Prep Cycle start 3.9.18 PW4 - PWS Recorded at 403.2 kbps DELETED FOR PHASE 2 3.9.19 BPB - Backup Science, Playback DELETED FOR PHASE 2 3.9.20 MPR - Medium-Rate Science, Probe Data. DELETED FOR PHASE 2 3.9.21 KPR - Keep Alive Power On Re set The KPR frame shall consist exclusively of alternate 1-0 data at 40 bps. 3.9.21.1 Source. The KPR frame shall exist in the downlink telemetry as a result of spacecraft failure which has allowed power to the CDS memories to be interrupted. The KPR frame shall be output from the CDS at the high rate channel and low rate channel interfaces to the MDS. The KPR frame can appear in the downlink as uncoded over S-band or (convolutionally) coded over either S- band or X-band, depending on the state of the MDS. Note that the KPR mode will exist in the downlink telemetry whenever the CDS experiences a power on reset (POR), but this existence will be transitory since the CDS will restart telemetry upon recovering from a POR. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.9.21.2 Spacecraft Clock Progression. Not applicable since the KPR frame does not contain a header. Recovery from a failure which has interrupted CDS memory power requires that the ground re-establish memory contents including the SCLK, reinstate the configuration, and then release the KAPOR lockout of the CDS. This recovery sequence will restart the spacecraft telemetry which has the SCLK incrementing in the normal manner defined in Table 7. 3.9.22 LMF - Launch Memory Failure . The LMF frame shall consist of an indeterminate data pattern at 600 bps. 3.9.22.1 Source. The LMF frame shall exist in the telemetry through the attached launch vehicle as a result of spacecraft failure which has allowed power to the CDS memories to be interrupted. 3.9.22.2 Spacecraft Clock Progression. Not applicable since the LMF frame does not contain a header. 3.10 PACKETIZED TELEMETRY It should be noted that while the Galileo Phase 2 Packetized telemetry design utilized portions of the CCSDS (Consultative Committee for Space Data Systems) packet telemetry concepts, it does not strictly conform to the full CCSDS standard. The following subsections describe the functional and operational aspects of the Galileo Phase 2 Packetized Telemetry. 3.10.1 Overview Galileo's packetized telemetry delivers telemetry data to the ground in the form of 56 self-identifiable data packet types. Of these, 15 types carry real-time data, 33 contain playback data, i.e. data based on previously recorded data that the CDS has retrieved from the spacecraft's DMS recorder, and 7 which are entitled "Record Rate Change Coverage" packets (they contain data constructed/sent in real-time to cover unavoidable gaps in the recording to DMS recorder process), and 1 single byte packet to be utilized as a VCDU filler/flush element. Real-time data packets can co-exist in the downlink with either the Playback packets or with the RRCC packets. In general, the packetized real-time functions and the playback functions (Playbacks execute as a time and data available background process), are independently optioned and controlled. With the exceptions of Real-time Optical Navigation (which requires there being no active reading or writing to the DMS recorder) and DDS, PLS and EPD Instrument imposed restrictions (they cannot support both their real-time packet making and the delivery of their data to the LPW format for recording at the same time), the real-time packet telemetry can concurrently operate on a non-interacting basis with the DMS data recording of any of its TDM recording GLL-3-280 Rev. D, Appendix D (PHASE 2) format (See Table 3 in 3.8.1 for a list of the TDM DMS recording formats). Playback, Real-time TDM DMS recording PPR Burst To Tape, and the "BDT" process referenced two paragraphs below are mutually exclusive in that each one of the three requires sole control of the DMS recorder. An eight-level "virtual channel" arrangement provides eight "data pipes" for transferring data to the ground. The primary purpose for the data piping is to provide a segmentation of data into groupings of the same general type and temporal sense. In general, Real time data, Playback data, and Record Rate Change Coverage data are separated from each other and within the real time and playback groups, Engineering and Science data are further differentiated as a result of the hard-coded virtual channel assignments in the Flight Software and the Data Prioritization scheme. An on-board buffering structure provides a 2-level priority in which the Real-time and Playback Optical Navigation Processes and the Real-time Engineering receive an absolute priority for data transfers to the ground. The structure gives the 2nd class data items (everybody else) an on-board option of a process called "Buffer Dump to Tape" or "BDT" that allows impending over-runs of the lower priority data packets to be recorded on the DMS recorder for a later retrieval and transmittal. Four types of on-board Data Compression (BARC, Rice, Lossless Huffman, and ICT) can be employed to reduce the transmission bandwidth requirements for selected packetized data types. When used, the BARC algorithm is executed by the SSI instrument at data access time; this implementation is not new and is unchanged from its use in the earlier spacecraft phases. The other three (Rice, Huffman and ICT) are new to Phase 2 and are implemented in Flight Software. In all but one usage, (the PWS Low-rate Data Real-time packets), the results of these data compressions appear as an element of a Playback function. In all applications except for the SSI Instrument data playbacks (where no uncompressed option exists), the Data Compression bearing packet is an alternative to a companion packet type that does not employ the compression. The Phase 2 applied compression algorithms fall into the two categories of a) "Lossless" in which no data integrity loss is guaranteed, and b) "Lossy" in which data is intentionally lost in order to maximize the compression. Table 27a indicates the expected ranges of data reduction to be realized for each of these data compression applications. Table 27a: Summary of GLL Phase 2 Data Compression Algorithms Data Type Compression Algorithm Comp. Factor R/T PWS Low-rate ICT (lossy) 2 - 80 NIMS, MAG, PLS, PPR UVS & AACS Playback Editing + Rice (lossless) 1 - 5 SSI Playback Huffman (lossless) 1 - 2 GLL-3-280 Rev. D, Appendix D (PHASE 2) SSI Playback ICT (lossy) + Huffman (lossless) 1 - 80 *SSI Record BARC (lossy) 2.03 *performed by SSI Instrument; all other performed by Flight Software (AACS + CDS CPU's) Table 28 in 3.10.5 lists and summarizes some of the above referenced characteristics of the Galileo Packetized Telemetry packets. 3.10.2 Downlink Data Rates The eight Downlink Packetized telemetry data rates are 8, 20, 32, 40, 60, 80, 120 and 160 bps. Rate, as used here, refers to the CDS bit rate prior to software convolutional code (11,1/2) and the MDS hardware convolutional code (7,1/2) being applied. The Downlink symbol rate is 4 times greater. The active data rate selection is inherent to the RTE/RTS Format selection (See 3.10.6.1). Unlike the GLL TDM experience, changing the downlink data rates under the new Phase 2 Packetized Telemetry is accomplished without a loss of lock or data. The opportunities to effect data rate changes occur at specific 128 second intervals based on a 128 second clock kept in the CDS. There is no synchronicity between these points of opportunity and the data being transferred; as such, the rate change can take place between any two bits in the data being transferred. When operating in the packetized telemetry mode and no other data is available to the packetized downlink, the CDS will construct PWH1 packets (from real-time high rate PWS data) for insertion into the downlink process. This mechanism ensures that data transitions are always being transmitted irrespective of the on- board data processing state. 3.10.3 Transfer Frame Format The downlink transfer unit is a 2048-byte Reed-Solomon encoded transfer frame. Each transfer frame contains the data from four fixed-length VCDUs (446 bytes for each VCDU) plus 254 bytes of Transfer Frame Reed-Solomon code words. Figure 25 depicts the transfer frame as received on the ground. GLL-3-280 Rev. D, Appendix D (PHASE 2) Figure 25. PKT Telemetry Transfer Frame Received On The Ground GLL-3-280 Rev. D, Appendix D (PHASE 2) A Packetized Transfer Frame starts with an 8-byte (64-bit) sync marker. The 64- bit marker is a fixed pattern which is the same for every frame; the eight bytes of the sync marker are not included in the Reed-Solomon encoding shell. Following the sync marker is a 2-byte unsigned Frame Sequence Number which increments by one for each transfer frame sent to the MDS for transmission to the ground. The remainder of the frame houses the four VCDU data blocks. As shown in Fig 25, Reed-Solomon code words are intermixed with the telemetry packet data in the 3rd and 4th VCDU data blocks (8-bytes and 246 bytes respectively). Figure 26, which diagrams the transfer frame in terms of its assemblage on board the spacecraft, more clearly indicates the format and location of the Reed-Solomon code elements. Figure 26. PKT Telemetry Transfer Frame Generated On-Board The S/C GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.4 Virtual Channel Data Unit (VCDU) Format A Virtual Channel Data Unit (VCDU) is a fixed length data structure consisting of a 4-byte header and a 442-byte data area. The VCDU format is shown in Figure 27. The generated VCDU is the basic storage unit used for storage in the on- board data buffers. Four of these units will be assembled into each transfer frame prior to its transmittal to the ground. Figure 27. Virtual Channel Data Unit, fixed Size (446 Bytes) The first field of the VCDU header is the 3-bit Virtual Channel Identifier (VCID). Accordingly, eight Virtual Channel paths are maintained in which data packets allocated to the same VCID level are placed end-to-end in succeeding VCDUs that have the same VCID number. A VCDU that has been only partially constructed due to the lack of additional packets under that VCID, will be held in memory until such time as additional packets of their VCID value complete the required full VCDU structure. VCDUs with VCID values of 0 are picked up from the on-board Priority Buffer; VCDUs with VCID values of 1 thru 7 are picked up from the on-board Multi-use Buffer. The VCDU pick up from both buffers operate on a FIFO basis. When assembling VCDUs into a transfer frame, the VCDUs from the Priority Buffer are taken first. It follows that if there are four or more VCDUs in the Priority Buffer, the next transfer frame released for transmittal will contain four VCID = 0 VCDUs in its data buffer positions. The second field of the VCDU header is the unsigned 20-bit VCDU Sequence Number. The number is incremented by one for each succeeding VCDU on each of the first 5 VCID indicated VCDU paths, i.e., for the VCDU 0, 1, 2, 3, & 4 channels. VCDU channels 5, 6 and 7 have no VCDU Sequence Numbers of their own. These GLL-3-280 Rev. D, Appendix D (PHASE 2) channels are used as paths for VCDU channel 1, 2 and 3 VCDU data blocks that have been placed on the DMS by a Buffer Dump to Tape operation and having been reaccessed from the DMS, have been placed in the Multi-use Buffer (MUB) for a delayed transmittal to the ground attempt. In this access and replacing to the MUB, the VCID numbers are altered from 1, 2, and 3 to 5, 6 and 7, respectively, but their VCDU Sequence Numbers are retained as originally set. Note: the "cycled" VCDUs may be "recycled" from Multi-use Buffer to DMS and back again any number of times with the VCDUs retaining their original VCDU Sequence Numbers on each trip. The third field of the VCDU header is the 9-bit "pointer to 1st packet header" in the VCDU. If the value is zero, a packet starts at the start of the VCDU data area, i.e., there is no packet data carry-over from the previous VCDU of this VCID path. If the value equals 511, there is no packet start within the data area of this VCDU, i.e., all 442 bytes are carry-over packet bytes. If the field value equals 1 through 441, the data area contains that number of carry-over packet bytes from the preceding VCDU with a new packet starting the byte after. Table 28 in 3.10.5 shows the assignment of Data Packet types to each of the VCDU channel paths. The general usage of each of the eight VCID-identified paths are as follows: Priority data channel (VCID=0) : This virtual channel contains Real Time Engineering (RTE) and both Real-time and Playback OPNAV packets. The RTE and OPNAV packets are placed into the Priority Buffer on a first come/first serve basis. These VCDU's cannot be dumped to tape. RTS channel (VCID=1) : This virtual channel contains Real-Time Science (RTS) and AACS real time packets. The VCDUs are stored in the Multi-use Buffer and may be dumped to tape as the result of BDT. PB channel (VCID=2) : This virtual channel contains "Record" and Burst to Tape packets created from data played back from DMS to the Multi-use Buffer. The PB channel VCDUs are stored in the downlink buffer and may be dumped to tape as the result of BDT. RRCC channel (VCID=3) : This virtual channel contains RRCC packets made from "Record" data directed to the Multi-use Buffer during DMS record rate changes. The RRCC VCDUs may be dumped to tape as the result of BDT. PWS Fill channel (VCID=4) : This virtual channel contains PWS High Rate Fill (PWH1 packet) data only. The PWH1 packet is sized to fit one VCDU exactly. BDT RTS Channel (VCID=5) : This virtual channel contains RTS channel VCDUs that have been recorded to DMS tape via the Buffer Dump To Tape process and then later restored to the Multi-use Buffer. The CDS will modify the VCDU ID value from 1 to 5 and leave everything else inside the VCDU, including the VCDU Sequence Number , untouched. GLL-3-280 Rev. D, Appendix D (PHASE 2) BDT PB channel (VCID=6) : This virtual channel contains PB channel VCDUs that have been recorded to DMS tape via the Buffer Dump To Tape process and then later restored to the Multi-use Buffer. The CDS will only modify the VCDU ID value from 2 to 6 and leave everything else inside the VCDU, including the VCDU Sequence Number, untouched. BDT RRCC channel (VCID=7) : This virtual channel contains RRCC channel VCDUs that have been recorded to DMS tape via the Buffer Dump To Tape process and then later restored to the Multi-use Buffer. The CDS will only modify the VCDU ID value from 3 to 7 and leave everything else inside the VCDU, including the VCDU Sequence Number, untouched. 3.10.5 Telemetry Packet Formats Figure 28 depicts the basic features of the structure employed by the GLL Phase 2 telemetry packets. (**) If Packet time is included in the packet header, the combined length of Format ID and Packet Time should be either 24, 32, or 40 bits as defined in the GLL-3-310. If the packet time is not included in the packet header and the Format ID is 4-bits long, there will be a 4-bit filler after the Format ID to make the packet header at byte-boundary. All numbers given in parentheses above are number of bits unless otherwise labelled. Figure 28. Telemetry Packet, Variable Size (Maximum 519 Bytes) GLL-3-280 Rev. D, Appendix D (PHASE 2) Every telemetry packet type (excepting the single byte filler packet) has a fixed header area, an optional header area, and a data area. The field definitions in each of these areas are described below: Fixed Header Area (24 bits) - Time Include Flag (1 bit): If set, SCLK for this data is given in this packet (See Packet Time Field in the Optional Header) Time inclusion summary: SCLK is included in the packet according to the following rules (Note: the inclusion behavior for each packet type is individually hard-coded in the Flight Software) 1) Always present when Packet Sequence No. = 0 2) Can be present or not for set intervals of 64, 32,16, 8, 4, 2 or 1 from the Seq # = 0 inclusion - it is more commonly specified as when PSN = 0 (Mod 2 n ,n=1,2....6 3) Other times when specific events pertaining to the packet/data type are encountered (See 3-270/3- 310 for details); Example: PPR1 packets "on 1st packet of a burst" - Application Identifier (7 bits): This "APID" unambiguously identifies the packet type. - Packet Size (9 bits): This value is a count of the bytes contained within the packet’s Data Area. - Packet Sequence Number (7 bits): Except for the "Exception" given below, this number is independently maintained for each packet type as identified by its APID; it is incremented by one for each newly generated packet of this type; the number cycles from 127 to 0 when 127 is incremented. These sequence numbers are never reset by the CDS. Exception : Where compressed/uncompressed packet type pairings exist (AACS2/AACS3,MAG2/MAG3,NIMS2/NIMS5,NIMS3/NIMS6,NIMS4/NIMS7,PLS 2/PL S3,PPR1/PPR2,PPR3/PPR4 and UVS2/UVS3), the linked packet types share a common packet sequence number. Optional Header Area (if any part present, 8 to 40 bits) - Format Identifier (If present 4 or 8 bits): This field provides a sub-packet type identifier; its existence, length and usage are detailed in the 3.10.5.x packet descriptions that follow. FIDs are utilized in 14 packet types - they are used mostly to indicate varying data sampling/accumulation rates; in other cases, they are used to further identify the packet contents. - Packet SCLK Time (if present, 20,24,28,or 32 bits) in one of 5 formats): Each packet type has one of the following formats hard-coded as its SCLK format (for any given packet type, see its 3.10.5.x description for further details). - GLL-3-280 Rev. D, Appendix D (PHASE 2) 1/2R-R-R 20 bits: 20 1s bits of RIM R-R-R 24 bits: 24 1s bits of RIM 1/2R-R-R-mf 28 bits: 20 1s bits of RIM plus M91 R-R-R-mf 32 bits: 24 ls bits of RIM plus M91 R-R-R-mf/232 bits: 24 1s bits of RIM plus M182 Note: "mf/2" and "M182" denote a counter that operates at twice the rate of a M91 counter; i.e., one that goes from 0 to 181 in a RIM increments at every five MOD10 counter intervals. Data Area (variable length to a maximum of 511 bytes): See the individual packet descriptions for the uses/formats/contents of the Data Area The total set of telemetry packets are listed and summarized in Table 28; Detailed descriptions for each packet type are given in the following 3.10.5 subsections. GLL-3-280 Rev. D, Appendix D (PHASE 2) Table 28. GLL Telemetry Packet Summary Table Note: Shaded Lines indicate Real-Time Data formats PACKET APID MNEMONIC Dec (Hex) Packet Title Virtual Channel Data Compression PB Source Format Packet Description AACS1 53 (35)AACS R/T Data 1,5 - - 3.10.5.2.1 AACS2 14 (0e)AACS Data Playback (uncomp) 2,6 - LPW*, LNR,LPU 3.10.5.2.2 AACS3 37 (25)AACS Data Playback (Rice Comp) 2,6 Rice LPW*, LNR,LPU 3.10.5.2.3 AACS4 29 (1d)AACS Record Rate Change Coverage 3,7 - - 3.10.5.2.4 DDS1 48 (30)DDS R/T Data 1,5 - - 3.10.5.3.1 DDS2 9 (09)DDS Data Playback 2,6 - LPW*, LNR 3.10.5.3.2 DDS3 25 (19)DDS Record Rate Change Data 3,7 - - 3.10.5.3.3 ENG1 56 (38)Engineering R/T Data 0 - - 3.10.5.1.1 ENG2 20 (14)Engineering EHR Data Playback 2,6 - LPW*, LNR 3.10.5.1.2 EPD1 49 (31)EPD R/T Data 1,5 - - 3.10.5.4.1 EPD2 10 (0a)EPD Data Playback 2,6 - LPW*, LNR 3.10.5.4.2 EPD3 26 (1a)EPD Record Rate Change Data 3,7 - - 3.10.5.4.3 EUV1 44 (2c)EUV R/T Data 1,5 - - 3.10.5.6.1 EUV2 3 (03)EUV Data Playback 2,6 - LPW*, LNR 3.10.5.6.2 HIC1 43 (2b)HIC R/T Rate, PHA and Status Data 1,5 - - 3.10.5.5..1 HIC2 2 (02)HIC Data Playback 2,6 - LPW*, LNR 3.10.5.5.2 HIC3 22 (16)HIC Record Rate Change Data 3,7 - - 3.10.5.5.3 MAG1 50 (32)MAG R/T Data 1,5 - - 3.10.5.7.1 MAG2 12 (0c)MAG Data Playback (uncomp) 2,6 - LPW*, LNR 3.10.5.7.2 MAG3 35 (23)MAG Data Playback (Rice comp) 2,6 Rice LPW*, LNR 3.10.5.7.3 MAG4 27 (1b)MAG Record Rate Change Data 3,7 - - 3.10.5.7.4 NIMS1 46 (2e)NIMS R/T Data 1,5 - - 3.10.5.8.1 NIMS2 5 (05)NIMS 11.52 Kbps Data Playback (uncomp) 2,6 - # 3.10.5.8.2 NIMS3 6 (06)NIMS 6.168 Kbps Data Playback (uncomp) 2,6 - LPU 3.10.5.8.3 NIMS4 7 (07)NIMS 2.592 Kbps Data Playback (uncomp) 2,6 - LNR 3.10.5.8.4 NIMS5 38 (26)NIMS 11.52 Kbps Data Playback (Rice Comp)2,6 Rice # 3.10.5.8.5 NIMS6 39 (27)NIMS 6.168 Kbps Data Playback (Rice Comp)2,6 Rice LPU 3.10.5.8.6 NIMS7 40 (28)NIMS 2.592 Kbps Data Playback (Rice Comp)2,6 Rice LNR 3.10.5.8.7 OPN1 54 (36)OPNAV R/T Extended Body Limb/Term. 0 - - 3.10.5.14.1 OPN2 55 (37)OPNAV R/T Star Window Data 0 - - 3.10.5.14.2 OPN3 18 (12)OPNAV Playback Extended Body Limb/Term.0 - IM8 3.10.5.14.3 OPN4 19 (13)OPNAV Playback Star Window Data 0 - IM8 3.10.5.14.4 PLS1 45 (2d)PLS R/T Data 1,5 - - 3.10.5.9.1 PLS2 4 (04)PLS Data Playback (uncomp) 2,6 - LPW*, LNR 3.10.5.9.2 PLS3 34 (22)PLS Data Playback (Rice Comp) 2,6 Rice LPW*, LNR 3.10.5.9.3 PLS4 24 (18)PLS Record Rate Change Data 3,7 - - 3.10.5.9.4 PPR1 11 (0b)PPR Data Playback (uncomp) 2,6 - LPW*, LNR, LPU 3.10.5.10.1 PPR2 36 (24)PPR Data Playback (Rice Comp) 2,6 Rice LPW*, LNR, LPU 3.10.5.10.2 PPR3 21 (15)PPR Burst to Tape Data Playback (uncomp)2,6 - BPT 3.10.5.10.3 PPR4 41 (29)PPR Burst to Tape Data Playback (Rice Comp)2,6 Rice BPT 3.10.5.10.4 PWH1 47 (2f)PWS High Rate Data R/T Fill 4 - - 3.10.5.11.1 PWH2 15 (0f)PWS High Rate Data Playback (MPW) 2,6 - MPW 3.10.5.11.2 PWH3 16 (10)PWS High Rate Data Playback (MPP) 2,6 - MPP 3.10.5.11.3 PWH4 17 (11)PWS High Rate Data Playback (HPW) 2,6 - HPW 3.10.5.11.4 PWH5 8 (08)PWS High Rate Data Playback (LPW) 2,6 - LPW* 3.10.5.11.5 GLL-3-280 Rev. D, Appendix D (PHASE 2) PWL1 51 (33)PWS Low Rate Data R/T (E-Packet) 1,5 ICT - 3.10.5.12.1 PWL2 52 (34)PWS Low Rate Data R/T (B- Packet) 1,5 ICT - 3.10.5.12.2 PWL3 13 (0d)PWS Low Rate Data Playback 2,6 - LPW*,LNR 3.10.5.12.3 PWL4 28 (1c)PWS Low Rate Data Record Rate Change 3,7 - - 3.10.5.12.4 SSI1 30 (1e)SSI Imaging Data Playback (ICT Comp) 2,6 ICT/ HUFFMAN HIM, HMA, HIS, IM8, AI8 3.10.5.13.1 SSI2 31 (1f)SSI Imaging Data Playback (BARC Comp) 2,6 BARC HCA, IM4 3.10.5.13.2 SSI3 32 (20)SSI Housekeeping Playback Data 2,6 - LPW*, LNR 3.10.5.13.3 UVS1 42 (2a)UVS R/T Data 1,5 - - 3.10.5.15.1 UVS2 1 (01)UVS Data Playback (uncomp) 2,6 - LPW*, LNR, LPU 3.10.5.15.2 UVS3 33 (21)UVS Data Playback (Rice Comp) 2,6 Rice LPW*, LNR, LPU 3.10.5.15.3 FILL 57 (39)Filler packet (single byte) all except 4 - - 3.10.5.16 * includes LPW frames embedded in MPW, MPP, HPW, HIM, HMA, HCA, HIS, IM4, IM8, and AI8 recorded formats # MPW, HPW, HIM, HMA, HCA, HIS, IM4, IM8, and AI8 recorded formats 3.10.5.1 Engineering Packets GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.1.1 ENG1 -- Engineering Real-Time Data Packet An ENG1 packet always contains 4 engineering subpackets; each subpacket equates to a snapshotted real-time Engineering minor frame. Each subpacket consists of a one-byte Engineering Format ID (EFID) followed by the engineering frame's 88 bytes of engineering data. The EFID for each subpacket identifies the mf's Real-time Rate (RTE)/minor frame stepping, its Commutation Map Index (CMI), its Map Sequence Number (MSN), and its Memory Read-out Flag (MRO). The definition and usage of these items are discussed in detail in 3.9.2.2. The real-time engineering carried by the ENG1 packet can have its rate asynchronously changed at any minor frame juncture; these rate changes can be reflected at any subpacket position in the ENG1 packet. When the real-time engineering rate (RTE) is commanded to zero, any partially filled ENG1 packet will be cleared with its already formatted data being lost. In the stop with throw- away and subsequent new start process, there will be no break in the ENG1 Packet Sequence Number sequence. The minor frame sequencings (MOD91 steppings) for the RTE rates of 2 bps, 10 bps and 40 bps are listed in Tables 7e, 7c and 7a, respectively. (These tables are located in 3.9.2.3.5). The ENG1 packet structure is depicted in the following figure. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, for PSN=0 (Mod n) where:. n = 4, if RTE rate = 2 bps; n = 8, if RTE rate = 10 bps; n = 32, if RTE rate = 40 bps. APID 1 7 38h (56) Packet Size (data bytes) 8 9 =356 Packet Sequence # 17 7 0 - 127 Packet Time 24 32/0* R-R-R-mf RTE rate/mf index 56/24* 2 00: 2 bps/every 600th EHR mf 01: 10 bps/every 120th EHR mf 10: 40 bps/every 30th EHR mf MRO flag 58/26* 1 =1: if packet includes 32-byte MRO CMI 59/27* 2 Commutation Map Identifier MSN 61/29* 3 Commutation Map Sequence Number 88-byte Eng. Data #1 64/32* 704 Section A2.2 EFID #2 768/736* 8 (See shaded area above) 88-byte Eng. Data #2 776/744* 704 Section A2.2 EFID #3 1480/1448* 8 (See shaded area above) 88-byte Eng. Data #3 1488/1456* 704 Section A2.2 EFID #4 2192/2160* 8 (See shaded area above) 88-byte Eng. Data #4 2200/2168* 704 Section A2.2 GLL-3-280 Rev. D, Appendix D (PHASE 2) Total packet length = 363/359* bytes * The 1st number is for time included, the 2nd number is for time NOT included 3.10.5.1.2 ENG2 -- Engineering Data Playback Packet An ENG2 packet contains from 1 to 4 engineering subpackets; each ENG2 subpacket equates to Playback accessed EHR Engineering frame that had been recorded to the DMS at the full engineering rate of 1200 bps. A Packet Time is included in every ENG2 packet. Each ENG2 subpacket, like its ENG1 counterpart, consists of a one-byte Engineering Format ID (EFID) followed by the engineering minor frame's 88 bytes of engineering data. Note that only the 1200 bps engineering rate is denoted for the ENG2 playback subpacket. GLL-3-280 Rev. D, Appendix D (PHASE 2) The ENG2 packet structure is depicted in the following figure. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, always APID 1 7 14h (20) Packet Size (data bytes) 8 9 max=356, min=89 Packet Sequence # 17 7 0 - 127 Packet Time 24 32 R-R-R-mf Recorded rate 56 2 11:1200 bps MRO flag 58 1 =1: if packet includes 32-byte MRO CMI 59 2 Commutation Map Identifier MSN 61 3 Commutation Map Sequence Number 88-byte Eng. Data #1 64 704 Section A2.2 EFID #2 768 8 (See shaded area above) 88-byte Eng. Data #2 776 704 Section A2.2 EFID #3 1480 8 (See shaded area above) 88-byte Eng. Data #3 1488 704 Section A2.2 EFID #4 2192 8 (See shaded area above) 88- byte Eng. Data #4 2200 704 Section A2.2 Total packet length: max=363 bytes, min=96 bytes 3.10.5.2 AACS Packets 3.10.5.2.1 AACS1 -- AACS Real-Time Data Packet An AACS RT subpacket consists of rotor RA, DEC, TWIST and scan platform RA, DEC, and TWIST plus spin rate from one real-time LPW minor frame. The size of the RT subpacket is 14 bytes. The AACS1 packet contains from 1 to 18 AACS RT subpackets. The number of subpackets in one packet may be less if it is the last packet before a mode change. The AACS1 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, for PSN = 0 (Mod 32) APID 1 7 35h (53) Packet Size (data bytes) 8 9 max=252, min=14 Packet Sequence # 17 7 0 - 127 Packet Time 24 24/0* R-R-R GLL-3-280 Rev. D, Appendix D (PHASE 2) D-103 Up to 18 AACS RT Subpackets 48/24* 112 to 2016 Each AACS RT subpacket is shown in the table below. Total packet length: max= 258/255* bytes, min=20/17* bytes * The 1st number is for time included, the 2nd number is for time NOT included AACS RT Subpacket: Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Rotor RA 0 16 E-1417 Rotor DEC 16 16 E-1418 Rotor TWIST 32 16 E-1421 Platform RA 48 16 E-1419 Platform DEC 64 16 E-1420 Platform TWIST 80 16 E-1422 Spin Rate 96 16 S-1958 Subpacket Length = 14 bytes GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.2.2 AACS2 -- AACS Data Uncompressed PB Packet An AACS PB subpacket consists of six measurements: rotor RA, DEC, TWIST and scan platform RA, DEC, and TWIST from one playback accessed LPW minor frame. The AACS2 contains from 1 to 40 PB subpackets. The number of subpackets in one packet may be less if it is the last packet before a mode change. The AACS2 structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, always APID 1 7 0Eh (14) Packet Size (data bytes) 8 9 max=480, min=12 Packet Sequence # 17 7 0 - 127 (seq. # shared with AACS3 packets) Packet Time 24 32 R-R-R-mf Up to 40 AACS PB Subpackets 56 96 to 3744 The AACS PB subpacket format is shown in the table below Total packet length: max = 487 bytes, min=19 bytes AACS PB Subpacket: Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Rotor RA 56 16 E-1417 Rotor DEC 72 16 E-1418 Rotor TWIST 88 16 E-1421 Platform RA 104 16 E-1419 Platform DEC 120 16 E-1420 Platform TWIST 136 16 E-1422 Subpacket Length = 12 bytes 3.10.5.2.3 AACS3 -- AACS Data Compressed PB Packet An AACS3 packet generating-operation can return only AACS3, both AACS3 and AACS2, or only AACS2 format packet(s). In this process, note that the AACS3 and AACS2 packets share a common Packet Sequence Number. The first step in the AACS3 packet achieving process is the accumulation of AACS data in the same manner as is done for the AACS2 (uncompressed) packet. The on-board Rice compression process for the AACS data works on two options of 20 or 40 subpackets of AACS data. For any failure to compress, i.e., the process returns more bytes than entered, the original uncompressed data is returned as an AACS2 packet. It follows that for any incoming data group of less than 20 packets, no compression is attempted and the data is returned as a partially filled AACS2 packet. For incoming data groups of 21 to 39 AACS subpackets, the return is either a 20- GLL-3-280 Rev. D, Appendix D (PHASE 2) unit AACS3 packet and a 1-to-19 unit AACS2 packet or two AACS2 packets of 20 and 1-to-19 units. For each AACS3 compression attempt, the Playback Editor appropriately arranges the data to a depth of 20 or 40 in the manner shown below. Channel 1 Channel 2 Channel 3 Channel 4 Channel 5 Channel 6 Rotor RA1 Rotor Dec 1 Rotor Twist 1 PL RA 1 PL Dec 1 PL Twist 1 Rotor RA2 Rotor Dec 2 Rotor Twist 2 PL RA 2 PL Dec 2 PL Twist 2 ... ... Rotor RA40 Rotor Dec 40 Rotor Twist 40 PL RA 40 PL Dec 40 PL Twist 40 For each packet to be compressed, the first value of each channel is used as a reference value to start off the compressor and is returned raw. Compression blocks are twenty values, with the reference value output from one block being used in the next one within a channel. Special treatment is given to the Rotor Twist value, since it is the only one in the set which is not expected to remain nearly constant much of the time. Rotor Twist increases by roughly 12 ??per minor frame at 3 RPM. CDS will preprocess the data in this one channel so that the first value x 0 of each compression block is sent to the compressor raw, and later value x n are converted to x n -x n-1 +x 0 -2295. GLL-3-280 Rev. D, Appendix D (PHASE 2) The final AACS3 packet format is shown below: Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, always APID 1 7 25h (37) Packet Size (data bytes) 8 9 < 480 Packet Sequence # 17 7 0 - 127 (seq # shared with AACS2 packets) Packet Time 24 32 R-R-R-mf mf Count 56 8 =20 or 40, (# of mfs compressed) Rotor RA pre-split bits 64 20 Rotor RA Ref 83 15 1st raw RRA value Rotor RA Comp. data. 98 variable Coder ID + Split Bits + rice encoded delta values Rotor RA pre-split bits 20 Rotor RA Comp. data. variable Coder ID + Split Bits + rice encoded delta values Rotor Dec pre-split bits 20 Rotor Dec Ref 15 1st raw RDEC value Rotor Dec Comp. data. variable Coder ID + Split Bits + Rice encoded delta values Rotor Dec pre-split bits 20 Rotor Dec Comp. data. variable Coder ID + Split Bits + Rice encoded delta values Rotor Twist pre-split bits 20 Rotor Twist Ref 15 1st raw RTWIST value Rotor Twist Comp. data. variable Coder ID + Split Bits + Rice encoded delta values Rotor Twist pre-split bits 20 Rotor Dec Comp. data. variable Coder ID + Split Bits + Rice encoded delta values Platform RA pre- split bits 20 Platform RA Ref 15 1st raw PRA value Platform RA Comp. data. variable Coder ID + Split Bits + Rice encoded delta values Platform RA pre-split bits 20 Platform RA Comp. data. variable Coder ID + Split Bits + Rice encoded delta values Platform Dec pre-split bits 20 Platform Dec Ref 15 1st raw PDEC value Platform Dec Comp. data. variable Coder ID + Split Bits + Rice encoded delta values Platform Dec pre-split bits 20 GLL-3-280 Rev. D, Appendix D (PHASE 2) Platform Dec Comp. data. variable Coder ID + Split Bits + Rice encoded delta values Platform Twist pre-split bits 20 Platform Twist Ref 15 1st raw PTWIST value Platform Twist Comp. data. variable Coder ID + Split Bits + Rice encoded delta value Platform Twist pre-split bits 20 Platform Twist Comp. data. variable Coder ID + Split Bits + Rice encoded delta value Total packet length < 494 byte GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.2.4 AACS4-- AACS Record Rate Change Coverage Packet An AACS RRCC subpacket consists of six measurements: rotor RA, DEC, TWIST and scan platform RA, DEC, and TWIST taken from one real-time LPW minor frame. A single AACS4 packet contains up to 18 of these subpackets. Up to 2 packets may be produced during a single RRCC execution. The AACS4 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, always APID 1 7 1Dh (29) Packet Size (data bytes) 8 9 max=216, min=12 Packet Sequence # 17 7 0 - 127 Packet Time 24 32 R-R-R-mf 1st mf Rotor RA 56 16 E-1417 1st mf Rotor DEC 72 16 E-1418 1st mf Rotor TWIST 88 16 E-1421 1st mf Platform RA 104 16 E- 1419 1st mf Platform DEC 120 16 E-1420 1st mf Platform TWIST 136 16 E-1422 Up to 17 additional AACS RRCC Subpackets 142 96 to 1728 Each AACS RRCC subpacket is 12 bytes as shown in the shaded area above Total packet length: max=223 bytes, min=19 bytes GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.3 DDS Packets 3.10.5.3.1 DDS1 -- DDS Real-Time Data Packet Normally, each DDS1 packet contains the data for one full DDS instrument cycle in the form of 7 DDS subpackets each consisting of 26 DDS data bytes. The DDS1 data pickup is 2 bytes of data sampled from either every 7th or every 21st LPW minor frame (see Format ID in format description below). Summarized, Data Pickup: two bytes each pickup (Every 7 or 21 mf's) Subpacket: 26 bytes from 13 consecutive pickups Instrument Cycle: 182 bytes from 7 consecutive subpackets When a request for changing the DDS1 sampling rate is received, the CDS will complete the in-process packet (a full 182 bytes worth) at the current rate before starting the next packet at the new rate. The DDS Instrument cannot support its real-time DDS1 function concurrently with providing its real-time support of the real-time LPW recording function. The transitions between these two mutually exclusive modes of operation are as follows: ??Real-time DDS1 change to real-time LPW Recording: All support of the real- time DDS1 packet building is terminated and the recording support function is activated. Any data already formatted into a DDS1 packet is sent on (most likely as a shortened packet). ??Real-time LPW Recording change to real-time DDS1: If the RTS real-time is enabled for DDS, the DDS1 process commences immediately. The DDS1 packet format is shown below: Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of a new rate and PSN = 0 (Mod 8) APID 1 7 30h (48) Packet Size data bytes) 8 9 max= 182, min=2 (one LPW access) Packet Sequence # 17 7 0 - 127 Packet Format ID 24 4 1h=1.1 bps (every 21st mf sample), 2h=3.4 bps (every 7th mf sample Packet Time 28 28/4* 1/2R-R-R-mf Up to 7 DDS Subpackets (Up to 91 DDS data sets) 56/32* 16 to 1456 DDS data from RT LPW (Sec. A2.5) Total packet length: max=189/186* bytes, min = 9 /6* bytes * the 1st number is for time included, the 2nd number is for time NOT included. 3.10.5.3.2 DDS2 -- DDS Data PB Packet GLL-3-280 Rev. D, Appendix D (PHASE 2) The DDS2 packet contains up to 128 2-byte DDS data sets. The DDS data pickup for DDS2 is 2 bytes from every LPW minor frame. The DDS2 packet is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of a set and PSN = 0 (Mod 8) APID 1 7 09h (9) Packet Size (data bytes) 8 9 max=256, min=2 Packet Sequence # 17 7 0 - 127 Packet Time 24 32/0* R-R-R-mf Up to 128 DDS data sets56/24* 16 to 2048 2-byte DDS data sets from PB LPW Total packet length: max = 263/259* bytes, min = 9/5* bytes * the 1st number is for time included, the 2nd number is for time NOT included. 3.10.5.3.3 DDS3 -- DDS Record Rate Change Coverage Data Packet A single DDS3 packet contains from one to thirty-one consecutive 2-byte DDS LPW data sets. This provides RRCC coverage from 2/3 second (1 mf) to 20-2/3 seconds (31 mfs). The DDS3 packet format is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, always APID 1 7 19h (25) Packet Size (data bytes) 8 9 max=62, min=2 Packet Sequence # 17 7 0 - 127 Packet Time 24 32 R-R-R-mf Up to 31 DDS data sets 56 16 to 496 2-byte DDS data sets from RT LPW Total packet length: max = 69 bytes, min = 9 bytes GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.4 EPD Packets 3.10.5.4.1 EPD1 -- EPD Real-Time Data Packets The EPD real-time data processing is quite complex (Refer to the 3-310 for a detailed description). Each EPD1 event generates two packets, an EPD1 "Rate Data" packet followed by an EPD1 "Event Data" packet. Both packets carry the same Application ID of 31h and share a common Packet Sequence Number. The Rate package always provides an SCLK value that applies to the data carried by both packets. Combinations of instrument mode and real-time format define two EPD maps (Map 1 and Map 2) whose use in controlling the EPD operations results in different packet sizes for both types of packets. Because the map selection is not directly provided in the packets, their sizes (all four types are fixed length) can be used to infer the map being used. The EPD1 packets are detailed in two following subsections as "Rate Data" packet and "Event Data" packet. The EPD Instrument cannot support its real-time EPD1 function concurrently with providing support of the LPW recording function. The transitions between these two mutually exclusive modes of operation are as follows: ??Real-time EPD1 change to real-time LPW Recording: All support of the real- time EPD1 packet building is terminated and the recording support function is activated immediately. Any already accumulated data for the CDS is discarded. ??Real-time LPW Recording change to real-time EPD1: If the RTS real-time is enabled for DPF, the EPD1 real-time support process commences immediately 3.10.5.4.1.1 EPD1 (Rate Data) Real-time Packet The Rate Data packets contain log compressed rate data. The EPD packets based on Map1 and Map2 provides 401 and 508 area data bytes, respectively. The processing and contents in both cases is given in 3-310. Packet Time is always included for these packets. The EPD1 Rate Data packet structures are shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, always APID 1 7 31h (49) - same as Event Data RT packet Packet Size (data bytes) 8 9 = 401 for Map1 packets = 508 for Map2 packets Packet Sequence # 17 7 0 - 127 GLL-3-280 Rev. D, Appendix D (PHASE 2) Packet Format ID 24 4 1h=5 bps, 2h=10 bps 3h=15 bps 4h=20 bps 5h=30 bps 6h=40 bps Packet Time 28 28 1/2R-R-R-mf EPD RT Rate Data 56 3208(Map 1) 4060(Map 2) Data is processed and log compressed; the processing is described below in 3-310 Total packet length = 408 bytes for Map 1 packets, 515 bytes for Map 2 packets 3.10.5.4.1.2 EPD1 (Event Data) Real-time Packet The Events Data packets contain 5 bytes of instrument status followed by CMA/PHA event data of lengths 30 or 60 bytes (Map 1 and Map 2, respectively). The processings involved are described in 3-310. Packet Time is never included for these packets. The EPD1 Event Data packet structures are shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =0, always APID 1 7 31h (49) - same as Event Data RT packet Packet Size (data bytes) 8 9 = 35 for Map1 packets = 65 for Map2 packets Packet Sequence # 17 7 0 - 127 (+1 of associated Rate Data Packet) Packet Format ID 24 4 + 4 Fill to byte boundary 1h=5 bps, 2h=10 bps 3h=15 bps 4h=20 bps 5h=30 bps 6h=40 bps EPD Instrument + Status32 40 5-byte block EPD RT Event Data 37 240 (Map 1) 480 (Map 2) Data is processed and log compressed; the processing is described in 3-310 Total packet length = 39 bytes for Map 1 packets, 69 bytes for Map 2 packets GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.4.2 EPD2 -- EPD Data PB Packet One EPD2 packet contains up to three EPD PB data sets. Each data set is 76- bytes of EPD data taken from an LPW playback minor frame. The EPD2 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet and PSN = 0 (Mod 16) APID 1 7 0Ah (10) Packet Size (data bytes) 8 9 max=228, min=76 Packet Sequence # 17 7 0 - 127 Packet Time 24 32/0* R-R-R-mf Up to 3 EPD PB data sets56/24* 608 to 182476-byte EPD data set from PB LPW Total packet length: max = 235/231* bytes, min = 83/79* bytes * the 1st number is for time included, the 2nd number is for time NOT included. 3.10.5.4.3 EPD3 -- EPD Record Rate Change Coverage Data Packet Each EPD3 packet contains from 1 to 3 EPD data sets, each of which contains the EPD data set taken from a real-time LPW minor frame. A maximum length RRCC function (31 LPW mfs providing 20-2/3 sec of real-time coverage) will result in 11 EPD3 packets being generated. The EPD3 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, always APID 1 7 1Ah (26) Packet Size (data bytes) 8 9 max=228, min=76 Packet Sequence # 17 7 0 - 127 Packet Time 24 32 R-R-R-mf Up to 3 EPD RT data sets56 608 to 1824 76-byte EPD data sets from RT LPW Total packet length: max = 235 bytes, min = 83 bytes GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.5 HIC Packets 3.10.5.5.1 HIC1 -- HIC Real-Time Rate, PHA, and Status Data Packet When set active, the CDS provides a real-time "data summing" service at 3 rates/summing intervals for the HIC instrument; this process is described in the 3-310 document. The three rate/interval choices, as indicated in the HIC1 packet's Packet Format ID, are: - 1 bps over a 50 RIM interval - 2 bps over a 25 RIM interval - 5 bps over a 10 RIM interval The intervals normally start and end on RIM boundaries and as such, the MOD91 Count at the included HIC1 Packet Times can assume to be at zero. When requested to change rate, the CDS holds the request until such time as the in- process summing reaches its full interval. At a deactivation of HIC real-time operations, the CDS does not fulfill the full in-process summing interval, choosing instead to send out a HIC1 with the summing values as they are at the time. The HIC1 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of a new rate and PSN = 0 (Mod 4) APID 1 7 2Bh (43) Packet Size (data bytes) 8 9 max=375, min=94 Packet Sequence # 17 7 0 - 127 GLL-3-280 Rev. D, Appendix D (PHASE 2) Packet Format ID 24 4 Structure = xxyy, where xx is "don't care" and yy indicates data acquisition rate: yy=01: @ 1 bps (50 RIM summing) yy=10: @ 2 bps (25 RIM summing) yy=11: @ 5 bps (10 RIM summing) Packet Time 28 20/4* 1/2R-R- R HIC data 48/32* 3000 375 bytes consisting of: a. 16 bytes of status b. 52 12-bit summed rate measurements, and c. Data from the PHA stacks, taking one each from single, double, triple events until the stacks are exhausted. Total packet length: max = 382/380*, min=100/98* bytes * the 1st number is for time included, the 2nd number is for time NOT included. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.5.2 HIC2 -- HIC Data PB Packet The HIC2 packet contains from 1 to 20 12-byte HIC data sets. The data sets are taken from contiguous LPW minor frames that have been accessed by playback from the DMS recorder. The HIC2 packet structure is shown below. . Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of a set and PSN = 0 (Mod 16) APID 1 7 02h (2) Packet Size (data bytes) 8 9 max=240, min=12 Packet Sequence # 17 7 0 - 127 Packet Time 24 32/0* R-R-R-mf Up to 20 HIC data sets 56/24* 96 to 192012-byte HIC data sets from LPW Total packet length: max = 247/243* bytes, min = 19/15* bytes * the 1st number is for time included, the 2nd number is for time NOT included. 3.10.5.5.3 HIC3 -- HIC Record Rate Change Coverage Data Packet Each HIC3 packet contains from 1 to 18 HIC data sets, each of which contains the HIC data taken from a real-time LPW minor frame. A maximum length RRCC function (31 LPW mfs providing 20- 2/3 sec of real-time coverage) will result in 2 HIC3 packets being generated. These packets will be generated without regard to the HIC being set "on". HIC3 packets generated for a HIC in the "off" state, will contain "garbage data". Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, always APID 1 7 16h (22) Packet Size (data bytes) 8 9 max=216, ,min=12 Packet Sequence # 17 7 0 - 127 Packet Time 24 32 R-R-R-mf Up to 18 HIC data sets 56 12 to 1728 12-byte HIC data sets from real-time LPW Total packet length = max=223, min=19 GLL-3-280 Rev. D, Appendix D (PHASE 2) Notes : A HIC Data Set is a 12-byte measurements that consists of 36 bits of Rate data, 12 bits of Tag word, and 36 bits of PHA data, and 12 bits of CRC. A HIC Subpacket consists of 3 data sets read over 3 minor frames. A HIC Instrument Cycle consists of 16 Subpackets. 3.10.5.6 EUV Packets 3.10.5.6.1 EUV1 -- EUV RT Data Packet While the EUV is powered on, it continuously sums the sensor data into its internal 2184-byte buffer. CDS reads out the 2184-byte buffer over a period of 29 RIMs (equivalent to 10 bps) or 59 RIMs (equivalent to 5 bps). The 2184 bytes of EUV data is partitioned into eight 273-byte data sets. One EUV1 packet contains one of the eight data sets that constitute one 2184-byte of instrument data. The order grouping of the EUV1 packet readouts to reconstruct the original 2184 byte set of data is determined by the MOD8 value of the Packet Sequence Number (see PSN description in the EUV1 diagram below). The first of the eight packets contains the time of the start of the summation period, and the last packet of the eight packets contains the time of the end of the summation. Because of selects, deselects, and 6UVRT commands, these EUV1 packet sets can contain data that has been summed for intervals either lesser or greater than the 29 or 59 RIM read-out intervals. The EUV1 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st and last packet of an 8-packet set (see PSN below) APID 1 7 2Ch (44) Packet Size (data bytes) 8 9 =273 Packet Sequence # 17 7 0 - 127 = 0 (MOD8) 1st readout packet = 1 (MOD8), 8th readout packet Packet Time 24 24/0* R-R-R 1/8 of EUV 2184 bytes real-time buffer 48/24* 2184 One of the 8-packet set. The 8 packets constitute a 2184-byte EUV buffer that EUV instrument summed for 29 or 59 RIMs. Total packet length = 279/276* bytes * the 1st number is for time included, the 2nd number is for time NOT included. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.6.2 EUV2 -- EUV Data PB Packet One EUV2 packet contains 21 EUV data sets unless fewer contiguous data sets are available. Each EUV data set is taken from a playback accessed LPW minor frame. The EUV2 packet format is: Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of mode change and PSN = 0 (Mod 16) APID 1 7 03h (3) Packet Size (data bytes) 8 9 max=252, min=12 Packet Sequence # 17 7 0 - 127 Packet Time 24 32/0* R-R-R-mf Up to 21 EUV data sets 56/24* 12 to 2016 12-byte EUV data sets from PB LPW Total packet length: max = 259/255* bytes, min = 19/15* bytes * the 1st number is for time included, the 2nd number is for time NOT included. 3.10.5.7 MAG Packets 3.10.5.7.1 MAG1 -- MAG Real-Time Data Packet The MAG1 real-time data set pickup is six selected bytes from the 20 bytes of MAG data in a real-time LPW minor frame. This data set consists of Instrument- averaged field strength measurements for the Mag X, Y and Z axis. The MAG1 data sets to be assembled into a MAG1 packet are picked by taking its 6-byte MAG1 data sets from a one out of "n" LPW minor frames scheme. The six operationally commandable values of "n" are: One out of every 36 LPW mf's: equates to about 2 bps One out of every 18 LPW mf's: equates to about 4 bps One out of every 12 LPW mf's: equates to about 6 bps One out of every 9 LPW mf's: equates to about 8 bps One out of every 6 LPW mf's: equates to about 12 bps One out of every 4 LPW mf's: equates to about 18 bps When a MAG1 rate change is requested, the existing MAG1 packet in its current state of fill, is sent and the new rate is put into operation. When real-time MAG is deselected and if there is a partially filled MAG1 packet, the CDS sends a shortened (less than the full 30 data sets) MAG1 packet. GLL-3-280 Rev. D, Appendix D (PHASE 2) The MAG1 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description __________________________________________________________________ Time Inc 0 1 =1, for the 1st and PSN = 0 Flag (Mod 16) & 1st packet of FID change APID 1 7 32h (50) Packet Size 8 9 max=180, min=6 (data bytes) Packet Sequence # 17 7 0 - 127 Packet Format ID 24 4 Indicate R/T rates 1h = 2 bps (one of 36 LPW mf's) 2h = 4 bps (one of 18 LPW mf's) 3h = 6 bps (one of 12 LPW mf's) 4h = 8 bps (one of 9 LPW mf's) 5h = 12 bps (one of 6 LPW mf's) 6h = 18 bps (one of 4 LPW mf's) Packet Time 28 28/4* 1/2R-R-R-mf Up to 30 MAG RT data sets (6 bytes each) 56/32* 48 to 1440 Each data set contains 3 measurements (2-byte each) corresponding to the X, Y, and Z axis, respectively. Sec. A2.7.4. __________________________________________________________________ Total packet length: max = 187/184* bytes, min = 13/10* bytes * the 1st number is for time included, the 2nd number is for time NOT included. ? 3.10.5.7.2 MAG2 -- MAG PB Data Packet (Uncompressed ) One MAG PB data set consists of X, Y, and Z axis measurements of two bytes each. One MAG PB subpacket contains two bytes of status data, followed by three contiguous PB data sets. One MAG2 packet contains 24 time-ordered MAG PB subpackets as shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description __________________________________________________________________ Time Inc 0 1 =1, for the 1st and PSN = 0 Flag (Mod 16 APID 1 7 0C h (12) Packet Size 8 9 max=480, min=20 (data bytes) Packet Sequence # 17 7 0 - 127 Packet Time 24 32/0 R-R-R-mf S1 56/24* 16 Status Data X1 72/40* 16 1st X-axis measurement Y1 88/56* 16 1st Y-axis measurement Z1 104/72* 16 1st Z-axis measurement X2 120/88* 16 2nd X-axis measurement Y2 136/104* 16 2nd Y-axis measurement Z2 152/120* 16 2nd Z-axis measurement X3 168/136* 16 3rd X-axis measurement Y3 184/152 16 3rd Y-axis measurement Z3 200/168* 16 3rd Z-axis measurement Up to 23 Additional MAG2 Subpackets 216/184* 160-384 MAG2 PB subpackets as above __________________________________________________________________ Total packet length: max = 487/483* bytes, min = 27/23* bytes * the 1st number is for time included, the 2nd number is for time NOT included. GLL-3-280 Rev. D, Appendix D (PHASE 2) D-118 3.10.5.7.3 MAG3 -- MAG Data PB Packet (Rice compressed) The MAG3 packet is a data compression alternative to the MAG2 packet for the same data. For MAG3, the data is Rice compressed in 9 sensor channels independently. The channels are shown column-wise in the table below. ch 1 ch 2 ch 3 ch. 4 ch. 5.. ch. 6 ch 7 ch 8 ch 9 mf 1 X1 mf 1 Y1 mf 1 Z1 mf 1 X2 mf 1 Y2 mf 1 Z2 mf 1 X3 mf 1 Y3 mf 1 Z3 ... mf 24 X1 mf 24 Y1 mf 24 Z1 mf 24 X2 mf 24 Y2 mf 24 Z2 mf 24 X3 mf 24 Y3 mf 24 Z3 MAG3 compression is performed on data blocks of 8 MAG subpackets. Each MAG3 packet then can contain 1, 2 or 3 Compression blocks that have been processed from 8, 16 or 24 subpackets, respectively. The reference value for the first block is the raw data from the first minor frame, the subsequent block uses the output from the previous block as the reference value within the same channel. For raw data quantities not numbering 8, 16, or 24 subpackets, a MAG2 packet bearing the left-over 1 to 7 uncompressed subpackets will be generated. If compression overall results in expansion of the packet, i.e., uncompressibility, all of the data will be returned in uncompressed MAG2 format. It should be noted that individual expansion of a compression block can occur without causing the entire packet to expand past the raw data size. In this case, the expanded compression block will be returned expanded if other blocks in the same packet compress well enough to keep the total below that of the MAG2 equivalent packet. The MAG3 packet (for a full 24 subpackets) is shown below. Note that the status data are not compressed and are grouped together and placed in the packet as the first two bytes of the packet data area (following the packet time block). Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet and PSN = 0 (Mod 16) APID 1 7 23h (35) Packet Size (data bytes) 8 9 < 480 Packet Sequence # 17 7 0 - 127 (seq # shared with MAG2 packets) Packet Time 24 32/0* R-R-R-mf mf count 56/24* 8 = 8 or 16 or 24 (# of mfs compressed) #mf Status (2-bytes each) 64/32* #mf x 16 Status data are returned raw. X1 pre-split bits 8 X1 ref 15 mf 1 X1 raw data value X1 comp. data block 1 variable coder ID + Split Bits + encoded [?(mf1..mf8)] X1 pre-split bits 8 X1 comp data block 2 variable coder ID + Split Bits + encoded [?(mf8..mf16)] GLL-3-280 Rev. D, Appendix D (PHASE 2) X1 pre split bits 8 X1 comp. data block 3 variable coder ID + Split Bits + encoded[??(mf16..mf24)] Y1 pre-split bits 8 Y1 ref 15 mf 1 Y1 raw data value Y1 comp. data block 1 variable coder ID + Split Bits + encoded [?(mf1..mf8)] Y1 pre- split bits 8 Y1 comp data block 2 variable coder ID + Split Bits + encoded [?(mf8..mf16)] Y1 pre split bits 8 Y1 comp. data block 3 variable coder ID + Split Bits + encoded[?mf16..mf24)] Z1 pre-split bits 8 Z1 ref 15 mf 1 Z1 raw data value Z1 comp. data block 1 variable coder ID + Split Bits + encoded[?(mf1..mf8)] Z1 pre-split bits 8 Z1 comp data block 2 variable coder ID + Split Bits + encoded[?(mf8..mf16)] Z1 pre split bits 8 Z1 comp. data block 3 variable coder ID + Split Bits + encoded[?mf16..mf24)] X2 pre-split bits 8 X2 ref 15 mf 1 X2 raw data value X2 comp. data block 1 variable coder ID + Split Bits + encoded[?(mf1..mf8)] X2 pre-split bits 8 X2 comp data block 2 variable coder ID + Split Bits + encoded[?(mf8..mf16)] X2 pre split bits 8 X2 comp. data block 3 variable coder ID + Split Bits + encoded[?mf16..mf24)] Y2 pre-split bits 8 Y2 ref 15 mf 1 Y2 raw data value Y2 comp. data block 1 variable coder ID + Split Bits + encoded[?(mf1..mf8)] Y2 pre-split bits 8 Y2 comp data block 2 variable coder ID + Split Bits + encoded[?(mf8..mf16)] Y2 pre split bits 8 Y2 comp. data block 3 variable coder ID + Split Bits + encoded[?mf16..mf24)] Z2 pre-split bits 8 Z2 ref 15 mf 1 Z2 raw data value Z2 comp. data block 1 variable coder ID + Split Bits + encoded[?(mf1..mf8)] Z2 pre-split bits 8 Z2 comp data block 2 variable coder ID + Split Bits + encoded[?(mf8..mf16)] Z2 pre split bits 8 Z2 comp. data block 3 variable coder ID + Split Bits + encoded[?mf16..mf24)] X3 pre-split bits 8 X3 ref 15 mf 1 X3 raw data value X3 comp. data block 1 variable coder ID + Split Bits + encoded[?(mf1..mf8)] X3 pre-split bits 8 X3 comp data block 2 variable coder ID + Split Bits + encoded[?(mf8..mf16)] X3 pre split bits 8 X3 comp. data block 3 variable coder ID + Split Bits + encoded[?mf16..mf24)] Y3 pre-split bits 8 Y3 ref 15 mf 1 Y3 raw data value GLL-3-280 Rev. D, Appendix D (PHASE 2) Y3 comp. data block 1 variable coder ID + Split Bits + encoded[?(mf1..mf8)] Y3 pre-split bits 8 Y3 comp data block 2 variable coder ID + Split Bits + encoded[?(mf8..mf16)] Y3 pre split bits 8 Y3 comp. data block 3 variable coder ID + Split Bits + encoded[?mf16..mf24)] Z3 pre-split bits 8 Z3 ref 15 mf 1 Z3 raw data value Z3 comp. data block 1 variable coder ID + Split Bits + encoded[?(mf1..mf8)] Z3 pre-split bits 8 Z3 comp data block 2 variable coder ID + Split Bits + encoded[?(mf8..mf16)] Z3 pre split bits 8 Z3 comp. data block 3 variable coder ID + Split Bits + encoded[?mf16..mf24)] Packet length = variable bytes < 487 bytes GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.7.4 MAG4 -- MAG Record Rate Change Coverage Data Packet The MAG3 packet contains from one to eighteen 20-byte MAG RT subpackets taken from the real-time LPW minor frames. A maximum length RRCC function (31 LPW mfs providing 20-2/3 seconds of real-time coverage) will result in 2 MAG4 packets being generated. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description __________________________________________________________________ Time Inc 0 1 =1, for the 1st and PSN = 0 Flag (Mod 16 APID 1 7 1B h (27) Packet Size 8 9 max=380, min=20 (data bytes) Packet Sequence # 17 7 0 - 127 Packet Time 24 32 R-R-R-mf Up to 18 MAG2 Subpackets 216/184 160-284 MAG2 PB subpackets as above __________________________________________________________________ Total packet length: max = 387 bytes, min = 27 bytes Time always included. 3.10.5.8 NIMS Packets There are 7 types of NIMS packets. One (NIMS1) delivers realtime data; the rest (NIMS2 -> NIMS7) package CDS-edited NIMS DMS Playback data for transfer to the ground. The six Playback packets are 3 uncompressed/compressed paired sets; the major difference between these sets is the rate at which they were recorded to the DMS. The NIMS Playback packets operate in much the same manner; the following statements apply to all six packets. 1) The NIMS playback process is based on delivering edited half-minor-frame blocks of NIMS data; and all are time tagged in the packets by a times 2 MOD91 count that counts 0 to 181 in a RIM. 2) Unlike all other GLL uncompressed/compressed paired packet sets, a compression that results in expansion will not result in the default of issuing the more space-efficient uncompressed packet. The results of the compression process, larger or not, will be delivered in the "compressed" packet. 3) Data within each packet takes the form of back-to-back NIMS PB subpackets. There are 4 types of these subpackets (See 3.10.5.8.8); they are self-identified by the first two bits of the subpacket. The data area of each NIMS Playback packet starts with the first byte of a subpacket; one or more subpackets can be contained in a packet; subpackets cannot be split across packet boundaries. NOTE: Subpacket formats 1 and 2 carry the Playback sensor data; format 2 is a data bytes extension to format 1 when the format 1's playback bits exceed the packet's data byte limit of 511 bytes. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.8.1 NIMS1 -- NIMS Real-Time Data Packet The NIMS real-time pickup is 96 bytes per RTI. The data are read from a dedicated location in NIMS memory. Each 96-byte pickup consists of a flag byte, a length byte specifying the number of valid data bytes, and 0 to 85 data bytes followed by fill if needed. Based on the received "length" value, the CDS extracts the valid data bytes from the pickup and collects them in a 2048-byte buffer until either the buffer is full or 12 minor frames, i.e., 120 RTI's, have passed. From this buffer, the CDS produces up to 4 NIMS1 packets, each up to 511 bytes in length. If less than 5 bytes are left over after producing a packet, those bytes are discarded. After producing the NIMS1 packet set, the CDS will not start its next collecting/filling of the data buffer until the number of RIMS equal to the number of bytes collected into the previous packet buffer divided by 75 has passed. In this way the CDS maintains the NIMS 10 bps real-time collection rate. GLL-3-280 Rev. D, Appendix D (PHASE 2) The NIMS1 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of a start and PSN = 0 (Mod 16) APID 1 7 2Eh (46) Packet Size (data bytes) 8 9 < 511 Packet Sequence # 17 7 0 - 127 Packet Time 24 32/0* R-R-R-mf/2** NIMS data 56/24* 4088 One or half instrument cycle Total maximum packet length = 518/514* bytes * the 1st number is for time included, the 2nd number is for time NOT included. ** mf/2 is a 1/2 minor frame count, (counts 0 to 181 over a RIM interval). 3.10.5.8.2 NIMS2 -- NIMS 11.52 Kbps Data PB Packet (Uncompressed) The NIMS2 packet is based on NIMS 11.52 Kbps data taken from one of 10 recorded TDM formats. (See Table 28 for list of formats). The NIMS2 packet is paired with and shares a Packet Sequence Number with the NIMS5 packet. The NIMS2 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of a set, the packet that starts at a RIM rollover, and when packet sequence number rolls over APID 1 7 05h (5) Packet Size (data bytes) 8 9 ?511 Packet Sequence # 17 7 0 - 127 (seq # shared with NIMS5 packets) Format ID 24 4 00h Packet Time 28 20/4* 1/2R-R-R MF/2 48/32* 8 mf/2 (always included) NIMS PB data (edited by CDS) 56/40* variable Contains one or more NIMS PB subpackets. Total maximum packet length = 518/514* bytes * the 1st number is for time included, the 2nd number is for time NOT included. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.8.3 NIMS3 -- NIMS 6.168 Kbps Data PB Packet (Uncompressed) The NIMS3 packet is based on NIMS 6.168 Kbps data taken from a recorded LPU minor frame. The NIMS3 packet is paired with and shares a Packet Sequence Number with the NIMS6 packet. The NIMS3 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of a set, the packet that starts at a RIM rollover, and when packet sequence number rolls over APID 1 7 06h (6) Packet Size (data bytes) 8 9 ?511 Packet Sequence # 17 7 0 - 127 (seq # shared with NIMS6 packets) Packet Format ID 24 4 04h Packet Time 28 20/4* 1/2R-R-R MF/2 48/32* 8 mf/2 (always included) NIMS PB data (edited by CDS) 56/40* variable Contains one or more NIMS PB subpackets.. Total maximum packet length = 518/514* bytes * the 1st number is for time included, the 2nd number is for time NOT included. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.8.4 NIMS4 -- NIMS 2.592 Kbps Data PB Packet (Uncompressed) The NIMS4 packet is based on NIMS 2.592 Kbps data taken from a recorded LNR minor frame. The NIMS4 packet is paired with and shares a Packet Sequence number with the NIMS7 packet. The NIMS4 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of a set, the packet that starts at a RIM rollover, and when packet sequence number rolls over APID 1 7 07h (7) Packet Size (data bytes) 8 9 max =511 Packet Sequence # 17 7 0 - 127 (seq # shared with NIMS7 packets) Packet Format ID 24 4 08h Packet Time 28 20/4* 1/2R-R-R MF/2 48/32* 8 mf/2 (always included) NIMS PB data (edited by CDS) 56/40* variable Contains one or more NIMS PB subpackets. Total maximum packet length = 518/514* bytes * the 1st number is for time included, the 2nd number is for time NOT included. 3.10.5.8.5 NIMS5 -- NIMS 11.52 Kbps Data PB Packet (Rice Compressed) The NIMS5 packet is based on NIMS 11.52 Kbps data. The NIMS5 packet is a compressed data alternative to the NIMS2 uncompressed packet; NIMS format 1 and format 2 subpackets will have their data areas Rice-compressed in the NIMS5 packet. The NIMS5 packet shares a Packet Sequence number with the NIMS2 packet. GLL-3-280 Rev. D, Appendix D (PHASE 2) The NIMS5 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of a set, the packet that starts at a RIM rollover, and when packet sequence number rolls over APID 1 7 26h (38) Packet Size (data bytes) 8 9 max=511 Packet Sequence # 17 7 0 - 127 (seq # shared with NIMS2 packets) Packet Format ID 24 4 00h Packet Time 28 20/4* 1/2R-R-R MF/2 48/32* 8 mf/2 (always included) NIMS PB data (edited by CDS) 56/40* variable Contains one or more NIMS PB subpackets. Total maximum packet length = 518/514* bytes * the 1st number is for time included, the 2nd number is for time NOT included. 3.10.5.8.6 NIMS6 -- NIMS 6.168 Kbps Data PB Packet (Rice Compressed) The NIMS6 packet is based on NIMS 6.168 Kbps data. The NIMS6 packet is a compressed data alternative to the NIMS3 uncompressed packet; NIMS format 1 and format 2 subpackets will have their data areas Rice-compressed in the NIMS6 packet. The NIMS6 packet shares a Packet Sequence Number with the NIMS3 packet. The NIMS6 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of a set, the packet that starts at a RIM rollover, and when packet sequence number rolls over APID 1 7 27h (39) Packet Size (data bytes) 8 9 max=511 Packet Sequence # 17 7 0 - 127 (seq # shared with NIMS3 packets) Packet Format ID 24 4 04h Packet Time 28 20/4* 1/2R-R-R MF/2 48/32* 8 mf/2 (always included) NIMS PB data (edited by CDS) 56/40* variable Contains one or more NIMS PB subpackets. Total maximum packet length = 518/514* bytes * the 1st number is for time included, the 2nd number is for time NOT included. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.8.7 NIMS7 -- NIMS 2.592 Kbps Data PB Packet (Rice Compressed) The NIMS7 packet is based on NIMS 2.592 Kbps data. The NIMS7 packet is a compressed data alternative to the NIMS4 uncompressed packet; NIMS format 1 and format 2 subpackets will have their data areas Rice-compressed in the NIMS7 packet. The NIMS7 packet shares a Packet Sequence Number with the NIMS4 packet. GLL-3-280 Rev. D, Appendix D (PHASE 2) The NIMS7 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of a set, the packet that starts at a RIM rollover, and when packet sequence number rolls over APID 1 7 28h (40) Packet Size (data bytes) 8 9 max=511 Packet Sequence # 17 7 0 - 127 (seq # shared with NIMS4 packets) Packet Format ID 24 4 08h Packet Time 28 20/4* 1/2R-R-R MF/2 48/32* 8 mf/2 (always included) NIMS PB data (edited by CDS) 56/40* variable Contains one or more NIMS PB subpackets. Total maximum packet length = 518/514* bytes * the 1st number is for time included, the 2nd number is for time NOT included. 3.10.5.8.8 NIMS Subpacket Types 3.10.5.8.8.1 NIMS PB Subpacket Format 0 -- Zero Count This subpacket tells how many consecutive half-minor-frames were skipped and contains no data for those half-minor-frames. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description ID 0 2 =00 Zero Count 2 6 Number of consecutive half-minor frames without any data up to a maximum of 63. Total Subpacket length = 1 byte 3.10.5.8.8.2 NIMS PB Subpacket Format 1 -- Normal Data (Compressed or Uncompressed ) This subpacket contains data from one half-minor-frame. The "Data field in this subpacket will be Rice-compressed for inclusion in the NIMS5, NIMS6, and NIMS7 packets. The Length is the total Length of the subpacket, including ID, length, flags, mirror direction, mask and data. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description ID 0 2 =01 Length 2 9 Total subpacket length (not just data length). Mask Present flag 11 1 =1, if the 17-bit Mask is present GLL-3-280 Rev. D, Appendix D (PHASE 2) Error flag 12 2 come from instrument data Mirror Direction 14 1 come from instrument data Mask 15 17/1* each bit corresponds to a detector present in the data. If the mask is not present, a one bit fill is used to align the data at byte boundary Data 32/16* variable NIMS Sensor data * x/y, x=Mask present and y=Mask not present 3.10.5.8.8.3 NIMS PB Subpacket format 2 -- Remaining data (Compressed or Uncompressed) This subpacket is a continuation of Format 1 subpacket. If the data from the half- minor-frame would cause the Format 1 subpacket to overflow the packet boundary, the remaining data will be put into the Format 2 subpacket. The "Data" field in this subpacket will be Rice compressed for inclusion in the NIMS5, NIMS6, and NIMS7 packets. The Length is the number of remaining data bytes, including the ID, length and spare bytes. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description ID 0 2 =10 Length 2 9 Total subpacket length (not just data length) Spare 11 5 Padded with zeros to align the byte boundary Data 16 variable more NIMS sensor data GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.8.8.4 NIMS PB Subpacket Format 3 -- Observation Start & RIM Rollover This subpacket is included in the packet when an Observation Start occurs (as indicated by the Playback Table) and when a RIM rollover has occurred. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description ID 0 2 =11 Spare 2 1 =0 or 1 Rate Control RTI Blocking Mask 3 5 for down mirror scans Spare 8 2 spare bits Mirror Direction for Commanded RTI Mask 10 1 0 = up 1 = down Commanded RTI Mask 11 5 Most recent commanded mask Total subpacket size = 2 bytes 3.10.5.9 PLS Packets 3.10.5.9.1 PLS1 -- PLS Real-Time Data Packet The CDS executes a PLS real-time data pickup of 226 bytes from the PLS Instrument every minor frame time. Each pickup contains a hand-shaking byte as its first byte. If this first byte is zero, the pickup is always discarded as a no-data transfer. The CDS exercises a delay counter mechanism (no "good" pickup is kept until the counter counts down) on the remaining "good" pickups to achieve the 6 real-time data rates allowed to the PLS data. The selected pickup is assembled into the packet by discarding the non-zero handshaking byte and placing the remaining 225 bytes into the data portion of the PLS1 packet. Data rate changes are affected by simply changing to the appropriate value as the delay counter's set value. GLL-3-280 Rev. D, Appendix D (PHASE 2) The PLS1 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, for the 1st and PSN = 0 (Mod 16) & at FID change. APID 1 7 2Dh (45) Packet Size (data bytes) 8 9 =225 Packet Sequence # 17 7 0 - 127 (seq # shared with PLS3 packets) Packet Format ID 24 4 Indicate R/T rates 1h: 5 bps 4h: 20 bps 2h: 10 bps 5h: 30 bps 3h: 15 bps 6h: 40 bps Packet Time 28 28/4* 1/2R-R-R-mf a PLS RT data pickup 56/32* 1800 225 bytes from Instrument (Sec A2.9) Total packet length = 232/229* bytes Note: The PLS1 packet will always have 225 bytes of PLS data. The PLS Instrument cannot support its real-time PLS1 function concurrently with providing its real-time support of the real-time LPW recording function. The transitions between these two mutually exclusive modes of operation are as follows: ??Real-time PLS1 to real-time LPW Recording: All support of the real-time PLS1 packet building is terminated and the recording support function is activated. Any already accumulated data for the CDS is discarded. ??Real-time LPW Recording to real-time PLS1: If the RTS real-time is enabled for PLS, the PLS1 process commences immediately. 3.10.5.9.2 PLS2 -- PLS Data PB Packet (Uncompressed) Each PLS2 packet contains from 1 to 9 PLS subpackets; each subpacket consists of the 51 bytes of PLS data present in the playback accessed LPW minor frames. All of the subpackets in any given PLS2 packet are contiguous to each other. The PLS2 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of mode change and PSN = 0 (Mod 16) APID 1 7 04h (4) Packet Size (data bytes) 8 9 max=459, min=51 Packet Sequence # 17 7 0 - 127 (seq # shared with PLS3 packets) Packet Time 24 32/0* R-R-R-mf GLL-3-280 Rev. D, Appendix D (PHASE 2) Up to 9 PLS data subpackets 56/24* 408 to 3672 51-byte subpackets from PB LPW Total packet length: max = 466/462* bytes, min = 58/54* bytes * the 1st number is for time included, the 2nd number is for time NOT included. 3.10.5.9.3 PLS3 -- PLS Data PB Packet (Rice compressed) The PLS3 contains the same type of data as the PLS2. Nine LPW records of PLS data are pre-processed for data compression. The data is compressed in 51 sensor channels independently. The channels are shown column-wise in the table below. ch 1 ch 2 ch 3 ... ch 51 mf 1 byte 1 mf 1 byte 2 mf 1 byte 3 ... mf 1 byte 51 mf 2 byte 1 mf 2 byte 2 mf 2 byte 3 ... mf 2 byte 51 ... ... ... ... ... mf 9 byte 1 mf 9 byte 2 mf 9 byte 3 ... mf 9 byte 51 GLL-3-280 Rev. D, Appendix D (PHASE 2) The compressed packet is as follows: Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of mode change and PSN = 0 (Mod 16) APID 1 7 22h (34) Packet Size (data bytes) 8 9 ??459 Packet Sequence # 17 7 0 - 127 (seq # shared with PLS2 packets) Packet Time 24 32/0* R-R-R-mf mf count 56/24* 8 =9 (# of mfs compressed) ch 1 ref 64/32* 8 mf 1 byte 1 ch 1 comp. data 72/40* variable coder ID + Split Bits + encoded[??byte1(mf1..mf9)] ch 2 ref 8 mf 1 byte 2 ch 2 comp. data variable coder ID + Split Bits + encoded[??byte2(mf1..mf9)] ... ch 51 ref 8 mf 1 byte 51 ch 51 comp. data variable coder ID + Split Bits + encoded[??byte51(mf1..mf9)] Max packet length = < 466/462* bytes (*) the 1st number is for time included, the 2nd number is for time NOT included. 3.10.5.9.4 PLS4 -- PLS Record Rate Change Coverage Data Packet Each PLS4 packet contains from 1 to 5 PLS data sets, each of which consists of the 51 bytes of PLS data taken from a real-time LPW minor frame. A maximum length RRCC function (31 LPW mf's providing 20-2/3 seconds of real-time coverage) will result in 7 PLS4 packets being generated. GLL-3-280 Rev. D, Appendix D (PHASE 2) The PLS4 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, always APID 1 7 18h (24) Packet Size (data bytes) 8 9 max=255, min=51 Packet Sequence # 17 7 0 - 127 Packet Time 24 32 R-R-R-mf Up to 5 PLS RT subpackets 56 408 to 2040 51-byte PLS subpackets from RT LPW Total packet length: max = 262 bytes, min = 58 bytes (*) the 1st number is for time included, the 2nd number is for time NOT included. 3.10.5.10 PPR Packets 3.10.5.10.1 PPR1 -- PPR Data Playback Uncompressed Packet A PPR1 packet contains up to 20 PPR PB data sets taken from LPW minor frames resulting from a playback operation. The data sets consist of the 18 bytes of PPR data available in the LPW format and all of the data sets in the PPR1 packet are from contiguous LPW minor frames. The PPR1 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of a burst and when PSN = 0 (Mod 32) APID 1 7 0Bh (11) Packet Size (data bytes) 8 9 max=360 min=18 Packet Sequence # 17 7 0 - 127 (seq # shared with PPR2 packets) Packet Time 24 32/0* R-R-R-mf Instrument Status 56/24* 48 A2.10.3 Status & Science 104/72* 8 A2.10.4 PPR Sci. Data 1 112/80* 24 A2.10.5 PPR Sci. Data 2 136/104* 32 A2.10.6 PPR Sci. Data 3 168/136* 32 A2.10.7 Up to 19 additional PPR PB subpackets 200/168* 144 to 2736 18-byte PPR instrument sub-packet data (see shaded area) Total packet length: max = 367/363* bytes, min = 25/21* bytes * the 1st number is for time included, the 2nd number is for time NOT included. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.10.2 PPR2 -- PPR Data PB Compressed Packet The PPR2 packet is an alternate format for the same data accessed for the PPR1 packet. If the full 20 contiguous LPW minor frame data is not available or if the attempted Rice compression results in expansion, the PPR2 packet is abandoned and a PPR1 packet with the same data is sent. Note that the PPR1 and PPR2 packets share the same Packet Sequence number. The data is Rice compressed in 18 sensor (all 18 bytes of the data set) independently. The channels are shown column-wise in the table below. ch 1 ch 2 ch 3 ... ch 18 mf 1 byte 1 mf 1 byte 2 mf 1 byte 3 ... mf 1 byte 18 mf 2 byte 1 mf 2 byte 2 mf 2 byte 3 ... mf 2 byte 18 ... ... ... ... ... mf 20 byte 1 mf 20 byte 2 mf 20 byte 3 ... mf 20 byte 18 The PPR2 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet and PSN = 0 (Mod 32) APID 1 7 24h (36) Packet Size (data bytes) 8 9 < 360 Packet Sequence # 17 7 0 - 127 (seq # shared with PPR1 packets) Packet Time 24 32/0* R-R-R-mf mf count 56/24* 8 =20 (# of mf's compressed ) ch 1 ref. value 64/32* 8 mf 1 byte 1 ch 1 comp. data 72/40* variable coder ID + Split Bits + encoded[??byte1(mf1..mf20)] ch 2 ref value 8 mf 1 byte 2 ch 2 comp. data variable coder ID + Split Bits + encoded[??byte2(mf1..mf20)] ... ... ch 18 ref. value 8 mf 1 byte 18 ch 18 comp. data variable coder ID + Split Bits + encoded[??byte18(mf1..mf20)] Total maximum packet length = < 367/363* bytes * the 1st number is for time included, the 2nd number is for time NOT included. 3.10.5.10.3 PPR3 -- PPR Burst to Tape Data Uncompressed Packet A PPR3 packet houses and transports the contents of a playbacked BPT tape record. The BPT record is a TDM format that contains 14 sets of MOD91 count, edited PPR subpacket data and GLL-3-280 Rev. D, Appendix D (PHASE 2) edited AACS data. The PPR subpacket editing (done by BPT) consists of discarding the 2nd byte from a standard PPR subpacket. The data access and its recording are described in the BPT description given in 3.9.4E. GLL-3-280 Rev. D, Appendix D (PHASE 2) The PPR3 packet structure is shown below. . Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of a burst and PSN = 0 APID 1 7 15h (21) Packet Size (data bytes) 8 9 =308 Packet Sequence # 17 7 0 - 127 (seq # shared with PPR4 packets) Packet Time 24 24/0* R-R-R mf count 48/24* 8 MOD91 value of 1st data set Instrument Status 56/32* 40 A2.10.3, (byte 2 of PPR subpacket removed by BDT) Status & Science 96/72* 8 A2.10.4 PPR Sci. Data Group 1 104/80* 24 A2.10.5 PPR Sci. Data Group 2 128/104* 32 A2.10.6 PPR Sci. Data Group 3 160/136* 32 A2.10.7 AACS PL RA 192/168* 16 AACS PL DEC 208/184* 16 13 additional BDT subpackets 224/200* 176 to 2288Each BDT subpacket contains 22-byte mf/PPR/AACS data Total packet length = 314/311* bytes * the 1st number is for time included, the 2nd number is for time NOT included. 3.10.5.10.4 PPR4 -- PPR Burst to Tape Data Compressed Packet The PPR4 packet is an alternate format for the same data accessed (playback of BPT record) for the PPR3 packet. If the attempted Rice compression results in expansion, the PPR4 packet is abandoned and a PPR3 packet with the same data is sent. Note that the PPR3 and PPR4 packets share the same Packet Sequence number. The data is Rice compressed in 20 channels independently (18 one-byte channels, 22-byte channels). The channel arrangements are shown column-wise below. Note the byte 2 discards from the original PPR data sets. (See Instrument Status in PPR3 diagram). ch 1 ch 2 ch 3 ch 18 ch 19 ch 20... *mf MOD91 ct PPR byte 1 PPR byte 3 ... PPR byte 18 PL Dec 1 PL RA 1 *mf MOD91 ct PPR byte 1 PPR byte 3 ... PPR byte 18 PL Dec 2 PL RA 2 ... ... ... ... *mf MOD91 ct PPR byte 1 PPR byte 3 ... PPR byte 18 PL Dec 14 PL RA 14 * all are 8-bit bit-reversed (from its BDT/PPR2 form) GLL-3-280 Rev. D, Appendix D (PHASE 2) The two AACS measurements are compressed as 16-bit data, resulting in pre- split bits being inserted by the compressor before the reference values, while the mf count and the instrument data are compressed as 8-bit values. The compressed packet format is described as follows. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of a burst and when PSN = 0 APID 1 7 29h (41) Packet Size (data bytes) 8 9 < 308 Packet Sequence # 17 7 0 - 127 (seq # shared with PPR3 packets) Packet Time 24 24/0* R-R-R Subpacket count 48/24* 8 spare = 1 ch.1 Ref. 56/32* 8 mf count (8-bit bit reversed) ch 1 Comp. data 64/40* variable mf count compressed data ch 2 Ref. 8 PPR subpacket 1 byte 1 ch 2 Comp. data variable coder ID + Split Bits + encoded ?[byte 1(subpkt1..subpkt14)] ch.3 Ref. 8 PPR subpacket 1 byte 3 ch 3 Comp. data variable coder ID + Split Bits + encoded ?[byte 3(subpkt1..subpkt14)] ... ... ch 18 Ref 8 PPR subpacket 1 byte 18 ch 18 Comp. data variable coder ID + Split Bits + encoded ?[byte 18(subpkt1..subpkt14)] ch 19 pre-split bits. 14 PL RA pre-split bits ch 19 Ref. Value 15 PL RA of subpacket 1 ch 19 Comp. data variable PL RA compressed data (coder ID + Split Bits + encoded delta) ch 20 pre-split bits 14 PL Dec pre-split bits ch 20 Ref. 15 PL Dec of subpacket 1 ch 20 Comp. data variable PL Dec compressed data (coder ID + Split Bits + encoded delta) Total packet length = variable bytes * the 1st number is for time included, the 2nd number is for time NOT included. 3.10.5.11 PWS High Rate Packets 3.10.5.11.1 PWH1 -- PWS High Rate Data Fill Packet CDS assembles the PWH1 packet by using the PWS high rate data taken from the first 435 bytes of the PWS High-rate input buffer in the CDS. This data is generally the same as that being collected for the PWH5 portion of the LPW minor frames. The PWH1 packet is only used as a downlink filler at the VCDU level. GLL-3-280 Rev. D, Appendix D (PHASE 2) The PWH1 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, always APID 1 7 2Fh (47) Packet Size (data bytes) 8 9 435 Packet Sequence # 17 7 0 - 127 Packet Time 24 32 R-R-R-mf PWS Hi-rate data 56 3480 Wideband Waveform Receiver Data filler 3512 24 Fill to exactly fit a VCDU Total packet length = 442 bytes 3.10.5.11.2 PWH2 -- PWS High Rate Data Playback (MPW) Packet The PWH2 contains PWS High Rate PB data taking from a playback MPW data frames. Up to 4 frames of PWS subpackets are put in one PWH2 packet. GLL-3-280 Rev. D, Appendix D (PHASE 2) The Packet Format ID contains the RTI # and 1-of-n-line editing value. The high order 4-bits of the FID are used to indicate the RTI of the start of the data. The low order 4-bit of the FID is the value of n, where n is used for CDS processing of skips n-1 RTIs of data after each RTI read. The PWH2 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, first and PSN = 0 (Mod 16), at FID change APID 1 7 0Fh (15) Packet Size (data bytes) 8 9 max=256, min=64 Packet Sequence # 17 7 0 - 127 Packet Format ID 24 8 xxxxyyyy, xxxx= RTI, yyyy=n for 1 of n lines return editor. Packet Time 32 32/0* R-R-R-mf 1st PWS mf 64/32* 512 Sec. A2.11.2. Taken @ packet time (tagged or derived) + xxxx 2nd PWS mf 576/544* 512 1st mf time + yyyy*(1 RTI), 3rd PWS mf 1088/1056* 512 1st mf time + 2yyyy*(1 RTI) 4th PWS mf 1600/1568* 512 1st mf time + 3yyyy*(1 RTI) Total packet length: max = 264/260* bytes, min = 72/68* bytes * the 1st number is for time included, the 2nd number is for time NOT included. 3.10.5.11.3 PWH3 -- PWS High Rate Data Playback (MPP) Packet The PWH3 packet contains PWS High Rate PB data taken from the MPP minor frame. One or two MPP frames of PWS subpackets are put in one PWH3 packet. The Packet Format ID has the same structure and semantic as that of the PWH2 packet. The PWH3 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, 1st and PSN = 0 (Mod 16) at FID change APID 1 7 10h (16) Packet Size (data bytes) 8 9 max=320, min=160 Packet Sequence # 17 7 0 - 127 Packet Format ID 24 8 xxxxyyyy, xxxx= RTI, yyyy=n for 1 of n lines return editor. Packet Time 32 32/0* R-R-R-mf 1st PWS mf 64/32* 1280 Sec. A2.11.7 taken @ packet time (tagged or derived) + xxxx GLL-3-280 Rev. D, Appendix D (PHASE 2) 2nd PWS mf 1344/1312* 1280 1st mf time + yyyy*(1 RTI) Total packet length: max = 328/324* bytes, min = 168/164* bytes The last packet of the MPP mode may contain only one PWS minor frame. * the 1st number is for time included, the 2nd number is for time NOT included. 3.10.5.11.4 PWH4 -- PWS High Rate Data Playback (HPW) Packet The PWH4 packet contains PWS High Rate PB data taken from an HPW minor frame. Each PWH4 packet contains one-half of the PWS subpacket taken from the HPW minor frame; as such each HPW minor frame generates 2 PWH4 packets. The PWH4 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, 1st and PSN = 0 (Mod 16) at FID change APID 1 7 11h (17) Packet Size (data bytes) 8 9 =394 Packet Sequence # 17 7 0 - 127 Packet Format ID 24 8 xxxxyyyy, xxxx= RTI; yyyy=n for 1 of n lines return editor in the lst packet, yyyy=0 in the 2nd packet. Packet Time 32 32/0* R-R-R-mf 1/2 of a PWS mf 64/32* 3152 Sec. A2.11.4 time = packet time (tagged or derived) + xxxx. one HPW frame is 788 bytes long which fits into two packets Total packet length = 402/398* bytes * the 1st number is for time included, the 2nd number is for time NOT included. 3.10.5.11.5 PWH5 -- PWS High Rate Data Playback (LPW): LRS Packet The PWH5 packet uses data from the PWS hi-rate area of the LPW minor frame that was previously used by the LRS format for its Golay code. The 1-of-n-line editor is used and the n value is indicated by the low order 4-bit of the Packet Format ID in the PWH5 packet. The high order 4-bit of the format ID is always zeros and should be ignored. One PWH5 packet can contain either one or two subpackets from the two low minor frames. (The first and last packets of the PWH5 playback may contain less than 2 LPW subpackets). The PWH5 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description GLL-3-280 Rev. D, Appendix D (PHASE 2) Time Include Flag 0 1 =1, 1st and PSN = 0 (Mod 16) APID 1 7 08h (8) Packet Size (data bytes) 8 9 max=432, min=216 Packet Sequence # 17 7 0 - 127 Packet Format ID 24 8 0000yyyy, yyyy=n for 1 of n lines return editor. Packet Time 32 32/0* R-R-R-mf 1st PWS subpackets 64/32* 1728 Sec. A2.11.1A 2nd PWS subpackets 1792/1760* 1728 consecutive mf of the 1st LPW record Total packet length ??440/436* bytes, min = 224/220* bytes * the 1st number is for time included, the 2nd number is for time NOT included. 3.10.5.12 PWS Low Rate Packets 3.10.5.12.1 PWL1 -- PWS Low Rate Data RT ECO Packet The PWS RT pickup is 20 bytes per LPW mf in RTI 1. The PWS Low Rate RT data are edited, rearranged, and sent through an 8x8 ICT compression at one of six commandable target compression ratios, giving effective post compression data rates of 5, 10, 15, 20, 30, and 40 bps. There is a global variable bit which tells the ICT handler whether or not to use the compression rate specified by the RT part of the telemetry mode. If the bit is set, the Q factor which determines the target level of compression comes from the 5 bps mode, rather than from the commanded RT mode. If the actual rate after compression exceeds the target rate, the CDS will adjust the Q factor to lower the actual rate. The PWL1 packet contains E-field measurement, its structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of a new rate and PSN = 0 (Mod 32) APID 1 7 33h (51) Packet Size (data bytes) 8 9 < 511 Packet Sequence # 17 7 0 - 127 Packet Format ID 24 4 0xxx: Normal pkt 1xxx: Continuation packet xxx=000: 3 bps xxx=001: 5 bps xxx=010: 10 bps xxx=011: 15 bps xxx=100: 20 bps xxx=101: 30 bps xxx=110: 40 bps GLL-3-280 Rev. D, Appendix D (PHASE 2) Packet Time 28 28/4* 1/2R-R-R-mf ICT Compression PWS Data Strip 56/32* var. A strip starts with a new packet. If a strip can't fit in one packet, the remaining data of the strip is packed into continuous packets. The PWS data strip format is defined in 3.10.5.12.1.1 below. Max packet length = 518/515* bytes * the 1st number is for time included, the 2nd number is for time NOT included. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.12.1.1 ICT Compression PWS Data Strip Format The PWS Low Rate RT data from the ICT consists of a strip of 19 8x8 blocks. Each block of data consists of Huffman codes from the 8x8 region following a 1- bit flag to indicate if an expansion has resulted from the ICT compression. In the case of expansion, the data returned are truncated at 64 bytes. The data from the compression blocks within the strip are packed into bytes with no gaps, but with up to 7 bits of zero fill after the last block in the strip. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description 1st 8x8 block Compression flag 1 1: data expanded, truncated at 64 bytes 0: data compressed compression data ??512 If Compression flag = 1, 64 bytes. 2nd 8x8 block Compression flag 1 1: data expanded, truncated at 64 bytes 0: data compressed compression data ??512 If Compression flag = 1, 64 bytes. . . . 19th 8x8 block Compression flag 1 1: data expanded, truncated at 64 bytes 0: data compressed compression data ??512 If Compression flag = 1, 64 bytes. filler ?7 zero fill to make the packet byte aligned GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.12.2 PWL2 -- PWS Low Rate Data RT BCO Packet The PWL2 packet contains B-field measurement of PWS Low Rate RT data. The data is collected, processed, and compressed the same way as the E-field data described above. The PWL2 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of a new rate and PSN = 0 (Mod 32) APID 1 7 34h (52) Packet Size (data bytes) 8 9 < 511 Packet Sequence # 17 7 0 - 127 Packet Format ID 24 4 0xxx: Normal pkt 1xxx: Continuation packet xxx=000: 3 bps xxx=001: 5 bps xxx=010: 10 bps xxx=011: 15 bps xxx=100: 20 bps xxx=101: 30 bps xxx=110: 40 bps Packet Time 28 28/4* 1/2R-R-R-mf ICT Compression PWS Data Strip 56/32* var. A strip starts with a new packet. If a strip can't fit in one packet, the remaining data of the strip is packed into continuous packets. The PWS data strip format is defined above. Max packet length = 518/515* bytes * the 1st number is for time included, the 2nd number is for time NOT included. 3.10.5.12.3 PWL3 -- PWS Low Rate Data PB Packet The PWL3 packet contains PWS Low Rate (LR) PB data taken from the LPW minor frame. Each LPW mf contains 20 bytes of PWS Low Rate PB subpacket. One PWL3 packet contains twelve (12) PWS LR subpackets. GLL-3-280 Rev. D, Appendix D (PHASE 2) The PWL3 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of mode change and PSN = 0 (Mod 32) APID 1 7 0Dh (13) Packet Size (data bytes) 8 9 max=240, min=20 Packet Sequence # 17 7 0 - 127 Packet Time 24 32/0* R-R-R-mf Up to 12 PWS LR data sets 56/24* 160 to 192020-byte PWS LR data sets from PB LPW Total packet length: max = 247/243* bytes, min = 27/23* bytes * the 1st number is for time included, the 2nd number is for time NOT included. 3.10.5.12.4 PWL4 -- PWS Low Rate Data Record Rate Change Coverage Packet Each PWL4 packet contains from one to eighteen PWS LR subpackets, each of which contains the PWS LR data from one real-time LPW minor frame. A maximum length RRCC function (31 LPW mfs providing 20-2/3 seconds of real- time coverage) will result in 2 PWL4 packets being generated. The PLW4 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, always APID 1 7 1Ch (28) Packet Size (data bytes) 8 9 max =360, min=20 Packet Sequence # 17 7 0 - 127 Packet Time 24 32 R-R-R-mf Up to 18 PWS LR data sets 56 160 to 2880 20-byte PWS LR data from RT LPW Total packet length: max = 367 bytes, min = 27 bytes GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.13 SSI Packets 3.10.5.13.1 SSI1 -- SSI Imaging Data ICT Packet The SSI1 packets deliver ICT compressed SSI images. One raw uncompressed SSI image can consist of up to 800 lines; each line can have up to 800 pixels; each pixel is digitized to 8 bits. In preparation to the compression processing, the received raw image is horizontally partitioned into 8-line high "slices" of image data. Each slice is then vertically partitioned into 8-pixel wide "units"; each unit is now an 8x8 pixel block that can be independently ICT compressed. At this point, the image can be rectangularly edited on a slice and 8-pixel basis to a desired lesser portion of the image (in the most extreme case, the image can consist of two adjoining 8x8 pixel "units"). In this form, an image may be compressed in a lossless form or a lossy form with a small lossless truth window (96x96 pixels) or a lossy form without the truth window. The resultant compressed image data is packaged into a group of SSI1 packets, all of which share a CDS assigned image number. Normally, multiple SSI1 packets are required to transport one image; all of the packets except the last one carry 511 bytes of image data. The SSI1 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, 1st packet of an image and when PSN = 0 (MOD64) APID 1 7 1Eh (30) Packet Size (data bytes) 8 9 < 511 Packet Sequence # 17 7 0 - 127 Image # 24 4 Packet Time 28 28/4* 1/2R-R-R- mf ICT or Lossless compressed image data 56/32* 32 - 4088 Pack 511 bytes of image data into each packet. The last packet of an image frame holds the remaining compression blocks. The data field can be split across packet boundaries, but the sync code can not. Total maximum packet length = 518/515* bytes * the 1st number is for time included, the 2nd number is for time NOT included. The CDS builds/formats the image to be compressed (into 8x8 pixel ICT units) according to the following rules: 1) the first pixel of the first image line received by the editor is the cornerstone from which the horizontal and vertical partitioning is based. 2) any element not contained within the MOD8 partitioning is discarded from the image compression process. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3) any image line loss at the start or end in retrieving an image is transparent to the CDS editor. 4) any single line lost in the middle of retrieving an image is also transparent to the CDS editor; two or more lines missing will result in an image truncation (ending) at that point and a "new" image will start with the next received image line record or with the next image, if needed. 5) all block editing will be by removal of whole outside rows or whole outside columns of image 8x8 blocks. Example 1: the SSI HIM format has 788 pixels per line; each slice for a HIM image will have at most only 98 blocks per slice and the last 4 pixels of each line will have been discarded. Example 2: lost image lines at the beginning or end of an image will result in at least one 8- line slice being lost; the line loss at the start will result in the packet line count being offset from its SSI reckoned counterpart. Example 3: single lines lost in the middle of any image will result in an unaccounted for vertical compression of the visual image. 3.10.5.13.1.1 ICT Compressed Image Data Format ICT compressed image block is the ICT transformed and Huffman coded bit stream made from an 8-line by 8-pixel region containing 64 bytes of raw image data. A compressed block can have a variable number of bits which are not normally byte aligned. The data from the compressed blocks within each slice are packed into bytes with no gaps, but with 7 bits of zero fill after the last block in the slice. Each compressed block follows a 1-bit flag which is set to 1 if the attempted compression results in expansion. In the case of ICT expansion, the data returned are truncated at 64 bytes; in the case of lossless expansion, the raw data is returned. The returned blocks are staggered together without boundary constraint. GLL-3-280 Rev. D, Appendix D (PHASE 2) The following figure shows the structure of data transported by the SSI1 packet. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Sync Code 0 25 '0'+24AAABh Slice Number 25 7 = 0 1st 8x8 block Compression Flag 32 1 = 1 if expansion. 1st 8x8 block Compressed pixels in one 8x8 region 33 ??512 ICT compressed data of 64-byte 8x8 block. If the ICT results in expansion, the bits after the 64 bytes (512 bits) are truncated. 2nd 8x8 block ??512+1 flag + pixels ... 100th 8x8 block Up to 100 8x8 blocks in one slice Trailing Zeros At most 7 bits to align the slice to byte boundary Sync Code 25 '0'+24AAABh Slice Number 7 = 1 1st 8x8 block Compression Flag 1 =1 if expansion. 1st 8x8 block Compressed pixels in one 8x8 region ??512 ICT compressed data of 64-byte 8x8 block. If the ICT results in expansion, the bits after the 64 bytes (512 bits) are truncated. 2nd 8x8 block ??512+1 flag + pixels ... 100th 8x8 block Up to 100 8x8 blocks in one slice Trailing Zeros At most 7 bits to align the slice to byte boundary . . . Sync Code 25 '0'+24AAABh Slice Number 7 < 100 1st 8x8 block Compression Flag 1 =1 if expansion. 1st 8x8 block Compressed pixels in one 8x8 region ??512 ICT compressed data of 64-byte 8x8 block. If the ICT results in expansion, the bits after the 64 bytes (512 bits) are truncated. 2nd 8x8 block ??512+1 flag + pixels ... 100th 8x8 block Up to 100 8x8 blocks in one slice Trailing Zeros At most 7 bits to align the slice to byte boundary Notes: Shaded portion shows an image slice. The darker area shows one ICT compression block. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.13.2 SSI2 -- SSI Image Data BARC Compressed Packet The SSI2 packet contains BARC-compressed SSI image data. One SSI2 packet contains one image line from HCA or IM4 frame. A two-byte line counter is included in the packet. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, 1st packet of an image and PSN = 0 (Mod 64) APID 1 7 1Fh (31) Packet Size (data bytes) 8 9 =326 Packet Sequence #17 7 0 - 127 Image # 24 4 0 - 15 Packet Time 28 28/4* 1/2R- R-R-mf Image Line Count 56/32* 16 0 - 799 Image Data 72/48* 2592 One BARC compressed image line from HCA or IM4 Total packet length = 333/330* bytes * The 1st number is for time included, the 2nd number is for time NOT included 3.10.5.13.3 SSI3 -- SSI Housekeeping Data Packet Each SSI Housekeeping packet contains housekeeping data for one SSI image. The SSI has two basic modes for taking images: the standard mode and a special 2-1/3 second mode. The size and data structure of these two modes are slightly different. The packet size field is used to identify the mode. If the packet size field is equal to 15, the packet is for a standard image mode. If the size field is equal to 13, the packet is for the 2-1/3 second imaging mode. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.13.3.1 Standard Mode Housekeeping Packet Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, always APID 1 7 20h (32) Packet Size (data bytes) 8 9 = 15 Packet Sequence # 17 7 0 - 127 Image # 24 4 Packet Time 28 28 1/2R-R-R-mf S/P RA 56 16 E-1419 S/P DEC 72 16 E-1420 S/P TWIST 88 16 E-1422 SBA ENC. Angle (Clock) 104 16 E-1293 Data word 14 120 8 S-1889 Data word 19 128 8 S-1894 Data word 22 136 8 S- 1912 Data word 23 144 8 S-1897, S-1875 Data word 24 152 8 S-1898, S-1876, S-1877, S-1878, S-1879 Data word 25 160 8 S-1913, S-1914, S-1916 Data word 26 168 8 S-1900, S-1907, S-1908, S-1909, S-1910 Total packet length = 22 bytes GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.13.3.2 2-1/3 Second Mode Housekeeping Packet Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, always APID 1 7 20h (32) Packet Size (data bytes) 8 9 = 13 Packet Sequence #17 7 0 - 127 Image # 24 4 Packet Time 28 28 1/2R-R-R-mf S/P RA 56 16 E-1419 S/P DEC 72 16 E-1420 S/P TWIST 88 16 E-1422 SBA ENC. Angle (Clock) 104 16 E-1293 Data word 22 120 8 S-1912 Data word 23 128 8 S-1897, S-1875 Data word 24 136 8 S-1898, S-1876, S-1877, S-1878, S-1879 Data word 25 144 8 S-1913, S-1914, S-1916 Data word 26 152 8 S-1900, S- 1907, S-1908, S-1909, S-1910 Total packet length = 20 bytes GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.13.3.3 SSI Housekeeping Data Word to S-Channel Map Data Word S-Channel Description (see table A2.12.3 for details) 14 Bits 1-8 S-1889 CCD Fine Temperature 19 Bits 1-8 S-1894 CCD Coarse Temperature 22 Bits 1-8 S-1912 Picture Count 23 Bit 1 Spare Bits 2-3 S-1897 Commanded Gain State Bits 4-8 S-1875 Exposure Number 24 Bit 1 Spare Bit 2 S-1898 Commanded Exposure Cycle Bit 3 S-1876 Commanded Exposure Mode Bit 4 S-1877 Commanded Blemish Protection Status Bit 5 S-1878 Commanded Filter Stepping Mode Bits 6-8 S-1879 Commanded Filter Position Step 25 Bits 1-3 S-1913 Imaging Mode: 000=60-2/3s, 010=8-2/3s, 100=30-1/3s, 101=15-1/6s, 110=2- 1/3s. Bit 4 None Long Exposure Cycle Bits 5-6 S-1914 Compressor Status Bits 7-8 S-1916 State Used. 26 Bit 1 S-1900 Memory Write Protect Bit 2 S-1907 Parallel Clock State Bit 3 S-1908 Watchdog Trip Flag Bit 4 S-1909 Blemish Protection Status Bits 5-7 S-1910 Actual Filter Bit 8 None GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.14 OPNAV Packets 3.10.5.14.1 OPN1 -- OPNAV R/T Extended Body Limb/Terminator Packet A Limb/Terminator (LT) packet contains up to 15 complete data sets. Each data set contains a pair of LT pixel segments of a line inside the 800x800 image frame. A data set is 32 bytes long; its structure is described below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Left Pixel # 0 16 Starting Pixel Location of the limb segment Line # 16 16 Line location of the limb pixel segments Limb pixels data 32 104 13 pixels value of the limb segment Right Pixel # 136 16 Starting Pixel Location of the terminator segment Terminator pixels data 152 104 13 pixels value of the terminator segment At least one LT packet and no more than six OPNAV packets (adding both LT and Star Windows packets) for each OPNAV image frame will be returned. The Limb/Terminator packet format is shown below. The six-packet set will all be of the Limb/Terminator type. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, always APID 1 7 36h (54) Packet Size (data bytes) 8 9 max=511, min=1 Packet Sequence # 17 7 0 - 127 Packet Time* 24 32 R-R-R-mf First LT data set 56 256 2nd LT data set 312 256 Up to 15 LT datasets (max. of 15 complete sets in one packet) Total packet length: max = 518 bytes, min = 8 bytes *the time the command starts to execute in the LLM or 3 mf's after execution of the functional command in the HLM. The basic routine starts with finding the extended target body by doing 10 to 50 cycles of skip n lines and read m lines. For each set of m lines read, CDS scans each line looking for the two LTs presumed to be present. The first LT is marked by the finding of i consecutive pixels greater than a specified high threshold, and the second by finding a pixel below a specified dark threshold. In each case the (x,y) location of the LT and the values of the 13 pixels surrounding it in the line are saved for downlink (the y value for the second LT of a pair is not downlinked, since the two segments are on the same line). The two pixel segments can overlap. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.14.2 OPN2 -- OPNAV R/T Star Window Data Packet One packet contains one star window. A star window is a rectangular region within a 800x800 image frame that contains a bright body (star). A star window can be any size up to a total of 506 pixels. for example, a 10x10 star window will contain 100 pixels, and a 33x15 star window has 495 pixels. A maximum of 5 star window packets per OPNAV image may be returned. The star window packet format is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, always APID 1 7 37h (55) Packet Size (data bytes) 8 9 Variable < 511 Packet Sequence # 17 7 0 - 127 Packet Time* 24 32 R-R-R-mf Pixel # 56 16 Starting pixel # of the star window Line # 72 16 Starting line # of the star window Width 88 8 width of the star window in # of pixels Pixels Data 96 ??506 pixels (bytes) Total maximum packet length = 518 bytes *the time the command starts to execute in the LLM or 3 mf's after execution of the functional command in the HLM. CDS will use locations in the top 1/3 of the LT to both determine that the proper bright body has been found by doing a curve fit to the expected shape and compute the location of the upper cusp of the body. Uplinked offsets from this cusp location determine the locations of the 0 to 5 rectangular windows surrounding star images which will be read out and downlinked along with the LT data. The stars must be below the top 1/3 of the extended body, and the line numbers of the star windows must be non-overlapping, though they may be contiguous. For example, two 33x15 windows could be placed vertically adjacent to each other, making in effect one 33x30 window. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.14.3 OPN3 -- OPNAV P/B Extended Body Limb/Terminator Packet A Limb/Terminator (LT) Playback packet contains up to 15 complete data sets. Each data set contains a pair of LT pixel segments of a line inside the 800x800 image frame. A data set is 32 bytes long; its structure is described in 3.10.5.14.1. The packet format is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, always APID 1 7 12h (18) Packet Size (data bytes) 8 9 max=511, min=1 Packet Sequence # 17 7 0 - 127 Packet Time* 24 32 R-R-R-mf First LT data set 56 256 2nd LT data set 312 256 ... Up to 15 LT data sets per packet (max. of 15 complete sets in one packet) Total packet length: max = 518 bytes, min = 8 bytes *the image time from the Playback Table 3.10.5.14.4 OPN4 -- OPNAV P/B Star Window Data Packet A maximum of 5 star window packets per OPNAV image may be returned. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, always APID 1 7 13h (19) Packet Size (data bytes) 8 9 Variable < 511 Packet Sequence # 17 7 0 - 127 Packet Time* 24 32 R-R-R-mf Pixel # 56 16 Starting pixel # of the star window Line # 72 16 Starting line # of the star window Width 88 8 width of the star window in # of pixels Pixels Data 96 < 506 pixels (bytes) Total maximum packet length = 518 bytes *the image time from the Playback Table GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.15 UVS Packets 3.10.5.15.1 UVS1 -- UVS Real Time Data Packet The UVS RT data pickup is 84 bytes per real-time LPW minor frame. A UVS RT instrument cycle is 13 mf's, comprising 1092 8-bit measurements. The 1092 bytes were summed into a 2184 CDS buffer (each 8-bit measurement into a 16- bit sum, ignoring overflow) for the period of 29 RIMs, 59 RIMs or 1423 RIMs. Because of deselects, selects and the 6UVRT commands which can cause packets to be produced at different times or not produced at expected times, the UVS1 packets may produce over longer or shorter periods. At the end of summation period and if the UVS is not deselected, the buffer is split into 8 packets. Each UVS1 packet contains 273 bytes of UVS RT data from the buffer. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, for the 1st and the last (8th) packet of the set. APID 1 7 2Ah (42) Packet Size (data bytes) 8 9 =273 Packet Sequence # 17 7 0 - 127 Packet Time 24 24/0* R-R-R # UVS data 48/24* 2184 One of the 8 packets of a UVS buffer. The 8 packets constitute a 2184-byte UVS buffer that is summed for 29, 59, or 1423 RIMs. Total packet length = 279/276* bytes * the 1st number is for time included, the 2nd number is for time NOT included.# the 1st of the 8 packets gives the start time of the Summation period. The 8th of 8 packets gives the end time of the Summation period; intervening packets do not contain times. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.15.2 UVS2 -- UVS Data PB Packet (Uncompressed) The UVS2 packet will contain up to 5 subpackets of UVS data taken from contiguously accessed LPW minor frames; the UVS subpacket consists of the 84 bytes of UVS data allocated to the LPW format. The UVS2 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of mode change and PSN = 0 (Mod 16) APID 1 7 01h (1) Packet Size (data bytes) 8 9 max=420, min=84 Packet Sequence # 17 7 0 - 127 (seq # shared with UVS3 packets) Packet Time 24 32/0* R-R-R-mf UVS data mf 1 56/24* 672 84-byte from PB LPW UVS data mf 2 728/696* 672 " UVS data mf 3 1400/1368* 672 " UVS data mf 4 2072/2040* 672 " UVS data mf 5 2744/2712* 672 " Total packet length: max = 427/423* bytes, min = 91/87* bytes * the 1st number is for time included, the 2nd number is for time NOT included. 3.10.5.15.3 UVS3 -- UVS Data PB Packet (Rice compressed) The UVS3 packet is a data compression equivalent to the UVS2 packet. UVS3 packets can be thought of as containing five subpackets (1 per minor frame) each containing 6 compression blocks of UVS data. A UVS3 packet can contain from 1 to 5 of these subpackets. With the Rice compression, CDS treats the entire 420 bytes as a single 8-bit channel. The first data byte is preserved as the reference value of the first compression block. There are 30 compression blocks per packet. Each compression block contains 14 values, with the last value output from one block being used as reference value of the next one. GLL-3-280 Rev. D, Appendix D (PHASE 2) Compression Block Bytes channel 1 1 1 mf 1 byte 1 1 2 mf 1 byte 2 ... ... 1 14 mf 1 byte 14 2 15 mf 1 byte 15 ... . ... 6 84 mf 1 byte 84 7 85 mf 2 byte 1 7 86 mf 2 byte 2 . ... 12 . mf 2 byte 84 . ... . ... 25 . mf 5 byte 1 25 . mf 5 byte 2 . 30 420 mf 5 byte 84 The UVS3 packet structure is shown below. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description Time Include Flag 0 1 =1, the 1st packet of mode change and PSN = 0 (Mod 16) APID 1 7 21h (33) Packet Size (data bytes) 8 9 ??420 Packet Sequence # 17 7 0 - 127(seq # shared with UVS2 packets) Packet Time 24 32/0* R-R-R-mf mf count 56/24* 8 (# of mf compressed) ref value 64/32* 8 mf 1 byte 1 30 compression blocks 72/40* variable Coder ID + Split bits + encoded [??bytes] Max packet length < 427/423* bytes * the 1st number is for time included, the 2nd number is for time NOT included. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.5.16 FILL Packet This is a single byte packet. It does not contain standard packet header. The original purpose for this packet type is to flush an VCDU by padding the remaining VCDU with FILL byte(s). There is currently no FSW implementation using this packet. Field Name Data Offset (bits) Field Size (bits) Content/Value/Description 0 8 =39h (57) This FILL packet is equivalent to "end-of-current-VCDU"; during the packet extraction, if the content of the first byte of a packet has the value 39 hex., the remaining VCDU can be skipped. GLL-3-280 Rev. D, Appendix D (PHASE 2) 3.10.6 Packetized Telemetry Operating Modes This section describes the operational aspects of configuring and controlling the spacecraft's data accessing, recording and processing in its packetized operating mode. 3.10.6.1 Packetized Real-Time Data Operations Real-Time packetized telemetry is a combination of Real-time Engineering (RTE), Real-time Science (RTS), and Real-time Optical Navigation (RTO). All three may be present or not present depending upon the operational directions given to the spacecraft. Figure 29 portrays the on-board real-time data paths. Figure 29. Real-Time Data Flow When present, the RTE and RTO constituents are given the highest transmittal priority. As highest priority, their assembled VCDUs are placed in the Priority Buffer - this buffer when filled will throw away any presented data that exceeds its capacity. The Priority Buffer has been sized to hold at least 50 minutes of continuous 10 bps RTE data. The RTS real-time component's generated VCDUs are assigned a VCID of 1 and are placed in the Multi-use Buffer. Data in this buffer can be "manually" saved to the DMS by a BDT operation if the DMS recorder is not otherwise committed to Playback or real-time recording. Lacking a BDT operation, this buffer when filled will also result in real-time data being lost. When retrieved via a playback, the BDT recorded VCDUs of RTS data are assigned a new VCID value of 5. GLL-3-280 Rev. D, Appendix D (PHASE 2) Operating configurations for the RTE and RTS real-time elements are linked/limited by the on-board Flight Software to one of 90 RTE/RTS Telemetry Modes; Table 29 below shows the allowable combinations to be achieved by specifying the configuration-setting parameter (for example, the "ZL2" or "AL4" or "CH5", etc.) to the 6TMCHG Command. The first letter of the configuration parameter relates to specific sets of RTS packet types; Table 30 in the following 3.10.6.1.2 subsection defines these selected RTS packet sets. The second letter indicates the RTE data rate to be realized and the third character (a number) sets the downlink telemetry rate to be enabled at the MDS. * Collection Rate is effective rate after R/S encoding plus packet overhead Modes below heavy line (within RTE rate) fill buffer, modes above line empty buffer. Deselecting engineering or RTS instruments will lower collection rate and shift lines. Table 29. Commandable RTE/RTS Telemetry Configurations RTE RTS Collection Rate*DOWNLINK TELEMETRY RATE (bps) bps for mat w/HIC w/EUV 0 8 20 32 40 60 80 120 160 2 Z 2.1 ZL2 ZL4 ZL6 2 A 25.0 AL1 AL2 AL3 AL4 AL5 AL6 AL7 AL8 2 B 26.1 BL0 BL2 BL3 BL4 BL5 BL6 BL7 2 C 37.9 37.9 CL1 CL2 CL3 CL4 CL5 CL6 CL7 CL8 2 D 40.2 49.5 DL2 DL3 DL4 DL5 DL6 DL7 2 E 71.6 80.9 EL0 EL1 EL2 EL3 EL4 EL5 EL6 EL7 EL8 2 F 79.8 FL1 FL2 FL3 FL4 FL5 FL6 FL7 FL8 2 G 108.9 108.9 GL2 GL3 GL4 GL5 GL6 GL7 GL8 2 H 139.1 HL2 HL4 HL5 HL6 HL7 HL8 2 I 178.7 IL3 IL5 IL6 IL7 IL8 10 A 33.2 AH1 AH2 AH3 AH4 AH5 AH6 AH7 AH8 10 B 34.4 BH0 10 C 46.2 46.2 CH1 CH2 CH3 CH4 CH5 CH6 CH7 CH8 10 D 48.5 57.8 10 E 79.9 89.2 EH2 EH3 EH4 EH5 EH6 EH7 EH8 10 F 88.1 10 G 117.1 117.1 10 H 147.4 10 I 187.0 40 B 65.5 BA4 BA6 GLL-3-280 Rev. D, Appendix D (PHASE 2) The bit-rate versus down-link capacity evaluation lines in the above Table 29 assume that 1) no other affecting processes (most notably any Real-time or Playback Optical Navigation) are active, and 2) that none of the data providing elements in the selection have been deselected. 3.10.6.1.1 Real-Time Engineering (RTE) RTE consists of a single packet format (ENG1 Packet) that delivers snap shotted GLL Engineering minor frames at the rate options of 2 bps (every 600th EHR mf), 10 bps (every 120th EHR mf), or 40bps (every 30th EHR mf). The 88-byte data portion of these frames coincide with the last 88 bytes of the TDM Engineering frames as described in 3.9.3. 3.10.6.1.2 Real-Time Science (RTS) RTS gives real-time coverage for a group of 9 Science instruments plus AACS positioning information; all of these values are extracted from the real-time LPW TDM telemetry. The RTS coverage will be some combination of the DDS1, EPD1, EUV1/HIC1, MAG1, NIMS1, PLS1, PWL1 and PWL2, UVS1 and AACS1 packets. Note that the EUV1/HIC1 packets are always mutually exclusive (one or the other or neither) and that the PWL1/PWL2 packets are from one source in which the packet format alternates between the two packet types. The operating RTS coverage set is always initially defined by selecting one of nine pre-defined sets of packets and rates; Table 30 documents these "standard" sets under the "Fmt" column labels of "A" through "I". Note that these letters are used in the combined RTE/RTS joint configuration setting mechanization described above in 3.10.6.1. Fmt RTS Total Data Rate (bps)Individual RTS Component Data Rates (bps) Symb ol w/HI C w/EU V MA G EPD PLS PW S DDS HIC EUV UVS NIM S AACS Z 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 A 19.7 2.0 5.0 5.0 5.0 1.1 1.0 0.0 0.2 0.0 0.4 B 20.7 2.0 5.0 5.0 5.0 1.1 2.0 0.0 0.2 0.0 0.4 C 30.8 30.8 2.0 5.0 5.0 5.0 3.4 5.0 5.0 5.0 0.0 0.4 D 32.8 40.8 2.0 5.0 5.0 5.0 3.4 2.0 10. 0 10. 0 0.0 0.4 E 59.8 67.8 4.0 10. 0 10. 0 10. 0 3.4 2.0 10. 0 10. 0 10. 0 0.4 F 66.8 6.0 15. 0 15. 0 15. 0 3.4 2.0 0.0 10. 0 0.0 0.4 G 91.8 91.8 8.0 20. 0 20. 0 20. 0 3.4 5.0 5.0 5.0 10. 0 0.4 GLL-3-280 Rev. D, Appendix D (PHASE 2) H 117. 8 12. 0 30. 0 30. 0 30. 0 3.4 2.0 0.0 10. 0 0.0 0.4 I 153. 8 18. 0 40. 0 40. 0 40. 0 3.4 2.0 0.0 10. 0 0.0 0.4 Note: HIC and EUV cannot be included in a format at the same time. One or the other will always be deselected. RTS data rate is the collection rate from the instruments prior to packetization and R/S overhead. Compression is assumed for PWS. Table 30. Real-Time Science (RTS) Telemetry Mode Definitions Once defined to the spacecraft's CDS, any component of the RTS activated set may be deselected by a following deselect command. Deselecting an RTS component from the set will lessen the set's down-link bit rates requirements as given in both Tables 29 and 30. 3.10.6.1.3 Real-Time Optical Navigation (RTO) RTO, when active and running, always generates a "Limb/Terminator" product (maximum of six OPN1 packets) and optionally an accompanying "Star Window" product (maximum of 5 OPN2 packets). The OPN1 and OPN2 packets are placed in the Priority Buffer and as such compete with the Real-time Engineering for that storage and the available downlink. The Real-time Optical Navigation function is independently activated and de- activated with no discernible effect on the RTE/RTS selection process. The RTO function requires that the DMS Recorder not be actively transferring data during its operation. It is allowed, however, to move or rewind the tape as background to the RTO's execution. The bit-rate requirements for the RTO function depends on both the content of the image being retrieved and the complexity of the operations that are asked to be performed. Both the OPN1 and OPN2 options are based on the real-time image read-out of the IM8 TDM telemetry format. 3.10.6.2 Playback Operations Playback processing is internally controlled by means of memory-resident Playback Tables in a manner described in the 3-310 Flight Software Requirements. Under the control of these tables, data is sequentially accessed from the DMS recorder (at its lowest operating rate of 7.68 Kbps) and placed into a working buffer # in accordance with "high" and "low" buffer water marks. The filling process is initiated at reaching the "low" mark and ceases upon reaching the "high" mark. During the fill process, SSI data is pre-processed into VCDU formats; all others are placed in their recorded TDM formats. Data not required for the selected Playback processings (including data not within the desired time window) is discarded at the point of access. Following the buffer fill process, the playback source data is sequentially processed (into completed VCDUs) down to the "low" mark - and the cycle is repeated until the table specified interval has been processed. GLL-3-280 Rev. D, Appendix D (PHASE 2) # Note: "Working buffer", as used here, is actually part of the Multi-use buffer: VCDU size units are allocated for the playback process as needed. There are no system-imposed concurrency restrictions between the 33 packet types that can result from the Playback process. In general, if the Playback data source being retrieved from the DMS recorder supports the packet type, that packet's generation if enabled can be received on the ground. Figure 30 gives an overview of the Playback process data paths. Playback cannot occur if either real-time recording a PPR Burst To Tape, or a BDT operation is in process. With the Playback "paused", however, these other operations can be exercised. If there has been any DMS tape movement since the Playback Pause, the CDS (having saved its position at the pause"), restores the tape to its same position before starting a Playback "resume". R/S CODING FRAME BUILDER CONV CODING DOWNLINK PROCESSED DATA RAW DATA EDIT/ COMPRESS PRIORITY BUFFER MULTI-USE BUFFER DMS OPNAV EDIT DESELECT EDIT SSI DATA OPNAV DATA OTHER DATA DESELECT NIMS EDIT/ COMPRESS *AACS, MAG, PLS, PPR, PWS (lo-rate), & UVS also compressed, if optioned GLL-3-280 Rev. D, Appendix D (PHASE 2) Figure 30. Playback Data/Process Paths 3.10.6.3 Record Rate Change Coverage (RRCC) Operations If enabled, an RRCC function is initiated at the termination of every DMS real- time recording operation. The RRCC function was originally intended to catch the data that would be lost while the DMS in its run-down/run-up that occurs at the changing of DMS real-time record rates; it is, however, not conditional on there being a near-term start-up of another DMS recording operation. RRCC Data packets are generated for the DDS, EPD, HIC, MAG, PWS (low- rate) and PLS Instruments and for LPW-contained AACS Rate/Position data. The RRCC function generates an "RRCC set" of real-time packets for the period immediately following the last recorded data on the DMS. The data for this set is extracted from a specified number of internally available real-time LPW TDM frames and is formatted to a set of VCID=3 VCDUs. The completed VCDUs are stored to the Multi-use Buffer for an intended subsequent real-time transfer to the ground. RRCC VCDUs saved to the DMS by a "BDT" operation, when reaccessed at a later time, will have their VCIDs changed to 7 before being re- entered into the Multi-use Buffer for another attempt at transmission. Partially filled VCDUs will be held in the CDS memory until such time as a following RRCC function provides data to push the held data out. The RRCC functions are enabled/disabled for all of the RRCC packet types as a group from a single control input. The length of the RRCC coverage, i.e., the number of LPW frames to be sequentially processed, is similarly set by a single control input (a specification of a number from 1 to 31).