Data Set Overview : This document describes how the MRO MCS instrument acquired the Mars Reconnaissance Orbiter Experiment Data Record (EDR) data, and how the data are processed, formatted, labeled, and uniquely identified. This document discusses standards used in generating the product and software that may be used to access the product. The data product structure and organization is described in sufficient detail to enable a user to fully utilize the EDR data product.  This data set consists of tables and supporting documentation from the final analysis of the Experimental Data Records (EDR) from the Mars Reconnaissance Orbiter (MRO) Mars Climate Sounder (MCS) instrument. The MCS instrument, its scientific goals, its measurement objectives, and its observational strategies are discussed in MCCLEESE ET Al 2006 and the INSTRUMENT.CAT file accompanying this data set.  MCS is an atmospheric sounder that makes one measurement every 2.048 seconds, containing science, engineering and housekeeping data, whenever the instrument is powered on. The instrument operates in a single data-taking mode and observational flexibility is provided by actuators that allow telescope boresights to be directed over a range of 270 degrees in azimuth and elevation.  Each instrument packet contains one measurement. The MCS EDR contains time-ordered, unpacked, raw data for the entire MCS mission, starting with the initial instrument power-on in the MRO mapping orbit at 16:00 UT on 24th September 2006. The data are organized by UTC in monthly archive volumes, with 6 four-hour ASCII tables per day accompanied by detached headers. Each table row contains one measurement, and each column contains one unpacked science, engineering or housekeeping parameter.  The MCS EDR contains all the good packets received by the MCS science team in APID 87. No attempt has been made to reconstruct corrupted packets in APID 88. Gaps in the data set are only evident from discontinuities in the timing of table rows (see Data Coverage and Quality section). Some, sub-commutated raw housekeeping data are not available every 2.048 seconds. For convenience these are presented in the same table format with -9999 indicating time slots where data are not taken.   Data Product Acquisition ------------------------ The MCS software collects 192 sixteen-bit science measurements from the focal plane interface electronics every 2.048 seconds, along with associated instrument engineering and housekeeping measurements. The science and housekeeping data are organized into data packets that are transmitted to the spacecraft at the same 2.048-second spacing. The data packets are downlinked to the MRO Ground Data System (GDS) and placed into the Raw Science Data Server (RSDS). MCS software queries the data from the RSDS and assembles them into EDR data tables, each covering a 4 hour time period.  Each MCS EDR data table will be approximately 16MB for each 4 hour time period; the volume of the EDR data product will be approximately 96 MB per day; 3 GB per month.   Data Product Generation and Flow -------------------------------- The MCS EDR data products, generated by the MCS Instrument Team at JPL, are reconstructed from telemetry data products and formatted according to the MRO/MCS EDR SIS. Meta-data derived from fields in the EDR, will be used to populate the PDS label.  MCS science and engineering telemetry are transferred to the MRO Project RSDS. Once transferred, the MCS software automatically processes the telemetry into Level 0 EDR data products. The MCS EDR data products are then archived locally at the MCS operation center. After an initial 6 month data validation period, the MCS team assembles the data products and ancillary files into archive volumes and transfers the assembled volumes to the PDS Atmospheres Node. An archive volume consists of one month of data. Volumes are delivered approximately every 3 months.  The MCS EDR archive will be made available via data releases scheduled at three month intervals as specified in the Mars Reconnaissance Orbiter Project Data Archive Generation, Validation and Transfer Plan   Processing : The MCS EDR data have been unpacked from raw packets and formatted into ASCII tables. The only derived parameters are Date (Column 2), UTC (Column 3) and decimal spacecraft clock (SCLK, Column 4). Time requires special treatment because MCS packets are delivered asynchronously to the spacecraft and are generated using an internal instrument clock.  Decimal SCLK at the center of each measurement integration period is derived from linear fits of instrument fine time to spacecraft time supplied to MCS at roughly 51 second intervals in time commands referenced to a 1 Hz time tick.  Instrument fine time at the start of each packet (Ticks_pkt_start, Column 16), and at the receipt of the one second time tick corresponding to the spacecraft time command (Ticks_at_SC_time, Column 17), is available at a resolution of 64 ticks per 2.048 second integration period, or 32 msec. Spacecraft time consists of integer and decimal parts of the spacecraft clock in seconds referenced to 00:00 UTC January 1st 1980. These parts are contained in Last_time_command (Column 48) and the last command received column (Last_command_rec, Column 45).  Linear fits between instrument fine time and spacecraft time (SCLK) at the receipt of each spacecraft time are performed over each four hour file. This is done for the following reasons.  1. To preserve the accurate, 2.048 second spacing of MCS measurements. 2. To track the slow drift between instrument and spacecraft clocks. 3. To correct occasional +- 1 second error associated with S/C time. 4. To correct ~50 second time jumps associated with anomalies in the MSC software.  Formally, the absolute time derived from this process could be in error by up to +- 32 msec, which is acceptable for MCS science. The relative timing between MCS samples is much better than 1 msec, except at the boundaries of four-hour files where errors of up to 4 msec are seen, which is also acceptable for MCS science.  SCLK is converted to UTC using the SPICE NAIF SCLK to SCET and Leap Seconds kernels.   Data : The MCS EDR is represented by a single PDS labeled table. Each table is accompanied by a full PDS detached label with the same name except for suffix *.LBL. The format of the table is described in detail in MCS_EDR.FMT. The PDS label completely describes the format and contents of the table.  The naming convention for the tables and detached headers follow the time-organization of the data itself and use the following naming convention:  yyyymmddhh_EDR.TAB; where:  yyyy : year in which the data was acquired mm : month of the year in which the data was acquired dd : day of the month in which the data was acquired hh : hour of the day in which the data was acquired  Note that the hour is UT (to within the nearest second) at the start of the coverage of the data contained in the file. There are six possible values for hour.  The first data after powering on in September 2006 are:  - 2006092416_EDR.LBL: The PDS label that describes the EDR data - 2006092416_EDR.TAB: The actual EDR data formatted into a PDS TABLE object   Ancillary Data : Ancillary data is limited to Spacecraft clock (sclk) to UTC conversion is performed using the following SPICE NAIF Kernels:  1. Sclk to Scet kernel 2. Leap Seconds kernel   Coordinate System : The only coordinate system appropriate to MCS EDR data is time.   Software : The MCS EDR products are formatted as columnar ASCII data; and as such, they can be read and manipulated by standard, public-domain software. For this reason, no special utilities are provided.  The MCS EDR products are standard PDS-labeled tables that can be viewed with NASAView, an application developed by the PDS and available for a variety of computer platforms from the PDS web site.   Archive Format : The individual archives were delivered to the PDS Atmospheres node as gzipped tar files via ftp. Once validated they are available online with the archive volume structure.

Overview :  With respect to the EDR data, the data exists in 2 states -- Absent or Present. For the data that is present, the confidence level is high due to simplicity of the processing and structure of the data.  The quality flag (column 1) has limited meaning for the EDR records. A value of 0 indicates present and completely valid data; a value of 1 indicates a record header line; a value of 4 indicates the unpacking software had an issue with the time interpolation (note there are only 4 records immediately at power on flagged this way).   Review : This archival data set was examined by a peer review panel prior to its acceptance by the Planetary Data System (PDS). The peer review was conducted in accordance with PDS procedures.  Prior to creation of the final version of the archival data set, key elements of the archive were distributed for preliminary review. These included electronic versions of example PDS labels, CATALOG files, and Software Interface Specifications (SISs). These materials were distributed to PDS personnel, the experiment investigator, and others, as appropriate.   Data Coverage and Quality : All MCS packets supplied to the MCS team by the project are included in the archive. Each MCS packet is complete due to the handling methods used by the spacecraft and ground system. The data in each packet is the information generated and sent by the instrument (checksums and other techniques are used to detect and correct any corruption).  There are a number places where there are gaps and missing packets. Most of these gaps are small (the largest is about 2 hours long). The gaps are due to a number of causes. The primary cause are those lost due to not being received at a DSN ground station. Other losses come from spacecraft activities (primarily ELECTRA testing and reformatting the SSR--solid state recorder), interface errors between MCS and the spacecraft, and ground data system issues.  Missing packets can be identified in several ways. The first is by looking for gaps of more than 2.05 seconds between packets. MCS produces a packet every 2.048 seconds, unless powered off. The date and time of the packet is represented in columns 2 and 3, respectively. Except for when the counter rolls (at 65535), the packet counter, column 5, can also be used to detect missing packets. Finally, there are 64 instrument ticks between each packet (column 16).   Limitations : The limitations in this data set follow from the quality of the execution, which is described above under Data Coverage and Quality.  The only known limitation is the occurence of brief periods of elevation mis-pointing associated with position errors. During these periods, the actuator (and thus the telescopes) are not in the intended orientation and thus not viewing the intended scene. These do not affect the quality of the EDR records, but are relevant for analysis and processing of higher data levels, as well as the conversion of EDR records to RDR records.  Position errors occur when the MCS FSW and the hardware disagree on the position of an actuator. The position of the actuators is checked at two locations: 0 degrees (blackbody position) and 105.7 degrees (step 2046, between the standard limb and space views). A position error is presumed (and in many cases confirmed) to indicate a physical mis-pointing of the instrument. Position errors only occur while slewing, but a mis-pointing caused by a position error will persist (with the same magnitude) until the actuator is re-intialized and in synch with where FSW assumes it is pointing.  Finding where the position errors are reported by MCS FSW is straight forward. The error is reported in the ERROR_ID column as error 19 (note that the last error generated is reported in every packet as a historical field, but is only generated when the ERROR_COUNT increments). The first byte of the ERROR_DETAIL field will indicate the number of position errors that FSW will allow before stowing the instrument.  After reporting a position error, the FSW re-intializes both actuators, removing any pointing errors. The time taken is variable depending on where the error is handled (it can take a minute in some cases), but all packets from that time are flagged as moving. The LAST_AZ_CMD and LAST_EL_CMD do not update until an SST commands a move for that actuator after the re-intialization (the re-intialization is not considered commanded movement).  The complexity is that the FSW does not report the error when it is detected, it is only reported at the end of an SST. The error was detected during one of the check points in that SST (there are special cases involving freeze and stow sequences). Thus, the actual pointing error occurred at some point before the last check point crossing in the SST. This is even more complicated in cases (e.g., limb staring) were the sequence does not go through any of the position check locations.  Position errors can also usually be detected by looking at the radiances when pointed at the limb. This is done by using A3 (core of the 15 micron band) and comparing the calibrated radiances of the limb views during the period around when the error is reported. We use limb view before the probable slewing error, while the error is in effect and after the actuator has been re-synchronized. This provides additional information on the timing of the position error and sometimes also provides knowledge of the magnitude and direction of the error. Based on experience, we've found that for small errors (< 1 degree), looking at the limb radiance provides a pointing accuracy of one actuator step (0.101 degrees). There are cases (especially over the poles) when the atmosphere is changing too fast and it is not possible to accurately measure the pointing error.  Note that even during a position error, all the fields in the EDR are correct since the instrument does not report the actual pointing, but the commanded pointing; see colums LAST_AZ_CMD and LAST_EL_CMD (columns 27 and 28, respectively).  Note that for the derived RDR data product, we have flagged the regions of the pointing errors and corrected them where possible.