PDS_VERSION_ID = PDS3 LABEL_REVISION_NOTE = "STEVEN GAISER, JIM MURPHY 2006-02-27; BSWORD, reformatted, 2007-03-13" RECORD_TYPE = STREAM OBJECT = DATA_SET DATA_SET_ID = "MRO-M-MCS-4-RDR-V1.0" OBJECT = DATA_SET_INFORMATION DATA_SET_NAME = "MRO MARS CLIMATE SOUNDER LEVEL 4 RDR V1.0" DATA_SET_TERSE_DESC = "The MCS atmospheric profiler detects vertical variations of temperature, dust, and water vapor concentrations in the Martian atmosphere." DATA_SET_COLLECTION_MEMBER_FLG = "N" DATA_OBJECT_TYPE = TABLE ARCHIVE_STATUS = "IN QUEUE" START_TIME = 2005-09-12T19:10:51.999 STOP_TIME = 2005-09-12T19:59:58.366 DATA_SET_RELEASE_DATE = 2005-02-27 PRODUCER_FULL_NAME = "DANIEL J. MCCLEESE" DETAILED_CATALOG_FLAG = "N" CITATION_DESC = "McCleese and Schofield, MRO MARS CLIMATE SOUNDER LEVEL 4 RDR V1.0, NASA Planetary Data System, MRO-M-MCS-4-RDR-V1.0, 2006." ABSTRACT_DESC = "NULL" DATA_SET_DESC = " Data Set Overview ================= This document describes how the MRO Mars Climate Sounder (MCS) Reduced Data Record (RDR) was generated, including data sources and destinations. The document is intended to provide sufficient information to enable users to understand the MCS RDR data product. The users for whom this document is intended are scientists who will analyze the data, including those associated with the Mars Reconnaissance Orbiter (MRO) Project and those in the general planetary science community. This document addresses the Mars Reconnaissance Orbiter Experiment Data Record (RDR) 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 RDR data product. This data set consists of tables and supporting documentation from the final analysis of the Reduced Data Record (RDR) and details how the RDR data set was derived from the Mars Reconnaissance Orbiter (MRO) Mars Climate Sounder (MCS) Experimental Data Records (EDR). The scientific goals, measurement objectives, and observational strategies for the RDR dataset 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 RDR contains time-ordered, calibrated 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 calibrated science, engineering or housekeeping parameter. The MCS RDR contains all the packets received by the MCS science team. 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. Geometry information is not provided for soundings when the instrument is slewing and a value of -9999 is used in all geometry fields. 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. The data in the EDR tables are then calibrated to produce the RDR tables. Each MCS RDR data table will be approximately 24MB for each 4 hour time period; the volume of the RDR data product will be approximately 144 MB per day; 4.3 GB per month. Data Product Generation and Flow -------------------------------- The MCS RDR data products, generated by the MCS Instrument Team at JPL, are constructed from the MRO/MCS EDR data and formatted according to the MRO/MCS EDR SIS. Meta-data derived from fields in the RDR, 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 re-processed into RDR data products. The RDR 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 RDR 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 Data Processing Level --------------------- This document uses the Committee on Data Management and Computation (CODMAC) data level numbering system to describe the processing level of the RDR data product. MCS RDR data products are considered CODMAC Level 4, equivalent to NASA level 1B. The RDR data files are generated from CODMAC Level 2 or Edited Data, which are the time-ordered instrument science data. Changes from Previous Versions ------------------------------ The following section describes the changes between the various versions of the archived volumes. This archive, regardless of version number, contains the changes listed below: Version 2: 1. Spaceviews, used in radiance calibration, are determined by analyzing the instrument actuator. It's possible that either Phobos or Deimos is in the instrument's field of view thereby giving a false observation for space. To fix this, spaceviews that did not fall within a specified threshold are discarded. 2. In rare instances the instrument was operated to perform two Blackbody views in a row. This triggered a bug in the radiance calibration software causing all subsequent records in the four hour file to be calibrated improperly. This bug was fixed. Version 3: 1. Improved item #1 from Version 2 above. The threshold solution discarded otherwise good space views that were not in family for reasons other than Phobos. To fix this, a geometric solution was implemented to determine when Phobos was actually in the space view and only discard those. 2. Improved gain calculation for non-standard scanning periods where there aren too few blackbody target views. A focal plane temperature fit is used to estimate gain when calibration views are not available, such as during limb staring. For periods where there is one calibration view per orbit or per day, the temperature dependent gain fit is calculated and shifted to match the actual gain at the calibration times. The shifts are then interpolated linearly in time. This gives a better estimation of gain than using calibration views or temperature fits alone. 3. Instrument pointing for in-track observations was improved by correcting the elevation pointing errors from < +-0.07 degrees to < +-0.02 degrees. Version 4: 1. MCS Frames kernels changed to modify a fixed instrument tilt identified in off-track limb observations. The tilt of 0.431 degrees was applied about an axis in the S/C XY plance inclined at 25.8 degrees to the S/C X-Axis. The elevation rotation in the Frames kernel was changed from -0.203 degrees to -0.030 degrees to compensate for the effect of the tilt change. The overall effect of these changes is to improve limb pointing in the vertical to better than 0.02 degrees in both in and off-track observations. Processing ========== The MCS RDR product is generated from the MCS EDR product with the following additions and modifications: 1. Engineering/housekeeping data, such as internal instrument temperatures, are calibrated. 2. Geometry information, such as spacecraft and scene latitude/ longitude is added. SPICE NAIF is used to do the geometry calculations. 3. The radiances are calibrated. Keep in mind that the LAST_AZ_CMD and LAST_EL_CMD fields in a record of the MCS RDR product is derived from previous record, which if the actuator isn't moving is the same as the current. During the mission, there were some periods of time where the instrument was experiencing actuator anomalies. The pointing for these time periods is incorrect by a small amount in elevation. To the best of our knowledge, these records have been marked, and where possible the elevation has been corrected. See the description of column GQUAL in MCS_RDR.FMT for details. RDR Calibration --------------- The RDR (Level 1) data set is structured in a very similar way to the EDR data set. The ASCII tables contain one row of data for each 2.048-second instrument measurement, or sounding. Three types of data are supplied in the RDR. 1. Housekeeping and engineering data from the EDR (Level 0) data set, converted from counts to engineering units where necessary. 2. Calibrated signal radiances for all 189 MCS detectors. 3. Supporting geometry information in Mars-centered coordinates, calculated for the nominal instrument field-of view axis vector. The conversions and calibrations required to derive RDR parameters from the data supplied in the EDR are summarized below. Housekeeping Data Calibration ----------------------------- A reduced set of housekeeping times, status flags and other parameters are carried over from the EDR. Only two of these parameters are converted from counts to physical units, 'Last_az_cmd' and 'Last_el_cmd'. Both elevation and azimuth scan step are converted into scan angle in degrees using the expression: Scan Angle = (Scan Step - 1000)*30/297 This expression allows for the 30 degree motion of the stepper motor and the 297:1 gearing reduction provided by the actuator planetary and harmonic drive gears. It follows from this expression that the MCS step angle is 0.101 degrees. Scan angle = 0 corresponds to the stow position in both elevation and azimuth angle. Engineering Data Calibration ---------------------------- The MCS engineering data consist of 23 voltages sampled and converted to counts by the MCS engineering hybrid chip. These voltages provide information on instrument voltages and temperatures, together with the calibration references needed to convert counts to voltage and temperature. Eight slots are reserved for MCS engineering parameters in each MCS data packet. These slots are sampled at 0.256 second intervals within the 2.048 second instrument signal integration period. The first six slots are assigned to specific engineering parameters which need to be monitored every 2.048 seconds, referred to below as frequently sampled. The last two slots cycle continuously through all 23 parameters. Both frequently and cyclically sampled engineering data are reported as counts in the EDR. The six parameters that are sampled frequently and cyclically do not have identical values because they are sampled at different times within the 2.048 second instrument signal integration period. They do, however, share the same engineering conversions. A subset of the EDR engineering data is converted from counts to physical parameters and reported in the RDR. Table X1 summarizes the parameters reported in both the EDR and RDR data sets. Definitions are given in the EDR and RDR SIS documents. The conversion of EDR counts to RDR voltages and temperatures is described in detail below. ------------------------------------------------------------------- EDR EDR EDR Continuous Cycling Cycling (Expanded) ------------------------------------------------------------------- FPA_temp Rotating_value_1 Vref_C2 FPB_temp Rotating_value_2 Vref_C1 Baffle_A_temp Rotating_index_1 PRT_narrow_C2 Baffle_B_temp Rotating_index_2 PRT_narrow_C1 BB_1_temp PRT_wide_C2 OBA_1_temp PRT_wide_C1 Hybrid_temp FPA_temp_cyc FPB_temp_cyc Baffle_A_temp_cyc Baffle_B_temp_cyc OBA_1_temp_cyc OBA_2_temp BB_1_temp_cyc BB_2_temp Solar_target_temp Yoke_temp El_actuator_temp Az_actuator_temp -15V +15V Solar_base_temp +5V ------------------------------------------------------------------- RDR RDR Continuous Cycling (Expanded) ------------------------------------------------------------------- FPA_temp Hybrid_temp FPB_temp FPA_temp_cyc Baffle_A_temp FPB_temp_cyc Baffle_B_temp Baffle_A_temp_cyc BB_1_temp Baffle_B_temp_cyc OBA_1_temp OBA_1_temp_cyc OBA_2_temp BB_1_temp_cyc BB_2_temp Solar_target_temp Yoke_temp El_actuator_temp Az_actuator_temp -15V +15V Solar_base_temp +5V ------------------------------------------------------------------- Table X1. MCS Engineering Parameter Names in the EDR and RDR. The first 6 engineering parameters in the cycled EDR engineering data are the two reference voltages and four resistances required to calibrate the other engineering parameters. These parameters are not carried over to the RDR data set, leaving 17 engineering parameters. Reference voltage and resistances can be used to remove drifts because all 23 engineering parameters are multiplexed into the same analog to digital converter (ADC). The ADC is an integrating type consisting of a voltage to frequency converter (VFC) and a counter. Because counts are generated by a clock timing a fixed number of VFC output pulses, there is an inverse, rather than a linear, relationship between voltage and counts. This complicates the interpolation of voltage and resistance between the references. Engineering Data Voltage Calibration ------------------------------------ Voltage calibration is performed using the counts from the voltage standards Vref_C2 and Vref_C1. The parameters converted to voltages are Hybrid_temp, +15V, -15V, and +5V. The expression converting a general count Cx (from the EDR) to voltage Vx for all four of these parameters is as follows. Vx = (V1*Vref_C1*(Cx - Vref_C2) + V2*Vref_C2*(Vref_C1 - Cx)) (X1) ------------------------------------------------------- Cx*(Vref_C1 - Vref_C2) where: V1 = 0.0000 V is the voltage standard producing Vref_C1 counts V2 = 4.9997 V is the voltage standard producing Vref_C2 counts This is simply the linear interpolation in inverse count space required to correct for the inverse relationship between voltage and counts discussed above. Typically Vref_C1 and Vref_C2 are not sampled at the same time as each other or the general count Cx that they are being used to calibrate in Equation X1. Because they are slowly varying, both parameters are linearly interpolated to their value at the time of Cx before Equation X1 is applied. Further processing is required to convert Vx defined by Equation (X1) to physical parameters. Hybrid_temp - Vx*100 = Temperature in Kelvin +15V - Voltage = Vx/3 -15V - Voltage = -Vx/3 +5V - Voltage = Vx Hybrid_temp is the temperature of the engineering hybrid chip itself, measured by an AD590 IC temperature transducer. This IC outputs a current proportional to temperature in Kelvin. Engineering Data Resistance Calibration --------------------------------------- The remaining 13 engineering parameters in the RDR are all temperatures measured by 500 Ohm Rosemount platinum resistance thermometers (PRTs). Counts for the temperature measurements are converted first to resistance, using high stability Vishay reference resistors, and then into temperature using calibration constants supplied with the PRTs. There are two temperature ranges -- a narrow and a wide range. Most of the 13 temperatures in Table X1 use the narrow range, but Solar_target_temp, Yoke_temp, El_actuator_temp, Az_actuator_temp, and Solar_base_temp use the wide range. Narrow and wide range conversions from counts to resistance are given by equations X2 and X3 respectively. These are simply linear interpolations in inverse count space required to correct for the inverse relationship between resistance and counts. Resistance has the same inverse relation to counts as voltage because the hardware converts resistance to voltage using a constant current source (V = I*R) before it is converted to counts. The expression converting a general count Cx (from the EDR) to resistance Rx for narrow range temperatures is: Rx = (R1*PRT_narrow_C1*(Cx - PRT_narrow_C2) + (X2) R2*PRT_narrow_C2*(PRT_narrow_C1 - Cx)) ---------------------------------------- Cx*(PRT_narrow_C1 - PRT_narrow_C2) where: R1 = 480.393 Ohms is the resistance standard producing PRT_narrow_C1 counts R2 = 620.318 Ohms is the resistance standard producing PRT_narrow_C2 counts Rx = (R1*PRT_wide_C1*(Cx - PRT_wide_C2) + (X3) R2*PRT_wide_C2*(PRT_wide_C1 - Cx)) ------------------------------------ Cx*(PRT_wide_C1 - PRT_wide_C2) where: R1 = 480.393 Ohms is the resistance standard producing PRT_wide_C1 counts R2 = 620.318 Ohms is the resistance standard producing PRT_wide_C2 counts PRT_narrow_C1, PRT_narrow_C2, PRT_wide_C1 counts, and PRT_wide_C2 counts in Equations X2 and X3 are linearly interpolated to their value at the time of Cx before the equations are applied. Both temperature ranges share the same resistance standards. Engineering Temperature Calibration ----------------------------------- Resistances for the 8 narrow range and 5 wide range temperature measurements are converted to temperatures using the calibration curves of the individual 500 Ohm PRT sensors. Continuous and cycled samples that share the same PRT sensor share exactly the same calibration for each of the six sensors that are sampled in both modes. The PRT calibration curves and constants are supplied on data sheets provided by the manufacturer Rosemount for each sensor. The measurements presented in these sheets were taken in May and June of 2001 and are traced to IPTS-1968. Table X2 summarizes the sensor serial numbers and constants for each measurement. The equation that converts resistance to temperature, based on these constants is TBS. ------------------------------------------------------------------ Measurement PRT Constants T > 0 Celsius Serial # R0 Alpha Delta FPA_temp DN89 499.05391 0.00387530 1.311279 FPB_temp EA57 497.66800 0.00387963 1.384464 Baffle_A_temp GC46 499.96783 0.00387543 1.310014 Baffle_B_temp GC47 500.52988 0.00387447 1.310845 BB_1_temp DY45 497.72600 0.00388253 1.363825 OBA_1_temp GC49 495.93794 0.00387641 1.318023 OBA_2_temp GC50 495.64512 0.00387456 1.299423 BB_2_temp DY46 497.88800 0.00387926 1.335400 Solar_target_temp DN65 498.18400 0.00387652 1.309527 Yoke_temp GC53 497.93790 0.00387672 1.316550 El_actuator_temp GC54 503.95194 0.00387600 1.302258 Az_actuator_temp GC51 496.20600 0.00387699 1.312691 Solar_base_temp GC52 496.22494 0.00387489 1.309952 Measurement PRT Constants T < 0 Celsius Serial # A B C FPA_temp DN89 9.0772248E-04 1.9444499E-05 -8.335224E-08 FPB_temp EA57 1.0273117E-03 2.7354368E-05 -1.139130E-07 Baffle_A_temp GC46 8.6241996E-04 2.0358312E-05 -8.609052E-08 Baffle_B_temp GC47 9.3209669E-04 1.9605711E-05 -8.426912E-08 BB_1_temp DY45 9.6626375E-04 2.0834433E-05 -8.922540E-08 OBA_1_temp GC49 8.7029127E-04 1.9346827E-05 -8.249298E-08 OBA_2_temp GC50 8.8071333E-04 1.9480837E-05 -8.312327E-08 BB_2_temp DY46 6.9631071E-04 2.6087108E-05 -1.048373E-07 Solar_target_temp DN65 8.2813522E-04 1.8661628e-05 -7.941946E-08 Yoke_temp GC53 8.3363238E-04 2.0405710E-05 -8.587821E-08 El_actuator_temp GC54 8.0448478E-04 1.8328526E-05 -7.788299E-08 Az_actuator_temp GC51 8.2131688E-04 1.8495794E-05 -7.872096E-08 Solar_base_temp GC52 9.2706213E-04 1.9729441E-05 -8.465461E-08 ------------------------------------------------------------------ Table X2 - PRT properties relevant to Temperature Calibration. Radiance Calibration -------------------- MCS science measurements are converted from counts to radiance using in-flight measurements of space and calibration targets, combined with linearity measurements and spectral calibration data acquired during instrument testing before launch. Thermal Channels - Normal Calibration. -------------------------------------- For the thermal channels, A1-A5 and B1-B3, a two-point radiometric calibration is provided by views of space and an instrument blackbody target that fill the channel apertures and fields-of-view. During normal observations, space is observed once every 34 seconds and the instrument blackbody target is viewed 10 times per orbit (once every 12 minutes). Space provides a good zero for the thermal channels and it is assumed that the blackbody target has an emissivity of 1.00, and that the target temperature measurements of BB_1_temp for the A channels and BB_2_temp for the B channels are correct. The combined effect of these approximations has been verified to better than the +- 0.5% radiometric accuracy requirement of the MCS instrument. Radiometric calibration proceeds in two stages. First, general signal counts Cx are converted to approximate radiance, R', in mW.m-2.sr-1/cm-1 using the expression. R' = (Cx - Offset)*Gain (X4) R' is referenced to an effective central wavenumber, and wavenumbers for each MCS channel are summarized in CALIB/MCS_Central_Wavenumbers.ASC Offset is the count at zero radiometric signal derived from the average of the 2 spaceview measurements obtained at 34 second intervals and interpolated linearly to the time of Cx. Gain is the radiance per unit count derived 10 times per orbit from the instrument blackbody calibration cycles, which contain both blackbody and space views, and interpolated linearly to the time of Cx. R' is then normalized by the radiance expected from a blackbody at 290K and corrected for the response linearity of each channel/detector using polynomial expressions derived from fits to linearity measurements made during instrument radiometric calibration prior to launch. After the linearity correction, radiance is again scaled back to physical units. Equations X5-X8 below summarize the process. R' = R'/(B(nu0,290) (X5) R = A*R' + B*R'^2 (Channels A1-A5) (X6) R = A*R' + B*R'^2 + C*R'^3 (Channels B1-B3) (X7) R = R*B(nu0,290) (X8) where: B(nu0,290) is the Planck function at wavenumber nu0 and 290K A, B, C are polynomial coefficients There is no constant term in Equations X6 & X7, as the polynomials are forced to pass through the origin. Polynomials for all the MCS thermal channels are given in CALIB/MCS_Linearity_Curves.ASC, together with the standard deviations of the fits to normalized radiance data for blackbody targets in the range 80 through 320 K. Thermal Channels - Non-Standard Calibration. -------------------------------------------- The normal calibration defined above depends on a regular sequence of space and blackbody calibration measurements in flight. Missing calibrations can be interpolated to a certain extent, but where data are missing for an extended period, constant offset and gain values based on an average for xx Sept 2006 are used. This provides an inferior calibration, but is better than nothing. It will be replaced by more intelligent interpolation in the variation of offset and gain round the orbit in the future. The constant offsets and gains for each channel are provided in /CALIB/CONSTANT_OFFSETS.ASC and /CALIB/CONSTANT_GAINS.ASC. In the early months of MCS operation there were no significant gaps in calibration measurements, when useful observations were being collected. However, from February 9th 2007 to June 16th 2007, problems with the instrument elevation actuator forced MCS into a limb-staring observation mode. During limb-staring, no regular space and blackbody calibrations were performed. The only calibration observations available were serendipitous space views acquired during large spacecraft rolls designed for targeting for the imaging cameras. During large rolls, azimuth actuation was used to allow MCS to view space. These space calibrations were limited to a few times per day at best and to mostly the dayside part of the orbit. The distribution and frequency of these measurements was insufficient for calculating the offset directly. and useless for calculating the gain. During limb-staring, the basic calibration approach is still to determine an offset and gain. Once determined, the actual calibration is identical to the approach described above. The difference is in the manner of determining the offset and gain. The offset for each observation was determined as follows. The offset values for all the orbits on January 4, 2007 were fitted with a four term Fourier series in orbit angle The fitted equation has the following form: Offset = Mean + A1Cos(X-P1) + A2Cos(2X-P2) + A3Cos(3X-P3) + A4Cos(4X-P4) Where A1..A4 are the amplitudes and P1..P4 are the phases for each Fourier component and X is the angle around the orbit, which starts at the descending equator crossing. The same fitting approach was repeated for all the orbits of June 16, 2007. Offset as a function of orbit angle during limb staring was then derived by the linear interpolation in time, between the two days, of each amplitude and phase coefficient in the above expression. This captured the main seasonal variation of with orbit angle, but comparisons of the fit with the available space views during limb-staring showed a slow offset drift. This was corrected by a cubic polynomial in time covering the limb-staring period. The files CALIB/ORB_OFFSET_COEFS.ASC and CALIB/DELTA_OFFSET_COEFS.ASC respectively contain coefficients for the Fourier fits and cubic correction for each detector and a description of their use. In the current RDR, gains during the limb staring are represented by the constant values discussed above. Gain variability around the orbit and orbit to orbit variability are both small, typically < +- 0.25%. The actual gain value used for each detector are summarized in /CALIB/CONSTANT_GAINS.ASC. We plan to substitute a fitting and interpolation approach for gain similar to that used for offset when the analysis is completed. The quality of calibration during limb staring is partially tested by the examining the spaceviews acquired during large rolls and the performance of the top detectors in some of the arrays where forward modeling indicates that radiance should be close to zero. For normal calibration both offset and gain measurements have a precision of < 0.1% of the dynamic range. For offset, the interpolation approach used above for limb staring reduces an error of 1-2% of the dynamic range produced by using constants by a factor of 4. Gain errors arising from the use of constant gain are expected to be less than 1%. Further improvement in offset is not possible because we have no data on the orbit to orbit variations during limb staring, although we know its magnitude from earlier data where good space calibration is available. Visible Channels - Interim Calibration. --------------------------------------- For the visible channels, A6, a two-point radiometric calibration is provided by views of space and an instrument solar calibration target that fill the channel apertures and fields-of-view. During normal observations, space is observed once every 34 seconds and the instrument solar calibration target is viewed twice per orbit as the sun rises and sets. Space provides a good radiometric zero for the visible channels. Solar radiation reflected from the solar target is viewed when the sun is roughly 15 degrees below the local horizontal at the spacecraft, but well above the atmosphere of Mars. The absolute spectral reflectance of the solar target has been measured during instrument testing before launch over the range of illumination and viewing angles encountered during the MRO mapping mission. As with the blackbody calibration target it is assumed that the properties of the solar target remain unchanged throughout the mission. This assumption has been verified to an accuracy of < 0.1% during cruise. The solar target is also designed as a calorimeter to quantify long-term darkening over the mission. Radiometric calibration for the visible channel follows the same approach as for the thermal channels. General signal counts Cx are converted to approximate radiance, R', using the expression: R' = (Cx - Offset)*Gain (X10) Offset is the count at zero radiometric signal derived from the average of the 2 spaceview measurements obtained at 34 second intervals and interpolated linearly to the time of Cx. Gain is the radiance per unit count derived twice per orbit from the solar target calibration cycles which contain both target and space views. The gain calibration process has not been completed for the visible channel and in the RDR data set, gain is set to unity. Radiance therefore has the units of counts corrected for the orbital variation of offset drift. Based on the performance of the thermal channels on the same focal plain, gain is expected to vary by +- 0.25% round the orbit and drift by a similar amount on a long-term basis. The intensity measurement defined by equation X10 is therefore not calibrated absolutely, but is expected to have a relative precision of better than 1%. Data ==== The MCS RDR 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_RDR.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_RDR.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_RDR.LBL: The PDS label that describes the RDR data - 2006092416_RDR.TAB: The actual RDR data formatted into a PDS TABLE object Ancillary Data ============== Ancillary data is used to generate the geometry fields in the MCR RDR product. This data comes from the navigation team and is assumed to be the best available. The following SPICE NAIF Kernels are used: 1. Sclk to Scet kernel (sclk) 2. Leap Seconds kernel (lsk) 3. Frame reference kernel (fk) 4. Planetary constants kernel (pck) 5. Spacecraft ephemeris kernel (spk) 6. Pointing kernel (ck) Coordinate System ================= All positions and vectors in the MCS RDR product files are specified in Areocentric spherical coordinates. Software ======== The MCS RDR 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 RDR 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. " CONFIDENCE_LEVEL_NOTE = " Overview ======== The quality of each MCS record has three more or less independent components. The first is the housekeeping, the second is the geometry and finally the calibrated radiances. The quality of the housekeeping is uniformly very good (see the limitations section). The quality of the geometry is either very good or missing (see the documentation on the relevant orbit and attitude data stored in PDS for more details). The only exception are the few records near pointing errors (see the limitations sect ion below). The key element is the quality of the radiance calibration for a give record. The quality of the radiance calibration depends on the availability of calibration observations and instrument thermal stability. Thermal perturbations generally last less tha n 24 hours and are triggered by three main causes. The largest perturbations are due to power cycling the instrument (and thus cooling to the survival temperatures). Other perturbations come from staring at warm (or cold) scenes for extended periods (the most common is the black body target). Finally minor perturbations can be caused by extensive changes to the scan pattern (due to changes in the equilibrium temperature of the actuators). All major sources of thermal perturbations are noted in the activity log. There are two major time frames in terms of the calibration observations. The first covers the period from power on to the end of January. During this timeframe, all the necessary calibration observations are available (assuming the instrume nt is scanning) and the quality of the radiances is excellent (or very good if thermally perturbed) and better than the requirements (while generally meeting the requirements even when thermally perturbed). Starting in February, while the instrument is staring at the limb, the calibration observations are limited and the radiances are good since the orbit to orbit variability is not known and the long term trends had to be fit and interpolated (see the calibration section). The limb staring calibration is still probably within a factor of two of the requirements. Apart from immediately after moving to limb staring and after powering on, the thermal transients do not significantly affect the quality of the calibration (the effects are smaller than the other errors). Quality Flags ------------- The quality flag (column 1) has limited meaning for the RDR 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. The GQUAL field describes the quality of the geometry calculation of the instrument pointing which is represented in the following fields: Scene_lat, Scene_lon, Scene_rad, Scene_alt, Vert_lat, Vert_lon, and Limb_ang. If the pointing is good this value will be 0, otherwise non-zero values are used to describe other possible states, see MCS_RDR.FMT for details. The RQUAL field describes the quality of the radiance calibration. The flag is not implemented yet, so for now it's always 0. Data Coverage and Quality ========================= All MCS packets supplied to the MCS team by the project that could be at least partly calibrated (geometry, housekeeping or radiance) 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). For some records, the information necessary to calculate the geometry is missing. In these cases, the geometry fields are replaced with -9999. After a gap in the MCS data, the first record does not have any information on the MCS pointing (it was in the previous record). In other cases, predicted and reconstructed attitude and/or ephemeris data are missing. The MCS processing assumes the input information from NAIF is perfect. See the MRO NAIF data in PDS for the estimates of the accuracy of the geometry. (The Derived Data Record (DDR) processing will provide a check on some parts of the geometry when it is complete). The repeatability and accuracy of the actuator pointing (ignoring the position errors, see below) is much better than the detector field of view and is negligible. See the ERRATA.TXT for a currently uncorrected systematic pointing error. The quality of the radiometric calibration varies depending on the time frame of the data record in question. During the early part of the mission, it is very good and essentially limited by instrument noise. During the limb staring portion of the activities, it is good and meets the requirements but is noticeably worse than earlier. In particular, the calibration is no longer able to account for orbit to orbit variability due to the lack of calibration data. Finally there is no attempt to correctly calibrate long periods where the instrument is staring at the blackbody (primarily during the actuator anomaly investigation period). The calibration section (above) goes into more detail. The main periods (and other periods of potentially degraded calibration) are called out in the MCS activity log. 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 is that packets are lost due to not being received at a Deep Space Network (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. From the start of the mission, these account for 0.27% of the MCS soundings. 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. Limitations =========== There are two limitations in calibration of the data. The first limitation is in the calibration of the instrument temperature sensors. There are frequent points (called 'flat spots') where the value reported by the temperature sensor does not change as the temperature increases due to the instrument electronics. As the temperature approaches one of the points, the counts reported locks into the value of the flat spot. In a situation where the instrument (or relevant component) is warming up (or cooling down) at a constant rate, the calibrated temperature rises (drops) more rapidly approaching the flat spot. The temperature then sits at the flat spot (forming a 'step') before finally pulling out and rising to the correct temperature. The size of the error varies depending on specific flat spot with all between .1 K and .2 K in the normal instrument operating range (the largest are order .5 K). The flat spots are frequent, but the specific temperatures of any flat spot varies with the temperature of the instrument electronics. The second limitation is the occurrence 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. When uncorrected, these result in errors in the calculated geometry related to the instrument pointing. In particular, the following geometry columns are affected: 7, 8, 15, 16, 17, 18, 19, 20, and 21. Position errors occur when the MCS Flight Software (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-initialized 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-initializes 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-initialization (the re-initialization 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 Scan Sequence Table (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 views 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. In cases where it is possible to determine the actual error, it has been corrected in the appropriate RDR records. In addition cases where there is an error, but insufficient information to determine the actual pointing have been flagged in the gqual field (column 8). In addition, observations where an error may (but may not) be affecting the pointing have been also flagged. The usual pattern is to have a period where the pointing may or may not be incorrect followed by a period where the pointing is incorrect (and will be corrected if possible). 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. " END_OBJECT = DATA_SET_INFORMATION OBJECT = DATA_SET_TARGET TARGET_NAME = MARS END_OBJECT = DATA_SET_TARGET OBJECT = DATA_SET_HOST INSTRUMENT_HOST_ID = MRO INSTRUMENT_ID = MCS END_OBJECT = DATA_SET_HOST OBJECT = DATA_SET_MISSION MISSION_NAME = "MARS RECONNAISSANCE ORBITER" END_OBJECT = DATA_SET_MISSION OBJECT = DATA_SET_REFERENCE_INFORMATION REFERENCE_KEY_ID = "MCCLEESEETAL2006" END_OBJECT = DATA_SET_REFERENCE_INFORMATION END_OBJECT = DATA_SET END