Phoenix (PHX) Project MET Lidar EDR and RDR Software Interface Specification (SIS) Version 1.5 JPL PHX-274-310 D-33233 Prepared by: _________________________________ Cameron Dickinson Phoenix MET Team _________________________________ Approved by: _________________________________ Jim Whiteway Instrument Co-Investigator, MET _________________________________ Leslie Tamppari Phoenix Project Scientist _________________________________ Dr. Reta Beebe Director, PDS Atmospheres Node _________________________________ Ed Grayzeck Project Manager, Planetary Data System 1. Purpose and Scope of Document 6 2. Applicable Documents 6 3. Relationships with Other Interfaces 7 4. Data Product Characteristics and Environment 7 4.1 Instrument Overview 7 4.1.1 Lidar Operation Summary 7 4.1.2 Lidar Instrument 8 4.1.3 Known Issues and Idiosyncrasies 9 4.2 Data Product Overview 10 4.2.1 Level 2 EDRs 10 4.2.2 Level 3 RDRs 11 4.3 Data Processing 11 4.3.1 Data Processing Level 12 4.3.2 Data Product Generation 12 4.3.3 Data Flow 13 4.4 Standards Used in Generating Data Products 13 4.4.1 PDS Standards 13 4.4.2 File Naming 13 4.4.3 Time Standards 14 4.4.4 Data Storage Conventions 15 4.5 Data Validation 15 5. Detailed Data Product Specifications 15 5.1 Overview 15 5.1.1 Label and Header Common Characteristics 16 5.1.2 Data File Common Characteristics 16 5.2 MET Lidar Level 2 EDR 17 5.3 MET Lidar Level 3 RDR 18 Appendix A. EDR/RDR PDS Label Elements 19 Appendix B. Sample Label File 24 Appendix C. EDR/RDR Data File elements 26 Appendix D. EDR/RDR File naming convention 29 Appendix E. Phoenix Token convention 30 Appendix F. MARS24 Algorithm 31 Acronyms, Abbreviations, and Definitions CCSDS Consultative Committee for Space Data Systems CSA Canadian Space Agency DN Digital Number EDR Elementary Data Record ELA EDR Lidar Analog Data ELP EDR Lidar Photon Counting Data ELS EDR Lidar Supplemental Data FPGA Field Programmable Gate Array GDS Ground Data Segment MDA MacDonald, Dettwiler and Associates Ltd. MET Meteorological Team MLMS MET Lidar Manager Software. The software in the PEB that records the data from the sensors and transmits it to the Lander PEB Payload Electronics Box. PRT Platinum Resistance Thermometer PSI Phoenix Science Interface Software Tool RDR Reduced Data Record RLA RDR Lidar Analog Data RLP RDR Lidar Photon Counting Data RLS RDR Lidar Supplemental Data wrt With Respect To 1. Purpose and Scope of Document This document provides users of the Phoenix MET (Meteorological) Lidar data product with a detailed description of the product and a description of how it was generated, including data sources and destinations. It is intended to provide enough information to enable users to read and understand the data product. The users for whom this document is intended are the scientists who will analyze the data, including those associated with the project and those in the general planetary science community. The resulting data products consist of profiles of atmospheric scattering at 532nm and 1064nm, at spatial resolutions between 5 and 1000m and temporal resolutions between 0.01 and 900 seconds. This Data Product SIS describes how the EDR is acquired by the MET-Lidar instrument, and how it is processed, formatted, labeled, and uniquely identified. The document discusses standards used in generating the product and software that may be used to access the product. The data product structure and organization is described in sufficient detail to enable a user to read the product. Finally, an example of a product label is provided. 2. Applicable Documents [1] MET Mission Requirements Document [2] MET Data Analysis Plan (DAP) V1.0 [3] MET Lidar Manager Software (MPTMS) System Requirements Specification, Document # MDR-PHX-SG-7927 [4] MET Ground Station Software ICD, Document# MDR-PHX-ICD-7882 [5] Planetary Data System Standards Reference, Document# JPL D-7669 V3.7 [6] Planetary Science Data Dictionary Document, Document# JPL D-7116, Rev. E [7] Instrument Paper - Whiteway, et. al., Lidar on the Phoenix Mars Mission. J. Geophys. Res. (2008) E00A08, doi:10.1029/2007JE003002 [8] MET-Lidar Science Team and PDS Atmospheres Node ICD, V1.1 [9] MET Lidar CCC Report [10] MET Lidar / MET Archive Volume SIS 3. Relationships with Other Interfaces Changes to this SIS will affect the following products, software, and/or documents. * MET Ground Segment software * MET Ground Station Software ICD [4] * MET Data Analysis Plan [2] 4. Data Product Characteristics and Environment 4.1 Instrument Overview The Meteorology Package (MET) is a scientific payload of the Phoenix Mars Scout Lander. The MET will be capable of performing the following functions: * Detecting and ranging scatterers in the Martian atmosphere vertically with respect to the lander deck. * Measuring the barometric pressure of the Martian atmosphere at the Phoenix landing site. * Measuring the atmospheric temperature of the Martian atmosphere at three elevations at the Phoenix landing site. This document provides users of the MET-LIDAR data products with a detailed description of the product and a description of how it was generated, including data sources and destinations. The data products for the MET-PT are described in a separate SIS. 4.1.1 Lidar Operation Summary The Lidar produces collinear laser pulses at two wavelengths, 532 nm and 1064 nm. The intensity of the reflected or "backscattered" light from the laser at both wavelengths is collected by a telescope, filtered, and detected by a Photo-Multiplier Tube (PMT) for the 532 nm return, and an Avalanche Photo Diode (APD) for the 1064 nm return. The PMT is also capable of counting the number of returned photons, yielding three "channels" of data, given as 532 Analog, 1064 Analog and 532nm Photon Counting, respectively. The Lidar instrument can be operated in one of the following mutually exclusive states, with respect to data collection: * Off - The instrument is not powered. * Idle - The instrument is powered, but no data is collected. * Record - Lidar return data is recorded, compressed, and stored in flash memory. * Transmit Stored Data - The previously stored data is transmitted to the Lander computer. No data is collected during this time. * Transmit Cyclic - Lidar data is immediately transmitted to the Lander computer. For Science data collection, the Lidar instrument will be employed using a single "default" mode of operation, employing the first four of the above states, data collected employing the Cyclic state (in place of the Record and Transmit states) will only be collected as a check of on board processing, and as a back-up method to collect data. Nominally, the default mode will integrate or average data every 20.48 seconds; at 50m increment bin heights over 0-20km for the Photon Counting Channel, and 10m increment bin heights over 0-5km for the two Analog channels, for a total duration of 15 minutes. This number of acquisitions will be dependent on power and data telemetry restrictions, but will nominally be four times on sols where the goal is to examine atmospheric phenomena; and sporadically on other sols, whenever resources are available. 4.1.2 Lidar Instrument The design and scientific specifications of the MET Lidar are given in documents [1] and [7]. The basic operation of a lidar instrument is to measure the relative intensity of scattered laser light as a function of vertical height and time. A single series of height measurements is known as a profile, and a series of profiles is collectively known as a lidar scan. Each profile thus provides a relative measure of the dust distribution in the atmosphere, and it is understood that absolute attenuation of the signals owing to dust deposition on the windows will occur, but will not be quantified. The MET-Lidar has been designed to produce both 532nm (~0.5mJ, 100Hz) and 1064nm (~0.3mJ, 100Hz) laser light from a Nd:YAG laser system. The scattered light is detected through a 10 cm telescope, and is directed onto either a PMT (532nm) or APD (1064nm) detector. Data from the PMT is stored as both digital (photon counting) and analog (V) signals, while data collected using the APD signal is stored as an analog signal only (V). The analog PMT and APD systems share a common A/D converter, and the Single Pulse Return Signals are thus collected every other laser pulse (50 Hz), while the Photon Counting system collects at the laser pulse frequency of 100 Hz. The Lidar Instrument will nominally: * Detect atmospheric scatterers between 0 and 20 km with the 532nm photon counting channel * Detect atmospheric scatterers in both analog channels between 0 and 10km The instrument is capable of various configurations which affect the final data volume: * Height range bins (i.e. spatial resolution) can be adjusted in increments of 5m, with the capability of defining three zones within a single profile with differing range bin heights for each zone (e.g. zone 1: 0-5km, 500 bins, each 10m in height; zone 2: 5-10km, 100 bins, each 50m in height; zone 3: 10-20km, 40 bins, each 250m in height). The photon counting and analog channels can also be configured independently. * The period duration, (i.e. integration time or temporal resolution), can be adjusted with a minimum of 0.01 seconds per profile, adjustable in second increments (where n = 0 - 17). * Collection of data for the PMT, APD or both channels simultaneously. In addition to lidar backscatter profiles, the Lidar instrument will make a relative measure of the average DC-background (the sum of skylight and detector DC background) for both 532nm and 1064nm analog channels. Data on the minimum and maximum background values is also provided. This data is collected 1ms after the laser pulse for 2.125_s, and is averaged over the integration time, and normalized to the smallest bin height value. Lidar health data is given as pre and post data collection values for thermal readings from within the sensor box (Laser Chassis). The average laser intensity, minimum and maximum over the period duration (integration time) measured from a laser pick-off signal is also provided. Values of the profile backscatter intensity are stored on the MET-Lidar instrument in engineering units, and require scaling by ground software such as the MET-GDS. 4.1.3 Known Issues and Idiosyncrasies * When the Laser diode is turned off, the sudden drop in voltage causes a 1-3mV "ripple" to appear in the Analog data at 10_s from the laser firing T0, or approximately 1.5km in the data [9]. This is ~1% of the signal and spans approximately 100m of the data (in vertical range). * The co-alignment of the telescope and laser beam axes was found to be highly dependant upon the Laser Chassis temperature over the operational range. Thus the near field overlap will change considerably as a function of operating temperature. A description of the overlap is given in [9], and the operational temperatures for each scan are given as supplemental data. * Upon commencement of surface operations, The Lidar experienced a small number (<10) of incidents of "missed laser shots" whereby there was a mismatch between the number of commanded pulses to fire, and the number of pulses detected by the T0 pickoff (which triggers the data acquisition). Early in the mission, this led to a 0.01 sec (1 shot) difference in the sampling interval during the affected time. As the data acquisition system was designed to collecta set number of shots, this leads to an increase in the affected sampling interval, or time between profiles: e.g. 20.49 instead of 20.48 sec, and thus the impact is quite small. Later in the mission, however, the problem became more pronounced, and led to an increase in missed shots, particularly during daytime operations, but only in ~5 operations. * The laser was designed to operate within temperature set points for three of it's laser components (the YAG crystal, the KTP doubling crystal and the pump laser diode). At times throughout the mission, particularly during the warmest portions, i.e. during daylight hours, the laser components exceeded their operational threshold and laser operation was momentarily suspended. As with the T0 issue above, the number of shots within a profile is unaffected, but the actual sampling interval is, as no laser pulses are fired until all three temperatures have re-established themselves. * Finally, upon commencement of surface operations, it was noted that there is a "droop" in the photon counting signals during periods of intense near-field scattering. This appears to only be a problem in daytime data (i.e. high background signal plus high near field signal), and is only observable when the data has been background subtracted. The analog profiles are unaffected by this phenomena. 4.2 Data Product Overview The Phoenix Mission uses CODMAC data processing level descriptions, as described in Table 1. 4.2.1 Level 2 EDRs Each EDR describe a single operation of the instrument, nominally up to 15 minutes in duration. These EDRs contain telemetry from two sources: the data elements measured using the MET lidar instrument and a timestamp provided by the Phoenix Lander (see section 4.4.3 for timestamp details.). MET Lidar telemetry will be parsed by collection channel (532nm photon counting, 532nm analog and 1064nm analog) and laser intensity data into separate files: label (.LBL) and tabulated data (.TAB). The data volume (described initially in Section 4.1.2) scales proportionally with the temporal and spatial resolution, and addition of the variance data increases the data volume approximately three fold. (The maximum data volume which could be generated for a single 15 min scan could result in a 8 Gb file!). Selection of appropriate spatial and temporal resolution will be dependent upon memory storage capacity, transmission bandwidth, and scientific value. Lastly, relevant parameters that are stored in the MET-GDS are added to the EDR (for example, commanded parameters of temporal resolution). Note that these are tracked in the ground software according to commands that have been sent, which are echoed back in the telemetry. 4.2.2 Level 3 RDRs Level 3 Data Products (RDRs) have had the following changes as compared to the Level 2 EDRs: 1. The data has been changed and reordered where required to be consistent with [2]. 2. The Frame Count is converted to the duration of each measurement in Earth seconds. 4.3 Data Processing This section provides general information about the processing of MET data sets. Details specific to each data set are found in Section 5 4.3.1 Data Processing Level TABLE 1 MET Ground Segment (CSA) 4.3.2 Data Product Generation MET data products will be generated by the MET Team led by Co-Investigator Whiteway at York University. The majority of the data processing for the MET-Lidar instrument is performed in the flight segment, either by FPGA hardware or MLMS software within the PEB, as specified in [3]. Under command from the MET Device Manager software (written by JPL) on the Lander computer, the MET-Lidar takes measurements and nominally saves the data to instrument internal Flash memory (Record state). The system will be separately commanded to transmit the data immediately to the Lander (Transmit state). In the nominal case where data is recorded to flash, it is first compressed, and it is then transmitted from the MET-PT to the Lander computer using the format described in [1]. The messages are replicated exactly as sent, with the addition of CCSDS header information applied by the MET Device Manager on the Lander. Included in this CCSDS information is a timestamp representing the time that data collection started and when collection was stopped. The data is then stored on the Lander and held for periodic download. The stored telemetry data are downloaded from the Lander for relay to the Deep Space Network (DSN). Data received from the DSN are inserted into the Jet Propulsion Laboratory's (JPL) Telemetry Data System (TDS). The University of Arizona (UA) queries the TDS for the most recent telemetry dataset. The dataset is output to a spooler that passes data to the UA. Raw telemetry data are received by the UA, and a number of automated computer processes are run to place data in the MET directory of the UA Science LAN in an ASCII formatted file described in [4]. The MET-GDS software appends the Timestamp, and writes the data out to files in the format given in Section 5. These are the Level 2 EDRs. 4.3.3 Data Flow The following diagram illustrates the data flow (see Section 5.1 for a description of each file within the data record): MET-Lidar Messages EDR RDR Table 2 MET Standard Data Products TABLE 2 4.4 Standards Used in Generating Data Products 4.4.1 PDS Standards All EDR and RDR products will comply with the Planetary Data System's standards as specified in the PDS Standards Reference [5]. All label keywords are PDS compliant and registered in the PDS dictionary [6]. 4.4.2 File Naming The EDR and RDR formats described in this document follow the Phoenix product filenaming conventions as described in Appendix D. Filenames, by definition, will be PDS compliant. Additional identification information will be contained in the PDS label as described in Appendix A. 4.4.3 Time Standards The following time standards and conventions are used throughout this document, as well as the Phoenix project for planning activities and identification of events. SCET Spacecraft event time. The time when an event occurred on-board, in GMT SCLK Spacecraft Clock, an on-board counter which increments once every 100 milliseconds[PZ1], with origin, set to zero, at midnight on 1-Jan-1980. Local True Solar Time (LTST) Local True Solar Time; LTST is the local solar time expressed by the number of local solar days (SOL_s) from a landing date and using a "24-hour" clock readout within the current local solar day (HR:MN:SC); LTST is a true local solar time and computed using MARS24 : SOL 12 12:00:00 Local Mean Solar Time (LMST) Local Mean Solar Time; LMST is the mean local solar time expressed by the number of local solar days (SOL_s) from a landing date and using a "24-hour" clock readout within the current local solar day (HR:MN:SC); LMST is an average local solar time and computed using MARS24 : SOL 12 12:00:01 Coordinated Universal Time (UTC) Coordinated Universal Time: yyyy-mm-ddThh:mm:ss.sss. The MET device returns a message containing the Lidar "Frame Count", which is the number of 0.01 sec intervals since power up, and resets each time the MET Lidar is powered down. Each message is given a CCSDS header, containing the Lander timestamp (UTC). The Lidar data collection start time is calculated simply as: START_TIMEUTC = UTC + 0.01sec * FRAME_COUNT* or START_TIMELTST,LMST = [SCET + 0.01sec * FRAME_COUNT*]LTST,LMST, with LTST and LMST indicating a time conversion Mars Local Solar Time (using MARS24, see Appendix F), and FRAME_COUNT* is the Frame Count at the start of data acquisition. LTST uses a Mars Longitude of 125.75W (actual, landed longitude) while LMST uses 126.65W (mission epoch, expected landing site longitude). Level 2 EDRs contain the raw frame count values, while level 3 RDRs are stored as the total DURATION, which is the number of seconds since START_TIME for each profile, with the interval between profiles being the integration period (PERIOD_DURATION). The UTC time of each profile for the level 3 RDRs is thus simply: Collection Time of each Profile = START_TIME + DURATION, with the caveat that DURATION will be provided in Earth seconds. The MET-Lidar integration period, (nominally 20.48 seconds) refers to the time at the end of the averaging block in the Level 2 EDRs and Level 3 RDRs. 4.4.4 Data Storage Conventions See MET Lidar Archive Volume SIS [10] 4.5 Data Validation The MET Lidar EDR and RDR data product design, as described in this SIS, is subject to PDS peer review. The peer review will be done well in advance of actual production, to allow time for changes in the design as needed. This SIS document will be updated to show any such changes. Validation of MET Lidar EDR and RDR products during production will be done according to specifications in the Phoenix Archive Plan and the MET Team - PDS Atmospherics Node ICD [8]. The MET Team will validate the science content of the data products, and the Atmospheres Node will validate the products for compliance with PDS standards and for conformance with the design specified in this SIS. 5. Detailed Data Product Specifications 5.1 Overview Each lidar profile, defined as a measurement of atmospheric scattering up to 0 - 20km for the photon counting channel and 0 - 10km for the analog channel, will be stored as a single row for each height and time measurement. The series of rows for a single profile will thus have the same time values. The intensity of scattering is provided as accumulated photon counts, or average analog voltage. The height column describes the top of the measurement, and thus the spatial resolution of each measurement is the difference in height between successive measurements recorded at the same time value. The spatial resolution may change within a given profile, as described in section 4.1.2, but will remain unchanged within a 15 minute scan. Each profile will be stored sequentially, with the temporal difference between profiles, being the integration or averaging period. This temporal difference will be provided in the FRAME COUNT, for EDR records, or as DURATION, for the RDR records. (see section 4.4.3 for details). Estimates of the background signal (average, maximum and minimum), measured between laser pulses, will be provided for both of the Analog channels. Each value will have its own column. Data will be separated into three .TAB files: 532nm Photon Counting, 532 and 1064nm Analog and supplemental data: measurements of the laser intensity, recorded as voltage, along with its min and max values; analog background average, minimum and maximum values; and Laser Chassis temperatures. Each file within the EDR data record will thus be labeled as "ELP", "ELA", and "ELS" corresponding to Photon Counting, 532nm and 1064nm Analog, and Supplemental, respectively. Similarly the RDR data files will be: "RLP", "RLA", and "RLS." (See Appendix D and Sections 4.3.3, 5.2 and 5.3). The data products will also contain the command parameters employed in their creation. This includes a unique MET telemetry ID, the integration period length (temporal resolution) and the number of integration periods. 5.1.1 Label and Header Common Characteristics PDS header label file (.LBL) will be human-readable ASCII files containing Identification Data Elements, History Data Elements and Commanded Parameters. Descriptions of the label elements can be found in Appendix A, a sample .LBL file can be found in 0. 5.1.2 Data File Common Characteristics The data files will be human-readable ASCII files (.TAB), delimited by commas (ASCII code 44) stored in columns of fixed-width records with a () delimiters at the end of each row. Descriptions of the label elements can be found in Appendix C. The following label fragment illustrates the general characteristics of the recommended ASCII format for a table with 1000-byte records: (See example label in Appendix A) RECORD_TYPE = FIXED_LENGTH RECORD_BYTES = 1000 ... OBJECT = TABLE INTERCHANGE_FORMAT = ASCII ROW_BYTES = 1000 ... END_OBJECT = TABLE Corresponding .TAB file: 5.2 MET Lidar Level 2 EDR Each EDR is comprised or three records with tabulated data (.TAB) provided in the following columns: "ELP" - 532nm Photon Counting Temporal Spatial Atmospheric Signal Frame Count Range Total Photon Counts "ELA" - 532nm and 1064nm Analog Temporal Spatial 532nm Atmospheric Signal 1064nm Atmospheric Signal Frame Count Range Average Average "ELS" - Supplemental Data Temporal 532 nm / 1064nm Laser Intensity 532 nm / 1064 nm Analog Background Signal Instrumental Frame Count Average/Min/Max Average/Min/Max Laser Chassis Temperature All values, with the exception of temporal and spatial data, are given in unscaled units. 5.3 MET Lidar Level 3 RDR Each RDR is comprised or three records (.TAB), with the following columns of data: "RLP" - 532nm Photon Counting Temporal Spatial Atmospheric Signal Duration Range Total Photon Counts "RLA" - 532nm and 1064nm Analog Temporal Spatial 532nm Atmospheric Signal 1064nm Atmospheric Signal Duration Range Average Average "RLS" - Supplemental Data Temporal 532 nm / 1064nm Laser Intensity 532 nm / 1064 nm Analog Background Signal Instrumental Duration Average/Min/Max Average/Min/Max Laser Chassis Temperature These entries are intended to correspond with the Level 2 EDR entries from which they are derived (ELP à RLP, etc). The FRAME_COUNT values will be converted into units of DURATION in earth seconds since START_TIME (UTC), and EDR units will be scaled to units of photon counts, V, K, etc. as required. Appendix A. EDR/RDR PDS LABEL ELEMENTS Elements Description Format PDS_VERSION_ID Represents the version number of the PDS standards document that is valid when a data product label is created. Values for the PDS_version_id are formed by appending the integer for the latest version number to the letters 'PDS'. string Source: PDS Location: All RECORD_TYPE Indicates the record format of a file. Note: In the PDS, when record_type is used in a detached label file it always describes its corresponding detached data file, not the label file itself. The use of record_type along with other file-related data elements is fully described in the PDS Standards Reference. All data products in this record will use "FIXED_LENGTH". string Source: Static Value Location: All RECORD_BYTES The number of bytes in each record (row) Integer Source: Calculated Location: All FILE_RECORDS Indicates the number of physical file records, including both label records and data records. Note: In the PDS the use of FILE_RECORDS along with other file-related data elements is fully described in the Standards Reference. Integer Source: Calculated Location: All DATA_SET_ID A unique alphanumeric identifier for a data set or a data product. The DATA_SET_ID value for a given data set or product is constructed according to flight project naming conventions. In most cases the DATA_SET_ID is an abbreviation of the DATA_SET_NAME. " PHX-M-MET-2-L-EDR-V1.0" string Source: PDS Location: All PRODUCT_ID Represents a permanent, unique identifier assigned to a data product by its producer. See also: source_product_id. Note: In the PDS, the value assigned to product_id must be unique within its data set. Filename less the extension, e.g. "LS003ELA_00896474226_10DCM0" string Source: Calculated Location: All PRODUCT_TYPE The PRODUCT_TYPE data element identifies the type or category of a data product within a data set. Examples: EDR, RDR. string Source: Static Value Location: All PRODUCT_VERSION_ID Identifies the version of an individual product within a data set. For MER, PRODUCT_ VERSION_ID includes a Version field that begins with "V" followed by the Version decimal number of the controlling SIS document. Example: "V1.4 D-22850" string Source: User Parameter Location: All RELEASE_ID Unique identifier associated with the release to the public of all or part of a data set. The first release of a data set should have a RELEASE_ID of "0001" When a data set is released incrementally, such as every three months during a mission, the RELEASE_ID is updated each time part of the data set is released. string Source: User Parameter Location: All INSTRUMENT_HOST_ID Provides a unique identifier for the host where an instrument is located. This host can be either a spacecraft or an earth base. "PHX" string Source: Static Value Location: All INSTRUMENT_HOST_NAME Provides the full name of the host on which an instrument is based. "PHOENIX" string Source: Static Value Location: All INSTRUMENT_ID Provides an abbreviated name or acronym which identifies an instrument "MET" string Source: Static Value Location: All INSTRUMENT_TYPE Identifies the type of an instrument. "LIDAR" string Source: Static Value Location: All LOCAL_TRUE_SOLAR_TIME Local true solar time, or LTST, is one of two types of solar time used to express the time of day at a point on the surface of a planetary body. LTST is measured relative to the true position of the Sun as seen from a point on the planet's surface. string Source: Calculated Location: All LOCAL_MEAN_SOLAR_TIME Local mean solar time, or LMST, is one of two types of solar time used to express the time of day at a point on the surface of a planetary body. LMST is calculated relative to the average position of the Sun over a Martian year. string Source: Calculated Location: All MISSION_NAME Identifies a major planetary mission or project. A given planetary mission may be associated with one or more spacecraft. "PHOENIX" string Source: Static Value Location: All MISSION_PHASE_NAME Provides the commonly-used identifier of a mission phase. e.g. "CRUISE", "EXTENDED MISSION", "PRIMARY MISSION", "ATLO", "ORT1", "ORT2", "TBD" string Source: Operator Supplied Parameter Location: All PLANET_DAY_NUMBER Indicates the number of sidereal days (rotation of 360 degrees) elapsed since a reference day (e.g., the day on which a landing vehicle set down) for the START of measurement. Days are measured in rotations of the planet in question from the reference day (which is day zero). Sols are also referenced to planning time: LMST. integer Source: Calculated Location: All PRODUCER_ INSTITUTION_NAME Identifies a university, research center, NASA center or other institution associated with the production of a data set. For MET this will be "YORK UNIVERSITY" string Source: Static Value Location: All PRODUCT_CREATION_TIME Defines the UTC system format time when a product was created. Formation rule: YYYY-MM-DDThh:mm:ss[.fff] Source: Calculated Location: All OPS_TOKEN (PSI Token) Uniquely identifies a scientific observation within a data set. The value is an 8 bit hex number. string Source: PSI Software Tool Location: All SPACECRAFT_CLOCK_CNT_PARTITION Indicates the clock partition active for the SPACECRAFT_CLOCK_START_COUNT and SPACECRAFT_CLOCK_STOP_COUNT elements. Set to "1" integer Source: Static Value Location: All SPACECRAFT_CLOCK_ START_COUNT Provides the value of the spacecraft clock at the beginning of a time period of interest. Format is dddddddddd.ddd, measured in units of Seconds stored internally as a floating point number. string Source: Calculated Location: All START_TIME Provides the date and time of the beginning of an event or observation (whether it be a spacecraft, ground-based, or system event) in UTC system format. Formation rule: YYYY-MM-DDThh:mm:ss[.fff]Z" string Source: Calculated Location: All STOP_TIME Provides the date and time of the beginning of an event or observation (whether it be a spacecraft, ground-based, or system event) in UTC system format. Formation rule: YYYY-MM-DDThh:mm:ss[.fff]Z" string Source: Calculated Location: All TARGET_NAME Identifies a target. The target may be a planet, satellite, ring, region, feature, asteroid or comet. See TARGET_TYPE. "MARS", string Source: Static Value Location: All TARGET_TYPE Identifies the type of a named target. "PLANET" string Source: Static Value Location: All SOFTWARE_NAME Identifies data processing software such as a program or a program library. "MET-GDS" string Source: User Parameter Location: All SOFTWARE_VERSION_ID Indicates the version (development level) of a program or a program library. "V1" string Source: User Parameter Location: All PROCESSING_ HISTORY_TEXT Provides an entry for each processing step and program used in generating a particular data file. e.g. "CODMAC LEVEL 1 TO LEVEL 2" string Source: Static Value Location: All OPS_TOKEN_ACTIVITY Unique 8 bit hex MET derived telemetry ID, used to track commanded parameters and telemetry within the MET-GDS. Identical to the upper half of OPS_TOKEN. string Source: Commanded Value Location: All INTEGRATION_DURATION MET parameter describing the duration each integration (photon counting) or averaging period (analog) spans. Integer Source: Commanded Value Location: All INTEGRATIONS_COUNT The number of INTEGRATION_ DURATION periods within a given data product. Integer Source: Commanded Value Location: All Appendix B. SAMPLE LABEL FILE RLP.LBL PDS_VERSION_ID = PDS3 /* FILE DATA ELEMENTS */ RECORD_TYPE = FIXED_LENGTH RECORD_BYTES = 49 FILE_RECORDS = 5200 /* POINTERS TO DATA OBJECTS */ ^TABLE = "LS003RLP_00896474226_10DCM0.TAB" /* IDENTIFICATION DATA ELEMENTS */ DATA_SET_ID = "PHX-M-MET-2-L-RDR-V1.0" PRODUCT_ID = "LS003RLP_00896474226_10DCM0" PRODUCT_TYPE = RDR PRODUCT_VERSION_ID = "V1.1 D-33233" RELEASE_ID = "0001" INSTRUMENT_HOST_ID = PHX INSTRUMENT_HOST_NAME = "PHOENIX LANDER" INSTRUMENT_ID = LIDAR INSTRUMENT_TYPE = "LIDAR" LOCAL_TRUE_SOLAR_TIME = "11:25:27" LOCAL_MEAN_SOLAR_TIME = "11:02:15" MISSION_NAME = "PHOENIX" MISSION_PHASE_NAME = "PRIMARY MISSION" PLANET_DAY_NUMBER = 091 PRODUCER_INSTITUTION_NAME = "YORK UNIVERSITY" PRODUCT_CREATION_TIME = 2009-02-17T16:34:25.000 OPS_TOKEN = "16#10DC0000#" SPACECRAFT_CLOCK_CNT_PARTITION = 1 SPACECRAFT_CLOCK_START_COUNT = "896474225.613" START_TIME = 2008-08-27T06:10:32.777 STOP_TIME = 2008-08-27T06:34:35.825 TARGET_NAME = MARS TARGET_TYPE = PLANET /* HISTORY DATA ELEMENTS */ SOFTWARE_NAME = "MET-GDS" SOFTWARE_VERSION_ID = "3.0.4" PROCESSING_HISTORY_TEXT = "CODMAC LEVEL 1 TO LEVEL 2" /* COMMANDED PARAMETERS */ OPS_TOKEN_ACTIVITY = "16#10DC#" INTEGRATION_DURATION = 11 INTEGRATION_NUMBER = 13 /* DATA ELEMENTS 532NM PHOTON COUNTING */ OBJECT = TABLE INTERCHANGE_FORMAT = ASCII COLUMNS = 3 ROWS = 5200 ROW_BYTES = 49 OBJECT = COLUMN COLUMN_NUMBER = 1 NAME = "DURATION" DATA_TYPE = ASCII_REAL START_BYTE = 1 BYTES = 15 UNIT = "SECONDS" DESCRIPTION = "The absolute number of seconds since instrument power up." END_OBJECT = COLUMN OBJECT = COLUMN COLUMN_NUMBER = 2 NAME = "LASER_SCATTERING_RANGE" DATA_TYPE = ASCII_INTEGER START_BYTE = 17 BYTES = 15 UNIT = "METERS" DESCRIPTION = "Meters from the surface of the Lander Deck" END_OBJECT = COLUMN OBJECT = COLUMN COLUMN_NUMBER = 3 NAME = "PHOTON_COUNT" DATA_TYPE = ASCII_INTEGER START_BYTE = 33 BYTES = 15 UNIT = "COUNTS" DESCRIPTION = "The total number of Photon Counts per height bin over the integration period." END_OBJECT = COLUMN END_OBJECT = TABLE END Appendix C. EDR/RDR DATA FILE ELEMENTS Column Description Format Notes* FRAME_COUNT Absolute Number of Frames Since Instrument Power Up (1 Frame (DN) = 0.01 sec) ASCII_ INTEGER Source: Telemetry Location: All EDR files Unit: DN DURATION The number of Earth Seconds since START_TIME ASCII_ REAL Source: Calculation Location: All RDR files Unit: Seconds LIDAR_ SCATTERING_ RANGE Range at which laser scattering is detected. This is based on the time between transmission and detection of scattering signal. ASCII_ INTEGER Source: Commanded Parameter Location: ELP, ELA, ELI, RLP, RLA, RLI Unit: Meter PHOTON_COUNT The total number of photon counts per height bin and INTEGRATION_ DURATION. EDR files are in units of DN, while RDR files are scaled to units of counts. ASCII_ INTEGER, ASCII_ REAL Source: Telemetry Location: ELP, RLP Unit: DN, Counts AVERAGE_532NM_ VOLTAGE Average analog 532nm signal voltage per height bin over INTEGRATION_ DURATION. EDR files are in units of DN, while RDR files are scaled to units of V. ASCII_ INTEGER, ASCII_ REAL Source: Telemetry Location: ELA, RLA Unit: DN, V AVERAGE_532NM_ BACKGROUND_ VOLTAGE Average analog 532nm background voltage per height bin over INTEGRATION_DURATION, measured between laser pulses (i.e. skylight plus detector DC background). EDR files are in units of DN, while RDR files are scaled to units of V. ASCII_ INTEGER, ASCII_ REAL Source: Telemetry Location: ELA, RLA Unit: DN, V MINIMUM_532NM_ BACKGROUND_ VOLTAGE Minimum analog 532nm background voltage per height bin over INTEGRATION_DURATION, measured between laser pulses (i.e. skylight plus detector DC background). EDR files are in units of DN, while RDR files are scaled to units of V. ASCII_ INTEGER, ASCII_ REAL Source: Telemetry Location: ELA, RLA Unit: DN, V MAXIMUM_532NM_ BACKGROUND_ VOLTAGE Maximum analog 532nm background voltage per height bin over INTEGRATION_DURATION, measured between laser pulses (i.e. skylight plus detector DC background). EDR files are in units of DN, while RDR files are scaled to units of V. ASCII_ INTEGER, ASCII_ REAL Source: Telemetry Location: ELA, RLA Unit: DN, V AVERAGE_1064NM_ VOLTAGE Average analog 1064nm signal voltage per height bin over INTEGRATION_ DURATION. EDR files are in units of DN, while RDR files are scaled to units of V. ASCII_ INTEGER, ASCII_ REAL Source: Telemetry Location: ELI, RLI Unit: DN, V AVERAGE_1064NM_ BACKGROUND_ VOLTAGE Average analog 1064nm background voltage per height bin over INTEGRATION_DURATION, measured between laser pulses (i.e. skylight plus detector DC background). EDR files are in units of DN, while RDR files are scaled to units of V. ASCII_ INTEGER, ASCII_ REAL Source: Telemetry Location: ELI, RLI Unit: DN, V MINIMUM_1064NM_ BACKGROUND_ VOLTAGE Minimum analog 1064nm background voltage per height bin over INTEGRATION_DURATION, measured between laser pulses (i.e. skylight plus detector DC background). EDR files are in units of DN, while RDR files are scaled to units of V. ASCII_ INTEGER, ASCII_ REAL Source: Telemetry Location: ELI, RLI Unit: DN, V MAXIMUM_1064NM_ BACKGROUND_ VOLTAGE Maximum analog 1064nm background voltage per height bin over INTEGRATION_DURATION, measured between laser pulses (i.e. skylight plus detector DC background). EDR files are in units of DN, while RDR files are scaled to units of V. ASCII_ INTEGER, ASCII_ REAL Source: Telemetry Location: ELI, RLI Unit: DN, V AVERAGE_532NM_ LASER_VOLTAGE Average analog 532nm laser voltage over INTEGRATION_DURATION, EDR files are in units of DN, while RDR files are scaled to units of V. ASCII_ INTEGER, ASCII_ REAL Source: Telemetry Location: ELL, RLL Unit: DN, V MINIMUM_532NM_ LASER_VOLTAGE Minimum analog 532nm laser voltage over INTEGRATION_DURATION. EDR files are in units of DN, while RDR files are scaled to units of V. ASCII_ INTEGER, ASCII_ REAL Source: Telemetry Location: ELL, RLL Unit: DN, V MAXIMUM_532NM_ LASER_VOLTAGE Maximum analog 532nm laser voltage over INTEGRATION_DURATION. EDR files are in units of DN, while RDR files are scaled to units of V. ASCII_ INTEGER, ASCII_ REAL Source: Telemetry Location: ELL, RLL Units: DN, V2 AVERAGE_1064NM_ LASER_VOLTAGE Average analog 1064nm laser voltage over INTEGRATION_DURATION, EDR files are in units of DN, while RDR files are scaled to units of V. ASCII_ INTEGER, ASCII_ REAL Source: Telemetry Location: ELL, RLL Unit: DN, V MINIMUM_1064NM_ LASER_VOLTAGE Minimum analog 1064nm laser voltage over INTEGRATION_DURATION. EDR files are in units of DN, while RDR files are scaled to units of V. ASCII_ INTEGER, ASCII_ REAL Source: Telemetry Location: ELL, RLL Unit: DN, V MAXIMUM_1064NM_ LASER_VOLTAGE Maximum analog 1064nm laser voltage over INTEGRATION_DURATION. EDR files are in units of DN, while RDR files are scaled to units of V. ASCII_ INTEGER, ASCII_ REAL Source: Telemetry Location: ELL, RLL Units: DN, V2 INSTRUMENT_ TEMPERATURE MET parameter describing the laser sensor head temperature during data acquisition. These measurements will be made once every 20 seconds, and interpolated to INTERGRATION_DURATION ASCII_ INTEGER, ASCII_ REAL Source: Telemetry Location: ELP, ELA, ELI, RLP, RLA, RLI Units: DN, K *Roman and Italic Data "Locations" correlate with Roman and Italic "Units" Appendix D. EDR/RDR FILE NAMING CONVENTION The file naming scheme defined for the MET complies with the filenaming conventions for Phoenix EDRs and RDRs which in turn complies with the PDS Level II 27.3 filename standards. Each product name is uniquely identifiable throughout the mission. A template for MET filenames is shown below: Position Name Description/value 1 Instrument S SSI R RAC T TEGA A RA O MECA-OM P MECA-TECP F MECA-AFM W MECA-WCL M MET-P&T L MET-LIDAR D MARDI E ASE 2 Source/Epic Spacecraft S Surface, flight model T Test-bed C Cruise, flight model 3-5 SOL Solar days since first full day on Mars. Landing day is Sol zero. If Source/Epic is T, day of year should be used (ERT or SCET). For cruise phase, always set to "_C_". 6-8 Product Type Lidar: ELP, RLP - Lidar 532 nm Photon Counting (EDR/RDR) ELA, RLA - Lidar 532/1064 nm Analog (EDR/RDR) ELS, RLS - Lidar Supplemental Data (EDR/RDR) P&T: EML, RML - MET P&T Low-Res (512sec) (EDR/RDR) EMH, RMH - MET P&T Hi-Res (2sec) (EDR/RDR) RMC - MET P&T Pressure Correction (RDR) RMA - MET P&T Pressure Ancillary (RDR) 9 Reserved Filler "_" 10-20 SCLK Spacecraft Clock (zero padded) 21 Reserved Filler "_" 22-25 Token Last 4 digits of PSI Token (Instrument + Command IDs = MET ID) 26 Producer (Reserved) M - MET Team 27 Version Version number, 0-9,A-Z (36 total) 28 Period Always set to "." (ASCII period) 29-31 File Extension PDS file extensions. LBL Label File TAB Data Table Appendix E. PHOENIX TOKEN CONVENTION A template for Token Conventions is shown below (All values given in Hex format): Position Name Description/value 1-4 Ops Token Assigned value for each unique PSI Activity 5-8 Command ID Payload specified ID, for MET: Not Used Appendix F. MARS24 ALGORITHM (Updated May 20, 2008) The calculations made by Mars24 to determine the time for a given location on Mars are primarily based on Allison and McEwen (2000) (henceforth AM2000). We also refer to Allison (1997) (henceforth A1997), of which AM2000 was a thorough update. However, some typographical errors appeared in the published version of AM2000, and some calculations have been revised since publication of that paper because of the availability of new data. (These updates may appear in a paper in preparation by Allison and Ferrier.) Consequently, we provide here step-by-step documentation of the equations employed by Mars24 for users who wish to implement their own Martian timekeeping applications. At the end of this presentation, we also provide worked examples for verification of intermediate results. I. Equations A. Determine Days Since J2000 Epoch Our Mars time calculations will use the parameter Dt_J2000, the elapsed time in days since the J2000 epoch, i.e., 12:00 on Jan. 1, 2000 (TT). The following describes how we get there from a Java call which returns the system time. If one has an alternative scheme for obtaining Dt_J2000, then these steps can be skipped. A-1. Get a starting Earth time. Mars24 is written in Java, so we use the System.currentTimeMillis() method to find out the number of milliseconds, millis, that have elapsed since 00:00:00 on Jan. 1, 1970 (i.e., the Unix epoch). Unfortunately, most if not all Java implementations (or the operating systems on which they run) do not keep track of leap seconds, i.e., they keep time in UT rather than UTC. Consequently, when Mars24 calls System.currentTimeMillis(), it assumes that the value returned uses UT rather than UTC. Only A-2 in the following steps explicitly uses millis. However, there are some displays in Mars24 which also use other readings based on the value of millis, so there is a possibility that if Mars24 is used on a computer and Java implementation which do keep track of leap seconds, display errors could result. A-2. Convert millis to Julian Date (UT). Although there's plenty of sample code available on-line which demonstrates how to convert a Gregorian calendar date to a Julian Date, we simply use the offset from a known, recent Julian Date. Again, we use the Unix epoch, 00:00:00 on Jan. 1, 1970. JD_UT = 2440587.5 + (millis / 8.64_107 ms/day) A-3. Determine time offset from J2000 epoch (UT). This step is optional; we only need to make this calculation if the date is before Jan. 1, 1972. Determine the elapsed time in Julian centuries since 12:00 on Jan. 1, 2000 (UT). T = (JD_UT - 2451545.0) / 36525. A-4. Determine UTC to TT conversion. (Replaces AM2000, eq. 27) Terrestrial Time (TT) advances at constant rate, as does UTC, but no leap seconds are inserted into it and so it gradually gets further ahead of UTC. The best way to determine the difference between TT and UTC is to consult a table of leap seconds. Alternatively, one could try to use an empirical formula. In Mars24 we, oddly enough, use both methods. We use the USNO table for dates after Jan. 1, 1972, and a formula for dates prior to then. In consulting the USNO table, however, it is important to note that the table provides values for the TAI-UTC difference, where TAI is International Atomic Time. To obtain the TT-UTC difference, add 32.184 seconds to the value of TAI-UTC. For example, the USNO table indicates that on Jan. 1, 2006, the TAI-UTC value is 33.0 seconds, and thus, the value for TT-UTC on that date (and until the next date on which another leap second is added to the clock) would be 33.0s + 32.184s = 35.184s. The formula applied for dates prior to Jan. 1, 1972, is similar to AM2000, eq. 27, but has been revised and includes additional terms: TT - UTC = 64.184s + 59 (s) T - 51.2 (s) T^2 - 67.1 (s) T^3 - 16.4 (s) T^4 (Note: Mars24 uses the USNO table which includes the leap second added Jan. 1, 2006. Obviously, then, it does not allow for any leap seconds which might be subsequently added. Bulletin C 33 from the IERS Earth Orientation Centre indicates this will not occur any earlier than Jan. 1, 2009.) A-5. Determine Julian Date (TT). JD_TT = JD_UT + [(TT - UTC) / 86400 s/day] A-6. Determine time offset from J2000 epoch (TT). (AM2000, eq. 15) Dt_J2000 = JD_TT - 2451545.0 B. Determine Mars Parameters of Date Now we turn our attention to Mars, first determining some orbital paramaters. B-1. Determine Mars mean anomaly. (AM2000, eq. 16) M = 19.3870 degrees + 0.52402075 degrees X Dt_J2000 B-2. Determine angle of Fiction Mean Sun. (AM2000, eq. 17) alpha_FMS = 270.3863 degrees + 0.52403840 degrees X Dt_J2000 B-3. Determine perturbers. (AM2000, eq. 18) PBS = SUM[i=1,7] A_i cos [ (0.985626 degrees X Dt_J2000 / tau_i) + phi_i] where 0.985626 degrees = 360 degrees / 365.25, and i A_i tau_i phi_i 1 0.0071 2.2353 49.409 2 0.0057 2.7543 168.173 3 0.0039 1.1177 191.837 4 0.0037 15.7866 21.736 5 0.0021 2.1354 15.704 6 0.0020 2.4694 95.528 7 0.0018 32.8493 49.095 B-4. Determine Equation of Center. (Bracketed term in AM2000, eqs. 19 and 20) The equation of center is the true anomaly minus mean anomaly. nu - M = (10.691 degrees + 3.0 X 10-7 degrees X Dt_J2000) sin M + 0.623 degrees X sin 2M + 0.050 degrees X sin 3M + 0.005¡ sin 4M + 0.0005 degrees X sin 5M + PBS B-5. Determine areocentric solar longitude. (AM2000, eq. 19) L_s = alpha_FMS + (nu - M) C. Determine Mars Time C-1. Determine Equation of Time. (AM2000, eq. 20) EOT = 2.861 degrees X sin 2L_s - 0.071 degrees X sin 4L_s + 0.002 degrees X sin 6L_s - (nu - M) The above result for EOT is in degrees. Multiply by (24 h / 360 degrees) = (1 h / 15 degrees) to obtain the result in hours. C-2. Determine Coordinated Mars Time. (AM2000, eq. 22, modified) This is the mean solar time at Mars' prime meridian. MTC = mod_24 { 24 h X ( [(JD_TT - 2451549.5) / 1.027491252] + 44796.0 - 0.00096 ) } The function mod_24 indicates a re-setting of the function parameter, a cyclical value, to a value between 0 and X. In this case, we apply mod24 to indicate that values outside the range 0-24 should be re-set to be within that range, e.g., mod24 (30) = 6. C-3. Determine Local Mean Solar Time. The Local Mean Solar Time for a given planetographic longitude, Lambda, in degrees west, is easily determined by offsetting from the mean solar time on the prime meridian. LMST = MTC - Lambda (24 h / 360 degrees) = MTC - Lambda (1 h / 15 degrees) C-4. Determine Local True Solar Time. (AM2000, eq. 23) LTST = LMST + EOT (24 h / 360 degrees) = LMST + EOT (1 h / 15 degrees)