1. Purpose and Scope of Document
The purpose of this document is to provide users of TEGA Reduced Data Record (RDR) products with a detailed description of the products and a description of how they are generated, including data sources and destinations. The TEGA RDR data set consists of four data products including converted engineering data, calorimetric data, and two types of gas analyzer (mass spectrometer) data.
The document is intended to provide enough information to enable users to read and understand the data products. The users for whom this document is intended are the scientists who will analyze the data, including those associated with the Phoenix Project and those in the general planetary science community.
2. Applicable Documents
1. Planetary Data System Standards Reference, JPL D-7669 part 2, version 3.7, March 20, 2006.
2. Phoenix Project Archive Generation, Validation and Transfer Plan, JPL D-29392, Rev. 1.0, December 20, 2004.
3. Planetary Data System Archive Preparation Guide, JPL D-31224, Version 1.1, August 29, 2006.
4. Mars Exploration Program Data Management Plan, Arvidson et al., Rev. 3.0, March 20, 2002.
5. Phoenix TEGA Team and PDS Geosciences Node Interface Control Document (ICD), Version 1.1, July 11, 2005.
7. Phoenix TEGA Archive Volume Software Interface Specification, Version 2 0, November 20, 2007.
8. CODMAC "Issues and Recommendations Associated with Distributed Computation and Data Management Systems for the Space Sciences", Committee on Data Management and Computation Space Science Board, National Research Council, National Academy Press, Washington, D.D., 1986
9. TEGA Experiment Data Record Software Interface Specification, JPL PH 274-304, D-33227, Version 1.2, March 22, 2007.
10. The Thermal and Evolved Gas Analyzer on the Phoenix Mars Lander, Boynton et al., in preparation, 2008.
3. Relationships with Other Interfaces
This SIS document and the products it describes could be affected by changes to PDS standards, Phoenix archive plans, the agreement between the TEGA Team and the PDS Geosciences Node, and the agreements among the Phoenix Science Operations Center, Phoenix instrument teams, and the PDS, as described in Applicable Documents 1, 2, 5, and 6. Changes to the TEGA Experiment Data Records (EDR) will necessitate changes in the RDR data products. Applicable Document 9 will record changes to the EDR data products. Changes to the design of the RDR products would require this SIS to be updated, and might also require updates to Applicable Document 7.
4. Data Product Characteristics and Environment
4.1 Instrument Overview
The TEGA instrument, one of seven instruments aboard the 2007 Phoenix Mars Lander, is a thermal and evolved-gas analyzer. TEGA is designed to analyze ~50 mg of fine grained soil or rock fragments that are loaded into ovens via a funnel. It consists of five basic components: a retractable contamination cover, a soil delivery system, an oven/calorimeter (TA), a gas storage and handling system, and an evolved-gas analyzer (EGA).
Prior to TEGA operation the retractable contamination cover opens slowly to carry away contamination expected to settle on the outer surfaces of TEGA. The cover system consists of two independent foil covers each sealing the space just above each row of four Thermal Analyzer (TA) cells cross contamination doors. The seal is made with the 0.03 mm thick stainless steel foil sandwiched between a continuous frame of neodymium-iron-boron magnets and a thin magnetic steel top frame. To open, the foil is slid from between the frames by winding it onto a spool which is driven by a paraffin actuator through a ratchet mechanism. When the cover is fully opened the sealed interior of the instrument is vented through 54 cm², 2 micron stainless steel wire cloth.
The TEGA soil delivery system is made up of a door release mechanism, a screen, a vibrating solenoid, a tri-bladed soil impeller, and a trough/funnel which delivers soil to the male oven half. Soil/rock samples are acquired from the Martian surface by the Phoenix Robotic Arm. The arm scoops the soil sample up and deposits it in the TEGA soil delivery system. A 1 mm grid screen filters out particles too large for the oven. The vibrations of the solenoid are imparted to the entire thermal analyzer (TA) chassis to sift soil through the screen, as well as assist gravity in the movement of the soil down the trough to the funnel area of the TA, which fills the male oven half. A detector and LED pair is located across the collar of the funnel just above the male oven half. The LED/detector pair is used to indicate when the oven is filled.
TEGA is built with eight, single-use thermal analyzer (TA) cells, each of which has its own oven and sample receiving funnel. The TEGA ovens are very small. The inside dimensions are about 2.4 mm diameter and 8 mm long. The male half, which receives the sample material via a funnel, is inserted into the female half, which contains heater and temperature sensors. The TA cells are used to collect calorimetric data, i.e. temperatures and heat flows associated with thermal transitions in a material, on the sample. These data are collected to characterize the thermodynamic and chemical properties of the sample material. Calorimetric data (SCRDR) is obtained by carefully measuring the power applied to the oven to achieve a desired temperature during a programmed temperature ramp.
Careful reduction of all heat loss mechanisms was necessary to permit calorimetry to be possible to the highest temperatures with the limited power and energy available from the lander. The entire TA unit is surrounded by a heated radiation shield. The shield is used to minimize the affect of imprecisely known and changing surface emissivities by controlling the shield temperature to match the sample container. The shield also minimizes the radiative heat loss from the sample container reducing its power requirement which increases the calorimetry sensitivity.
Figure 1. TA before being hooked up to EGA - Retractable cover slightly retracted to expose the TA doors.
The TEGA gas-handling system distributes Calibration or Carrier gas and regulates the pressure in the system through a manifold and plumbing system. The calibration tank provides a mass and concentration standard to provide an in-situ calibration source for the mass spectrometer. These gasses as well as any evolved gas are eventually exhausted to the Mars atmosphere. The supply tanks have sufficient capacity to support all eight SC samples and any calibration requirements with an appreciable margin ( >100%).
The gases are distributed to the ovens via a manifold assembly. The manifold contains 19 valves, a pressure sensor, and five flow-regulating frits. A downstream frit at the outlet of the Evolved Gas Analyzer provides additional pressure rise at the mass analyzer input as well as providing a substantial impediment to back-streaming atmospheric gases.
The calibration tank contains 40% by volume Carbon dioxide, Oxygen at 0.1%, Krypton 86 at 0.01%, and 1mL of Deuterium enriched liquid water. The balance of this mixture is nitrogen. The water was added to the tank as a liquid so that the gas would be saturated at the tank temperature. In operation, we will control the temperature of the tank to determine the partial pressure of water vapor in the calibration gas supply.
The manifold is highly adaptable in its operation. The oven inlet and outlet valves are operated independently, so it is possible to seal the ovens, flow carrier gas through the ovens, or allow the ovens to vent via the vapor pressure of the evolved gases. The manifold also has a bypass valve which permits calibration gas to be analyzed in the EGA and allows the calibration gas to be purged from the system by flowing carrier gas directly into the EGA before a sample is analyzed. Owing to mass and volume constraints, commercially available, elastomer-sealed, normally closed solenoid valves were selected and qualified for TEGA. The leak integrity of the carrier and calibration supply tanks is maintained by nickel foils which are punctured by a wax-motor mechanism just prior to the first analysis on the surface. The carrier or calibration master valve is pulsed to regulate the pressure of the carrier and calibration gases in the manifold to control the flow rate through the system. At our nominal flow rate of 0.04 standard mL/min, the pressure in the oven and at the mass analyzer inlet are ~30 mbar. These pressures are a function of the flow rate and are determined by various flow restrictors.
Figure 2. Overall block diagram of the TEGA instrument.
Various engineering readings associated with the gas and many other mechanical and electrical components will be recorded in the engineering data products (ENGRDR). See Figure 2 for the overall block diagram of the TEGA instrument for engineering reading context.
As a sample is heated, various gases are evolved depending on the nature of the sample. The evolved gas is passed through a manifold to the EGA. The EGA is a magnetic-sector mass spectrometer, which can determine both the quantity of the evolved gas and its isotopic composition (EGSRDR, EGHRDR). The EGA is synchronized to the temperature of the oven, so the composition of the gases can be correlated to their temperature of evolution.
The EGA has four mass ranges extending from 1.5 Da to 140 Da. The four specific mass ranges are 0.9-4, 7-35, 14-70 and 28-140 Da. Using four channels reduces the magnitude of the mass scan and provides simultaneous coverage of the mass ranges. The width of the object and collector slits and the radius of the ion path in the magnetic field determine the mass resolution of the instrument. This is set at 150 (M/DM) for the high mass channel. The mass resolution of the other channels is proportionally reduced.
The instrument sensitivity is adjusted so that the max counting rate at an ion source pressure of 8 x 10-6 mbar is 2 megahertz. The frequency of the preamp is 12 megahertz and has a probability of missing a count for this maximum frequency of < 3 %. The dynamic range is then at 1 count/sec equal to 2 x 10-6. Using the high sensitivity adds a factor of 8, for a dynamic range of 1.6 x 10-7. Adding the counting rates for 100 measurements at each mass should allow measurement of a constituent at the 100 ppb mixing ratio (partial pressure of 1 x 10-12) to a statistical precision of 10%; at 10 ppb (partial pressure of 1 x 10-13) the precision is 30%. The realized sensitivity will depend on the residual peak amplitude at the particular mass number of interest. The accuracy of the measurement of amount of a constituent gas or its isotopic ratio depends on comparison of the counting rates on the sample of interest to those in the calibration gas.
Two operating modes are available for the EGA. One consists of sweeping in a stepwise manor the ion acceleration voltage to cover the entire mass range over the 4 channels to determine what gasses are present in the furnace sample or in the atmosphere and the relative abundances of each constituent (EGSRDR). Sweep mode is used to see the whole mass range instead of just the expected masses. The other mode, called the peak hopping mode, involves adjusting the ion accelerating voltage to hop from peak top to peak top (EGHRDR). On a given peak, 5 or 7 measurements of counting rate will be made while stepping over the top of the peak. A step size as small as 0.01 to 0.02 Da is used. The amplitude of the peak is determined by fitting a curve to the 5 or 7 data points. Dwell time for the accumulation of counts is adjustable by command and will be selected as a function of the expected counting rate for each mass peak to be measured. Those peaks having high counting rates will have a shorter accumulation time. There is a dead time imposed between each accumulation period as the high voltage sweep power supply is commanded to a new voltage. The settle time of the power supply is a function of the voltage step size and ranges from 5 to 50 msec.
In Mass Hopping mode (EGHRDR) the EGA only scans certain selected masses. The selected masses are pre-programmed groups of elements and are generally the most common species of interest, i.e. H, H2, C, CO2, H2O, N2 or CO. Several sets of modes can be strung together making a "supermode", which is used to perform an analysis such as a TA analysis or an atmospheric analysis. The hopping mode is used to measure isotopic ratios of the various elements and can also be used to monitor a given mass peak to determine the exact temperature at which the molecule is released from the sample in the TA. For example, the temperatures at which water vapor and carbon dioxide are released can be measured as the sample is heated. See Appendix 7.4 for examples of the EGA sweeps, hops, and super modes.
A nominal TEGA thermal analyzer run spans 5 days; The first day will include opening the door of the selected thermal analyzer and performing a health check on the thermal analyzer at least one day prior to soil acquisition. Instrument warming, EGA calibration, soil acquisition, oven closure, low-temperature scanning calorimetry and evolved-gas analysistakes place on the second day. Soil acquisition includes receiving a sample from the robotic arm, vibrating the sample to load it into the oven, autonomously verifying soil delivery, and performing the low-temperature sample analysis. The third day activities consist of instrument warming and EGA calibration followed by mid-temperature scanning calorimetry and evolved-gas analysis.The fourth day activities will consist of instrument warming and EGA calibration followed by high-temperature scanning calorimetry and evolved-gas analysis. The fifth day will repeat the high-temperature sequence executed on the fourth day but without the evolved-gas analysis. The repeat of the high temperature experiment will provide a baseline measure of heat capacity and heat lost to the environment without the mineral decomposition phase transitions. These data will be subtracted from the data taken on the fourth day and the difference will be the differential calorimetry. The optimization of TEGA operation will depend on what is found in the first Mars samples, so the nominal operational flow given above may change. The E-kernel RDR data product will contain a description of the events of each sol. This will include experimental activities on Mars and planning activities on Earth. The e-kernel data product is the definitive source for what happened when.
Figure 3. Instrument with TA and EGA integrated as one unit. Cover fully deployed.
TEGA will use all eight single-use ovens over the course of the mission. The results of the each oven sample will impact how the other ovens are used. If organic material is detected the Organic Free Blank (OFB) material (Ming et al. 2008) that has been included with the TEGA instrument will be used. Initially, the soil delivery system and/or the scoop on the RA may have some terrestrial contamination that gets removed by repeated use so that samples measured later in the mission might have less contamination. Analyzing the blank later in the mission will allow a better assessment of the blank after any loose terrestrial contamination has been removed. If a positive organic signal is detected before analyzing the blank, the same sample can be analyzed again after the blank to ensure the first result was correct. The differences between the three measurements should show the difference between Earth contaminants that have accompanied the spacecraft to Mars or organics that are Martian in origin. In addition, it is possible that organics may not be detected on Mars in which case OFB would not be analyzed, allowing the use of all eight TA cells for Mars samples. See Ming et al., 2008 for a full discussion of the TEGA blank strategy.
TEGA is controlled by flight software that runs on the dedicated TEGA microprocessor. The flight software issues commands to the instrument, and collects housekeeping and science data. The TEGA flight software reports TEGA specific information to the Lander command and data handling system. TEGA information collected by the Lander, along with spacecraft engineering data are then returned to Earth via the Deep Space Network.
Further information about the TEGA instrument and experiment specifics can be found in the TEGA instrument paper [Applicable Document #10].
4.2 RDR Data Product Overview
Table 4.1 summarizes TEGA standard RDR data products.
Table 4‑1TEGA Standard RDR Data Products
|
Product Type |
NASA Level |
Description |
PDS Data Set ID |
|
ENGRDR |
1A |
Engineering data converted to engineering units as time series |
PHX-M-TEGA-3-ENGRDR-V1.0 |
|
SCRDR |
1B |
SC time series data of oven and shield duty cycle durations within each of the time series slices. |
PHX-M-TEGA-4-SCRDR-V1.0 |
|
EGSRDR |
1B |
EGA counts at each mass swept by the mass spectrometer as a time-series. |
PHX-M-TEGA-4-EGSRDR-V1.0 |
|
EGHRDR |
1B |
Times and counts at masses scanned in mass hopping mode. |
PHX-M-TEGA-4-EGHRDR-V1.0 |
All RDR products are time-series data stored as binary tables described by detached PDS labels, with one table perActivity perMartian Sol. In addition to the standard data products, a text file call the TEGA_E_KERNEL will be produced for each activity during a Martian Sol. This file will have an attached PDS label and will describe the data collection events of each sol. Details of the RDR data products are specified by product in Section 5.
4.3 Data Processing
This section provides general information about the processing of TEGA data sets. Details specific to each data set are found in Section 5.
4.3.1 Data Processing Level
All TEGA RDR products are considered reduced data products as defined by both NASA and CODMAC (see Appendix 7.1.) TEGA ENGRDR products are processed to NASA Level 1A (CODMAC 3) as they have been calibrated. SCRDR, EGSRDR and EGHRDR products are processed to NASA Level 1B (CODMAC 4) as they have been re-sampled from the raw data.
4.3.2 Data Product Generation
TEGA data products will be generated by the TEGA Team led by Co-Investigator Boynton at the Lunar and Planetary Laboratory,University of Arizona. Once a TEGA measurement is collected it is stored on the Lander and held for periodic download. The stored telemetry data are downloaded periodically 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 UA. Raw telemetry data are received by UA, and a number of automated computer processes are run to ingest the data into a database, and to transform the data into scientifically useful data products. The following sections describe this process in more detail.
4.3.2.1 TEGA_tl
TEGA_tl is the process by which telemetry data down-linked from the 2007 Mars Phoenix Lander is transferred from the JPL TDS to the UA and prepared for ingestion into the UA TEGA database. Data packets are wrapped with specifically formatted headers at each phase of data transfer. The TEGA _tl program is designed to remove any or all of the header information and transform data packets to a useable form. TEGA_tl receives input data from any of a number of input sources (e.g. raw telemetry), strips out the TEGA specific data, and outputs that data in the requested format. In the case of telemetry data, a process on the JPL Spacecraft Operations Processing Computer (SOPC) called stot retrieves selected Standard Format Data Unit (SFDU) packets from the TDS via a query server, and sends the retrieved SFDU packets to a socket. A connection is made between the socket and TEGA_tl, and packet data is passed to TEGA_tl.
The stream of SFDU data packets is read in from the socket. The SFDU packet consists of a primary label, an aggregate header (Compressed Header Data Object, CHDO), up to 4 headers (Primary [required], secondary, tertiary, quaternary), and an optional data CHDO. The primary label and headers are stripped from the packet and are written to a file "SFDU.hdr." The remaining information is a Consultative Committee for Spacecraft Data Systems (CCSDS) packet, consisting of header information and data. The CCSDS headers are removed and written to a file "CCSDS.hdr." The remaining data is then in the form of a TEGA packet, and includes the data as output by the TEGA instrument suite. The TEGA data packets consist of a telemetry header structure, a data type specific data structure, and an appended checksum. The last step in the process is to convert the TEGA data packets to BCE (Bench Checkout Equipment) type packets. BCE type packets are a suite of data type specific packet formats with a common header structure that were developed for data transfer and handling during pre-flight tests. The packet definitions were found to work well, and have been modified only slightly for the flight data. BCE packets are formed by stripping the telemetry header from the TEGA packet and replacing it with the BCE common header structure followed by the data type specific data structure. Any needed regrouping or decompression of data occurs in the translation from TEGA to BCE data format.
Figure 4.4 TEGA_tl data flow diagram.
Data with an invalid telemetry header is flagged as "invalid header." If the checksum is not correct, then the packet is flagged as "bad checksum." The BCE formatted data are sent either to a data spooler (similar to a print spooler) to wait for database ingestion or to be written to files. If BCE output is written to files, it is placed in a structured directory which can then be used for data validation. The directory structure is a top level directory with standard sub-directories categorized by data type.
TEGA_tl can also be used to translate data from one packet type to another (Figure 4.1.) The input data stream can consist of SFDU packets, CCSDS packets or TEGA data packets. The packets are read, parsed, and translated to an output packet format. Output types can be SFDU, CCSDS, TEGA data or BCE formatted packets. The output packets can then be sent to a socket and/or written to a file. The only restrictions on data type transformation are that BCE packets cannot be used as TEGA_tl input, and the data types cannot be "up converted", for example CCSDS packets cannot be transformed into SFDU packets.
4.3.2.2 TEGA_Ingest
The ingest process is the mechanism by which data is ingested into the UA TEGA database. The input data used by ingest are the BCE packet type output from the TEGA_tl program. Ingest receives data from the spooler and inserts it into the appropriate database tables.
Ingest initialization sets up the necessary connections to the SPICE kernel information, the database, and the input data. The Navigation and Ancillary Information Facility (NAIF) Node of the Planetary Data System (PDS) collects and maintains the SPICE information system. SPICE (Spacecraft, Planet, Instrument, C-matrix, Events) is a means for providing scientists with geometric and event data and related tools useful in the interpretation of science instrument observations returned from planetary spacecraft. SPICE data files, called kernels, exist for spacecraft trajectory (S); planet ephemeris and associated physical and cartographic constants (P); instrument information, including mounting alignment and other relevant geometric information (I); orientation of spacecraft structures upon which science instruments are mounted (C); and spacecraft and ground data system events, both planned and unplanned (E) (NAIF, http://pds.jpl.nasa.gov/naif.html). The SPICE kernel files are opened and loaded, and a connection to the database is established. Once the appropriate connections are made, the data ingestion begins.
Figure 4.5 TEGA Database Ingest data flow diagram
The Ingest function, which waits for the client on the socket, calls the input_open procedure. Input_open initializes the socket on the designated port. Once the socket is open, the proc_pkts function processes each packet of data through the input_next procedure. Input_next reads the socket header to get the total number of bytes in the packet, and then reads the common header to get the sequence bytes. The rest of the packet is then read.
The data type, read from the common header, is returned, determining the next step in the processing. One of eleven different procedures is run to insert packet data into the database (Figure 4.2). The insertion procedure is based on the data type being processed. If the data type returned is less than or equal to 0 an error message is returned stating that the packet was not inserted.
Engineering data is converted from the raw telemetry digital number value to engineering unit value upon ingest into the database. There are 82 identically formatted engineering data tables (see Table 4.2) in the UA database. The ingest process inserts the raw engineering data and TEGA time (tega_time) into each engineering table based on the engineering parameter name. The raw engineering values as received from the spacecraft are in a digital number (DN) format and are supplied to the PDS as the TEGA ENEDR data product. In order to facilitate data reduction the digital numbers are converted to engineering values by a database trigger that is called by the ingest process. The trigger uses an appropriate polynomial conversion factor for the value, and then inserts the converted engineering unit value into the database table. The polynomial conversion factors for each engineering parameter were derived from ground calibrations and can be found in Appendix 7.3.
Table 4‑2TEGA Engineering Parameters
|
Engineering Parameter Name |
Abbreviation |
Unit |
Description |
|
|
TA_MANIFOLD_PRES |
TA_MAN |
mB |
Manifold Pressure |
|
|
TA_PLUS_5_VREF |
TA_P5R |
V |
+5V REF |
|
|
TA_OUTLET_PRES |
TA_OUT |
mB |
Outlet Pressure |
|
|
TA_MANIFOLD_TEMP |
TA_MAT |
C |
TA Manifold Temperature |
|
|
TA_EGA_PLUMB_TEMP |
TA_EPT |
C |
MS Plumbing Temperature |
|
|
TA_EGA_BAKEOUT_TEMP |
TA_EBT |
C |
Bakeout temperature |
|
|
TA_PLUMBING_1_TEMP |
TA_P1T |
C |
Plumbing 1 Temperature |
|
|
TA_PLUMBING_2_TEMP |
TA_P2T |
C |
Plumbing 2 Temperature |
|
|
TA_EGA_MAN_TEMP |
TA_EMT |
C |
MS Manifold Temperature |
|
|
TA_CAL_TANK_TEMP |
TA_CTT |
C |
Cal Tank Temperature |
|
|
TA_CPU_TEMP |
TA_CPT |
C |
CPU Temperature |
|
|
TA_PWR_SPLY_1_TEMP |
TA_PS1 |
C |
Power Supply 1 Temperature |
|
|
TA_PWR_SPLY_2_TEMP |
TA_PS2 |
C |
Power Supply 2 Temperature |
|
|
TA_PWR_CNTL_1_TEMP |
TA_PC1 |
C |
Power Control 1 Temperature |
|
|
TA_PWR_CNTL_2_TEMP |
TA_PC2 |
C |
Power Control 2 Temperature |
|
|
TA_A2D_TEMP |
TA_ADT |
C |
ADC Temperature |
|
|
TA_COVER_1_TEMP |
TA_C1T |
C |
cover 1 temperature |
|
|
TA_INPUT_FUNNEL_1_LO_TEMP |
TA_FL1 |
C |
Funnel 1 Temperature |
|
|
TA_PRES_SENSE_FD_BK |
TA_PSC |
V |
Pres Sense Exc. Feedback |
|
|
TA_INPUT_FUNNEL_2_LO_TEMP |
TA_FL2 |
C |
Funnel 2 Temperature |
|
|
TA_OVEN_TEMP |
TA_OVT |
C |
Oven Temperature |
|
|
TA_SHLD_TEMP |
TA_SHT |
C |
Shield Temperature |
|
|
TA_EGA_ELECT_BOX_TEMP |
TA_EGT |
C |
TEB Temperature |
|
|
TA_T_HEATER_TEMP |
TA_THT |
C |
"T" Heater Temperature |
|
|
TA_TRANS_TUBE_TEMP |
TA_TTT |
C |
Transfer Tube Temperature |
|
|
TA_EGA_GEC_TEMP |
TA_GEC |
C |
GEC Temperature |
|
|
TA_BUS_A_VOLT |
TA_BAV |
V |
Bus A Voltage |
|
|
TA_AGD_0_3 |
TA_G03 |
V |
AGD_0_3 ground |
|
|
TA_AGD_3_1 |
TA_G31 |
V |
AGD_3_1 ground |
|
|
TA_CPU_PLUS_5_VOLT |
TA_P5V |
V |
CPU Voltage |
|
|
TA_ANLG_PLUS_12_VOLT |
TA_APV |
V |
Analog +12V Voltage |
|
|
TA_ANLG_MINUS_12_VOLT |
TA_AMV |
V |
Analog -12V Voltage |
|
|
TA_OVEN_PLUS_15_VOLT |
TA_OPV |
V |
Oven Voltage |
|
|
TA_SHIELD_PLUS_30_VOLT |
TA_SPV |
V |
Shield Voltage |
|
|
TA_BUS_A_CUR |
TA_BAC |
A |
Bus A Current |
|
|
TA_BUS_B_CUR |
TA_BBC |
A |
Bus B Current |
|
|
TA_EGA_CUR |
TA_EGC |
A |
EGA Current |
|
|
TA_CPU_PLUS_5_CUR |
|
A |
CPU Current |
|
|
TA_ANLG_PLUS_12_CUR |
|
A |
Analog +12V Current |
|
|
TA_ANLG_MINUS_12_CUR |
TA_AMC |
A |
Analog -12V Current |
|
|
TA_OVEN_PLUS_15_CUR |
TA_OPC |
A |
Oven Current |
|
|
TA_SHIELD_PLUS_30_CUR |
TA_SPC |
A |
Shield Current |
|
|
TA_FULL_DETECT |
TA_FDE |
V |
Full Detect Integrated Diode Sensor |
|
|
TA_FULL_DETECT_RAW |
TA_FDR |
V |
Full Detect Raw Diode sensor reading |
|
|
TA_OVEN_ERR |
TA_OER |
V |
Oven Error |
|
|
TA_SHLD_ERR |
TA_SER |
V |
Shield Error |
|
|
TA_CAL_TANK_COLD_TEMP |
TA_CTC |
C |
Cal Tank Cold Temperature |
|
|
TA_COVER_2_TEMP |
TA_C2T |
C |
cover 2 Temperature |
|
|
MEM_OVEN_INT_LO |
ME_OIL |
DN |
Oven integrator value low bytes |
|
|
MEM_OVEN_INT_HI |
ME_OIH |
DN |
Oven integrator value high bytes |
|
|
MEM_SHLD_INT_LO |
ME_SIL |
DN |
Shield integrator value low bytes |
|
|
MEM_SHLD_INT_HI |
ME_SIH |
DN |
Shield integrator value high bytes |
|
|
MEM_OVEN_VOLT |
ME_MOV |
V |
Oven voltage |
|
|
MEM_OVEN_CUR |
ME_MOC |
A |
Oven current |
|
|
MEM_SHLD_VOLT |
ME_MSV |
V |
Shield voltage |
|
|
MEM_SHLD_CUR |
ME_MSC |
A |
Shield current |
|
|
MEM_MANIFOLD_PRES |
ME_MMP |
mB |
Manifold pressure |
|
|
MEM_OVEN_ERR |
ME_MOE |
V |
Oven error |
|
|
MEM_SHLD_ERR |
ME_MSE |
V |
Shield error |
|
|
MEM_T_WIDTH |
ME_MTW |
DN |
T pulse width |
|
|
MEM_OVEN_WIDTH |
ME_MOW |
DN |
Oven pulse width |
|
|
MEM_SHLD_WIDTH |
ME_MSW |
DN |
Shield pulse width |
|
|
EGA_STATUS_BITS |
EG_ESB |
Bits |
Status bits value |
|
|
EGA_TRAP_CUR |
EG_ETC |
mA |
Trap current monitor |
|
|
EGA_EMISSION_CUR |
EG_EEC |
mA |
Emission current monitor |
|
|
EGA_FILAMENT_1 |
EG_EF1 |
V |
Filament 1 in use |
|
|
EGA_FILAMENT_2 |
EG_EF2 |
V |
Filament 2 in use |
|
|
EGA_PLUS_5_VOLT |
EG_EP5 |
V |
+5 volt monitor |
|
|
EGA_PLUS_12_VOLT |
EG_EP2 |
V |
+12 volt monitor |
|
|
EGA_MINUS_12_VOLT |
EG_M12 |
V |
-12 volt monitor |
|
|
EGA_FILAMENT_CUR_1 |
EG_FC1 |
V |
Filament 1 current monitor |
|
|
EGA_FILAMENT_CUR_2 |
EG_FC2 |
V |
Filament 2 current monitor |
|
|
EGA_MULTIPLIER_VOLT |
EG_EMV |
V |
Multiplier voltage monitor |
|
|
EGA_ION_PUMP_VOLT |
EG_EIV |
V |
Ion Pump voltage monitor |
|
|
EGA_ION_PUMP_CUR |
EG_EIC |
mA |
Ion Pump Current monitor |
|
|
EGA_SWEEP_VOLT |
EG_ESV |
V |
Sweep voltage monitor |
|
|
EGA_GEC_CUR |
EG_EGC |
A |
GEC current monitor |
|
|
EGA_MAGNET_TEMP_1 |
EG_M1T |
C |
Magnet 1 temperature |
|
|
EGA_MAGNET_TEMP_2 |
EG_M2T |
V |
Magnet 2 temperature |
|
|
EGA_PROC_TEMP |
EG_ECT |
C |
CPU temperature |
|
|
EGA_AVG_CALLS |
EG_EAC |
Count |
Average # of calls to Task Queue |
|
|
EGA_MIN_CALLS |
EG_EMC |
Count |
Minimum # of calls to Task Queue |
SC and EGA telemetry are inserted into appropriate data tables in the UA TEGA database. These values are inserted into the database in a raw telemetry form. Once all telemetry values have been inserted into the TEGA database at UA, EDR data products are generated. After EDR data product generation, simple correlations of telemetry derived date, SPICE kernel information for time conversions, and ground based calibration information are made to generate the RDR data products. The processes used to create the RDR data products are called create_scrdr, create_egsrdr, and create_eghrdr, respectively. The e-kernel is created by hand from mission planning notes.
4.3.3 Data Flow
TEGA RDR data products are generated from the raw TEGA data that has been stored in the TEGA database, as discussed in Section 4.3.2. Table 4.2 lists the time span covered by each data product, the data product generation interval, the expected size of each of the RDR data products, and the total expected data volume for each product.
Table 4‑3TEGA RDR Data Volume
|
Product Type |
Time span covered |
Generation Interval |
Expected Size of Product (Bytes)* |
Total Data Volume (Bytes). |
|
ENGRDR |
1 Activity on 1 Sol |
90 sols |
4,460,000 |
200,700,000 |
|
SCRDR |
1 Activity on 1 Sol |
90 sols |
2,000 |
90,000 |
|
EGHRDR |
1 Activity on 1 Sol |
90 sols |
805,000
|
36,255,000 |
|
EGSRDR |
1 Activity on 1 Sol |
90 sols |
23,000 |
1,035,000 |
*Data volumes based on the TEGA operation plan of 45 sols. Nominally 5 days/sample, plus 5days margin.
The TEGA RDR data products are delivered to the Phoenix Science Operations Center (SOC) where they are made available to other Phoenix science teams and assembled into archive volumes. The SOC will then deliver the TEGA archive volumes to the PDS Geosciences Node for release to the public. This data flow is governed by Applicable Document 6.
4.4 Standards Used in Generating Data Products
This section specifies various standards that apply to TEGA data products.
4.4.1 Labeling and Identification
The file naming scheme defined for the Phoenix Lander instrument products adheres to, and is compliant with the PDS Level II 27.3 filename standards. The file naming convention described here divides the filename into two parts (none consecutive). The first part is instrument-independent, or generic, containing a minimal set of fields, which apply to all instruments aboard the Phoenix Lander. The second part is reserved for instrument-specific fields.
Each product name must be uniquely identifiable throughout the mission by incorporating a combination of relevant fields such as Spacecraft Clock count (SCLK), instrument identifier, data source, observation identifier, product token, etc.
The generic portion of the file name as described here is not sufficient for uniqueness. The information saved in the instrument-specific portion, in conjunction with the generic portion, must guarantee uniqueness.
The file naming rules are as follows:
I. Only letters A-Z, digits 0-9 and the underscore ("_") may be used.
II. All characters must be in upper case.
III. The full length of product name must be 31 characters, 27 for the filename followed by a "." and a three-character file extension.
IV. All fields and sub-fields must be filled or padded with "_" (ASCII underscore) as needed to maintain proper length. For number fields, zeros should be used instead.
V. The convention used for/by instrument must guarantee uniqueness throughout the whole mission.
A template for general filename is shown below, and the table that follows provides additional detail for individual fields.
Table 4‑4 File Naming Template
|
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 |
30 |
31 |
|
Instrument |
Source/Epic |
Sol |
Product Type |
Instrument Specific |
Producer |
Version |
. |
Extension |
||||||||||||||||||||||
The "Instrument Specific" portion is reserved for each instrument/team to use as needed, within the boundaries stated by the above rules.
Table 4‑5 Detailed description of product name components
|
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-WCE X MECA-Misc 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 |
These 3-char identifiers are differentiated as either EDR (Level 0) or RDR (Level 1+) products. If the identifier begins with an "E", then the product is a type of EDR. Otherwise, it is a type of RDR.
See applicable instrument SIS documents for detailed descriptions of all valid product types for each instrument. |
|
9-25 |
Reserved |
Reserved, and required, for instrument-specific fields. See table 4-6 for TEGA-specific RDR file names. Unused positions are filled with "_" (ASCII underscore) |
|
26 |
Producer (Reserved) |
Producer's id, although part of the reserved portion for instrument-specific field, this field to be used to identify the generating entity of the product. M MIPL U TEGA
|
|
27 |
Version |
Version number, 0-9,A-Z (36 total) |
|
28 |
Period |
Always set to "." (ASCII period) |
|
29-31 |
File Extension |
PDS file extension, instrument specific. IMG Imaging/Camera data DAT Non-imaging instrument data QUB Multi-layer, cube products TAB Table/tabular data
See table 10-1 in the PDS Standards Ref. for complete list of acceptable extensions |
Table 4‑6 TEGA-specific RDR file names
|
Character Position |
1-8 |
9-27 |
28-31 |
|
ENGRDR Product |
TSnnnRDR |
_aa_bbb_yyyymmdd_cv |
.DAT |
|
ENGRDR Examples |
TS020RDR |
_TA_MAN_20080501_U1 |
.DAT |
|
All other RDR products |
TSnnnRDR |
_aaa_yyyy_mm_dd__cv |
.DAT |
|
SCRDR Example |
TS020RDR |
__SC_2008_05_01__U1 |
.DAT |
|
EGHRDR Example |
TS020RDR |
_EGH_2008_05_01__U1 |
.DAT |
|
EGSRDR Example |
TS020RDR |
_EGS_2008_05_01__U1 |
.DAT |
4.4.1 PDS Standards
TEGA RDR data products comply with Planetary Data System standards as specified in the PDS Standards Reference (Applicable Document 1). All filenames, by definition, will be PDS compliant. Additional identification information will be contained in the PDS label files for each data product as described in Appendix 7.
4.4.2 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 even occurred on-board, in UTC.
SCLK Spacecraft Clock: An on-board 64-bit counter, in units of nano-seconds, which increments once every 100 milliseconds, with origin, set to zero, at midnight on 1-Jan-1980.
ERT Earth Received Time (UTC): The time when the first bit of the packet containing the current data was at the Deep Space (DSN) station.
Local Solar Time: LST is the local solar time expressed by the number of local solar days (SOLs) from a landing date and using a "24-hour" clock readout within the current local solar day (HR:MN:SC); LST is a true local solar time and computed using positions of the Sun and the landing site from SPICE kernels specified in CHRONOS setup file; if a landing date is unknown to the program it cannot convert input LST to any other time system and can compute LST only without SOL number for the output; LST examples: SOL 12 12:00:01 SOL 132 01:22:32.498 SOL 2 9.
4.4.3 Coordinate Systems
The following coordinate systems are used within the project to refer to the position of the Lander and its instruments.
Table 4‑7 Coordinate Systems.
|
Coordinate System |
Origin |
Orientation |
|
Local Level |
Same as payload frame, and it moves with the Lander |
+X North +Z down along gravity vector +Y East |
|
Payload Frame |
At the shoulder of the Robotic Arm. Attached and moves with the Lander |
+X along Lander -X ( point out into the work space) +Z down along Lander (vertical axis) +Y along Lander -Y
|
|
Site Frame |
Same as payload frame when first defined and never moves relative to Mars. Possible to define multiple site frames in case the Lander moves/slips. |
Same as local level |
Phoenix imaging product conventions are as follows.
- XYZ maps are generated in site frame
- Surface Normal maps are in Lander frame
- PSI targets are in site frame
- RSVP targets are in site frame
4.4.4 Data Storage Conventions
The TEGA RDR data products are stored as fixed-length binary files, most-significant-byte-first (big-endian) format. Text files are formatted in standard ASCII text.
4.4.5 Command Sequence Tracking
Each TEGA data product label includes the Phoenix-specific keyword OPS_TOKEN.
The OPS_TOKEN is a code associated with a Phoenix data product that provides information about the command sequence that caused the product to be acquired. The value is a 32-bit unsigned hexadecimal integer expressed in a PDS label as 16#AAAAPCCC#, where:
- AAAA is the campaign ID assigned by the sequence planning team,
- P is a 4-bit payload ID reserved for use by each instrument team, as defined by the team, and
- CCC is the command sequence number, which is set to zero for each new campaign and automatically incremented with each command.
The combination of OPS_TOKEN and sol number should uniquely identify a Phoenix data product.
For TEGA products, the payload ID field (bits 17-20) is defined as 0.
4.5 Data Validation and Peer Review
The TEGA 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 TEGA RDR products during production will be done according to specifications in the Phoenix Archive Plan and the TEGA Team - Geosciences Node ICD (Applicable Documents 2 and 5). The TEGA Team will validate the science content of the data products, and the Geosciences 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 TEGA ENGRDR
5.1.1 Data Product Structure and Organization
The ENGRDR data product is a collection of engineering readings gathered from 84 engineering sensors aboard the TEGA instrument. This data product reports the engineering readings as physical unit of volts, amps, or degrees Celsius. The physical nits are derived from the digital number readings reported in the TEGA ENGEDR data product. The ENGRDR data product is structured as 84, 3-column, time ordered data files. Each data file corresponds to a single engineering parameter. (See Table 4‑2 TEGA Engineering Parameters for the list of engineering parameters.)
This product is organized as 84 binary data files containing converted engineering data collected over a single activity during a measurement day, with a detached ASCII text PDS label file (See Appendix 7.4 for example label). The label is a combined-detached label with pointers to all the files. Each engineering data file will be labeled in a format of a 27 character string with a .DAT file extension. The first eight characters indicate instrument and product level. The second eight characters indicate engineering parameters. The third eight characters indicate the date of collection. The last three characters indicate the location where data were produced. These 84 data files will be grouped together by activity on a single measurement day. The data folders will be labeled by activity in a format of N, where N is a consecutively number activity on a measurement day starting with 1.
5.1.2 Data Format
The data format for the ENGRDR is a 3-column binary table. Columns range from 8 to 23 bytes in width. Column structure and start byte are described in Appendix 7.4.1. The number of rows in a data table will depend on the number of collection intervals during the measurement period. We would expect approximately 1000 data records per file, but there may be some variations due to short data gaps.
5.1.3 Label and Header
The TEGA data product has detached PDS labels stored as ASCII text. A PDS label is object-oriented and describes the objects in the data file. The PDS label contains the keywords for product identification and for data object definitions. The label also contains descriptive information needed to interpret or process the data objects in the file.
PDS labels are written in Object Description Language (ODL) [4]. PDS label statements have the form of "keyword = value". Each label statement is terminated with a carriage return character (ASCII 13) and a line feed character (ASCII 10) sequence to allow the label to be read by many operating systems. Pointer statements with the following format are used to indicate the location of data objects:
^object = location
where the carat character (^, also called a pointer) is followed by the name of the specific data object. The location is the name of the file that contains the data object.
An example of the ENGRDR label can be found in Appendix 7.4
5.2 TEGA SCRDR
5.2.1 Data Product Structure and Organization
The TEGA SCRDR are scanning calorimeter data from the TEGA Thermal Analyzer. This dataset is comprised of oven and shield duty cycle durations. The data product is structured as a time series, 7-column data table. See Appendix 7.5 for an example of the data product label and the table structure.
This product is organized as a binary data file containing SC data collected over a single activity during a measurement, with a detached ASCII text PDS label file for each binary data file. The data folders will be labeled by activity in a format of N, where N is a consecutively number activity on a measurement day starting with 1.
5.2.2 Data Format
The data format for the SCRDR is a 7-column binary table that varies in width from 4 to 23 bytes. Column structure and start byte are described in Appendix 7.5.1. The number of rows in a data table will depend on the number of collection intervals during the measurement period. We would expect approximately 50 data records per file, but there may be some variations due to short data gaps.
5.2.3 Label and Header
The TEGA SCRDR data product has detached PDS labels stored as ASCII text. A PDS label is object-oriented and describes the objects in the data file. The PDS label contains the keywords for product identification and for data object definitions. The label also contains descriptive information needed to interpret or process the data objects in the file.
An example of the SCRDR label can be found in Appendix 7.5.
5.3 TEGA EGHRDR
5.3.1 Data Product Structure and Organization
The TEGA EGHRDR are EGA mass hopping data. The mass hopping mode of the EGA is a mode where selected masses are examined by hopping to a mass range and collecting data at the next 5 or 7 masses and then hopping to the next mass of interest. The data product is structured as a time series, 14-column data table. See Appendix 7.6 for the table structure.
This product is organized as a binary data file containing EGA mass hopping data collected over a single activity during a measurement day, with a detached ASCII text PDS label file for each binary data file. The data folders will be labeled by activity in a format of N, where N is a consecutively number activity on a measurement day starting with 1.
5.3.2 Data Format
The data format for the EGHRDR is a 14-column binary table that varies in width from 1 to 34 bytes. The last column in the binary table is a pointer to a container, which is itself a 5-column binary table. The container holds the EGHRDR data records. Column structure and start byte for both the EGHRDR and the EGHRDR data records are described in Appendix 7.6.1 and Appendix 7.6.2, respectively. The number of rows in the data record data table will depend on the number of collection intervals during the measurement period. We would expect approximately 200 data records per file, but there may be some variations due to short data gaps.
5.3.3 Label and Header
The TEGA EGHRDR data product has detached PDS labels stored as ASCII text. A PDS label is object-oriented and describes the objects in the data file. The PDS label contains the keywords for product identification and for data object definitions. The label also contains descriptive information needed to interpret or process the data objects in the file.
An example of the TEGA EDHRDR label can be found in Appendix 7.6.
5.4 TEGA EGSRDR
5.4.1 Data Product Structure and Organization
The EGSRDR are EGA sweep mode data. Sweep mode data can either be used for calibrations (sweep mode calibration = 4) or for sample analysis (sweep mode normal = 1). The data product is structured as a time series, 14-column data table. See Appendix 7.7 for a label example and table structure.
This product is organized as a binary data file containing EGA sweep mode data collected over a single activity during a measurement day, with a detached ASCII text PDS label file for each binary data file. The data folders will be labeled by activity in a format of N, where N is a consecutively number activity on a measurement day starting with 1.
5.4.2 Data Format
The data format for the EGARDR is a 14-column binary table that varies in width from 1 to 36 bytes. The last column in the binary table is a pointer to a container, which is itself a 9-column binary table. The container holds the EGSRDR data records. Column structure and start byte for both the EGSRDR and the EGSRDR data records are described in Appendix 7.7.1 and Appendix 7.7.2, respectively.
5.4.3 Label and Header
The TEGA EGSRDR data product has detached PDS labels stored as ASCII text. A PDS label is object-oriented and describes the objects in the data file. The PDS label contains the keywords for product identification and for data object definitions. The label also contains descriptive information needed to interpret or process the data objects in the file.
See Appendix 7.7 for an example of the EGSRDR label.
5.5 TEGA_E_KERNEL
5.5.1 Data Product Structure and Organization
The TEGA_E_KERNEL data are ASCII text narrations of the events that take place in the TEGA subsystem during each activity. See Appendix 7.9 for a label example and table structure.
This product is organized as an ASCII text file containing information about data collected over a single activity, with an attached ASCII text PDS label.
5.5.2 Data Format
The data format for the TEGA_E_KERNEL files will be ASCII Text.
5.5.3 Label and Header
The TEGA _E-KERNEL data product has an attached PDS labels stored as ASCII text. A PDS label is object-oriented and describes the objects in the data file. The PDS label contains the keywords for product identification and for data object definitions. The label also contains descriptive information needed to interpret or process the data objects in the file.
See Appendix 7.9 for an example of the TEGA_E_KERNEL label.
6. Applicable Software
No software will be supplied with these data products.
6.1 Utility Programs
There are no TEGA specific utility programs supplied with these data products. All products are viewable with the NASAView software supplied by the PDS.
6.2 Applicable PDS Software Tools
PDS-labeled images and tables can be viewed with the program NASAView, developed by the PDS and available for a variety of computer platforms from the PDS web site http://pds.jpl.nasa.gov/tools/software_download.cfm. There is no charge for NASAView.
6.3 Software Distribution and Update Procedures
There are neither software-distribution nor update procedures associated with these data products.
7. Appendices
7.1 Definitions of Data Processing Levels
Table 7.1 shows definitions of processing levels as defined by NASA and by CODMAC, the Committee on Data Management and Computation (Applicable Document 8.)
Table 7‑1Data Processing Levels
|
NASA |
CODMAC |
Description |
|
Packet data |
Raw - Level 1 |
Telemetry data stream as received at the ground station, with science and engineering data embedded. |
|
Level-0 |
Edited - Level 2 |
Instrument science data (e.g., raw voltages, counts) at full resolution, time ordered, with duplicates and transmission errors removed. |
|
Level 1A |
Calibrated - Level 3 |
Level 0 data that have been located in space and may have been transformed (e.g., calibrated, rearranged) in a reversible manner and packaged with needed ancillary and auxiliary data (e.g., radiances with the calibration equations applied). |
|
Level 1B |
Re-sampled - Level 4 |
Irreversibly transformed (e.g., re-sampled, remapped, calibrated) values of the instrument measurements (e.g., radiances, magnetic field strength). |
|
Level 1C |
Derived - Level 5 |
Level 1A or 1B data that have been re-sampled and mapped onto uniform space-time grids. The data are calibrated (i.e., radiometrically corrected) and may have additional corrections applied (e.g., terrain correction). |
|
Level 2 |
Derived - Level 5 |
Geophysical parameters, generally derived from Level 1 data, and located in space and time commensurate with instrument location, pointing, and sampling. |
|
Level 3 |
Derived - Level 5 |
Geophysical parameters mapped onto uniform space-time grids. |
|
|
Ancillary - Level 6 |
Data needed to generate calibrated or re-sampled data sets. |