Phoenix Project

Software Interface Specification (SIS)

MECA Non-imaging

Experiment Data Record (EDR)

Authors:

M. Hecht (JPL), S. Slavney (Washington U.), A. Stanboli (JPL), P. Zamani (JPL)

Custodian:

Payam Zamani

Paper copies of this document may not be current and should not be relied on for official purposes. The current version is in the Community Server at: Team Work Area/Mission System/MOS/GDS/OPGS-MIPL

JPL D-33230

4 December 2008

Jet Propulsion Laboratory

California Institute of Technology

DOCUMENT CHANGE LOG

TBD ITEMS

CONTENTS

1. Purpose and Scope of Document......................................................................................................... 6

2. Applicable Documents............................................................................................................................... 6

3. Relationships with Other Interfaces.......................................................................................... 6

4. Data Product Characteristics and Environment................................................................ 7

4.1 Instrument Overview................................................................................................................................... 7

4.1.1 Atomic Force Microscope (AFM)............................................................................................................ 7

4.1.2 Thermal and Electrical Conductivity Probe....................................................................................... 11

4.1.3 Wet Chemistry Laboratory (WCL)......................................................................................................... 13

4.1.4 Software and Electronics....................................................................................................................... 14

4.2 Data Product Overview............................................................................................................................ 15

4.3 Data Processing overview....................................................................................................................... 16

4.3.1 Data Processing Level............................................................................................................................. 16

4.3.2 Data Product Generation....................................................................................................................... 16

4.3.3 Data Flow.................................................................................................................................................. 16

4.3.4 Labeling and Identification standards................................................................................................ 16

4.3.5 PDS Standards.......................................................................................................................................... 16

4.3.6 Time Standards......................................................................................................................................... 17

4.3.7 Data Storage Conventions..................................................................................................................... 18

4.4 Data Validation and Peer Review....................................................................................................... 18

5. Detailed Data Product Specifications....................................................................................... 18

5.1 Data Product Structure and Organization.................................................................................... 18

5.2 Label and Header........................................................................................................................................ 19

6. Applicable Software................................................................................................................................ 19

Appendix A. PRODUCT LEVELS................................................................................................................. 20

Appendix B. RECORD STRUCTURE........................................................................................................... 21

B.1 Data Structure Overview....................................................................................................................... 21

B.2 Binary data description.......................................................................................................................... 21

B.2.1 Binary header detail............................................................................................................................... 21

B.2.2 Binary data detail.................................................................................................................................... 22

Appendix C. PDS LABEL KEYWORDS...................................................................................................... 59

Appendix D. EDR File naming convention................................................................................... 71

Standards.............................................................................................................................................................. 71

File Naming Rules.............................................................................................................................................. 71

Appendix E. Examples of EDR PDS Labels.................................................................................... 73

Type 0: AFM_FRQTEST....................................................................................................................................... 73

Type 1: AFM_RESPONSE.................................................................................................................................... 75

Type 2: AFM_SCAN.............................................................................................................................................. 78

Type 3: AFM_TIPS................................................................................................................................................. 81

Type 4: CME_STATUS......................................................................................................................................... 84

Type 5: POWER_DATA........................................................................................................................................ 86

Type 6: TBL............................................................................................................................................................. 90

Type 7: TECP........................................................................................................................................................... 93

Type 8: WCHEM.................................................................................................................................................... 95

Appendix F. EDR Type 6 Table Contents....................................................................................... 99

Table 0: State Table......................................................................................................................................... 99

Table 1: Parameter Value Table.............................................................................................................. 102

Table 2: Parameter Range Table.............................................................................................................. 110

Table 3: AFM Attribute Table.................................................................................................................... 110

Table 4: Coupons Table................................................................................................................................. 112

Table 5: Tips Table........................................................................................................................................... 112

Appendix G. Format Files..................................................................................................................... 114

AFM_FREQUENCY_SAMPLE.FMT................................................................................................................ 114

AFM_TIPS.FMT.................................................................................................................................................... 116

TBL_0_STATE_DATA.FMT.............................................................................................................................. 118

TBL_1_PARAMETER_VALUES_DATA.FMT.............................................................................................. 124

TBL_2_PARAMETER_RANGE_DATA.FMT................................................................................................ 124

TBL_3_AFM_ATTRIBUTE_DATA.FMT....................................................................................................... 125

TBL_4_COUPONS_DATA.FMT....................................................................................................................... 126

TBL_5_TIPS_DATA.FMT.................................................................................................................................. 126

TECP_SAMPLE.FMT.......................................................................................................................................... 127

Appendix H. Acronyms............................................................................................................................. 131

1. Purpose and Scope of Document

The purpose of this document is to provide users of MECA Experiment Data Records (EDR) with a detailed description of the products and how they are generated, including data sources and destinations.

The document is intended to provide enough information to enable users to read and understand the data products. Intended users of this document are the scientists who will analyze the mission and supporting data, both those associated with the Phoenix Project and members of 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, version 0.050503, May 3, 2005.

4. Mars Exploration Program Data Management Plan, Arvidson et al., Rev. 3.0, March 20, 2002.

5. Data Management and Computation, Volume 1: Issues and Recommendations, Committee on Data Management and Computation, Space Science Board, Assembly of Mathematical and Physical Sciences, National Research Council, National Academy Press, Washington D.C., 1982

6. Issues and Recommendations Associated with Distributed Computation and Data Management Systems for Space Sciences, Space Science Board, Assembly of Mathematical and Physical Sciences, National Research Council, National Academy Press, Washington D.C., 1986

3. Relationships with Other Interfaces

This SIS document, and the products that it describes, could be affected by changes to the MECA or Phoenix flight software or PDS standards. Such changes may require updates to this document as applicable. Major changes would require re-approval of all listed individuals and teams per the signature page.

4. Data Product Characteristics and Environment

The Microscopy, Electrochemistry, and Conductivity Analyzer (MECA) is a suite of soil analysis instruments that combines a wet chemistry laboratory (WCL), an optical microscope (OM), an atomic-force microscope (AFM), and a thermal and electrical-conductivity probe (TECP), with common supporting structure, electronics, and software.

Data in this product represent the lowest level reduction of packet data from the MECA instrument with the notable exception of the images acquired by the OM, which are described in the Phoenix Camera EDR/RDR SIS and archived on the Imaging node of the Planetary Data System. However, status information pertaining to those images and various tabular data that determine how they are acquired are part of this Non-Imaging product.

4.1 Instrument Overview

The MECA instrument suite is a component of the Mars '07 Phoenix investigation, which will also return data from a Thermal and Evolved Gas Analyzer (TEGA), three cameras, and a meteorology suite (MET). Phoenix is motivated by the goals of (1) studying the history of water in all its phases, and (2) searching for habitable zones. Samples of surface and subsurface soil and ice will be delivered to MECA and TEGA from a trench excavated by a Robot Arm, while MECA's Thermal and Electrical Conductivity Probe (TECP) will be deployed in soil and air by the Robot Arm. The Robot Arm Camera will document the morphology of the trench walls, while the Surface Stereo Imager (SSI) and the Mars Descent Imager (MARDI) establish a geological context. Throughout the mission, MET will monitor polar weather and local water transport.

4.1.1 Atomic Force Microscope (AFM)

The Atomic Force Microscope (AFM) is part of the MECA Microscopy Station, which comprises a Sample Wheel and Translation Stage (SWTS), an optical microscope (OM), and the AFM. As shown in Figure 1, the MECA AFM is located between the OM and the SWTS inside the darkened MECA enclosure on the spacecraft deck. It scans a small region (from 1-65 µm square) on any of 69 substrates, each 3-mm in diameter, positioned along the rim of the SWTS. The chief scientific objectives of the AFM are to analyze small dust and soil particles in terms of their size, size distribution, shape, and texture. The AFM is particularly well suited to analyze particles carried by the wind, which are believed to be in the size range 1-3 µm.

Prior to AFM scanning, OM images are acquired to document the substrates and provide context for the AFM scans. OM data is described in the Phoenix camera SIS, along with the RAC and SSI, and is outside the scope of this document. The reader is also referred to that document for more detailed description of the SWTS and its substrates.

The AFM is contributed by a Swiss-led consortium spearheaded by the University of Neuchatel. Run by a dedicated microcontroller, the AFM uses one of an array of eight micromachined cantilevers with sharp tips to obtain topographs (sometimes called "scans" or "images") of up to a 65×65-µm area of the sample. Within this constraint the scan can be of any size, dimension, or orientation, but the AFM can only address a narrow horizontal stripe of each substrate. Since the sample wheel can be rotated (but not elevated) prior to initiation of scanning, the AFM can access a thin band approximately 1/3 of the way up from the bottom of the corresponding OM image. Note that the x and y axes of the MECA AFM image are rotated by +45 degrees relative to the OM images (figure 2).

The 69 substrates on the SWTS are divided into ten sets of six (a weak and a strong magnet, two "microbuckets", a textured substrate, and a sticky silicone pad) and nine utility or calibration targets. Using the SWTS, these can be coated with a thin layer of dust or soil, and then rotated to the vertical scanning position where they can be imaged by the optical microscope. Of the six substrates in each set, two are specifically designed for AFM use in that they resist the tendency for particles to become dislodged and to adhere to the AFM tip. Such particle adhesion can degrade the scans in question and the quality of the tip in general. One of these substrates is a uniform piece of silicone that remains pliant under martian conditions. The second is a custom micro-machined silicon substrate with pits and posts that hold particles of an appropriate scale for AFM scanning. Two of the remaining four substrates are magnets that may, under certain circumstances, be appropriate for AFM scanning. The final two substrates are deep "buckets" that would not normally be accessible to the AFM.

To operate the microscopy station, soil samples are deposited by the RA (or dust from the air) onto a segment of the SWTS ring that has been extended such that exactly one set of 6 substrates protrudes from a horizontal slot in the MECA enclosure. Excess material is removed by passing the substrates under a blade positioned 0.2 mm above the surface, after which the samples are rotated for imaging by the OM and AFM. The exposed substrates are then rotated from their horizontal load positions into their vertical imaging positions. The SWTS is also used for focusing and AFM coarse positioning.

Attempting to scan excessively steep or ragged surfaces with the AFM will result in scans that are largely out of range, and could conceivably damage the tip. Further, bandwidth and time constraints severely limit the number of scans that can be acquired and returned to Earth. These considerations dictate a two-day imaging strategy for each set of microscopy samples. On the first day a sample is delivered, then characterized by the optical microscope. AFM calibration scans are also acquired. These images are evaluated on the ground and targets for AFM scanning are selected. On the second day the targeted areas are imaged again with the optical microscope, and then scanned with the AFM.

MECA's AFM comprises three major components, a microfabricated probe-chip, an electro-magnetic scanner-actuator and single board control electronics. The probe-chip features 8 cantilevers, numbered 0-7. The chip is mounted with two orthogonal tilt angles of 10 degrees relative to the sample to ensure that only one tip contacts the sample at a time. In case of contamination or malfunction of this front-most tip, the defective cantilever and its support beam can be cleaved off by a special tool on the sample wheel, after which the next one in the array becomes active. The force constant of the levers varies between 9 and 13 N/m.

Each of the 8 MECA cantilevers features an integrated piezo-electric stress sensor, which is used to measure its pure deflection (static mode) or its vibration amplitude, frequency and phase (dynamic mode). In static mode the deflection signal is proportional to the force, while in dynamic mode the shift of the resonance frequency is a measure of the force gradient. Dynamic mode minimizes the interactions between tip and surface and is less likely to result in particles being moved around or dislodged during the scan. In either mode, these signals are used to regulate the distance between the tip and the sample in the z-direction by means of a proportional-integral feedback loop.

The z-axis servo signal represents the sample topography as the tip is rastered across the surface in the x (fast) and y (slow) directions. (Though the resulting topograph is sometimes referred to as an image, it bears little resemblance to an optical image until it is transformed and processed.) Imperfect feedback or an out-of-range condition can result in residual bending of the cantilever in static mode, or a phase shift of the oscillation in dynamic mode. This error signal may optionally be recorded in a second data channel. Since each line in the raster scan begins at the same point on the x-axis, both primary and error signals may be recorded either on the forward or the backward legs of the scan (or, typically, both). Thus a single raster scan can produce up to four arrays of data: Forward (signal), forward (error), backward (signal), and backward (error), each of which can be displayed in image format.

Several of the status values returned in MECA telemetry refer to the configuration and status of the AFM digital feedback loop. The piezoresistors on the cantilevers are addressed by a multiplexer, which links them to a temperature-compensated Wheatsone bridge. For static mode imaging the value of the bridge is directly compared to a setpoint. For dynamic mode imaging a frequency modulation technique is applied that maintains the resonant frequency of the cantilever at a setpoint while stabilizing the amplitude. The measured parameters are the phase-shift between the excitation of the cantilever and the measured signal from the Wheatstone bridge, maintained by a phase locked loop. The array geometry is designed to spread the resonant frequencies of the levers between 30 and 40 kHz in order to avoid cross-talk during dynamic operation (these shift slightly with temperature).

It must be emphasized that an AFM scan is acquired by rastering a physical tool across a surface. As a result, line-to-line noise and artifacts may be significantly different than point-to-point artifacts along the scan direction. Moreover, outside the range of authority of the cantilever (approximately 65 x 65 micrometers laterally and 13 micrometers in height) the topograph does not go "out of focus" but simply saturates, while anywhere within its range of authority it is equally "in focus." The topograph itself reflects the interaction between a tip of finite size and a non-uniform surface, and therefore convolves physical characteristics of both the probe and the target. Thus, while an AFM topograph may look like an image product, the processing required bears little in common with the processing of an actual optical image.

4.1.2 Thermal and Electrical Conductivity Probe

An end-effector on the Phoenix Robotic Arm (figure 3), the TECP is a probe of soil physical properties including temperature, thermal conductivity and diffusivity, electrical conductivity and permittivity, as well as atmospheric temperature, humidity, and wind speed. These measurements are made with four conical needles, three of which contain electrical heaters and thermometers, and a hygrometer sensor mounted separately in the body of the TECP.

Three of the four parallel needles contain a thermocouple and a heater. The two needle pairs are used as electrodes for regolith electrical properties measurements. The same needles also serve as heating elements and thermometers for regolith thermal properties and wind speed measurements. The needles can be inserted into the soil for thermal and electrical measurements or positioned above the surface for atmospheric temperature, and wind speed measurements. Regolith thermal properties (including temperature, thermal conductivity, thermal diffusivity, volumetric heat capacity, and thermal inertia) as well as wind speed are derived from the heating and cooling behavior of the needles before and after a known amount of heat is added. Regolith electrical properties, including electrical conductivity and dielectric permittivity, are measured with capacitance and resistance sensors coupled to the regolith through the sensing needles. Atmospheric water vapor concentration is measured with a calibrated capacitance hygrometer mounted near a temperature sensor on the TECP printed circuit board, but exposed to the atmosphere through a particulate filter.

The humidity sensor determines the capacitance of the thin film hygrometer, which is a calibrated function of the relative humidity at the film surface. By measuring the film temperature with the adjacent temperature sensor, the result can be converted to absolute humidity. Under the assumption that gradients in vapor pressure are small, external relative humidity can be determined by comparison of the TECP result with the MET temperature sensors.

The scientific objectives of the TECP are:

• To provide ground-truth for orbital surface thermal measurements and input parameters for thermal models by directly measuring the thermal properties of Martian regolith.
• To measure the concentration and nature of water in martian regolith in solid, "non-frozen," liquid, and vapor states.
• To determine changes in the reservoirs of water when soil is freshly exposed.
• To characterize the movement of water in and out of the soil by measuring atmospheric humidity, temperature, and wind speed above the surface.

Figure 3: Top: Schematic of TECP position on the RA. See description of RA encoder joint angles in TECP_SAMPLE.FMT. Bottom: TECP (right) mounted on the robotic arm. The small white circle on the lower left is the humidity sensor. The four needles at right perform the other sensor measurements.

TECP thermal and electrical properties measurement quality depends on proper needle placement by the RA. Non-linear insertion, partial insertion, and lateral movement all affect data quality negatively. Thermal properties measurements can also be negatively impacted by non steady state thermal conditions, and the TECP should therefore be allowed to equilibrate to its thermal environment before making thermal properties measurements.

Measurement electronics are contained in the body of the TECP, and include a 12 bit A/D converter, two phase detectors, three resistance bridges, and a digital shift register. The A/D converter and shift register communicate through a serial interface to an FPGA on the primary MECA control and measurement electronics (CME) board.

4.1.3 Wet Chemistry Laboratory (WCL)

MECA's wet chemistry laboratory (WCL) comprises four single-use modules, each consisting of a beaker assembly and an actuator assembly (figure 4). The modules mix soil samples with a leaching solution in a pressure vessel for electrochemical analysis. The scientific objective of the WCL is to determine the total pH, redox properties, and concentration of the principal aqueously solvated components of the acquired soil samples.

Chemical data is returned by 26 distinct sensors, some redundant, lining the walls of each beaker. These measure: Temperature; pH (3); conductivity; oxidation-reduction potential; the anions chloride (2), bromide, and iodide; cations sodium, potassium, calcium, magnesium; and barium, used in a sulfate titration. Also included are electrodes for cyclic voltammetry, anodic stripping voltammetry, and chronopotentiometry (3). Lithium electrodes (2) are used as a reference relative to the known concentration of lithium salts in the solution. Sensors for nitrate, ammonium, dissolved oxygen and carbon dioxide, which for various reasons do not provide a quantitative measure of soil composition, are used only for context. A heater is imbedded in the base of the beaker to maintain water temperature during operation.

Each WCL actuator assembly includes a tank containing 25-30 ml of a calibration and leaching solution, a sample loading drawer with a capacity of ~1.0 cm³, temperature and pressure sensors, heaters, a stirring mechanism, and a device to dispense up to five small crucibles into the solution. The AA is responsible for soil, water, and solid reagent addition as well as stirring and two-zone internal heating (tank and drawer). Telemetry returned by the AA includes internal cell pressure, water storage tank and sampling drawer temperatures, and certain limit switch positions.

Each WCL experiment lasts two days, not necessarily sequential. After an initial post-landing checkout, preparation for a chemical experiment starts with melting the frozen leaching/calibration solution in the storage tank and delivering it to the beaker by actuating a puncture mechanism. Sensors are calibrated in that solution, and then calibrated again after addition of a crucible containing small quantities of specific salts. The combined ion concentration from the initial solution and from the crucible, less than 10-4 molar for most ions, establishes the detection floor. The final step is to open the sampling drawer and receive a sample from the robotic arm. The total sample volume is estimated with an accuracy of 0.25 cc (maximum 1 cc) from images acquired by the robot arm camera. For the remainder of the day, the concentration of major anions and cations are monitored as well as key indicators such as pH, redox potential, and cyclic voltammetry, stirring when appropriate and maintaining a constant temperature of 5C. At the end of the day the solution is allowed to freeze in the beaker. A second day of measurement begins with thawing of the solution in the beaker, determining the sensor baseline, and adding an acid-containing crucible to lower the pH. Monitoring continues as on the first day. The final activity is the sequential addition of three crucibles of barium chloride. A sulfate titration is performed by monitoring the barium and chloride levels as the crucible contents slowly dissolve.

Most sensors will have three separate calibration steps prior to their use on Mars. Each individual electrochemical sensor was first calibrated prior to integration into the beaker by laboratory measurement in several standard solutions using commercial electronics. The second calibration was performed with the same solutions after beaker integration, using flight-like analog electronics and a laboratory digital controller. The exceptions were the bromide and iodide sensors, which could not be tested after integration without contaminating the chloride sensor. The final two-point calibration will occur on Mars. In general, the ion selective electrodes exhibit classic logarithmic Nernstian behavior over the specified measurement range. While the two-point calibration will be used to determine logarithmic slope and zero offset, the laboratory data suggests that it is sufficient to assume the ideal Nernstian slope and correct only the offset.

Pre-amplifier circuitry for the electrochemical sensors is embedded in the beaker walls. Analog to digital conversion (12-bit) is performed on a heavily-multiplexed "Analog Board" which interfaces to an FPGA on the primary MECA control and measurement electronics (CME) board. The FPGA also generates waveforms for the voltammetric and potentiometric sensors, performs temperature control, and operates actuators. Also returned in telemetry is a reading from an external temperature sensor located on the base of the microscopy sample stage.

4.1.4 Software and Electronics

MECA flight software (FSW) runs on the primary spacecraft computer and communicates to MECA hardware at 9600 baud via a serial Payload and Attitude Control Interface(PACI) interface. On the other side of that interface is an FPGA, located on the Command and Measurement Electronics (CME) board inside the MECA enclosure. The FPGA controls all hardware functions in the MECA suite with the exception of the Atomic Force Microscope (AFM), which has an embedded processor, and discreet switches, controlled directly by the spacecraft computer, for powering MECA and for switching between AFM processor and FPGA. Data return described here is generated by the FPGA.

The common MECA electronics return telemetry packets indicative of the overall instrument configuration, including parameter tables, the status of the command and measurement electronics, and the products of a low-level command parser that can be used to address any of the four instruments.

4.2 Data Product Overview

Each MECA Non-Imaging EDR consists of a single file containing binary data preceded by an ASCII PDS label. The body of the file is a binary data set consisting of one of sixteen format types as described in Appendix B. Types 0-3 contain data pertinent to an AFM measurement; the actual scan data is a table in type 2. Types 4 (CME status), 5 (power monitoring), and 6 (tables) are data returned by common electronics functions. Type 7 contains all the TECP data. Types 8-15 pertain to the WCL: Type 8 contains data from all the potentiometric WCL sensors such as pH and ion-selective electrodes; type 9 contains conductivity data; types 10-14 contains various voltammetries and potentiometries, all in a common format; and type 15 contains pressure and temperature data.

Experiment Data Records (EDR), the Level 0 products, are generated directly from the spacecraft telemetry stream but also include results from calibration, characterization, and cataloguing (CCC) activities on a variety of laboratory instruments. Each MECA non-imaging EDR consists of a cluster of uncalibrated data records, typically in a time-series, grouped together by virtue of being acquired on the same sol with the same token, product type, and record length. Tokens are embedded in the file and are assigned at the time of sequence generation specifically for the purpose of dividing EDRs into logical segments and helping to associate the data products with the original command sequence. Product types reflect the flight software command used to generate the data. Sixteen distinct telemetry product types have been defined, and are described in Appendix B. Within a particular telemetry type, the record length may vary with commanded parameters, and thus it is contingent on sequence engineers to apply common parameters to data commands whose records should be grouped together. As part of EDR generation, distinct products that have been transmitted in multiple telemetry packets (as indicated by a common time stamp) are reassembled into single records within the EDR.

Discussion of Reduced Data Records (RDR) is outside the scope of this document. In general, however, the objective of the EDR is to ensure that all telemetry, regardless of perceived importance, is retained in an unadulterated form, while the RDRs will emphasize key data and will offer more accessible forms such as ASCII tables and spreadsheets.

4.3 Data Processing overview

4.3.1 Data Processing Level

MECA non-imaging EDRs are equivalent to NASA Level 0 (CODMAC Level 2) data products as defined in Appendix-A. Higher level products (RDR) may have the same general format and structure as EDRs, although they are not described by this document.

4.3.2 Data Product Generation

The MGSS-IOS element, supported by the Multi-mission Image Processing Lab (MIPL) at JPL is responsible for generation of the MECA non-imaging EDRs. Raw MECA data packets are extracted from the telemetry stream and stored in EDRs, by activity, product type and record length. The PDS product label and its keywords are described in detail in Appendix-C.

4.3.3 Data Flow

After generation, each EDR is saved locally on the MIPL file server located at JPL and automatically delivered to the Science Operation Center (SOC) at the University of Arizona in real-time using the File Exchange Interface (FEI),a tool developed by MIPL for automation of data/file transfer using subscription and notification. Upon arrival at the SOC, these files/products will be published into the product catalog (ROMe) via another automated process. It will subsequently be organized in time order and delivered to the PDS in the form of an Archive Volume by the MECA team.

FEI is a tool that is used for automation of data/file transfer using subscription and notification. FEI is a multi-mission tool developed by MIPL.

After the proprietary period has passed, all applicable product such as EDRs, RDRs, etc. will be put into a PDS archive volume and submitted to the PDS Geosciences Node by the MECA team.

4.3.4 Labeling and Identification standards

The EDR format described in this document will follow the Phoenix product file naming conventions as described in Appendix-D. All filenames will be PDS compliant and will follow the Phoenix file naming convention described in Appendix D. Additional identification information will be contained in the PDS label as described in Appendix-C.

4.3.5 PDS Standards

MECA non-imaging EDR products will comply with the Planetary Data System's standards as specified in the PDS Standards Reference (see Applicable Documents). All label keywords are PDS compliant and registered in the PDS dictionary.

4.3.6 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.

4.3.7 Data Storage Conventions

MECA non-imaging EDR products will be stored as binary files, with the binary data preceded by a PDS label in ASCII format, with each keyword definition terminated by ASCII carriage-return and line-feed characters. EDR products are defined as PDS spreadsheet objects (Applicable Document 1).

All MECA non-imaging EDRs will contain fixed length records, although the size of the records in each file could differ between EDRs. When necessary, records will be padded with extra bytes of 0x00.

4.4 Data Validation and Peer Review

The MECA non-imaging EDR product design, as described in this SIS, is subject to PDS peer review. The peer review will be completed 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 MECA non-imaging EDR products during production will be performed according to specifications in the Phoenix Archive Plan and the MECA Team - Geosciences Node ICD (Applicable Documents 2 and 10). The MECA 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

The MECA non-imaging EDR contains time-ordered clusters of raw sensor and status data as specified below. Details of individual fields are described in Appendix B.

Notably absent from many of the EDR products are specific indicators of the relationship between the data and the command that produced it. Since Phoenix is a short mission and there are limited MECA resources (e.g. only four WCL cells and ten SWTS sets), the spacecraft clock tag on every data packet is usually sufficient to allow comparison with, for example, the uplink and downlink logs from the operations team. More explicit linkage will be provided in RDR products.

5.1 Data Product Structure and Organization

The philosophy of the MECA non-imaging data product is to retain the full detail provided in the raw telemetry packet, while clustering related time-sequences of data and eliminating the segmentation of individual objects (e.g. spectra) imposed by the telemetry process. This approach places the emphasis for data analysis on tools provided by the Phoenix Science Team for "ingesting" the binary data into common analysis or spreadsheet platforms. Initially tools will be provided for porting EDRs into the Matlab^© environment and into comma-separated-value (CSV) files for use in spreadsheet environments such as Excel^©.

MECA non-imaging EDRs are generated from raw telemetry with 16 different data types anddata definitions. All instances of MECA non-imaging EDRs will have the same PDS label information, though some fields may be undefined (designated "UNK") for some telemetry types. The binary field definitions are dependent on the telemetry type, which is defined both in the ASCII label information and in the binary header. Definitions of the fields in the MECA non-imaging products are provided in Appendix B.

To aidin distinguishing the ASCII label information from the binary data, the location of the first binary data record will be the final ASCII line which consists of the word "END" followed by carriage return and line feed characters.

5.2 Label and Header

MECA non-imaging data products are described by the same information in the header of each product. A PDS label is an ASCII text field consisting of a series of keyword=value statements. The label carries the metadata necessary to read and understand the data product. An example of a PDS label is provided in Appendix E, and definitions of the keywords used in the label are given in Appendix C.

6. Applicable Software

MECA non-imaging EDRs can be read with any programming language capable of interpreting binary data. As a courtesy to the scientific community, tools will be made available by the Phoenix science team for importing these EDRs into the Matlab^© environment and for producing pure ASCII files consisting of a PDS header and tabulated data. Please contact the MECA Instrument Co-Investigator at michael.h.hecht@jpl.nasa.gov for more information.

Appendix A. PRODUCT LEVELS

Definitions of Data Processing Levels

This table shows definitions of processing levels as defined by NASA and by CODMAC, the Committee on Data Management and Computation (Applicable Documents 8 and 9)

Table A.1 Data Processing Levels

Appendix B. RECORD STRUCTURE

B.1 Data Structure Overview

Each EDR contains an ASCII header consisting of the PDS label, followed by a series of binary data records, each of which begins with a binary header. While certain fields in the binary header are common, others are specific to an individual data type. All records in any single EDR are of the same length and format.

The PDS label is an ASCII text field consisting of a series of keyword=value statements. The label carries the metadata necessary to read and understand the data product. An example of a PDS label is provided in Appendix E, and definitions of the keywords used in the label are given in Appendix C.

Note that all binary quantities are big-endian; that is, the most significant byte of a multi-byte value comes first. In general, PCs are little-endian while Macintosh and UNIX systems are big-endian.

Note also that the word "packet" as used in the field name descriptions is not strictly equivalent to a telemetry packet. The packets referred to in the EDR should more properly be thought of as records, which correspond to a single packet of telemetry except when the data set length forced the flight software to divide it among two or more packets. In the EDR, such split records have been reunited into a single record or "super-packet."

B.2 Binary data description

Following the PDS keywords, each EDR contains a series of binary records of the same type, length, and ops_token (see below) each of which is preceded by a 36-byte binary header.

B.2.1 Binary header detail

* Not present in some data types

The generic format of the Binary Header is described in Table B.2.1, where the fields may be interpreted as follows:

CMD_secs: This is the time that the command was issued from the spacecraft computer to the MECA subsystem across the serial interface. Units are seconds of Spacecraft Clock (SCLK).

CMD_frac: The remainder, where 2³² is a full second.

read_secs: This is the time that the data was returned to the spacecraft computer across the serial interface from the MECA subsystem (not used for some telemetry types). Units are seconds of Spacecraft Clock (SCLK).

read_frac: The remainder, where 2³² is a full second.

datalength: The length of the following record (and all records in this product), not including this header.

records: The number of records in this EDR.

record_num: The number of this record, from 1 to records. These should be in chronological order, but preliminary data products may not have these fields properly populated and the records may be out of order or have data gaps..

datatype: The telemetry type, 0-15, as described in following sections.

TypeSpecific: See individual descriptions in the following sections

ops_token: The ops token consists of 8 hexadecimal digits that help link the data record to the issuing command. It serves to separate groups of products into distinct EDRs in a logical manner and may also be coded for information that is not present elsewhere, such as the command type that produced the data, the WCL beaker number, or TECP gain settings. The first four hexadecimal characters of the ops token are an "activity id" that will be common to all the records in one EDR. The remaining four hexadecimal characters are assigned for various purposes at command time. This document will be updated as protocols for these definitions are established.

B.2.2 Binary data detail

Record descriptions for the various telemetry types are presented in the following sections.

Type 0: AFM: FRQTEST

Description:

Each of the eight AFM cantilevers is tuned to a unique resonant frequency that is used in the "dynamic" or frequency-modulated mode of operation. In dynamic mode a piezoelectric vibrator, which shakes the entire chip, is tuned to a particular cantilever. This is the preferred mode of operation (as compared to "static" mode) because it results in less interaction between the tip and the surface, but it is more complicated and prone to failure. FRQTEST scans through the frequency spectrum to find the resonant frequency and phase as well as the strength of the resonance for the "current" cantilever, which may be temporarily changed by the sequence to allow backup cantilevers to be tested. The quality of the resonance is captured in the applied voltage, V_ap­­­, which is the input voltage required to keep the Phase Locked Loop (PLL) output amplitude at 10V. A good V_ap is around 2.3V, while values above 6V typically indicate that the cantilever cannot be used in dynamic mode.

The test consists of two passes, each of which scans the designated frequency range using each of nine phase settings (0°,20°,40°, etc.). The best frequency and phase, as indicated by the lowest value of V_ap, is selected from these 18 scans.

Generated by:

MECA_AFM_FRQTEST

Format:

Field descriptions:

Tip: This refers to the current beam/cantilever/tip assembly, numbered 0-7. The AFM has eight silicon beams, each topped by a short, flexible cantilever. Protruding from each cantilever is a fine silicon tip. Here and elsewhere, tip is shorthand used to designate the entire assembly. Upon landing, Tip 0 is employed until it is no longer usable.

Vap_initial: This is the value of V_ap at the start of the test (see above).

freq0: The starting frequency for the test

Vap_pass1: The lowest value of V_ap for each of 9 sweeps with different phases

Vap_pass2: Same as above, second pass

freq_pass1: Frequencies corresponding to Vap_pass1

freq_pass2: Frequencies corresponding to Vap_pass1

Vap_min: Best (lowest) value of V_ap from all 18 scans

Vap_min_phase: Phase corresponding to Vap_min

Vap_new: Final value of Vap (should be Vap_min)

amplitude: Amplitude of oscillation corresponding to Vap_min

frequency: Resonant frequency corresponding to Vap_min

Usage notes:

· Voltages are coded as integer data numbers (DN) such that V=DN/25.5

Type 1: AFM: RESPONSE

Description:

The AFM is operated by a custom microprocessor using proprietary code similar to that used by the commercial NanoSurf instrument. Phoenix FSW communicates with the AFM over a serial line. The low-level commands listed below have little or no associated telemetry other than return status codes from the microprocessor. These status codes, a string of ASCII bytes, are returned in Telemetry Type 1. A glossary of these codes is beyond the scope of this document, but the MECA Science Team can advise on the meaning of specific returns. Product length may vary with AFM command, in which case records under a common activity code may be separated into multiple EDRs.

Generated by:

MECA_AFM_ATTRGET (Returns AFM attributes with any of 43 IDs)

MECA_AFM_INITPLN (Prepares to scan)

MECA_AFM_INITBRG (Bridge initialization)

MECA_AFM_MVSTART (Moves to starting point for scan)

MECA_AFM_RAW (Issues raw, low-level command)

MECA_AFM_RDADCS (Reads Analog/Digital Converter)

Format:

Field descriptions:

AFM_response: This is the raw response from the AFM microcontroller to the issued command. the response should be 256 bits (32 bytes) long unless the raw command performed a scan (unlikely).

The format of the response is: <STX> <StatID> [ <StatStr> ] <SUM> <ETX> , where:

• <STX> is a start byte (0x02)
• <StatID> is an identification byte
• [<StatStr>] is the optional return data
• <SUM> is a checksum
• <ETX> is an end-of-transmission byte (0x03)

Type 2: AFM: SCAN

Description:

The AFM acquires topographic information by scanning the image in a raster pattern. Typically the scan is performed both forwards and backwards, and both the nominal height and the error signal are recorded. Thus each physical scan typically results in four data products, typically in the order Forward/Error, Forward/Height, Backwards/Error, Backwards/Height.

Image dimensions along the x and y axes vary to 512x512 bytes, or 266240 bytes per image including line headers. The physical dimensions corresponding to the data grid are not specificied in the telemetry and must be recovered from the command sequence. Subsequent reduced data products will include the conversion to physical units.

The AFM achieves a wide range of vertical (Z-axis) resolution in 8-bit data by offering a choice of gain settings, termed Channel Gain (CG), which is reported in every line header. When CG=0 the 8 bits of data span the entire ~13.6µm range of authority of the z-axis. The exact scan range is somewhat dependent on temperature and will require calibration in situ. Each step increase in CG decreases the range by a factor of two. For example, CG=2 nominally spans 3.4 µm. After every scan line the mean value of z is determined and that becomes the reference position, termed z-offset, for the subsequent line. In this way, even with a high CG, the scan can report some variations of topography in 8-bit data over the entire range of authority of the scanner.

Regardless of the gain setting for the height signal, the error signal range is always 20 V, centered on the setpoint (not reported in telemetry). For example, if the setpoint is 2 V, the range is from -8 to +12 V. The relation between the 20V and the deflection at the end (in microns) depends on the calibration and the mode. In dynamic mode the setpoint, and therefore the error signal is based on a frequency shift.

Note that the AFM feedback loop is always operating over the full range of authority of the cantilever, even if the resulting data is outside the reportable range designated by CG. Height data at the rails do not necessarily imply that the scanner is out of lock - this must be determined from the corresponding error signal. Correspondingly, since the error signal reports the physical error in the feedback loop, it will not reflect the "error" resulting from data values falling outside the range determined by CG and z-offset.

Generated by:

MECA_AFM_IMAGE

MECA_AFM_DOFRAME (low-level command)

MECA_AFM_DOLINE (low-level command)

Format:

Field descriptions:

• width (in header): The number of points per line in the scan
• height (in header): The number of lines in the scan
• direction (in header): Forward or backward scan (typically both are acquired, in that order)
• channel (in header): Error or height (typically both are acquired)
• zoomregion (in header, not used): This was designated for an autozoom function that was never implemented satisfactorily
• AFM Scan Data: Scan data is returned line by line. Each line contains an 8-byte line header followed by the 8-bit scan data. Note that certain items in the line header are inherited from the commercial system and contain redundant information. All bytes are signed integers.
  
  

Byte 1: Scan direction (0 = forward, 1 = backward)

Byte 2: Channel mask (always set to 3)

Bytes 3-4: Line number

Bytes 5-6: Z-offset. The 0-255 range spans the full z-range of the scanner.

Byte 7: Z channel gain (0 spans the full z-range, 1 spans half the range, etc.)

Byte 8: Designated for Vap, not implemented (see Type 0)

Byte 9 - (8+width): 8-bit scan data

Usage notes:

· In nearly all cases, data results from a call to MECA_AFM_IMAGE. In rare cases the low-level commands AFM_DOFRAME and AFM_DOLINE may have been called, in which case the scan data may include interleaved directions and/or channels as well as status data (see Type 1).

· Product length may vary, in which case records under a common activity code may be separated into multiple EDRs.

Type 3: AFM: TIPS

Description:

Data reported here result from initialization and test of the Wheatstone Bridge used to monitor the deflection of the AFM cantilevers. The result is an offset, an assessment of the quality of the cantilever, and the error signal from a "scan" in air which serves to evaluate noise on the measurement circuit (only the error is returned because the actual signal should be at the rail).

Generated by:

MECA_AFM_TSTTIPS

Format:

Field descriptions:

· current-tip: The number 0-7 of the cantilever that the software understands is currently being used for scanning. This is for status only, and all 8 cantilevers are evaluated in order, regardless of this value.

· BridgeOffset1: The offset required to balance the Wheatstone bridge

· BridgeOffset2: Same thing, second pass

· LeverState1: The evaluated condition of the cantilever, pass 1 (0 = NOT_TESTED, 1 = DEAD, 2 = NOT_CENTERED, 3 = OUT_OF_RANGE, 4 = NOISY, 5 = OK)

· LeverState2: Same as above, second pass

· ScanResults1: The error signal from a test "scan" in air consisting of a single line, forwards and backwards. Unlike the AFM_SCAN data type, the signal is not preceded by header information.

· ScanResults2: The Same as above, second pass

Usage notes:

· Data starts with the tip 0 and goes through tip 7, regardless of the value of current_tip. Broken off tips should be marked as dead.

· Note that the first three bytes of the data block (36-38) are not repeated.

· Note that tips 0-7 map into array elements 1-8 to accommodate array numbering conventions of analysis software.

Type 4: CME_STATUS

Description:

Type 4 is a direct response from the FPGA that controls all aspects of MECA operations. It is preserved in EDR format for completeness and because it is occasionally used as a "workaround" for a primary science measurement, but it would not normally be used directly by the general community.

The most common usage of this telemetry type is as a reply to routine requests including turning on LEDs for imaging, moving the microscope sample stage, deploying a chemistry actuator (sample drawer, water release, or stirring motor), or simply a status inquiry. The data return provides not only confirmation that the requested operation occurred, but specific information useful for calibration, such as the position of the stage when the atomic force microscope is engaged.

A second usage of this telemetry type is in response to a "raw" command, a direct instruction to the FPGA to execute any of its allowed functions. While not recommended for routine science measurements, this mode is often used for operations that are not performed in the desired sequence by the standard flight software commands. This method is currently used, for example, to set up the waveform prior to a WCL voltammetry or potentiometry scan. Since all records in a single EDR must be of the same length, the commands containing RAW fields will be in separate EDRs from the routine requests.

Generated by:

MECA_CMD_NO_OP

MECA_CMD_RAW

MECA_OM_SETLEDS

MECA_STG_ABSROT

MECA_STG_ABSXLT

MECA_STG_RELROT

MECA_STG_RELXLT

MECA_WC_DRWRCLS

MECA_WC_DRWROPEN

MECA_WC_RLSRGT

MECA_WC_RLSWATER

MECA_WC_STIR

Format:

Field descriptions:

· RAW: This field would normally be populated only for WCL commands used to set up voltammetry and potentiometry scans.

· CME_Command: Used only when RAW is present, this is an echo of the 42-byte command to the FPGA. Details are available from the MECA team.

· CME_status: This is a standard 22-byte coded field returned by the FPGA. It indicates such things as limit switch positions or which components are enabled or disabled. Details are available from the MECA team.

Type 5: POWER_DATA

Description:

Type 5 data returns a time series of voltage and current values provided by the primary MECA 5V (load and logic) and 15V (load and AFM) power supplies. These results are diagnostic of the functioning of all subsystems and should be indicative of many anomalous conditions.

Generated by:

MECA_CMD_RDPOWER

Format:

Field descriptions:

· nsamples: The number of times the power lines were read.

· samplesize: Should always read 20 (bytes).

· response: The first 4 fields return voltage readings for the 5V logic and load lines followed by the 15V load and the 15V dedicated AFM drive lines. The following 4 fields contain the current signals for the same line. These 12-bit signals are concatenated such that the sequence of 8 requires 12 bytes. The final 8 bytes tag each set of readings with the spacecraft clock time, using the same convention as the header. To express voltages in mV, multiply the data numbers to by 7.324. To express current values in mA, multiply by 0.610.

Type 6: TBL

Description:

Type 6 data returns, on request, the contents of any of six tables that modify the operation of the MECA flight software (FSW). These include a state table which is autonomously maintained by FSW as well as several tables that can only be set by explicit user command. These user-maintained tables contain the values and allowed ranges of parameters and attributes that define the implementation of each experiment. For microscopy, for example, they might define the different substrate positions on the sample wheel as well as the optimal focus position. Download of these latter tables is for the purpose of confirmation that the actual parameters of an experiment were set as intended.

Generated by:

MECA_TBL_DWNLD

Format:

Field descriptions:

· tabletype: The type of table requested: (0=State, 1=Parameter Values, 2=Parameter Ranges, 3=AFM Attribute ranges, 4=Coupons, 5=Tips).

· response: Depends on table type (see Appendix F). Note that the header listed in Appendix F is used on upload but is not returned with the data. Table lengths are:

0. State Table: 136 bytes

1. Parameter Value Table: 1600 bytes

2. Parameter Range Table: 3200 bytes

3. AFM Attribute Table: 860 bytes

4. Coupons Table: 276 bytes

5. Tips Table: 192 bytes

Type 7: TECP

Description:

Type 7 data contains results of TECP measurements in all its modes, accompanied by indications of the robotic arm position (hence the TECP position) at the time the data was acquired. The mode itself is not indicated except by reference to the original command sequence (this will be corrected in the reduced data records). All eight channels (3 thermocouples, humidity, electrical conductivity and permittivity, electronics board temperature and the heater current) are always returned, with data values set to zero if the channel is inactive. Typically several channels are active at a time. If the robotic arm is not powered on during a TECP activity, the RA position will not be properly reported in the EDR. RA position variables for such observations will be added into the RDR, along with comments about the records and observations.

The eight TECP channel values are converted from data numbers (DN) to physical units as described below. The calibration constants are nominal, and the user should refer to the official calibration document for the most up-to-date values.

· Thermocouples 1-3: The data are returned as 12-bit unsigned values that must first be converted to a signed integer. This, if DN>2048, the signed value is (DN/2048-2), while if DN<2048, the signed value is DN/2048. The result is then multiplied by the opamp gain, nominally 1277, to retrieve ΔV (µV) of the thermocouple. This result is converted to temperature using the formula

T(K) = T_b + ΔV/S

where T_b is the board temperature (see below) and S is the corresponding Seebeck coefficient, derived using the polynomial form:

S (µV/K) = 1.05x10^-6∙T_b³ - 1.04x10^-3∙T_b² + 0.432∙T_b - 1.62

Note, however, that for electronic reasons, T_b cannot be read simultaneously with the thermocouples, so T_b will be zero for any EDRs that contain nonzero values of thermocouples 1-3. T_b must therefore be extracted from preceding or following EDRs.

· Board temperature: Temperature is retrieved from the data in DN from:

T_b(K) = 0.0831∙DN - 4.76.

· Humidity: Relative humidity was calibrated by measuring the DN reading of the TECP at various known combinations of temperature and humidity. Thus DN can be converted to RH by solving for the larger root of the polynomial:

DN = -59.922∙RH² + (-1742 +8.843∙T_b) ∙RH

+ (1860 - 8.2781∙T_b - 0.017443∙T_b²)

where T_b is the board temperature in Kelvin (see above).

· Permittivity: The dielectric constant is found from the polynomial:

ε_r = 1.172x10^-9∙DN³ - 8.528x10^-6∙DN²8.504x10^-6∙DN ² + 0.02289∙DN0.02277∙DN - 10.5810.42

· Electrical conductivity: Conductivity data is acquired at one of three gain settings. Unfortunately, the gain setting is not returned with the telemetry and must be recovered from the original command. This will be corrected in the reduced data records. Note that at high gain, conductivity is only defined for DN<3421; at medium gain, 229<DN<3636; and at low gain, for DN>211.

The resistance of the medium R_m is determined from the data with the temperature-dependent polynomial:

R_m (Ω) = exp[a∙DN⁴exp[a∙DN⁵ + b∙DN³b∙DN⁴ + c∙DN²c∙DN³ + d∙DN + e]

Where for high gain, and DN < 3421:

For medium gain, and 229 < DN < 3636 :

For low gain, and 211< DN £ 2750:

For low gain and 2750 < DN £ 3400:

To retrieve actual soil conductivity, DN are first converted to resistance, which then yields conductivity according to

EC (µS/cm) = 10⁶ / (R_m∙ p):

where the probe constant p is a function of R_m and gain according to:

p (cm) = a∙ [ln(R_m)] ² + b∙ln(R_m) + c

where:

· Heater current: Heater current is retrieved from the data in DN from:

I(mA) = 0.610∙DN

Generated by:

MECA_TECP_READ

Format:

Field descriptions:

· nsamples: The number of times the TECP was read.

· samplesize: Should always read 100 (bytes).

· response: The first 8 fields are the actual TECP 12-bit data channels, concatenated such that the sequence of 8 requires 12 bytes. The next 8 bytes tag each set of readings with the spacecraft clock time, using the same convention as the header. The remaining values in each iteration locate the TECP in the RA frame. If the robotic arm is not powered on during a TECP activity, the RA position will not be reported in the EDR. The fields RA_encoders, RA_pots, Tjoint, and TECP_pos will be all zero. TECP_orientation (the quaternion) elements will be 0, 1, 0, 0. The user is referred to Phoenix Camera EDR/RDR SIS for further discussion of lander reference frames.

Type 8: WCL: ISES

Description:

This data type contains a single set of readings from the majority of the sensors in the WCL beakers. Conversion to physical units begins with conversion of data numbers (DN) to mV, a characteristic of the analog-to-digital converter circuit common to most the ISEs. Nominal values for the half-cell are:

V(mV) = -0.80579∙DN + 2057.8

The half-cell results are then converted to an absolute potential by subtracting the potential measured on either of the lithium reference sensors. Note that oxidation-reduction potential (ORP) is not specifically listed as a sensor because it serves as the ground for all other sensors. Thus V_ORP = -V_Li.

Conversion from mV to molar concentration is uses calibration constants specific to the beaker. These will be updated after in situ calibration. See the WCL calibration report for additional details.

Generated by:

MECA_WC_READ (Mode 2)

Format:

Field descriptions:

· response: Data consists of 24 12-bit words returned in two bytes with the most significant bits set to zero. Data is returned in the following order:

· CME_Command: This is an echo of the 42-byte command to the FPGA. Details are available from the MECA team.

· CME_status: This is a standard 22-byte coded field returned by the FPGA. It indicates such things as limit switch positions or which components are enabled or disabled. Details are available from the MECA team.

Type 9: WCL: COND

Description:

This data type contains a single set of readings from the WCL conductivity sensor, the current in each of two ranges and the voltage (read twice). Conversion to physical units begins with conversion of data numbers (DN) to resistance, with the nominal gain given by.

R_low(Ω) = 5715.3∙(V/I_low)

R_high(Ω) = 5810.4∙(V/I_high)

where V = 2517.95-DN and I = 2570-DN.

Conductance is the reciprocal of the resistance. Conductance is converted to conductivity by multiplying by the cell constant, which varies from beaker to beaker and is described in the WCL Calibration Report. The cell constant will be updated after in situ calibration.

Generated by:

MECA_WC_READ (Mode 3)

Format:

Field descriptions:

· response: Data consists of 4 12-bit, unpacked data, each returned in two bytes with the most significant bits set to zero. Data is returned in the following order:

· CME_Command: This is an echo of the 42-byte command to the FPGA. Details are available from the MECA team.

· CME_status: This is a standard 22-byte coded field returned by the FPGA. It indicates such things as limit switch positions or which components are enabled or disabled. Details are available from the MECA team.

Type 10: WCL: DOX

Description:

The WCL Dissolved Oxygen sensor consists of an oxygen permeable membrane encapsulating a gel with electrochemical properties sensitive to the oxygen concentration. Behind the gel is a cyclic voltammetry (CV) electrode, and the form of the readout is thus identical to that of CV (Type 11).

To convert the data to physical units requires knowledge of both the drive (voltage) waveform and the response (current). Both require information that can be extracted from the CME_Command echo (see Field Descriptions). This information will be provided in an accessible form in reduced data records.

With knowledge of the gain setting, the current response to the waveform can be extracted according to the formula:

I(nA) = a∙DN + b

where the parameters a and b for each of the 8 gain settings are nominally as follows (please see the WCL Calibration Report for most recent values):

Note that the gain settings are not monotonically increasing due to a bit order reversal in the FPGA.

The voltage ramp is typically a triangle, repeated until the specified number of points is exhausted (normally just once). The step size, timing, upper and lower voltage limits, and number of points can be extracted from CME_Command in data numbers (DN), but not the starting voltage and ramp, which depend on preceding RAW commands. In most cases, however, the ramp will start at the lower voltage limit.

The drive waveform can be converted from DN to voltage with the following nominal formula:

V(mV) = -1.614∙DN + 3310

Generated by:

MECA_WC_READ (Mode 4)

Format:

Field descriptions:

· response: Data consists of a series of 12-bit samples padded and returned in two-byte words. Up to 2015 samples can be requested.

· CME_Command: This is an echo of the 42-byte command to the FPGA. Selected fields are described below and will be explicitly specified in future reduced data records. Contact the MECA team for additional information.

For each byte # specified in the table, the top line refers to the four MSBs and the second line to the four LSBs. 12-bit values cross byte boundaries.

· CME_status: This is a standard 22-byte coded field returned by the FPGA. It indicates such things as limit switch positions or which components are enabled or disabled. Details are available from the MECA team.

Type 11: WCL: CV

Description:

Type 11 returns data from a cyclic voltammetry experiment. To convert the data to physical units requires knowledge of both the drive (voltage) waveform and the response (current). Both require information that can be extracted from the CME_Command echo (see Field Descriptions). This information will be provided in an accessible form in reduced data records.

With knowledge of the gain setting, the current response to the waveform can be extracted according to the formula:

I(nA) = a∙DN + b

where the parameters a and b for each of the 8 gain settings are nominally as follows (please see the WCL Calibration Report for most recent values):

Note that the gain settings are not monotonically increasing due to a bit order reversal in the FPGA.

The voltage ramp is typically a triangle, repeated until the specified number of points is exhausted (normally just once). The step size, timing, upper and lower voltage limits, and number of points can be extracted from CME_Command in data numbers (DN), but not the starting voltage and ramp, which depend on preceding RAW commands. In most cases, however, the ramp will start at the lower voltage limit.

The drive waveform can be converted from DN to voltage with the following nominal formula:

V(mV) = 1.612∙DN - 3296

Generated by:

MECA_WC_READ (Mode 6)

Format:

Field descriptions:

· response: Data consists of a series of 12-bit samples padded and returned in two-byte words. Up to 2015 samples can be requested.

· CME_Command: This is an echo of the 42-byte command to the FPGA. Selected fields are described below and will be explicitly specified in future reduced data records. Contact the MECA team for additional information.

For each byte # specified in the table, the top line refers to the four MSBs and the second line to the four LSBs. 12-bit values cross byte boundaries.

· CME_status: This is a standard 22-byte coded field returned by the FPGA. It indicates such things as limit switch positions or which components are enabled or disabled. Details are available from the MECA team.

Type 12: WCL: CP

Description:

Type 12 returns data from a chronopotentiometry (CP) experiment, in which a current ramp is applied to one of three electrodes and the corresponding potential is measured. When either of the two Ag electrodes are selected (CP1 or CP2), peaks in the derivative of the returned waveform reflect the concentration of chloride, bromide, or iodide in the solution. When the Pt electrode is used (CP3), the same peaks may suggest the presence of iron.

CP was not part of the original FPGA configuration and therefore masquerades as a CV experiment - a switch set in a prior RAW command alerts the electronics boards to respond in chronopotentiometry mode. In contrast to CV, the user has a choice of six gain settings for the drive current but only a single setting for the returned voltage. To convert the data to physical units requires knowledge of both the drive (current) waveform and the response (voltage). Both require information that can be extracted from the CME_Command echo (see Field Descriptions). This information will be provided in an accessible form in reduced data records.

With knowledge of the gain setting, the current corresponding to the waveform can be extracted according to the formula:

I(nA) = a∙DN + b

where the parameters a and b for each of the 8 gain settings are nominally as follows (please see the WCL Calibration Report for most recent values):

Note that the gain settings are not monotonically increasing due to a bit order reversal in the FPGA.

The current ramp uses the same parameters as CV, but is specified to either increase from a low value to a higher value or to remains constant (Dac_inc=0). The step size, timing, upper and lower current limits, and number of points can be extracted from CME_Command in data numbers (DN). The current ramp should always start at the lower voltage limit.

The output can be converted from DN to voltage with the following nominal formula:

V(mV) = -0.70∙DN + 1788

Generated by:

MECA_WC_READ (Mode 6)

Format:

Field descriptions:

· response: Data consists of a series of 12-bit samples padded and returned in two-byte words. Up to 2015 samples can be requested.

· CME_Command: This is an echo of the 42-byte command to the FPGA. Selected fields are described below and will be explicitly specified in future reduced data records. Contact the MECA team for additional information.

For each byte # specified in the table, the top line refers to the four MSBs and the second line to the four LSBs. 12-bit values cross byte boundaries.

· CME_status: This is a standard 22-byte coded field returned by the FPGA. It indicates such things as limit switch positions or which components are enabled or disabled. Details are available from the MECA team.

Type 13: WCL: AS

Description:

Type 13 returns data from an anodic stripping voltammetry (ASV) experiment. In this mode, the applied waveform moves in a stairstep from a low to a high voltage. At each step a squarewave is applied and the resulting current is measured a fixed interval above, then below the designated ramp voltage. Prior to running this experiment, trace metals are plated onto the electrode by application of a fixed potential. The ASV waveform drives these metals from the electrode, resulting in characteristic peaks.

To convert the data to physical units requires knowledge of both the drive (voltage) waveform and the response (current). Both require information that can be extracted from the CME_Command echo (see Field Descriptions). This information will be provided in an accessible form in reduced data records.

With knowledge of the gain setting, the current response to the waveform can be extracted according to the formula:

I(nA) = a∙DN + b

where the parameters a and b for each of the 8 gain settings are nominally as follows (please see the WCL Calibration Report for most recent values):

Note that the gain settings are not monotonically increasing due to a bit order reversal in the FPGA.

The voltage ramp is a squarewave superimposed on a ramp. It is monotonically increasing and, if too many points are specified, will simply flatten off at the maximum voltage. The step size, timing, upper and lower voltage limits, square wave amplitude, and number of points can be extracted from CME_Command in data numbers (DN). The ramp should always start at the lower voltage limit.

The drive waveform can be converted from DN to voltage with the following nominal formula:

V(mV) = 1.612∙DN - 3296

Generated by:

MECA_WC_READ (Mode 6)

Format:

Field descriptions:

· response: Data consists of a series of 12-bit samples padded and returned in two-byte words. Up to 2015 samples can be requested.

· CME_Command: This is an echo of the 42-byte command to the FPGA. Selected fields are described below and will be explicitly specified in future reduced data records. Contact the MECA team for additional information.

For each byte # specified in the table, the top line refers to the four MSBs and the second line to the four LSBs. 12-bit values cross byte boundaries.

· CME_status: This is a standard 22-byte coded field returned by the FPGA. It indicates such things as limit switch positions or which components are enabled or disabled. Details are available from the MECA team.

Type 14: WCL: (Reserved)

Description:

Currently unused, reserved for special modes of voltammetry or potentiometry.

Generated by:

MECA_WC_READ

Type 15: WCL: PT

Description:

For the active WCL cell (known from the command history) each record contains a measurement of the internal pressure sensor as well as temperature data from each of three sensors mounted on the water tank, the sample drawer, and in the beaker wall. The tank is used to monitor and verify thawing of the stored leaching solution, while the drawer sensor monitors the operation of sample introduction and reagent addition actuators. The beaker sensor is critical for analysis of chemical data. Regardless of which cell is active, each telemetry record includes a reading of the microscopy sample stage temperature. Thus many of the returned EDRs may be for the purpose of supporting microscopy experiments.

Each datum is a 12-bit number stored in 2 bytes, with the four most significant bits set to 0. Except for the stage sensor, the conversion to physical units is specific to the selected chemistry cell. The conversion follows the appropriate formula below:

P(mbar) = a∙DN + b

T(°C) = a∙DN + b

Nominal values of a and b are specified in the table below:

Generated by:

MECA_WC_READ (Mode 7)

Format:

Field descriptions:

· T stage: Common reading of microscopy stage temperature.

· Pressure: Pressure in the active WCL cell.

· T drawer: Temperature measured at the sample drawer of the active cell.

· T tank: Temperature measured on the water tank of the active cell.

· T beaker: Temperature measured in the wall of the beaker of the active cell.

· CME_Command: This is an echo of the 42-byte command to the FPGA. Details are available from the MECA team.

· CME_status: This is a standard 22-byte coded field returned by the FPGA. It indicates such things as limit switch positions or which components are enabled or disabled. Details are available from the MECA team.

Appendix C. PDS LABEL KEYWORDS

Appendix D. EDR File naming convention

Standards

The file naming convention defined for the MECA non-imaging EDRs complies with the conventions for Phoenix EDRs and RDRs, which in turn complies with the PDS Level II 27.3 file naming standards.

Each product name is uniquely identifiable throughout the mission.

File Naming Rules

A template for general filename is shown below. Character positions 9 through 25 are reserved for instrument specific.

Detailed definition of product filenames are defined in the table below. Both the generic and MECA-specific fields are described.

Appendix E. Examples of EDR PDS Labels

The following examples were taken from actual MECA EDRs. Due to the large number of different EDR types, only one example of each type is provided.

Type 0: AFM_FRQTEST

PDS_VERSION_ID = PDS3

LABEL_REVISION_NOTE = "2006-10-27, Initial"

/* File characteristics */

RECORD_TYPE = FIXED_LENGTH

RECORD_BYTES = 148

LABEL_RECORDS = 52

FILE_RECORDS = 54

/* Pointers to object in file */

^AFM_TABLE = 7253 <BYTES>

/* Identification */

DATA_SET_ID = "PHX-M-MECA-2-NIEDR-V1.0"

DESCRIPTION = "UNK"

PRODUCT_ID = "FT___EM0_00_00070ABABABABM0"

PRODUCT_VERSION_ID = "V1.0 D-22850"

PRODUCT_TYPE = "MECA-EM0"

RELEASE_ID = "0001"

INSTRUMENT_HOST_NAME = "PHOENIX"

INSTRUMENT_HOST_ID = PHX

INSTRUMENT_NAME = "MECA ATOMIC FORCE MICROSCOPE"

INSTRUMENT_ID = "MECA_AFM"

INSTRUMENT_MODE_ID = "FRQTEST"

MISSION_NAME = "PHOENIX"

OPS_TOKEN = "16#BABA#"

OPS_TOKEN_ACTIVITY = "16#BABA#"

OPS_TOKEN_PAYLOAD = "16#5#"

OPS_TOKEN_SEQUENCE = "16#BAB#"

TARGET_NAME = MARS

/* History */

PROCESSING_HISTORY_TEXT = "CODMAC LEVEL 1 to LEVEL 2 CONVERSION

VIA JPL/MIPL PHXTELEMPROC"

/* Telemetry */

TELEMETRY_SOURCE_TYPE = SFDU

/* Time information */

MISSION_PHASE_NAME = "TEST"

SPACECRAFT_CLOCK_START_COUNT = "849981735.032"

SPACECRAFT_CLOCK_STOP_COUNT = "850003332.077"

START_TIME = 2006-12-07T18:02:01.125

STOP_TIME = 2006-12-08T00:01:58.301

PLANET_DAY_NUMBER = UNK

EARTH_RECEIVED_START_TIME = 2006-01-12T00:00:00.000

EARTH_RECEIVED_STOP_TIME = 2006-12-08T00:07:51.550

LOCAL_TRUE_SOLAR_TIME = "12:03:50"

PRODUCT_CREATION_TIME = 2007-04-10T16:59:59.000

/* Processing information */

APPLICATION_PROCESS_ID = 50

APPLICATION_PROCESS_NAME = APID_MECA_AFM_KEY_STRAT

PRODUCER_FULL_NAME = "N/A"

PRODUCER_INSTITUTION_NAME = "MULTIMISSION IMAGE PROCESSING SUBSYSTEM,

JET PROPULSION LAB"

SOFTWARE_NAME = PHXTELEMPROC

SOFTWARE_VERSION_ID = "V2.0 03-16-07"

SPICE_FILE_NAME = "phx.furn"

/* Data object definition */

OBJECT = AFM_TABLE

INTERCHANGE_FORMAT = BINARY

COLUMNS = 26

ROWS = 2

ROW_BYTES = 148

OBJECT = COLUMN

COLUMN_NUMBER = 1

NAME = "CMDTIME WHOLE SECONDS"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 1

BYTES = 4

UNIT = SECOND

DESCRIPTION = "Spacecraft command receipt time,

whole seconds portion"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 2

NAME = "CMDTIME FRACTION"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 5

BYTES = 4

UNIT = "SECOND/2**32"

DESCRIPTION = "Spacecraft command receipt time,

fractional seconds portion

(value / 2**32)"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 3

NAME = "READTIME WHOLE SECONDS"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 9

BYTES = 4

UNIT = SECOND

DESCRIPTION = "Time at which this data was received

from the instrument, whole seconds

portion"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 4

NAME = "READTIME FRACTION"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 13

BYTES = 4

UNIT = "SECOND/2**32"

DESCRIPTION = "Time at which this data was received

from the instrument, fractional seconds

portion (value / 2**32)"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 5

NAME = "DATA LENGTH"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 17

BYTES = 4

DESCRIPTION = "Product length in bytes, minus headers"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 6

NAME = "OF TOTAL"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 21

BYTES = 2

DESCRIPTION = "Total number of records in this

product"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 7

NAME = "PART NUM"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 23

BYTES = 2

DESCRIPTION = "Number of this record within the

product (starting with 1)"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 8

NAME = "DATA TYPE"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 25

BYTES = 2

DESCRIPTION = "Telemetry type"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 9

NAME = "INST_PART_1"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 27

BYTES = 2

DESCRIPTION = "Unused (zero) TBR"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 10

NAME = "INST_PART_2"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 29

BYTES = 4

DESCRIPTION = "Unused (zero) TBR"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 11

NAME = "OPS TOKEN"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 33

BYTES = 4

DESCRIPTION = "Ops token"

END_OBJECT = COLUMN

OBJECT = CONTAINER

NAME = "AFM FREQUENCY SAMPLE"

BYTES = 112

START_BYTE = 37

REPETITIONS = 1

DESCRIPTION = "AMF Frequency test results."

^STRUCTURE = "AFM_FREQUENCY_SAMPLE.FMT"

END_OBJECT = CONTAINER

END_OBJECT = AFM_TABLE

END

Type 1: AFM_RESPONSE

PDS_VERSION_ID = PDS3

LABEL_REVISION_NOTE = "2006-10-27, Initial"

/* File characteristics */

RECORD_TYPE = FIXED_LENGTH

RECORD_BYTES = 49

LABEL_RECORDS = 159

FILE_RECORDS = 170

/* Pointers to object in file */

^AFM_TABLE = 7204 <BYTES>

/* Identification */

DATA_SET_ID = "PHX-M-MECA-2-NIEDR-V1.0"

DESCRIPTION = "UNK"

PRODUCT_ID = "FT___EM1_00_0000DABABABABM0"

PRODUCT_VERSION_ID = "V1.0 D-22850"

PRODUCT_TYPE = "MECA-EM1"

RELEASE_ID = "0001"

INSTRUMENT_HOST_NAME = "PHOENIX"

INSTRUMENT_HOST_ID = PHX

INSTRUMENT_NAME = "MECA ATOMIC FORCE MICROSCOPE"

INSTRUMENT_ID = "MECA_AFM"

INSTRUMENT_MODE_ID = "RESPONSE"

MISSION_NAME = "PHOENIX"

OPS_TOKEN = "16#BABA#"

OPS_TOKEN_ACTIVITY = "16#BABA#"

OPS_TOKEN_PAYLOAD = "16#5#"

OPS_TOKEN_SEQUENCE = "16#BAB#"

TARGET_NAME = MARS

/* History */

PROCESSING_HISTORY_TEXT = "CODMAC LEVEL 1 to LEVEL 2 CONVERSION

VIA JPL/MIPL PHXTELEMPROC"

/* Telemetry */

TELEMETRY_SOURCE_TYPE = SFDU

/* Time information */

MISSION_PHASE_NAME = "TEST"

SPACECRAFT_CLOCK_START_COUNT = "849989007.044"

SPACECRAFT_CLOCK_STOP_COUNT = "850006300.088"

START_TIME = 2006-12-07T20:03:13.172

STOP_TIME = 2006-12-08T00:51:26.344

PLANET_DAY_NUMBER = UNK

EARTH_RECEIVED_START_TIME = 2006-01-01T00:00:00.000

EARTH_RECEIVED_STOP_TIME = 2006-12-08T00:51:52.488

LOCAL_TRUE_SOLAR_TIME = "14:01:48"

PRODUCT_CREATION_TIME = 2007-04-10T17:00:10.000

/* Processing information */

APPLICATION_PROCESS_ID = 50

APPLICATION_PROCESS_NAME = APID_MECA_AFM_KEY_STRAT

PRODUCER_FULL_NAME = "N/A"

PRODUCER_INSTITUTION_NAME = "MULTIMISSION IMAGE PROCESSING SUBSYSTEM,

JET PROPULSION LAB"

SOFTWARE_NAME = PHXTELEMPROC

SOFTWARE_VERSION_ID = "V2.0 03-16-07"

SPICE_FILE_NAME = "phx.furn"

/* Data object definition */

OBJECT = AFM_TABLE

INTERCHANGE_FORMAT = BINARY

COLUMNS = 12

ROWS = 11

ROW_BYTES = 49

OBJECT = COLUMN

COLUMN_NUMBER = 1

NAME = "CMDTIME WHOLE SECONDS"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 1

BYTES = 4

UNIT = SECOND

DESCRIPTION = "Spacecraft command receipt time,

whole seconds portion"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 2

NAME = "CMDTIME FRACTION"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 5

BYTES = 4

UNIT = "SECOND/2**32"

DESCRIPTION = "Spacecraft command receipt time,

fractional seconds portion

(value / 2**32)"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 3

NAME = "READTIME WHOLE SECONDS"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 9

BYTES = 4

UNIT = SECOND

DESCRIPTION = "Time at which this data was received

from the instrument, whole seconds

portion"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 4

NAME = "READTIME FRACTION"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 13

BYTES = 4

UNIT = "SECOND/2**32"

DESCRIPTION = "Time at which this data was received

from the instrument, fractional seconds

portion (value / 2**32)"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 5

NAME = "DATA LENGTH"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 17

BYTES = 4

DESCRIPTION = "Product length in bytes, minus headers"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 6

NAME = "OF TOTAL"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 21

BYTES = 2

DESCRIPTION = "Total number of records in this

product"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 7

NAME = "PART NUM"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 23

BYTES = 2

DESCRIPTION = "Number of this record within the

product (starting with 1)"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 8

NAME = "DATA TYPE"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 25

BYTES = 2

DESCRIPTION = "Telemetry type"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 9

NAME = "INST_PART_1"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 27

BYTES = 2

DESCRIPTION = "Unused (zero) TBR"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 10

NAME = "INST_PART_2"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 29

BYTES = 4

DESCRIPTION = "Unused (zero) TBR"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 11

NAME = "OPS TOKEN"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 33

BYTES = 4

DESCRIPTION = "Ops token"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 12

NAME = "AFM RESPONSE"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 37

BYTES = 13

ITEMS = 13

ITEM_BYTES = 1

ITEM_OFFSET = 1

DESCRIPTION = "The actual AFM response to the command,

including the STX, checksum and ETX protocol bytes."

END_OBJECT = COLUMN

END_OBJECT = AFM_TABLE

END

Type 2: AFM_SCAN

PDS_VERSION_ID = PDS3

LABEL_REVISION_NOTE = "2006-10-27, Initial"

/* File characteristics */

RECORD_TYPE = FIXED_LENGTH

RECORD_BYTES = 1316

LABEL_RECORDS = 10

FILE_RECORDS = 14

/* Pointers to object in file */

^AFM_TABLE = 11845 <BYTES>

/* Identification */

DATA_SET_ID = "PHX-M-MECA-2-NIEDR-V1.0"

DESCRIPTION = "UNK"

PRODUCT_ID = "FT___EM2_00_00500ABABABABM0"

PRODUCT_VERSION_ID = "V1.0 D-22850"

PRODUCT_TYPE = "MECA-EM2"

RELEASE_ID = "0001"

INSTRUMENT_HOST_NAME = "PHOENIX"

INSTRUMENT_HOST_ID = PHX

INSTRUMENT_NAME = "MECA ATOMIC FORCE MICROSCOPE"

INSTRUMENT_ID = "MECA_AFM"

INSTRUMENT_MODE_ID = "SCAN"

MISSION_NAME = "PHOENIX"

OPS_TOKEN = "16#BABA#"

OPS_TOKEN_ACTIVITY = "16#BABA#"

OPS_TOKEN_PAYLOAD = "16#5#"

OPS_TOKEN_SEQUENCE = "16#BAB#"

TARGET_NAME = MARS

/* History */

PROCESSING_HISTORY_TEXT = "CODMAC LEVEL 1 to LEVEL 2 CONVERSION

VIA JPL/MIPL PHXTELEMPROC"

/* Telemetry */

TELEMETRY_SOURCE_TYPE = SFDU

/* Time information */

MISSION_PHASE_NAME = "TEST"

SPACECRAFT_CLOCK_START_COUNT = "849993940.065"

SPACECRAFT_CLOCK_STOP_COUNT = "849993940.065"

START_TIME = 2006-12-07T21:25:26.254

STOP_TIME = 2006-12-07T21:25:26.254

PLANET_DAY_NUMBER = UNK

EARTH_RECEIVED_START_TIME = 2006-12-07T21:30:26.939

EARTH_RECEIVED_STOP_TIME = 2006-12-07T21:30:26.939

LOCAL_TRUE_SOLAR_TIME = "15:21:50"

PRODUCT_CREATION_TIME = 2007-04-10T16:59:43.000

/* Processing information */

APPLICATION_PROCESS_ID = 50

APPLICATION_PROCESS_NAME = APID_MECA_AFM_KEY_STRAT

PRODUCER_FULL_NAME = "N/A"

PRODUCER_INSTITUTION_NAME = "MULTIMISSION IMAGE PROCESSING SUBSYSTEM,

JET PROPULSION LAB"

SOFTWARE_NAME = PHXTELEMPROC

SOFTWARE_VERSION_ID = "V2.0 03-16-07"

SPICE_FILE_NAME = "phx.furn"

/* Data object definition */

OBJECT = AFM_TABLE

INTERCHANGE_FORMAT = BINARY

COLUMNS = 20

ROWS = 4

ROW_BYTES = 1316

OBJECT = COLUMN

COLUMN_NUMBER = 1

NAME = "CMDTIME WHOLE SECONDS"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 1

BYTES = 4

UNIT = SECOND

DESCRIPTION = "Spacecraft command receipt time,

whole seconds portion"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 2

NAME = "CMDTIME FRACTION"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 5

BYTES = 4

UNIT = "SECOND/2**32"

DESCRIPTION = "Spacecraft command receipt time,

fractional seconds portion

(value / 2**32)"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 3

NAME = "READTIME WHOLE SECONDS"

DATA_TYPE = MSB_UNSIGNED_INTEGER

START_BYTE = 9

BYTES = 4

UNIT = SECOND

DESCRIPTION = "Time at which this data was received

from the instrument, whole seconds

portion"

END_OBJECT = COLUMN

OBJECT = COLUMN

COLUMN_NUMBER = 4

NAME = "READTIME FRACTION"

DATA_TYPE = MSB_UNSIGNED_INTEGER