1 Purpose and Scope of Document

The purpose of this document is to provide users of the SHAllow RADar Reduced Data Record (SHARAD RDR) data product with a detailed description of the product and a description of how it was generated, including data sources and destinations. The document is intended to provide enough information to enable users to read and understand the data product. The users for whom this document is intended are the scientists who will analyze the data, including those associated with the project and those in the general planetary science community.

Each SHARAD RDR product contains SHARAD Experiment Data Record (EDR) data [AD6] that have been Doppler filtered, range compressed and converted to complex voltages, and possesses proper engineering and spacecraft information.

2 Applicable Documents

The following documents apply to the extent specified in this document, with revision number/date of issue as specified below. These documents are referred to in the text as [ADn], where n is their position in the following list.

1. Planetary Data System Standards Reference, JPL D-7669 part 2, version 3.6, August 1, 2003.

2. Planetary Science Data Dictionary Document, JPL D-7116 Rev. E, August 28, 2002.

3. Planetary Data System Archive Preparation Guide, Version 0.050503, 2005.

4. Mars Reconnaissance Orbiter Project Data Archive Generation, Validation, and Transfer Plan, Version 1.1, 26 January 2006.

5. Mars Reconnaissance Orbiter SHAllow RADar EDR and RDR Archive Volume Software Interface Specification, Version 1.0, 1 August 2007.

6. Mars Reconnaissance Orbiter SHAllow RADar Experiment Data Record Software Interface Specification, Version 1.2, 20 July 2007.

7. SHARAD Flight User Manual, Issue 1, MAN-SHR-0007-ALS, 03 November 2004.

8. P. K. Seidelmann, V. K. Abalakin, M. Bursa, M. E. Davies, C. De Bergh, J. H. Lieske, J. Oberst, J. L. Simon, E. M. Standish, P. Stooke, P. C. Thomas. Report of the IAU/IAG Working Group on cartographic coordinates and rotational elements of the planets and satellites: 2000. Celestial Mechanics and Dynamical Astronomy 82, 83-110, 2002.

9. P.H. Eichel, C.V. Jakowatz, Jr. Phase-gradient algorithm as an optimal estimator of the phase derivative. Optics Letters 14, 1101-1103, 1989.

SHARAD project documents, e.g. [AD7], are available in the SHARAD RDR Archive Volume, see [AD5].

3 Relationships with Other Interfaces

This Software Interface Specification (SIS) is applicable to the development of data processing software under the responsibility of the SHARAD Team.

The Reduced Data Record products described in this SIS are produced from other archived products of the Mars Reconnaissance Orbiter (MRO) mission, so that changes to their content and format may result in an interface impact. In particular, the Reduced Data Record products take Experiment Data Record products [AD6] as their input data sets.

4 Data Product Characteristics and Environment

4.1 Instrument Overview

SHARAD is the sub-surface sounding radar provided by the Italian Space Agency (ASI) as a facility instrument to NASA's 2005 Mars Reconnaissance Orbiter (MRO). SHARAD is a wideband radar sounder transmitting at a centre frequency of 20 MHz. The bandwidth of the radar pulse is equal to 10 MHz.

The primary objective of the SHARAD investigation is to map, in selected locales, dielectric interfaces to depths of up to one kilometer in the Martian subsurface and to interpret these interfaces in terms of the occurrence and distribution of expected materials, including rock, regolith, water, and ice.

Vertical resolution is 15 m in free space, and scales with the inverse of the square root of the dielectric constant of the material being sounded. Horizontal resolution is 300-1000 m along-track, and 1500-8000 m across-track, depending on spacecraft altitude and terrain roughness. Expected penetration depends on the dielectric properties of subsurface materials, and is estimated from several hundred meters up to 1 km for the range of dielectric properties of expected Martian rocks.

4.1.1 On-board Processing

A detailed description of the operation and working of SHARAD can be found in [AD7], and is also summarized in [AD6]. For the purpose of explaining the content of data products, a brief account of on-board processing follows.

Data processing performed on-board is very limited to simplify instrument operations, and consists mainly in a coherent pre-summing of the received echoes. According to the operating scenario, several levels of pre-summing can be selected, i.e.: pre-summing 1 (i.e. no pre-summing), 2, 4, 8, 16, 28, 32. When pre-summing N is selected, the samples from N sequential pulse repetition intervals (PRIs) are summed sample-by-sample, thus reducing the data rate by a factor N. The result of the sum of N echoes is referred to as a data block.

The SHARAD on-board processor works in 32-bit precision, but data samples are down-linked at either 8-bit, 6-bit or 4-bit resolution, according to the instrument mode selected. Table 1 below illustrates the number of pre-summed echoes and the sample resolution for all Subsurface Sounding modes.

Instrument Mode	Number of Pre-summed Echoes	Bits per Sample
SS01	32	8
SS02	28	6
SS03	16	4
SS04	8	8
SS05	4	6
SS06	2	4
SS07	1	8
SS08	32	6
SS09	28	4
SS10	16	8
SS11	8	6
SS12	4	4
SS13	2	8
SS14	1	6
SS15	32	4
SS16	28	8
SS17	16	6
SS18	8	4
SS19	4	8
SS20	2	6
SS21	1	4

Table 1: Subsurface Sounding modes according to the number of pre-summed echoes and bits per sample.

Echo samples are converted from full resolution to 8-bit, 6-bit or 4-bit resolution by one of two methods, according to the value of a parameter set from ground and reported in the science ancillary data of the data product (see Section 7.5). These two methods are called fixed scaling and dynamic scaling.

For fixed scaling, it is assumed that the signal is close to saturation of the receiver, i.e. that the full 8-bit dynamic range of the Analog to Digital Converter (ADC) is exploited. Thus, if no sum is performed, it is assumed that all the rightmost 8 bits contain information, and only the leftmost 4, 6, or 8 bits of this 8-bit string are then transmitted to the ground. If the number of pre-summed echoes is 2, all bits from 1 to 9 will contain information, and only bits from 9 to 6, from 9 to 4 or from 9 to 2 will be retained, and so on.

For dynamic scaling, the sample in the echo with the highest absolute value is detected, and bits to be transmitted to the ground for all samples in the echo are counted to the right starting from the leftmost significant bit of such sample. A quantity called SDI_BIT_FIELD, which is reported in the science ancillary data of the data product (see Section 7.5), provides indication of the position of this most significant bit.

4.1.2 Ground Processing

SHARAD achieves its spatial resolution, both in depth and along the ground track, only after processing of the received echo on ground. The method through which vertical resolution is achieved is called range processing, or range compression, while horizontal resolution is enhanced through what is called azimuth, Doppler, or synthetic aperture processing. Ground processing of SHARAD data involves the following steps:

· Decompression and Pre-Summing

· Range Processing

· Azimuth Processing

· Calibration

· Ionosphere Correction

· Time Alignment of Echoes

4.1.2.1 Decompression and Pre-Summing

Decompression of raw echoes consists in reversing scaling performed on board. It is convenient to sum echoes in small groups before further processing, so as to reduce computer load: this is done at this stage.

4.1.2.2 Range Processing

Pulse radars can discriminate between two targets at different ranges only if their echoes do not overlap, i.e. their distance divided by the velocity of light is greater than half of the pulse duration.

The waveform transmitted by SHARAD is a chirp, a long pulse that is linearly modulated in frequency. Chirps are used when the length of the pulse for the desired range resolution is so short that the pulse, to achieve good signal-to-noise ratio, would require a peak power exceeding the limits imposed by the mission design.

The chirp allows the fine resolution associated with the wider bandwidth, which conceptually is achieved by passing the received echo through a filter whose time delay is a function of frequency. The filter should have a time delay such that the frequency transmitted first is delayed long enough so that it arrives at the output of the filter at the same time as the frequency transmitted last. All the frequencies in between also arrive at this time, so they are superimposed at a single instant of time in the filter output.

Of course, in a practical case, because of the finite bandwidth, a temporal delta-function output is not possible. With a bandwidth B the approximate width of the output pulse is 1/B, and if the transmitted amplitude is constant during the pulse, the output takes the form of a (sin x) / x pulse.

4.1.2.3 Azimuth Processing

It is well known that the angular resolution of an optical instrument (i.e. its capability to separate two nearby objects in the observed field) is equal to l / D, where l is the wavelength and D is the diameter of the instrument aperture, apart from a factor of the order of unity which depends on the aperture geometry. Arrays of antennas, like those used in radio astronomy, achieve the angular resolution corresponding to the array size, rather than to the diameters of the array antennas, by coherently summing the signals coming from each antenna.

In arrays of antennas this can be achieved by putting an equal length of cabling between the antennas and the processor performing the coherent (amplitude and phase) sum, thus ensuring that all signals reach the processor at the same time. In this way, the antennas behave as they were sampling points of a single aperture extending across the entire array. It is to be noted that, by its conformation, the array just described will constructively sum only the detected radiation coming from zenith: to focus other directions, it is necessary to adjust the length of the cables so as to allow the coherent sum of signals which have a non-zero delay from one antenna to the next.

Radars using aperture synthesis function according to this same principle, but sample the aperture in successive instants as they move. In digital signal processing, aperture synthesis consists of Fourier-transforming received echoes and then shifting the phase of their samples, which amounts to adding a delay in the time domain; then, the FFT's of pulse echoes are summed, resulting in the constructive sum of the signal components whose delay (phase shift) from one pulse to the next corresponds to the direction being focused. SHARAD ground processing software performs focused processing on the echoes: this means that the phase shift varies quadratically from one echo to the next.

4.1.2.4 Calibration

Absolute calibration of SHARAD data is not possible because the antenna gain could not be characterized on ground, due to its large size and long operational wavelength. It is possible, however, to compensate for effects other than antenna gain, and thus to obtain a relative calibration of the data with a precision of ~1.5 dB, as the electronics of the instrument have been fully characterized through on-ground testing, and the effects of the spacecraft on the instrument have been characterized from an electromagnetic point of view through a dedicated calibration campaign at Mars.

Because of electric coupling between antenna and spacecraft, SHARAD antenna gain differs from that of a simple dipole, and needs to be characterized through dedicated measurements. This has been achieved by observing the same flat portion of the surface of Mars with different spacecraft attitudes in different orbits, and then scaling the measured antenna gain with respect to a baseline configuration. It has been found that gain variations occur mainly along the spacecraft roll angle.

Also because of electric coupling between antenna and spacecraft, a change of the position of large moving parts of the spacecraft, namely the high gain antenna (HGA) and the solar panels, affects SHARAD antenna gain. Characterization of the antenna gain as a function of the spacecraft configuration has been achieved through a set of dedicated observations similar to the ones used to determine the effect of spacecraft attitude. It has been found that all possible spacecraft configurations can be reduced to a limited number of configuration classes changing the antenna gain.

4.1.2.5 Ionosphere Correction

Propagation of the signal through the ionosphere of Mars has the potential to produce a distortion of the waveform, because the ionospheric plasma has a dielectric constant which is frequency-dependent, and thus introduces a variation of group velocity from low frequencies to high frequencies within the chirp, causing a degradation of the signal to noise ratio.

Ionospheric effects are not uniform over Mars: the ionosphere is excited by solar radiation, and its effect are much stronger on the day side of the planet than on the night side. Thus, data acquired on the night side usually do not need any correction, while observations on the day side require the use of a method to undo the effects of ionospheric distortion.

4.1.2.6 Time Alignment of Echoes

Echoes within an RDR Data Product can be aligned to a common time reference, so that the position of echo features from one processed echo to the next correctly represents variations of the topography along the ground track.

4.2 Data Product Overview

Level 1B data (Data Set MARS RECONNAISSANCE ORBITER MARS SHARAD REDUCED DATA RECORD V1.0) will consist of received echoes that have been Doppler filtered, range compressed and converted to complex voltages, correlated with the auxiliary information needed to locate observations in space and time and to process data further. Level 1B data users are expected to be mainly geologists interested in determining the structure of the shallow Martian subsurface. Data users must be aware that processed echoes may contain artifacts due to off-nadir surface reflections, the so-called clutter, reaching the radar after nadir surface echoes, and thus appearing as subsurface reflections.

Figure 1: Simulated SHARAD RDR data from a plane parallel Martian stratigraphy: Plot represents the power received by the instrument as a function of time after range compression; vertical bars mark instants of time in which echoes from each stratigraphy layer reaches the radar. Peaks corresponding to individual subsurface reflections are clearly visible. Echoes coming from layers that are too deep or too close to each other are not discernible. The "bumps" in the processed echo are an artifact of the range compression processing ("sidelobes"): they must not be confused with echoes from subsurface layers.

Each SHARAD RDR data product is the result of the processing of all echoes acquired continuously in time using the same operation mode, instrument status and on-board processing scheme. There is one RDR data product for every SHARAD Experiment Data Record [AD6] data product acquired in subsurface sounding mode, which in fact constitutes the input for the RDR product generation.

The content of each SHARAD RDR data product is highly variable in terms of number of processed echoes, and depends on how operations for the instrument were planned during a given data collection period.

Each processed radar observation in an RDR data product is the result of range and azimuth processing of a variable number of raw echoes. Thus, although there is an one-to-one correspondence between EDRs and RDRs, such correspondence does not hold between individual raw and processed echoes: in general, many raw echoes (of the order of several tens or a few hundreds) result in the production of a single processed echo.

Because each processed echo is a sequence of time samples of a received signal, complemented by ancillary information, the natural organization for processed echoes within a Data Product is a table, in which each line contains data from a single processed echo, and each column contains the value of a single parameter or time sample across different processed echoes.

Each Data Product will consist of two files (see also Figure 2):

· A binary file containing the scientific data of the instrument, that is a sequence of processed echoes, each of which is preceded by a header containing information on the instrument setting and on-board processing of the data, and followed by parameters characterizing the ground processing of the echoes, by geometric quantities generated on-ground from spacecraft navigation data, and by parameters extracted from instrument housekeeping telemetry.

· A detached ASCII label file describing the content of the data product. Such label is written according to standards defined by the Planetary Data System (PDS) [AD1], and lists parameters describing both the observation in which data were acquired and the structure of the files in which data are stored.

Binary files are structured as PDS Table data objects [AD1]. The content of such tables is listed in a format file that will be contained in the LABEL directory of the Data Set Volume [AD5].

Figure 2: Structure of a SHARAD RDR data product

Although binary tables are not human-readable, and add complexity to the long-term accessibility of the data, it was deemed that the conversion to ASCII would have resulted in an unacceptably large increase of data volume (by at least a factor of four, in first approximation), for very little gain, as data cannot be readily interpreted by a human reader in any case.

4.3 Data Processing

This section provides general information about the data product content, format, size, and production rate. Details about data format are specified in Section 5.

4.3.1 Data Processing Level

This documentation uses the "Committee On Data Management And Computation" (CODMAC) data level numbering system. The RDR data files referred to in this document are considered CODMAC "Level 4" or "Resampled", corresponding to NASA Level 1B (see Section 7.2). The data files are generated from level 1A or Experiment Data Record data products, which are the a collection of radar echoes at full (as downloaded) resolution, time ordered, with duplicates and transmission errors removed, and located in space and time (see [AD6]).

4.3.2 Data Product Generation

SHARAD RDR Data Products will be generated at the SHARAD operation center located in Rome, Italy, under the responsibility of the Team Leader Institution (INFOCOM Department, University of Rome "La Sapienza").

The software used to produce RDR data products requires a configuration file containing values for parameters used by the processing algorithms. Once the parameters are set, data processing proceeds in a fully automated way. Level 1B processing software functions are described below.

4.3.2.1 Decompression and Pre-Summing

Decompression of raw echoes consists in reversing scaling performed on board. This is done by first determining the kind of scaling applied to data, from the keyword MRO:COMPRESSION_SELECTION_FLAG found in a data product label or, equivalently, from the parameter COMPRESSION_SELECTION found in science ancillary data of the data product itself (see Sections 7.4 and 7.5). For fixed scaling, the uncompressed value U of the echo sample is given by:

U = C 2^S / N

where

· C is the compressed value

· S is given by L - R + 8

· N is the number of pre-summed echoes

· L is the base 2 logarithm of N rounded up to the nearest integer

· R is the bit resolution of the compressed value (i.e. either 4, 6 or 8 bits)

For dynamic scaling, the uncompressed value U of the echo sample is given by:

U = C 2^S / N

where

· C is the compressed value

· N is the number of pre-summed echoes

· S = SDI for SDI £ 5

· S = SDI-6 for 5 < SDI £ 16

· S = SDI-16 for SDI > 16

where SDI is the SDI_BIT_FIELD parameter mentioned above.

It is convenient to sum echoes in small groups before further processing, so as to reduce computer load. This is done at this stage, and the number of echoes that have been pre-summed on-ground is reported as the value of the parameter N_PRE found in science ancillary data of the data product (see Section 7.5).

Because of the large number of echoes collected during a single observation, raw data are segmented in groups of echoes to be processed together called blocks. The ID of the block to which a processed echo belongs to is reported as the value of the parameter BLOCK_NR found in science ancillary data of the data product, while the number of raw echoes contained in the block is reported as the value of the parameter BLOCK_ROWS, also found in science ancillary data (see Section 7.5).

4.3.2.2 Range Processing

In digital signal processing, the filtering described in Section 4.1.2.2 is done by correlating the impulse response of the instrument, or reference chirp, with the received echo to detect the presence of the reference chirp in the echo. This is equivalent to convolving the echo with a time-reversed version of the reference chirp, and is more conveniently performed by computing the FFT of the discretely sampled echo, by multiplying it by the complex conjugate of the FFT of the discretely sampled reference chirp and then by performing the IFFT of the result. This method is called matched filtering, and is the optimal linear filtering for maximizing the signal to noise ratio (SNR) in the presence of additive stochastic noise.

Another method of filtering available to SHARAD is to divide the FFT of the discretely sampled echo by the FFT of the discretely sampled reference chirp and then by performing the IFFT of the result. This method conceptually is a deconvolution of the received echo, which is treated as if it was an ideal echo that had been "blurred" by a distorting function equal to the reference chirp, and is called inverse filtering.

The kind of filtering applied to data can be read from the keyword MRO:NUMERICAL_FILTER_TYPE found in RDR Data Product labels (see Section 7.4).

Changes in the temperature of the transmitter and the receiver change the shape and intensity of the radar waveform. As discussed above, filtering consists of the mathematical correlation of the received echo with some function of the the impulse response of the instrument (reference chirp). Neglecting the effects of temperature-induced distortions in this correlation produces a degradation of the signal to noise ratio by a few to several dB, introducing also artifacts ("side lobes", see below) that may appear as subsurface reflections.

The CALIB directory of the MRO SHARAD EDR/RDR archives [AD6] stores reference chirps for range processing. From ground tests, the behavior of the chirp as a function of transmitter (Tx) and receiver (Rx) temperatures has been determined, and is reported there in the form of 40 binary files. Each file contains the FFT of the base-banded reference chirp for a given combination of Tx and Rx temperatures.

To choose the correct reference chirp for range compression, it is necessary to read the transmitter and receiver temperatures as reported in the auxiliary data of each data product (fields TX_TEMP and RX_TEMP, see Section 7.5), and then to select the chirp whose transmitter and receiver temperatures most closely match those found in the data product.

The reference chirp used in producing the RDR data product can be read from the keyword MRO:REFERENCE_FUNCTION_FILE_NAME found in RDR Data Product labels (see Section 7.4): the usual value for this keyword is "AUTO", meaning that, as the temperatures of transmitter and receiver were changing during the observation, the ground processing software automatically selected the optimal reference chirp.

Filtering introduces artifacts, called "side lobes", which are peaks appearing in the processed signal where no subsurface reflection is actually present, like a sort of "ringing" originating from a real subsurface echo (see Figure 1). Side lobes can be minimized (i.e. their strength can be reduced compared to that of the reflection that produces them) through a process called windowing or weighting.

A window function (or apodization function) is a function that is zero-valued outside of some chosen interval. For instance, a function that is constant inside the interval and zero elsewhere is called a rectangular window, which describes the shape of its graphical representation. When another function or a signal (data) is multiplied by a window function, the product is also zero-valued outside the interval: all that is left is the "view" through the window.

Windowing is performed in the spectral domain by multiplying the FFT of the filtered signal by the chosen weighting function. If no weighting function is applied, this is equivalent to the use of a rectangular window encompassing the entire bandwidth of the echo. Weighting function are chosen so as to reduce the "ringing" by muting or suppressing the frequencies in the signal that are the farthest from the central frequency.

Because of the resulting smaller effective bandwidth, the width of an echo in the processed signal is greater than the nominal value of 1/B. Thus, weighting suppresses side lobes at the expense of vertical resolution. The kind of filtering applied to data can be read from the keyword MRO:WEIGHTING_FUNCTION_NAME found in RDR Data Product labels (see Section 7.4).

4.3.2.3 Azimuth Processing

SHARAD ground processing software performs focused processing on the echoes: this means that the phase shift varies quadratically from one echo to the next. In SHARAD azimuth processing, the along-track resolution can be set by the operator working on the data product. These parameters determine in turn the required number of range-processed echoes for every synthetic aperture. The type and value of the along-track resolution can be read from the keywords MRO:NOMINAL_ALONG_TRACK_RESOLUTION and MRO:AZIMUTH_SPACING_TYPE found in RDR Data Product labels (see Section 7.4).

Synthetic apertures cannot be extended indefinitely to achieve infinite resolution: echoes that are acquired too early or too late will probably contain no information coming from the area being focused. To determine the maximum permissible length of the synthetic aperture, the Doppler parameters of the echoes are estimated. These are the Doppler centroid frequency and of the Doppler bandwidth.

Doppler centroid estimation determines the average Doppler frequency of received echoes in order to perform an optimum azimuth filtering. The centroid frequency is the frequency dividing the energy spectra of averaged signals in two equal parts. The Doppler bandwidth determines the maximum possible azimuth resolution of the output echoes, and the amount of data overlapping from one synthetic aperture to the next. These two parameters are reported as DOPPLER_BW and DOPPLER_CENTROID in the science ancillary data of the data product (see Section 7.5).

4.3.2.4 Calibration

The change of antenna gain in amplitude as a function of the roll angle of the spacecraft is reported in Table 2 listing the relative gain compared to zero roll (i.e. level) attitude. The roll angle of the spacecraft is reported in the auxiliary data of each data product (field SC_ROLL_ANGLE, see Section 7.5) for each data block.

Table 2: Antenna relative gain as a function of the roll angle of the spacecraft.

The change of antenna gain in amplitude as a function of the spacecraft configuration can be found starting from values extracted from the auxiliary data of each data product for each data block. These values are those of the parameters describing the position of the solar panels and the HGA of the spacecraft, namely MRO_SAMX_INNER_GIMBAL_ANGLE, MRO_SAMX_OUTER_GIMBAL_ANGLE, MRO_SAPX_INNER_GIMBAL_ANGLE, MRO_SAPX_OUTER_GIMBAL_ANGLE, MRO_HGA_INNER_GIMBAL_ANGLE, and MRO_HGA_OUTER_GIMBAL_ANGLE (see Section 7.5). An average value of the outer gimbal angle for the solar panels needs to be computed to identify the type of configuration the spacecraft is in from Table 3

Table 3: Types of spacecraft configuration affecting SHARAD antenna gain. SAPXIG is the inner gimbal angle of the MRO solar array in the +X direction, SAMXIG is the inner gimbal angle of the MRO solar array in the -X direction, OGA is the outer gimbal angle of the MRO high gain antenna.

Once the spacecraft configuration type has been determined, Table 4 can be used to find the corresponding antenna gain variation relative to the base configuration (configuration 0, the so-called "spread eagle").

Table 4: Antenna relative gain as a function of the spacecraft configuration.

The product of the two relative gains obtained through the methods just described is reported as ANTENNA_RELATIVE_GAIN in the science ancillary data of the data product (see Section 7.5). It is to be noted that such gain is not applied to the data stored in the data product: it is for the data user to decide if the processed signal needs to be multiplied by this factor.

4.3.2.5 Ionosphere Correction

A deterministic correction of signal distortions due to the ionosphere would require a knowledge of its physical structure to a level of detail which is outside the capabilities of the suite of experiments on board MRO, and which cannot be extracted from detailed measurements done by other experiments in different times and places due to the high spatial and temporal variability of the ionosphere.

The correction implemented in the SHARAD ground processing software is thus an adaptive algorithm which does not require any prior knowledge of the ionosphere, called the Phase Gradient Autofocus (PGA) method, originally developed for Synthetic Aperture Radar (SAR) images [AD9]. The fundamental concept from which PGA was developed was to make a robust estimation of the derivative (gradient) of the phase error using only the defocused complex SAR image. The estimation process exploits the redundancy of the phase-error information contained in the degraded image, independent of the underlying scene content.

The type of correction applied to the data to compensate ionosphere distortion can be read from the keyword MRO:PHASE_CORRECTION_TYPE found in RDR Data Product labels (see Section 7.4).

4.3.2.6 Time Alignment of Echoes

Because the processed echo is 667 samples long, and because the sampling interval of the processed echo is 0.075 microseconds (see Section 7.5), the time distance between the first and the last sample of the echo corresponds to a round-trip distance of 7.5 km. Changes of topographic height on Mars can be greater than 20 Km over a distance of 400 km, and it is thus impossible in principle to correctly represent topographic height changes from echo to echo over great distances. A common time reference, expressed as the round trip time of an electromagnetic pulse from the center of Mars, is provided for the entire RDR Data Product, but the first sample of an echo is shifted with respect to this time by an amount which changes from echo to echo.

The common reference time for all echoes in a Data Product, expressed can be read from the keyword MRO:RADARGRAM_RETURN_INTERVAL found in RDR Data Product labels (see Section 7.4), while the shift of the first sample of a given echo from this reference time is reported as RANGE_SHIFT in the science ancillary data of the data product (see Section 7.5).

In the generation of the output files, the processed echoes, now a complex quantity because of the processing taking place in the Fourier spectral domain, are complemented with the original auxiliary data contained in the scientific telemetry of the instrument, with parameters characterizing the ground processing of the echoes, with geometric quantities generated on-ground from spacecraft navigation data, and with parameters extracted from instrument and spacecraft housekeeping telemetry. All this auxiliary information, with the exception of processing parameters, is copied from the input Level 1A files used to produce the RDR data product.

4.3.3 Data Flow

Level 1B processing for the production of RDR data products will use the SHARAD Level 1A data archive as its sole input, and will take place at the SHARAD operation center where Level 1A data are also produced. The rate of RDR data production will keep the pace of EDR data production, although there could be some delay (of the order of a few days) due to the need to verify the content and quality of Level 1A data products used as input.

Once produced, SHARAD RDR data products are archived locally at the SHARAD operation center. They are also made immediately available to SHARAD Team Members through a server located at the ASI Science Data Center (ASDC) in Frascati, Italy, and through a server provided by the PDS Geosciences Node and located at Washington University, St. Louis, Missouri, USA, via a secure client-server protocol.

After a data validation period of 6 months or less, the SHARAD team will notify the Geosciences Node that certain products have been validated and are ready to be archived in PDS.

A single SHARAD RDR Data Product includes all data belonging to a single data take, i.e. all data that have been acquired continuously in time using the same instrument mode and on-board processing settings.

Data takes can be of virtually any duration, ranging from a few tens of seconds to twenty minutes or more, depending on a number of factors including the nature of the terrain being sounded and spacecraft operational constraints. Thus, the content of each SHARAD RDR data product is highly variable in terms of number of echoes, and depends on how operations for the instrument were planned for a given data collection period.

A better indication of the rate at which products are generated can be obtained by starting from the data volume allocated to SHARAD over the course of the mission [AD4]: for a 26 Tbits mission data volume over a 731 day mission duration, the resulting raw data volume generated by the instrument is, on average, 5.5 Gbits per day. Note that actual mission data volume may be higher than the planned 26 Tbits: it is currently deemed possible that the total data volume downlinked from the spacecraft can reach 50 Tbits, resulting in an average raw data production rate of 10.5 Gbits per day.

Level 1A processing to generate EDR data products results in a slight increase of data volume, because scientific telemetry is basically left untouched, while PDS headers and auxiliary data needed to locate each observation in space and time are added. In the high data volume case, it is estimated that 10.6 Gbits of EDR Data Products are generated on average each day, for a total of 7.6 Tbits of EDR data over the course of the nominal mission.

Level 1B processing to generate RDR data products results in an increase of the size of each echo, due to the conversion of echo samples from 4-, 6- or 8-bit integer numbers to 4-bytes real numbers, but in a potential decrease in the number of echoes, because of the possibility to pre-sum echoes on ground before processing (see Section 4.3.2.1). The net effect is estimated as a doubling of data volume in the passage from EDRs to RDRs.

Examination of different operation scenarios of the instrument provides an indication of the number of daily data takes, and thus of the number of EDR Data Products, ranging from a few to several tens, for an average number that is currently estimated at around 10. This results in an average RDR Data Product size of approximately 270 MBytes, and in a total of about 8000 RDR Data Products over the course of the mission, with a wide margin of variation for both estimates.

Data products will be delivered to the PDS Geosciences Node according to the schedule originally specified in the MRO Archive Plan [AD4], as maintained and updated by the MRO Data and Archives Working Group.

Whenever Level 1A (EDR) data are re-processed, due for example to the refinement of the spacecraft ephemerides used to compute the geometric parameters of the observations, all the corresponding RDR data products will also be reprocessed. Also, variations in input files such as the antenna pattern file, the reference function file, or the spurious frequencies file will result in the reprocessing of RDR data products generated through older versions of those files. In such an instance, the data will be re-delivered to the PDS Geosciences Node.

4.3.4 Labeling and Identification

SHARAD RDR data products consist of two files each, the first of which contains the processed instrument data, auxiliary scientific data, engineering parameters and geometric information used to locate observations in space and time. The second file is the detached PDS label describing the content of the previous file.

The file naming scheme adheres to the ISO Level II 27.3 file name convention to be compliant with PDS standard. File names are built by a concatenation of up to six identifiers separated by underscore characters ("_"), followed by a dot and a three-letter extension. Each identifier provides one type of information on the content of the file. Identifiers are concatenated in the following order:

The data product identifier is the character "R", denoting a Reduced Data Record product.

The transaction ID is a 7-digit number associated with the transaction ID (sometimes called product ID or observation ID) uniquely identifying the Operation Sequence Table (OST) used during data acquisition (see [AD7] for a description of the OST). The first five digits of the transaction ID correspond to the number of the orbit in which data were acquired, while the last two digits denote the number of the OST that was used during data acquisition.

The Operation Sequence Table line number is the three-digit number of the OST line being used during data acquisition.

Operative modes have been briefly discussed in Section 4.1.1. Operative mode identifiers consist of two letters followed by a two-digit number, the two letters being SS for sub-surface sounding, while the number ranges from 01 to 21 and is associated to the number of pre-summed echoes and to the bit resolution of each sample, as illustrated in Table 1.

The pulse repetition frequency (PRF) identifier is a three-digit number corresponding to the integer part of the PRF value used in transmitting radar pulses. Valid values for this identifier are 335, 350, 387, 670, 700 and 775, as listed in [AD7, section 3.5.5.5].

The version identifier is a single character denoting the current version of the data product, and ranges from A to Z.

File extension defines the format of data contained in the file: the extension is ".DAT" for binary files, denoting that the file contains a binary table object, and ".LBL" for the associated detached PDS label.

Files belonging to the same data product have identical names except for the extension.

Permitted values for different file name identifiers are listed in Table 5 below.

Data product

Transaction ID

OST line #

Operative mode

PRF

Version

Extension

0000000

9999999

000

…

999

RO01

RO21

SS01

SS21

335

350

387

670

700

775

.DAT

.LBL

Table 5: Permitted values for identifiers used in building RDR data product file names.

For example, the first version of a data product containing all data acquired during the measurements relative to the fifth Operation Sequence Table in orbit 1234, using the first OST line, in Subsurface Sounding mode at 700.28 Hz pulse repetition frequency with no pre-summed echoes per data block and 8-bit resolution per sample, would consist of the following three files:

· Data binary file: R_0123405_001_SS07_700_A.DAT

· Associated detached PDS label: R_0123405_001_SS07_700_A.LBL

A data product is identified by the part of the file name common to the files of which it consists, that is

Thus, in the previous example, the data product would be identified as

R_0123405_001_SS07_700_A

This value would be reported as the PRODUCT_ID value in the detached PDS label.

Individual RDR products may be revised during the course of the mission. A product's revision status is recorded both in the name of files constituting the data product and in its PDS label using the keyword PRODUCT_VERSION_ID. The value of this keyword is "A" for the first version of a product. The value is incremented with each product revision. Also, the label keyword PRODUCT_CREATION_TIME is updated with each product revision.

The PDS label also includes a RELEASE_IDkeyword to indicate the number of the data release in which the product was included. The first release of the mission has a RELEASE_ID value of "0001"; the second release three months later has a value of "0002", and so on. This keyword is not updated for a revised product; it always shows the ID of the release in which the product first appeared.

PRODUCT_VERSION_ID, PRODUCT_CREATION_TIME, and RELEASE_ID appear in the index table for the RDR archive so that the set of revised products can be easily identified.

The minimum unit for reprocessing of data products is the release: thus, if any data products belonging to a given release need to be reprocessed, all data products belonging to that release will be reprocessed as well. Older versions of data products will be erased upon the availability of a new version, so that the RDR archive contains only one version of a given data product. Because reprocessing is handled at the release level, data products in different releases may have a different value for PRODUCT_VERSION_ID.

4.4 Standards Used in Generating Data Products

4.4.1 PDS Standards

All data released by the SHARAD Team for archiving are required to be compliant with the Planetary Data System standard [AD1, 2, 3]. This standard imposes requirements on several aspects of the data product generation process, among which there is need for detailed documentation describing the origin, structure and processing undergone by data, for their accurate location in space and time, and in general for all auxiliary and ancillary data which are needed for the scientific use of the data product. Also, such information has to be provided in an Object Description Language (ODL), in the format keyword = value, where keyword is a standard term used to label a parameter (e.g. latitude), and value is any allowed information quantifying that parameter.

4.4.2 Time Standards

4.4.2.1 START_TIME and STOP_TIME Formation

The PDS formation rule for dates and time in UTC is YYYY-DDDThh:mm:ss.fff, with

· YYYY year (0000-9999)

· DDD day of year (001-366)

· T date/time separator

· hh hour (00-23)

· mm minute (00-59)

· ss second (00-59)

· fff fractions of second (000-999) (restricted to 3 digits)

4.4.2.2 SC_CLOCK_START_COUNT and SC_CLOCK_STOP_COUNT

The SC_CLOCK*COUNTS represents the on-board time counters (OBT) of the spacecraft and instrument computers. This OBT counter is given in the headers of the experiment telemetry source packets. It contains the data acquisition start time as 32 bit of unit seconds followed by 16 bit of fractional seconds. The time resolution of the fractional part is 2^-16 = 1.53 10^-5 seconds. Thus the OBT is represented as a decimal real number in floating-point notation with 5 digits after the decimal point. A reset of the spacecraft clock is represented by an integer number followed by a slash, e.g. "1/" or "2/".

Example 1: spacecraft_CLOCK_START_COUNT = "1/21983325.39258"

Example 2: spacecraft_CLOCK_START_COUNT = "21983325.39258"

Example 3: spacecraft_CLOCK_START_COUNT = "2/0000325.39008"

Example 1 and Example 2 represents the same time instance.

4.4.3 Coordinate Systems

SHARAD RDR data products will conform to a Project-determined set of cartographic standards. All map-projected data will use planetocentric coordinates and east-positive longitudes in the range 0° - 360°, computed w.r.t. the IAU 2000 reference ellipsoid [AD8]. Vector quantities such as spacecraft positions will be expressed in a Cartesian planetocentric reference frame.

4.4.4 Data Storage Conventions

Binary files are all fixed-length records, stored in least-significant-byte-first (little-endian) format. The RDR files will be produced on a PC running the Linux operating system. The PDS labels are stored as ASCII character strings conforming to the conventions outlined in the PDS Standards Reference [AD1]. In text files, each record is terminated with a carriage return followed by a line feed.

4.5 Data Validation

SHARAD Reduced Data Records will be validated before being released to the PDS. Validation is accomplished in two parts: validation for scientific integrity and validation for compliance with PDS standards.

SHARAD Team members are expected to conduct validation for scientific integrity in the course of their analysis of the products. Science validation is meant to ensure that data products contain the expected measurements and that they are otherwise suitable for analysis. The details of the science validation process are the responsibility of the SHARAD Team.

Validation for PDS compliance will be performed by the Geosciences Node and is meant to ensure that data products conform to PDS standards and to the specifications in this SIS.

A data set will pass a peer review before it is accepted by PDS. The SHARAD Team and the associated PDS Node will convene a peer review committee made up of scientists and data engineers. The committee will examine the data set to make sure it is complete and meets the product specifications as defined in the SIS. The committee will include a PDS representative to ensure that the data set is in compliance with PDS standards.

5 Detailed Data Product Specifications

5.1 Data Product Structure and Organization

Each Data Product will consist of two files: one is a binary file containing the scientific data of the instrument, that is a sequence of processed echoes, each of which is preceded by a header containing information on the collection and on-board processing of the data, and followed by parameters characterizing the ground processing of the echoes, by geometric quantities generated on-ground from spacecraft navigation data, and by parameters extracted from instrument and spacecraft housekeeping telemetry. The second file is a detached ASCII label describing the content of the data product. Such label is written according to standards defined by the Planetary Data System (PDS) [AD1], and lists parameters describing both the observation in which data were acquired and the structure of the file in which data is stored.

The binary file is structured as a PDS Table data object [AD1]. The content of such table is listed in a format file that will be contained in the LABEL directory of the Data Set Volume [AD5].

The detached PDS label contains a description of the table object in the file, and a pointer to a structure file in the LABEL directory describing each column of the table.

Because it is estimated that a large number of data files will be produced, the directory containing them will be further divided into a number of subdirectories, each containing data collected through the use of a single Operation Sequence Table (or OST, see [AD7] for a description). These subdirectory will be named so as to make clear which data products they contain and when such data were collected. Their name will be in the form pppnnnnnoo, where ppp is a group of letters denoting the kind of data product contained in the subdirectory (RDR for Reduced Data Records), nnnnn is the number of the orbit in which data were acquired, and oo is the number of the Operation Sequence Table in that orbit through which data were acquired: for example, the subdirectory named RDR0123405 will contain all files of Level 1B data collected in orbit 1234 with the instrument settings contained in the fifth Operation Sequence Table of that orbit.

5.2 Data Format Descriptions

Each SHARAD RDR data product consists of a binary file in fixed record-length format and a detached PDS label containing also information on source data, production process, relation between stored bytes and physical quantities, product identification, storing and organizing of ancillary data and descriptive information needed to interpret and process the data. An example label is given in Appendix 7.3, and definitions of the label keywords in Appendix 7.4. The structure of data contained in the binary file is that of a PDS Table object [AD1]. The PDS label contains pointers to a file containing definitions of the columns of such Table object: Appendix 7.5 lists the content of such definition file.

Each record in a binary file is a processed echo, that is the result of the Doppler filtering and range compressing of a variable number of raw echoes, and is expressed as a time series of complex voltages. Each record contains also a number of parameters describing the operation of the instrument during data acquisition, together with engineering and spacecraft information. Specifically, each record is subdivided into five parts, each of which contains a different type of information: ancillary data, scientific data, processing parameters, geometric parameters and instrument engineering parameters.

Ancillary data describe the instrument settings during data acquisition and report parameters used in on-board processing. Scientific data consist of the processed complex echo, expressed as a vector for the real part of the complex echo, followed by a second vector of the same length containing the imaginary part of the echo. Processing parameters have been computed by the ground processing software, and contain information such as the Doppler centroid and Doppler bandwidth of original raw echoes. Geometric parameters have been computed on ground from spacecraft trajectory and attitude data, and allow the location of each processed echo in space and time. Instrument engineering parameters are extracted from SHARAD housekeeping telemetry and report quantities such as currents and temperatures within the instrument.

5.3 Label and Header Descriptions

PDS labels are written in Object Description Language (ODL) [AD1]. PDS label statements have the form of "keyword = value". Each label statement is terminated with a carriage return character (ASCII 13) and a line feed character (ASCII 10) sequence to allow the label to be read by many operating systems.

The labels contained in SHARAD EDR files conform to the general structure used for all PDS detached labels [AD1]. The metadata in the label can be divided into seven categories as follows:

The first and shortest is the label standards specifier, which indicates the PDS standards version that applies to the label. The second group of keywords consists of identification data elements that give information about the dataset. These include identifiers for the specific data product and the PDS dataset to which it belongs; information about the input data such as spacecraft, instrument, and time range of data; and information about the product creation process.

This is followed by file characteristics for the binary files of the data product (Science Telemetry and Auxiliary Data), such as the record format, record length, and number of records. Next, pointers to the data product binary files containing the data objects are given; for the SHARAD RDRs, such objects are PDS Table objects. Pointer statements have the following format:

^object = file name

where the caret character (^, also called a pointer) is followed by the name of the specific data object. The string after the "=" sign is the name of the file containing the data object.

Following the object pointer is a set of identification data elements that give information about the input data used to produce the data object. Then follow descriptive data elements providing information about the content of the data object. These include instrument setup during data collection and an assessment of data quality.

Finally, definitions of the data objects in the files are given. The Table object definition contains information about the size, data type, scaling, and special values of the data. This object also contains a pointer to another file that contains the table column definitions, in order to avoid repeating the lengthy definitions in every label. These column definition files have the extension ".FMT" and are stored in the LABEL directory of the RDR archive. The data files themselves do not contain any embedded headers. Examples of SHARAD RDR labels and Table object column definitions are found in Appendix 7.3, 7.4 and 7.5 to this document.

6 Applicable Software

6.1 Applicable PDS Software Tools

SHARAD RDR data products can be read by the PDS software NASAView, which reads a PDS label and displays the associated image or table. NASAView is free software and is available for several computer platforms.

NASAView is a PDS archive product display program that runs on multiple platforms in a GUI environment. This application was built using the Label Library Light (L3), Object Access Library (OAL) and the XVT Development Solution for C package. Label Library Light parses PDS ODL labels and creates an in-memory representation of the label information. The object access library uses the parse tree and accesses the actual PDS object. The XVT Development solution supplies the cross platform GUI and an object-oriented environment. XVT allows the definition and code with them.

NASAView has been tested on both EDR and RDR data products, and a few minor problems have been found.

While there are some unusual numeric formats representing parameter values throughout EDR data products, NASAView is usually capable of reading them. The only exception are three-byte unsigned integers, which are displayed as asterisks. There are only two instances of such format, namely the parameters DATA_BLOCK_ID and DATA_BLOCK_FIRST_PRI in EDR data products, which are tags for records within a data product.

In reading a binary table, NASAView displays the name of the column as well as its content. It has been found, however, that such name must be less than 30 character long, otherwise the displayed column name is blank.

Finally, while NASAView is able to display individual ITEMs in a COLUMN object, it seems incapable of doing so for ITEMs in BIT_COLUMN objects.

6.2 Software Distribution and Update Procedures

NASAView is available for free from the Planetary Data System, but the source code is not available. Platforms supported are LINUX, SOLARIS, Windows and Power MAC. The executable of the program can be downloaded following links found at http://pds.jpl.nasa.gov/tools/software_download.cfm

For updates to the software, users may visit the web site or register with the PDS Subscription Service at http://pds.jpl.nasa.gov/.

7 Appendices

7.1 Acronyms

ADC	Analog to Digital Converter
ASDC	ASI Science data Center
ASI	Agenzia Spaziale Italiana (Italian Space Agency)
CODMAC	Committee On Data Management And Computation
EDR	Experiment Data Record
HGA	High Gain Antenna
INFOCOM	[Dipartimento di] Scienza e Tecnica dell'Informazione e della Comunicazione ([Department of] Science and Technology of Information and Communications)
JPL	Jet Propulsion Laboratory
MRO	Mars Reconnaissance Orbiter
NAIF	Navigation and Ancillary Information Facility at JPL
NASA	National Aeronautics and Space Administration
OBT	On Board Time
ODL	Object Description Language
OST	Operation Sequence Table
PDS	Planetary Data System
PGA	Phase Gradient Autofocus
PRF	Pulse Repetition Frequency
PRI	Pulse Repetition Interval
RDR	Reduced Data Record
Rx	Receiver
SAR	Synthetic Aperture Radar
SHARAD	SHAllow RADar
SIS	Software Interface Specification
SPICE	Geometric and ancillary data (Spacecraft, Planet, Instrument, C-kernel, and Event)
Tx	Transmitter
UTC	Coordinated Universal Time

Table 6: List of acronyms used throughout this document.

7.2 Definitions of Data Processing Levels

NASA	CODMAC	Description
Packet data	Raw - Level 1	Telemetry data stream as received at the ground station, with science and engineering data embedded.
Level-0	Edited - Level 2	Instrument science data (e.g., raw voltages, counts) at full resolution, time ordered, with duplicates and transmission errors removed.
Level 1A	Calibrated - Level 3	Level 0 data that have been located in space and may have been transformed (e.g., calibrated, rearranged) in a reversible manner and packaged with needed ancillary and auxiliary data (e.g., radiances with the calibration equations applied).
Level 1B	Resampled - Level 4	Irreversibly transformed (e.g., resampled, remapped, calibrated) values of the instrument measurements (e.g., radiances, magnetic field strength).
Level 1C	Derived - Level 5	Level 1A or 1B data that have been resampled and mapped onto uniform space-time grids. The data are calibrated (i.e., radiometrically corrected) and may have additional corrections applied (e.g., terrain correction).
Level 2	Derived - Level 5	Geophysical parameters, generally derived from Level 1 data, and located in space and time commensurate with instrument location, pointing, and sampling.
Level 3	Derived - Level 5	Geophysical parameters mapped onto uniform space-time grids.

Table 7: Equivalence between NASA and CODMAC data processing level.

7.3 Example PDS Label

Below is listed the content of the label file R_0168901_002_SS19_700_A.LBL.

/* Label standards identifier */

PDS_VERSION_ID = PDS3

/* Identification data elements that apply to all referenced data files */

DATA_SET_ID = "MRO-M-SHARAD-4-RDR-V1.0"

PRODUCT_ID = "R_0168901_002_SS19_700_A"

RELEASE_ID = "0001"

PRODUCT_TYPE = RDR

INSTRUMENT_HOST_ID = MRO

INSTRUMENT_HOST_NAME = "MARS RECONNAISSANCE ORBITER"

INSTRUMENT_ID = SHARAD

INSTRUMENT_NAME = "SHALLOW RADAR"

INSTRUMENT_TYPE = RADAR

TARGET_NAME = MARS

MISSION_PHASE_NAME = "MAPPING"

ORBIT_NUMBER = 1689

MRO:START_SUB_SPACECRAFT_LONGITUDE = 229.725482 <DEGREES>

MRO:START_SUB_SPACECRAFT_LATITUDE = 61.070977 <DEGREES>

MRO:STOP_SUB_SPACECRAFT_LONGITUDE = 229.355538 <DEGREES>

MRO:STOP_SUB_SPACECRAFT_LATITUDE = 59.706975 <DEGREES>

START_TIME = 2006-340T02:09:41.792

STOP_TIME = 2006-340T02:10:07.782

SPACECRAFT_CLOCK_START_COUNT = "2/849838181.51915"

SPACECRAFT_CLOCK_STOP_COUNT = "2/849838207.51298"

PRODUCT_CREATION_TIME = 2007-170T20:17:54.000

PRODUCT_VERSION_ID = "A"

PRODUCT_VERSION_TYPE = RECONSTRUCTED

OBJECT = FILE

/* File characteristic data elements */

RECORD_TYPE = FIXED_LENGTH

RECORD_BYTES = 5822

FILE_RECORDS = 4431

/* Data object pointers */

^PROCESSED_ECHO_TABLE = "R_0168901_002_SS19_700_A.DAT"

/* Identification data elements */

SOURCE_PRODUCT_ID = "E_0168901_002_SS19_700_A.LBL"

/* Descriptive data elements */

INSTRUMENT_MODE_ID = SS19

INSTRUMENT_MODE_DESC = "In this mode the instrument performs

scientific measurements by transmitting

radar pulses and collecting, processing

and formatting received echoes. Data

processing performed on-board consists

in summing 04 sequential echoes, and

converting the result from 32-bit

precision to 08-bit precision."

MRO:PULSE_REPETITION_INTERVAL = 1428 <MICROSECONDS>

MRO:PHASE_COMPENSATION_TYPE = "NO COMPENSATION"

MRO:MANUAL_GAIN_CONTROL = 10

MRO:COMPRESSION_SELECTION_FLAG = "STATIC"

MRO:CLOSED_LOOP_TRACKING_FLAG = "DISABLED"

DATA_QUALITY_ID = "0"

DATA_QUALITY_DESC = "0: no corrupted data

1: less than 2% corrupted data

2: less than 5% corrupted data

3: less than 10% corrupted data

4: more than 10% corrupted data"

MRO:WEIGHTING_FUNCTION_NAME = "HANNING"

MRO:NUMERICAL_FILTER_TYPE = "INVERSE"

MRO:PHASE_CORRECTION_TYPE = "PHASE GRADIENT AUTOFOCUS"

MRO:REFERENCE_FUNCTION_FILE_NAME = "AUTO"

MRO:NOMINAL_ALONG_TRACK_RESOLUTION = 300 <METERS>

MRO:AZIMUTH_SPACING_TYPE = "UNIFORM"

MRO:RADARGRAM_RETURN_INTERVAL = 312321

/* Data object definitions */

OBJECT = PROCESSED_ECHO_TABLE

INTERCHANGE_FORMAT = BINARY

COLUMNS = 102

ROW_BYTES = 5822

ROWS = 4431

DESCRIPTION = "Binary table containing SHARAD processed

scientific data, that is the result of

the Doppler filtering and range

compressing of a variable number of raw

echoes, and is expressed as a time

series of complex voltages. Each record

contains also a number of parameters

describing the operation of the

instrument during data acquisition,

together with engineering and spacecraft

information. Specifically, each record

is subdivided into five parts, each of

which contains a different type of

information: ancillary data, scientific

data, processing parameters, geometric

parameters and instrument engineering

parameters."

^STRUCTURE = "RDR.FMT"

PRIMARY_KEY = ("SCET_BLOCK_WHOLE","SCET_BLOCK_FRAC")

START_PRIMARY_KEY = (849838181,51915)

STOP_PRIMARY_KEY = (849838207,51298)

END_OBJECT = PROCESSED_ECHO_TABLE

END_OBJECT = FILE

END

7.4 PDS Label Keywords

The following table lists in alphabetical order the keywords appearing in an RDR data product PDS label, together with an explanation of its meaning and a set of valid values.

Keyword name	Definition	Type	Valid values
COLUMNS	Number of columns in each row of a data object.	INTEGER	102
DATA_QUALITY_DESC	Description of the data quality which is associated with a particular DATA_QUALITY_ID value.	CHARACTER	" 0: no corrupted data 1: less than 2% corrupted data 2: less than 5% corrupted data 3: less than 10% corrupted data 4: more than 10% corrupted data"
DATA_QUALITY_ID	Numeric key which identifies the quality of data in the data product.	CHARACTER	"0", "1", "2", "3", "4", "N/A"
DATA_SET_ID	Unique alphanumeric identifier for a data set or a data product. The DATA_SET_ID value for a given data set or product is constructed according to flight project naming conventions.	CHARACTER	"MRO-M-SHARAD-4-RDR-V1.0"
DESCRIPTION	Free-form, unlimited-length character string that represents or gives an account of something.	CHARACTER	Text describing the content of a data object.
FILE_RECORDS	Number of physical file records.	INTEGER	Number of processed echoes in the Data Product.
INSTRUMENT_HOST_ID	Unique identifier for the host where an instrument is located.	CHARACTER	MRO
INSTRUMENT_HOST_NAME	Full name of the host on which an instrument is based.	CHARACTER	"MARS RECONNAISSANCE ORBITER"
INSTRUMENT_ID	Abbreviated name or acronym which identifies an instrument.	CHARACTER	SHARAD
INSTRUMENT_MODE_DESC	Description of the instrument mode which is identified by the INSTRUMENT_MODE_ID element.	CHARACTER	Text providing a brief account of the characteristics of the instrument Operative Mode.
INSTRUMENT_MODE_ID	Instrument-dependent designation of operating mode.	CHARACTER	SS01 ¼ SS21
INSTRUMENT_NAME	Full name of an instrument.	CHARACTER	"SHALLOW RADAR"
INSTRUMENT_TYPE	Type of an instrument.	CHARACTER	RADAR
INTERCHANGE_FORMAT	Manner in which data items are stored.	CHARACTER	BINARY
MISSION_PHASE_NAME	Commonly-used identifier of a mission phase. See [AD4, Table 9] for timing of mission phases.	CHARACTER	"CRUISE", "AEROBRAKING", "MAPPING", "EXTENDED MISSION"
MRO:AZIMUTH_SPACING_TYPE	Type of azimuth (i.e. along-track) spacing of SHARAD radar footprints after ground processing. UNIFORM means that azimuth lines are evenly spaced. NOT UNIFORM means that azimuth lines are not evenly spaced.	CHARACTER	"UNIFORM", "NOT UNIFORM"
MRO:CLOSED_LOOP_TRACKING_FLAG	Flag used by the SHARAD on-board processing software to enable or disable the closed-loop tracking algorithm, which dynamically determines the opening of the receiving window based on the time delay of previous echoes.	CHARACTER	"ENABLED", "DISABLED"
MRO:COMPRESSION_SELECTION_FLAG	Flag used by the SHARAD on-board processing software to enable or disable the dynamic bit compression algorithm, which reduces the signal dynamic range based on the value of the echo strength.	CHARACTER	"STATIC", "DYNAMIC"
MRO:MANUAL_GAIN_CONTROL	Parameter used by the SHARAD on-board processing software to set the receiver gain to a fixed value during data acquisition.	INTEGER	0 … 255
MRO:NOMINAL_ALONG_TRACK_RESOLUTION	Horizontal resolution of the instrument in the along-track direction achieved through azimuth processing, expressed in meters.	REAL	0 … 10000
MRO:NUMERICAL_FILTER_TYPE	Parameter used by the SHARAD ground processing software for the selection of the method used for building the numerical filter used in the range compression of the signal.	CHARACTER	"INVERSE", "MATCHED"
MRO:PHASE_COMPENSATION_TYPE	Parameter used by the SHARAD on-board processing software to select the type of time shifting applied to received echoes before coherent summing.	CHARACTER	"NO COMPENSATION", "RADIAL VELOCITY", "SURFACE SLOPE", "RADIAL VELOCITY AND SURFACE SLOPE"
MRO:PHASE_CORRECTION_TYPE	Parameter used by the SHARAD ground processing software for the selection of the algorithm used for the correction of any phase distortion in the signal caused by the ionosphere.	CHARACTER	"NONE", "PHASE GRADIENT AUTOFOCUS"
MRO:PULSE_REPETITION_INTERVAL	Time between the transmission of two consecutive pulses, expressed in microseconds.	INTEGER	1428, 1492, 1290, 2856, 2984, 2580
MRO:RADARGRAM_RETURN_INTERVAL	Round trip time of an electromagnetic pulse from the center of Mars to the first sample of each echo in the data product. This time delay is expressed in terms of number of echo samples. Time distance between echo samples in RDR data products is 0.075 microseconds.. See Section 4.3.2.6 for details.	INTEGER	0 … 1000000
MRO:REFERENCE_FUNCTION_FILE_NAME	Name of the file located in the CALIB directory containing the function used for building the numerical filter used in the range compression of the signal. See Section 4.3.2.2 for details.	CHARACTER	"AUTO"
MRO:START_SUB_SPACECRAFT_LATITUDE	Planetocentric latitude of the sub-spacecraft point at the beginning of data collection.	REAL	-90 … 90
MRO:START_SUB_SPACECRAFT_LONGITUDE	Planetocentric east longitude of the sub-spacecraft point at the beginning of data collection.	REAL	0 … 360
MRO:STOP_SUB_SPACECRAFT_LATITUDE	Planetocentric latitude of the sub-spacecraft point at the end of data collection.	REAL	-90 … 90
MRO:STOP_SUB_SPACECRAFT_LONGITUDE	Planetocentric east longitude of the sub-spacecraft point at the end of data collection.	REAL	0 … 360
MRO:WEIGHTING_FUNCTION_NAME	Parameter used by the SHARAD ground processing software for the selection of the function used for weighting the contribution of different frequencies in the signal before range compression.	CHARACTER	"CHEBYCHEV", "HANNING", "KAISER", "UNIFORM"
ORBIT_NUMBER	The ORBIT_NUMBER element identifies the number of the orbital revolution of the spacecraft around a target body.	INTEGER	0 … 99999
PDS_VERSION_ID	Version number of the PDS standards documents that is valid when a data product label is created	CHARACTER	"PDS3"
PRIMARY_KEY	Names of columns in the table that may be used to uniquely identify each row in the table.	CHARACTER	( "SCET_BLOCK_WHOLE", "SCET_BLOCK_FRAC" )
PRODUCT_CREATION_TIME	UTC system format time when a product was created. See Section 4.4.2.1 for formation rules.	CHARACTER	Example: 2006-217T18:00:00.000
PRODUCT_ID	Permanent, unique identifier assigned to a data product by its producer. See Section 4.3.4 for formation rules.	CHARACTER	Example: "R_0123405_001_SS07_700_A"
PRODUCT_TYPE	Type or category of a data product within a data set.	CHARACTER	RDR
PRODUCT_VERSION_ID	Version of an individual product within a data set.	CHARACTER	"A" … "Z"
PRODUCT_VERSION_TYPE	Version of an individual data product that might appear in several incarnations.	CHARACTER	"PREDICTED" (predicted spacecraft trajectory data), "RECONSTRUCTED" (reconstructed spacecraft trajectory data)
RECORD_BYTES	Number of bytes in a physical file record, including record terminators and separators.	INTEGER	5822
RECORD_TYPE	Record format of a file.	CHARACTER	FIXED_LENGTH
RELEASE_ID	The RELEASE_ID element identifies the unique identifier associated with a specific release of a data set. See [AD4, Table 9] for timing of releases.	CHARACTER	"0001" … "9999"
ROWS	Number of rows in a data object.	INTEGER	Number of processed echoes in the Data Product
ROW_BYTES	Number of bytes in each data object row.	INTEGER	5822
SOURCE_PRODUCT_ID	Experiment Data Record data product used as input to create a new product. See [AD6].	CHARACTER	Name of the label of the Experiment Data Record data product used in making the data product.
SPACECRAFT_CLOCK_START_COUNT	Value of the spacecraft clock at the time of acquisition of the first Data Block in the Data Product. See Section 4.4.2.2 for formation rules.	CHARACTER	Example: "2/0818975946.01161"
SPACECRAFT_CLOCK_STOP_COUNT	Value of the spacecraft clock at the time of acquisition of the last Data Block in the Data Product. See Section 4.4.2.2 for formation rules.	CHARACTER	Example: "2/0818975949.00906"
START_PRIMARY_KEY	Beginning of the range of values for the PRIMARY_KEY column in the table.	INTEGER	SCET_BLOC_WHOLE and SCET_BLOCK_FRAC of the first echo in the Data Product.
START_TIME	Date and time of acquisition of the first Data Block in the Data Product in UTC system format. See Section 4.4.2.1 for formation rules.	CHARACTER	Example: 2005-213T21:18:48.409
STOP_PRIMARY_KEY	End of the range of values for the PRIMARY_KEY column in the table.	INTEGER	SCET_BLOC_WHOLE and SCET_BLOCK_FRAC of the last echo in the Data Product.
STOP_TIME	Date and time of acquisition of the last Data Block in the Data Product in UTC system format. See Section 4.4.2.1 for formation rules.	CHARACTER	Example: 2005-213T21:18:51.405
TARGET_NAME	Target of observation.	CHARACTER	MARS
^PROCESSED_ECHO_TABLE	Pointer to the binary data file containing the processed echo Table object.	CHARACTER	Example: "R_0123405_001_SS07_700_A.DAT"
^STRUCTURE	Pointer to the format descriptor of the Table object.	CHARACTER	"RDR.FMT"

Table 8: alphabetical list of keywords appearing in an RDR data product PDS label.

7.5 RDR Format Files

The binary data file of every RDR data product contains the scientific data of the instrument, that is a sequence of processed echoes, each of which is preceded by a header containing information on the collection and on-board processing of the data, and followed by parameters characterizing the ground processing of the echoes, by geometric quantities generated on-ground from spacecraft navigation data, and by parameters extracted from instrument housekeeping telemetry.

The binary data file is organized as a table, in which each record corresponds to a processed echo. Columns of the table are described in a separate file called format file: below is listed the content of such format file, called RDR.FMT, which is to be found in the LABEL directory of the data volume.

OBJECT = COLUMN

NAME = SCET_BLOCK_WHOLE

COLUMN_NUMBER = 1

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 1

BYTES = 4

DESCRIPTION = "Spacecraft clock count at the time of data

block start of acquisition, integer seconds

part."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = SCET_BLOCK_FRAC

COLUMN_NUMBER = 2

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 5

BYTES = 2

DESCRIPTION = "Spacecraft clock count at the time of data

block start of acquisition, fractional seconds

part expressed in units of 2^-16 seconds."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = TLM_COUNTER

COLUMN_NUMBER = 3

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 7

BYTES = 4

DESCRIPTION = "Sequential counter uniquely identifying the

data block in the telemetry flux."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = FMT_LENGTH

COLUMN_NUMBER = 4

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 11

BYTES = 2

DESCRIPTION = "Length of the data block in bytes as formatted

by the instrument (excluding header and

trailer). Valid values are 1972 for 4-bit

modes, 2872 for 6-bit modes, 3772 for 8-bit

modes."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = SCET_OST_WHOLE

COLUMN_NUMBER = 5

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 13

BYTES = 4

DESCRIPTION = "Spacecraft clock count at the start of

execution of the current Operation Sequence

Table, integer seconds part."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = SCET_OST_FRAC

COLUMN_NUMBER = 6

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 17

BYTES = 2

DESCRIPTION = "Spacecraft clock count at the start of

execution of the current Operation Sequence

Table, fractional seconds part expressed in

units of 2^-16 seconds."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = OST_LINE_NUMBER

COLUMN_NUMBER = 7

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 19

BYTES = 1

DESCRIPTION = "Number of the Operation Sequence Table line in

execution."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = PULSE_REPETITION_INTERVAL

COLUMN_NUMBER = 8

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 20

BYTES = 1

DESCRIPTION = "This parameter is extracted from the Operation

Sequence Table. It is the time between the

transmission of two consecutive pulses, to be

used for the entire duration of the selected

Operation Mode:

- a value of 1 means 1428 microseconds;

- a value of 2 means 1492 microseconds;

- a value of 3 means 1290 microseconds;

- a value of 4 means 2856 microseconds;

- a value of 5 means 2984 microseconds;

- a value of 6 means 2580 microseconds."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = PHASE_COMPENSATION_TYPE

COLUMN_NUMBER = 9

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 21

BYTES = 1

DESCRIPTION = "This parameter is extracted from the Operation

Sequence Table, and is used by on-board

software to select the type of phase shifting

applied to the chirp transmitted by the radar,

to compensate for the pulse-to-pulse echo

shift caused by a surface slope and by the

spacecraft radial motion:

- a value of 0 means no compensation;

- a value of 1 means radial velocity only;

- a value of 2 means surface slope only;

- a value of 3 means radial velocity and

surface slope."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = DATA_TAKE_LENGTH

COLUMN_NUMBER = 10

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 22

BYTES = 4

DESCRIPTION = "This parameter is extracted from the Operation

Sequence Table, and is the duration of the

data take expressed in number of pulse

repetition intervals; it shall be an integer

multiple of the number of pre-summed echoes in

a data block."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = OPERATIVE_MODE

COLUMN_NUMBER = 11

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 26

BYTES = 1

DESCRIPTION = "This parameter is extracted from the Operation

Sequence Table, and is used to select the

Operative Mode of the instrument: a value from

33 to 53 means Subsurface Sounding modes from

01 to 21; a value from 97 to 117 means Receive

Only modes from 01 to 21."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = MANUAL_GAIN_CONTROL

COLUMN_NUMBER = 12

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 27

BYTES = 1

DESCRIPTION = "This parameter is extracted from the Operation

Sequence Table, and is used by on-board

software to set the receiver gain during data

acquisition."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = COMPRESSION_SELECTION

COLUMN_NUMBER = 13

DATA_TYPE = BOOLEAN

START_BYTE = 28

BYTES = 1

DESCRIPTION = "This parameter is extracted from the Operation

Sequence Table, and is used by on-board

software to select either the static scaling

algorithm or the the dynamic scaling algorithm

for the compression of echo samples from 32

bits to 4, 6 or 8 bits:

- a value of 0 means static scaling;

- a value of 1 means dynamic scaling."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = CLOSED_LOOP_TRACKING

COLUMN_NUMBER = 14

DATA_TYPE = BOOLEAN

START_BYTE = 29

BYTES = 1

DESCRIPTION = "This parameter is extracted from the Operation

Sequence Table, and is used by the on-board

software to enable or disable the closed-loop

tracking algorithm, which dynamically

determines the opening of the receiving window

based on the time delay of previous echoes:

- a value of 0 means closed-loop tracking

disabled;

- a value of 1 means closed-loop tracking

enabled."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = TRACKING_DATA_STORAGE

COLUMN_NUMBER = 15

DATA_TYPE = BOOLEAN

START_BYTE = 30

BYTES = 1

DESCRIPTION = "This parameter is extracted from the Operation

Sequence Table, and is used by the on-board

software to enable or disable the storage of

radar echoes processed on board for the

closed-loop tracking of the echo:

- a value of 0 means storage of tracking data

disabled;

- a value of 1 means storage of tracking data

enabled."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = TRACKING_PRE_SUMMING

COLUMN_NUMBER = 16

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 31

BYTES = 1

DESCRIPTION = "This parameter is extracted from the Operation

Sequence Table, and is the number of radar

echoes to pre-sum before processing them on

board for the closed-loop tracking of the

echo:

- a value of 0 means no pre-summed echoes;

- a value of 1 means 2 pre-summed echoes;

- a value of 2 means 3 pre-summed echoes;

- a value of 3 means 4 pre-summed echoes;

- a value of 4 means 8 pre-summed echoes;

- a value of 5 means 16 pre-summed echoes;

- a value of 6 means 32 pre-summed echoes;

- a value of 7 means 64 pre-summed echoes."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = TRACKING_LOGIC_SELECTION

COLUMN_NUMBER = 17

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 32

BYTES = 1

DESCRIPTION = "This parameter is extracted from the Operation

Sequence Table, and selects the method used to

determine the position of the echo within the

receiving window during closed-loop tracking:

- a value of 0 means use of the threshold

overshooting method;

- a value of 1 means use of the center of

gravity method."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = THRESHOLD_LOGIC_SELECTION

COLUMN_NUMBER = 18

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 33

BYTES = 1

DESCRIPTION = "This parameter is extracted from the Operation

Sequence Table, and selects the method for the

determination of the threshold that echo

sample values have to exceed for successful

detection of an echo in closed-loop tracking:

- a value of 0 means threshold evaluated on

board;

- a value of 1 means threshold set from

ground."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = SAMPLE_NUMBER

COLUMN_NUMBER = 19

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 34

BYTES = 1

OFFSET = 1

DESCRIPTION = "This parameter is extracted from the Operation

Sequence Table, and is the minimum number of

echo samples whose value has to exceed the

threshold for successful detection of an echo

in closed-loop tracking:

- a value of 0 means 1 sample;

- a value of 1 means 2 samples;

...and so on, until

- a value of 15 means 16 samples."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = ALPHA_BETA

COLUMN_NUMBER = 20

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 35

BYTES = 1

DESCRIPTION = "This parameter is extracted from the Operation

Sequence Table, and determines the selection

of a set of coefficients stored in the

Parameter Table for the Kalman filter used to

track the motion of the echo within the

receiving window."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = REFERENCE_BIT

COLUMN_NUMBER = 21

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 36

BYTES = 1

DESCRIPTION = "This parameter is extracted from the Operation

Sequence Table, and selects the refresh logic

of the close-loop tracking algorithm after a

change of instrument operative mode:

- a value of 0 means that algorithm parameters

are retrieved from the previous mode;

- a value of 1 means that algorithm parameters

are refreshed and read from the Parameter

Table."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = THRESHOLD

COLUMN_NUMBER = 22

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 37

BYTES = 1

DESCRIPTION = "This parameter is extracted from the Operation

Sequence Table, and is the first order

coefficient for the evaluation of the

threshold value in closed-loop tracking."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = THRESHOLD_INCREMENT

COLUMN_NUMBER = 23

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 38

BYTES = 1

DESCRIPTION = "This parameter is extracted from the Operation

Sequence Table, and is the first order

coefficient for the evaluation of the

threshold value increment in closed-loop

tracking."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = INITIAL_ECHO_VALUE

COLUMN_NUMBER = 24

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 39

BYTES = 1

DESCRIPTION = "This parameter is extracted from the Operation

Sequence Table, and is the first order

coefficient for the prediction of the echo

position in the receiving window during

closed-loop tracking."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = EXPECTED_ECHO_SHIFT

COLUMN_NUMBER = 25

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 40

BYTES = 1

DESCRIPTION = "This parameter is extracted from the Operation

Sequence Table, and is the first order

coefficient for the prediction of the echo

shift in the receiving window during

closed-loop tracking."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = WINDOW_LEFT_SHIFT

COLUMN_NUMBER = 26

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 41

BYTES = 1

DESCRIPTION = "This parameter is extracted from the Operation

Sequence Table, and is the first order

coefficient for the left shift of the tracking

window during closed-loop tracking."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = WINDOW_RIGHT_SHIFT

COLUMN_NUMBER = 27

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 42

BYTES = 1

DESCRIPTION = "This parameter is extracted from the Operation

Sequence Table, and is the first order

coefficient for the right shift of the

tracking window during closed-loop tracking."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = DATA_BLOCK_ID

COLUMN_NUMBER = 28

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 43

BYTES = 4

DESCRIPTION = "Order of acquisition of the data block within

the current Operation Sequence Table line."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = SCIENCE_DATA_SOURCE_COUNTER

COLUMN_NUMBER = 29

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 47

BYTES = 2

DESCRIPTION = "Order of acquisition of the data block within

the current Operation Sequence Table line.

This index is incremented only for data

acquired during closed-loop tracking."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = SCIENTIFIC_DATA_TYPE

COLUMN_NUMBER = 30

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 49

BYTES = 1

DESCRIPTION = "This field is used to indicate the type of

data acquired:

- a value of 0 means Tracking Data;

- a value of 1 means Science Data."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = SEGMENTATION_FLAG

COLUMN_NUMBER = 31

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 50

BYTES = 1

DESCRIPTION = "This field is used in case of segmentation of

observations in the current Operation Sequence

Table line:

- a value of 0 means that the data block is

the only one in the current Operation

Sequence Table line;

- a value of 1 means that the data block is

the first one in the current Operation

Sequence Table line;

- a value of 2 means that the data block is

neither the first nor the last one in the

current Operation Sequence Table line;

- a value of 3 means that the data block is

the last one in the current Operation

Sequence Table line."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = DMA_ERROR

COLUMN_NUMBER = 32

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 51

BYTES = 1

DESCRIPTION = "Flag used to signal the occurrence of a DMA

Error condition in the Field Programmable Gate

Array of the slave board:

- a value of 0 means no error;

- a value of 1 means DMA Error."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = TC_OVERRUN

COLUMN_NUMBER = 33

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 52

BYTES = 1

DESCRIPTION = "Flag used to signal the occurrence of a

Telecommand Overrun condition in the Field

Programmable Gate Array of the slave board:

- a value of 0 means no error;

- a value of 1 means Telecommand Overrun."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = FIFO_FULL

COLUMN_NUMBER = 34

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 53

BYTES = 1

DESCRIPTION = "Flag used to signal the occurrence of a FIFO

Full condition in the Field Programmable Gate

Array of the slave board:

- a value of 0 means FIFO Full;

- a value of 1 means no error."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = TEST

COLUMN_NUMBER = 35

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 54

BYTES = 1

DESCRIPTION = "Flag used in testing the Field Programmable

Gate Array of the slave board."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = DATA_BLOCK_FIRST_PRI

COLUMN_NUMBER = 36

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 55

BYTES = 4

DESCRIPTION = "Value of the Pulse Repetition Interval counter

for the first data block of the current

Operation Sequence Table line."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = TIME_DATA_BLOCK_WHOLE

COLUMN_NUMBER = 37

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 59

BYTES = 4

DESCRIPTION = "Instrument clock count at the time of data

block acquisition, integer seconds part. The

instrument clock is reset at the start of

execution of a new Operation Sequence Table."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = TIME_DATA_BLOCK_FRAC

COLUMN_NUMBER = 38

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 63

BYTES = 2

DESCRIPTION = "Instrument clock count at the time of data

block acquisition, fractional seconds part

expressed in units of 2^-16 seconds. The

instrument clock is reset at the start of

execution of a new Operation Sequence Table."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = SDI_BIT_FIELD

COLUMN_NUMBER = 39

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 65

BYTES = 2

DESCRIPTION = "This parameter provides indication of the

position of the most significant bit in the

dynamic scaling of echo samples. It is used in

decompressing echoes on ground."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = TIME_N

COLUMN_NUMBER = 40

DATA_TYPE = PC_REAL

START_BYTE = 67

BYTES = 4

UNIT = SECONDS

DESCRIPTION = "This parameter is extracted from the Parameter

Table, and is the value of the instrument

clock count identifying the line in the

Orbital Data Table which most closely precedes

in time the instrument clock count for the

data block."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = RADIUS_N

COLUMN_NUMBER = 41

DATA_TYPE = PC_REAL

START_BYTE = 71

BYTES = 4

UNIT = KILOMETERS

DESCRIPTION = "Spacecraft distance from Mars' center of mass,

read from the line in the Orbital Data Table

whose reference time most closely precedes the

instrument clock count for the data block."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = TANGENTIAL_VELOCITY_N

COLUMN_NUMBER = 42

DATA_TYPE = PC_REAL

START_BYTE = 75

BYTES = 4

UNIT = "METERS/SECOND"

DESCRIPTION = "Spacecraft tangential velocity with respect to

Mars' center of mass, read from the line in

the Orbital Data Table whose reference time

most closely precedes the instrument clock

count for the data block."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = RADIAL_VELOCITY_N

COLUMN_NUMBER = 43

DATA_TYPE = PC_REAL

START_BYTE = 79

BYTES = 4

UNIT = "METERS/SECOND"

DESCRIPTION = "Spacecraft radial velocity with respect to

Mars' center of mass, read from the line in

the Orbital Data Table whose reference time

most closely precedes the instrument clock

count for the data block."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = TLP

COLUMN_NUMBER = 44

DATA_TYPE = PC_REAL

START_BYTE = 83

BYTES = 4

UNIT = KILOMETERS

DESCRIPTION = "Spacecraft position along its ground track,

measured from the beginning of execution of

the current Operation Sequence Table. It has

been read from the line in the Orbital Data

Table whose reference time most closely

precedes the instrument clock count for the

data block."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = TIME_WPF

COLUMN_NUMBER = 45

DATA_TYPE = PC_REAL

START_BYTE = 87

BYTES = 4

UNIT = SECONDS

DESCRIPTION = "Instrument clock count at which orbital

parameters used in on-board processing are

interpolated from values extracted from the

Orbital Data Table. This clock count is not

the instrument clock count for the data block,

but rather an approximate value which is

refreshed every 64 pulse repetion intervals."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = DELTA_TIME

COLUMN_NUMBER = 46

DATA_TYPE = PC_REAL

START_BYTE = 91

BYTES = 4

UNIT = SECONDS

DESCRIPTION = "Parameter used in the linear interpolation of

orbital parameters used in on-board processing

from values extracted from the Orbital Data

Table. It is the difference between TIME_WPF

and TIME_N."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = TLP_INTERPOLATE

COLUMN_NUMBER = 47

DATA_TYPE = PC_REAL

START_BYTE = 95

BYTES = 4

UNIT = KILOMETERS

DESCRIPTION = "Spacecraft position along its ground track,

measured from the beginning of execution of

the current Operation Sequence Table. It has

been interpolated from values extracted from

the Orbital Data Table at the time TIME_WPF."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = RADIUS_INTERPOLATE

COLUMN_NUMBER = 48

DATA_TYPE = PC_REAL

START_BYTE = 99

BYTES = 4

UNIT = KILOMETERS

DESCRIPTION = "Spacecraft distance from Mars' center of mass,

interpolated from values extracted from the

Orbital Data Table at TIME_WPF."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = TANGENTIAL_VELOCITY_INTERPOLATE

COLUMN_NUMBER = 49

DATA_TYPE = PC_REAL

START_BYTE = 103

BYTES = 4

UNIT = "METERS/SECOND"

DESCRIPTION = "Spacecraft tangential velocity with respect to

Mars' center of mass, interpolated from values

extracted from the Orbital Data Table at

TIME_WPF."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = RADIAL_VELOCITY_INTERPOLATE

COLUMN_NUMBER = 50

DATA_TYPE = PC_REAL

START_BYTE = 107

BYTES = 4

UNIT = "METERS/SECOND"

DESCRIPTION = "Spacecraft radial velocity with respect to

Mars' center of mass, interpolated from values

extracted from the Orbital Data Table at

TIME_WPF."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = END_TLP

COLUMN_NUMBER = 51

DATA_TYPE = PC_REAL

START_BYTE = 111

BYTES = 4

UNIT = KILOMETERS

DESCRIPTION = "Parameter extracted from the Parameter Table,

and defining the greatest value of the

spacecraft position along its ground track,

measured from the beginning of execution of

the current Operation Sequence Table, for

which the current set of polynomial

coefficients used in computing Mars' planet

radius and terrain slope is still valid."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = S_COEFFS

COLUMN_NUMBER = 52

DATA_TYPE = PC_REAL

START_BYTE = 115

BYTES = 32

ITEMS = 8

ITEM_BYTES = 4

DESCRIPTION = "Set of coefficients of a polynome used to

estimate the mean slope of the Martian surface

along the ground track of the spacecraft."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = C_COEFFS

COLUMN_NUMBER = 53

DATA_TYPE = PC_REAL

START_BYTE = 147

BYTES = 28

ITEMS = 7

ITEM_BYTES = 4

DESCRIPTION = "Set of coefficients of a polynome used to

estimate the radius of Mars inclusive of

topography along the ground track of the

spacecraft."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = SLOPE

COLUMN_NUMBER = 54

DATA_TYPE = PC_REAL

START_BYTE = 175

BYTES = 4

UNIT = RADIANS

DESCRIPTION = "Estimated value of the mean slope of the

Martian surface computed from a set of

polynomial coefficients using

TLP_INTERPOLATE."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = TOPOGRAPHY

COLUMN_NUMBER = 55

DATA_TYPE = PC_REAL

START_BYTE = 179

BYTES = 4

UNIT = KILOMETERS

DESCRIPTION = "Estimated value of the radius of Mars

inclusive of topography computed from a set of

polynomial coefficients using

TLP_INTERPOLATE."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = PHASE_COMPENSATION_STEP

COLUMN_NUMBER = 56

DATA_TYPE = PC_REAL

START_BYTE = 183

BYTES = 4

DESCRIPTION = "Phase compensation step used in the generation

of the transmitted chirp within the Digital

Chirp Generator."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = RECEIVE_WINDOW_OPENING_TIME

COLUMN_NUMBER = 57

DATA_TYPE = PC_REAL

START_BYTE = 187

BYTES = 4

DESCRIPTION = "Opening time of the receiver, measured from

the start of the transmission of the pulse and

expressed in units of the sampling interval of

the analog-to-digital converter, which is

0.0375 microseconds long."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = ANTENNA_RELATIVE_GAIN

COLUMN_NUMBER = 58

DATA_TYPE = PC_REAL

START_BYTE = 191

BYTES = 4

DESCRIPTION = "Antenna two-way gain variation due to the

effect of spacecraft roll and orientation of

the spacecraft high gain antenna and solar

panels." END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = ECHO_SAMPLES_REAL

COLUMN_NUMBER = 59

DATA_TYPE = PC_REAL

START_BYTE = 195

BYTES = 2668

ITEMS = 667

ITEM_BYTES = 4

DESCRIPTION = "Real part of the complex processed echo. Time

distance between echo samples is 0.075

microseconds."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = ECHO_SAMPLES_IMAGINARY

COLUMN_NUMBER = 60

DATA_TYPE = PC_REAL

START_BYTE = 2863

BYTES = 2668

ITEMS = 667

ITEM_BYTES = 4

DESCRIPTION = "Imaginary part of the complex processed echo.

Time distance between echo samples is 0.075

microseconds."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = N_PRE

COLUMN_NUMBER = 61

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 5531

BYTES = 2

DESCRIPTION = "Number of pre-summed echoes within the RDR

processor, i.e. oversampling factor of the

estimated Doppler bandwidth for the processed

data block."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = BLOCK_NR

COLUMN_NUMBER = 62

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 5533

BYTES = 2

DESCRIPTION = "Reference number of the processed data

block."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = BLOCK_ROWS

COLUMN_NUMBER = 63

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 5535

BYTES = 2

DESCRIPTION = "Number of echoes within a data block."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = DOPPLER_BW

COLUMN_NUMBER = 64

DATA_TYPE = PC_REAL

START_BYTE = 5537

BYTES = 4

UNIT = HERTZ

DESCRIPTION = "Estimated Doppler bandwidth of the processed

data block."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = DOPPLER_CENTROID

COLUMN_NUMBER = 65

DATA_TYPE = PC_REAL

START_BYTE = 5541

BYTES = 4

UNIT = HERTZ

DESCRIPTION = "Estimated Doppler centroid of the processed

data block."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = AZ_TIME_SPACING

COLUMN_NUMBER = 66

DATA_TYPE = PC_REAL

START_BYTE = 5545

BYTES = 4

UNIT = SECONDS

DESCRIPTION = "Time interval elapsing between the current

processed echo and the next."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = AZ_RES

COLUMN_NUMBER = 67

DATA_TYPE = PC_REAL

START_BYTE = 5549

BYTES = 4

UNIT = METER

DESCRIPTION = "Azimuth resolution, i.e. horizontal

resolution in the along-track direction."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = T_INT

COLUMN_NUMBER = 68

DATA_TYPE = PC_REAL

START_BYTE = 5553

BYTES = 4

UNIT = MICROSECOND

DESCRIPTION = "Integration time, i.e. duration of

acquisition of the processed data block."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = AVG_TAN_VELOCITY

COLUMN_NUMBER = 69

DATA_TYPE = PC_REAL

START_BYTE = 5557

BYTES = 4

UNIT = "KILOMETER/SECOND"

DESCRIPTION = "Effective tangential velocity of the

spacecraft as derived from Doppler centroid

estimation."

OBJECT = COLUMN

NAME = RANGE_SHIFT

COLUMN_NUMBER = 70

DATA_TYPE = LSB_INTEGER

START_BYTE = 5561

BYTES = 2

DESCRIPTION = "relative shift of the echo with respect to the

value of the MRO:RADARGRAM_RETURN_INTERVAL

reported in the data product label. This time

shift is expressed in terms of number of echo

samples. Time distance between echo samples in

RDR data products is 0.075 microseconds."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = EPHEMERIS_TIME

COLUMN_NUMBER = 71

DATA_TYPE = PC_REAL

START_BYTE = 5563

BYTES = 8

UNIT = SECOND

DESCRIPTION = "Seconds elapsed since Jan, 1, 2000, 12:00 UTC

corresponding to SCET_BLOCK."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = GEOMETRY_EPOCH

COLUMN_NUMBER = 72

DATA_TYPE = DATE

START_BYTE = 5571

BYTES = 23

DESCRIPTION = "Time, corresponding to SCET_BLOCK, at which

the geometrical and position parameters are

computed, expressed in UTC."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = SOLAR_LONGITUDE

COLUMN_NUMBER = 73

DATA_TYPE = PC_REAL

START_BYTE = 5594

BYTES = 8

UNIT = DEGREE

DESCRIPTION = "Value of the angle between the body-Sun line

at the time of interest and the body-Sun line

at the vernal equinox. This provides a measure

of season on a target body, with values of 0

to 90 degrees representing northern spring, 90

to 180 degrees representing northern summer,

180 to 270 degrees representing northern

autumn and 270 to 360 degrees representing

northern winter."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = ORBIT_NUMBER

COLUMN_NUMBER = 74

DATA_TYPE = LSB_INTEGER

START_BYTE = 5602

BYTES = 4

DESCRIPTION = "Number of the orbital revolution of the

spacecraft around Mars."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = MARS_SC_POSITION_VECTOR

COLUMN_NUMBER = 75

DATA_TYPE = PC_REAL

START_BYTE = 5606

BYTES = 24

ITEMS = 3

ITEM_BYTES = 8

UNIT = KILOMETER

DESCRIPTION = "Components of the position vector from Mars

center to the spacecraft expressed in the

planetocentric IAU 2000 reference frame, and

corrected for light time and stellar

aberration."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = SPACECRAFT_ALTITUDE

COLUMN_NUMBER = 76

DATA_TYPE = PC_REAL

START_BYTE = 5630

BYTES = 8

UNIT = KILOMETER

DESCRIPTION = "distance from the spacecraft to the IAU 2000

Mars ellipsoid measured normal to the

surface."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = SUB_SC_EAST_LONGITUDE

COLUMN_NUMBER = 77

DATA_TYPE = PC_REAL

START_BYTE = 5638

BYTES = 8

UNIT = DEGREE

DESCRIPTION = "IAU 2000 longitude of the sub spacecraft point

that is the point on Mars that lies directly

beneath the spacecraft."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = SUB_SC_PLANETOCENTRIC_LATITUDE

COLUMN_NUMBER = 78

DATA_TYPE = PC_REAL

START_BYTE = 5646

BYTES = 8

UNIT = DEGREE

DESCRIPTION = "IAU 2000 planetocentric latitude of the sub

spacecraft point that is the point on Mars

that lies directly beneath the spacecraft."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = SUB_SC_PLANETOGRAPHIC_LATITUDE

COLUMN_NUMBER = 79

DATA_TYPE = PC_REAL

START_BYTE = 5654

BYTES = 8

UNIT = DEGREE

DESCRIPTION = "IAU 2000 planetographic latitude of the sub

spacecraft point that is the point on Mars

that lies directly beneath the spacecraft."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = MARS_SC_VELOCITY_VECTOR

COLUMN_NUMBER = 80

DATA_TYPE = PC_REAL

START_BYTE = 5662

BYTES = 24

ITEMS = 3

ITEM_BYTES = 8

UNIT = "KILOMETER/SECOND"

DESCRIPTION = "Components of the velocity vector of the

spacecraft w.r.t. the center of Mars expressed

in the planetocentric IAU 2000 reference

frame, and corrected for light time and

stellar aberration."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = MARS_SC_RADIAL_VELOCITY

COLUMN_NUMBER = 81

DATA_TYPE = PC_REAL

START_BYTE = 5686

BYTES = 8

UNIT = "KILOMETER/SECOND"

DESCRIPTION = "Radial component of the velocity vector of the

spacecraft w.r.t. the center of Mars expressed

in the planetocentric IAU 2000 reference

frame, and corrected for light time and

stellar aberration."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = MARS_SC_TANGENTIAL_VELOCITY

COLUMN_NUMBER = 82

DATA_TYPE = PC_REAL

START_BYTE = 5694

BYTES = 8

UNIT = "KILOMETER/SECOND"

DESCRIPTION = "Tangential component of the velocity vector of

the spacecraft w.r.t. the center of Mars

expressed in the planetocentric IAU 2000

reference frame, and corrected for light time

and stellar aberration."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = LOCAL_TRUE_SOLAR_TIME

COLUMN_NUMBER = 83

DATA_TYPE = PC_REAL

START_BYTE = 5702

BYTES = 8

UNIT = "DECIMAL HOUR"

DESCRIPTION = "Angle between the meridian passing through the

sub-spacecraft point and the meridian passing

through the subsolar point of Mars, expressed

on a '24 hour' clock. 12.000 corresponds to an

angle of 0 degrees, while 00.000 corresponds

to an angle of 180 degrees."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = SOLAR_ZENITH_ANGLE

COLUMN_NUMBER = 84

DATA_TYPE = PC_REAL

START_BYTE = 5710

BYTES = 8

UNIT = DEGREE

DESCRIPTION = "Angle between the nadir at the sub-spacecraft

point and a vector from the sub-spacecraft

point to the Sun."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = SC_PITCH_ANGLE

COLUMN_NUMBER = 85

DATA_TYPE = PC_REAL

START_BYTE = 5718

BYTES = 8

UNIT = DEGREE

DESCRIPTION = "Spacecraft pitch angle in the reference frame

with the Z axis co-aligned with the center of

Mars - spacecraft position vector and the X

axis in the plane containing the Z axis and

the spacecraft velocity vector w.r.t. Mars."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = SC_YAW_ANGLE

COLUMN_NUMBER = 86

DATA_TYPE = PC_REAL

START_BYTE = 5726

BYTES = 8

UNIT = DEGREE

DESCRIPTION = "Spacecraft yaw angle in the reference frame

with the Z axis co-aligned with the center of

Mars - spacecraft position vector and the X

axis in the plane containing the Z axis and

the spacecraft velocity vector w.r.t. Mars."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = SC_ROLL_ANGLE

COLUMN_NUMBER = 87

DATA_TYPE = PC_REAL

START_BYTE = 5734

BYTES = 8

UNIT = DEGREE

DESCRIPTION = "Spacecraft roll angle in the reference frame

with the Z axis co-aligned with the center of

Mars - spacecraft position vector and the X

axis in the plane containing the Z axis and

the spacecraft velocity vector w.r.t. Mars."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = MRO_SAMX_INNER_GIMBAL_ANGLE

COLUMN_NUMBER = 88

DATA_TYPE = PC_REAL

START_BYTE = 5742

BYTES = 8

UNIT = DEGREE

DESCRIPTION = "Inner gimbal angle of the MRO solar array in

the -X direction."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = MRO_SAMX_OUTER_GIMBAL_ANGLE

COLUMN_NUMBER = 89

DATA_TYPE = PC_REAL

START_BYTE = 5750

BYTES = 8

UNIT = DEGREE

DESCRIPTION = "Outer gimbal angle of the MRO solar array in

the -X direction."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = MRO_SAPX_INNER_GIMBAL_ANGLE

COLUMN_NUMBER = 90

DATA_TYPE = PC_REAL

START_BYTE = 5758

BYTES = 8

UNIT = DEGREE

DESCRIPTION = "Inner gimbal angle of the MRO solar array in

the +X direction."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = MRO_SAPX_OUTER_GIMBAL_ANGLE

COLUMN_NUMBER = 91

DATA_TYPE = PC_REAL

START_BYTE = 5766

BYTES = 8

UNIT = DEGREE

DESCRIPTION = "Outer gimbal angle of the MRO solar array in

the +X direction."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = MRO_HGA_INNER_GIMBAL_ANGLE

COLUMN_NUMBER = 92

DATA_TYPE = PC_REAL

START_BYTE = 5774

BYTES = 8

UNIT = DEGREE

DESCRIPTION = "Inner gimbal angle of the MRO high gain

antenna."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = MRO_HGA_OUTER_GIMBAL_ANGLE

COLUMN_NUMBER = 93

DATA_TYPE = PC_REAL

START_BYTE = 5782

BYTES = 8

UNIT = DEGREE

DESCRIPTION = "Outer gimbal angle of the MRO high gain

antenna."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = DES_TEMP

COLUMN_NUMBER = 94

DATA_TYPE = PC_REAL

START_BYTE = 5790

BYTES = 4

UNIT = CELSIUS

DESCRIPTION = "Internal DES Temperature."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = DES_5V

COLUMN_NUMBER = 95

DATA_TYPE = PC_REAL

START_BYTE = 5794

BYTES = 4

UNIT = VOLT

DESCRIPTION = "DES Digital 5V Supply."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = DES_12V

COLUMN_NUMBER = 96

DATA_TYPE = PC_REAL

START_BYTE = 5798

BYTES = 4

UNIT = VOLT

DESCRIPTION = "DES Analog 12V Supply."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = DES_2V5

COLUMN_NUMBER = 97

DATA_TYPE = PC_REAL

START_BYTE = 5802

BYTES = 4

UNIT = VOLT

DESCRIPTION = "DES Digital 2V5 Supply."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = RX_TEMP

COLUMN_NUMBER = 98

DATA_TYPE = PC_REAL

START_BYTE = 5806

BYTES = 4

UNIT = CELSIUS

DESCRIPTION = "Internal RX Temperature."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = TX_TEMP

COLUMN_NUMBER = 99

DATA_TYPE = PC_REAL

START_BYTE = 5810

BYTES = 4

UNIT = CELSIUS

DESCRIPTION = "Internal TFE Temperature"

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = TX_LEV

COLUMN_NUMBER = 100

DATA_TYPE = PC_REAL

START_BYTE = 5814

BYTES = 4

UNIT = WATT

DESCRIPTION = "TFE output power level."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = TX_CURR

COLUMN_NUMBER = 101

DATA_TYPE = PC_REAL

START_BYTE = 5818

BYTES = 4

UNIT = AMPERE

DESCRIPTION = "TFE primary power current (measured internally

to TFE)."

END_OBJECT = COLUMN

OBJECT = COLUMN

NAME = QUALITY_CODE

COLUMN_NUMBER = 102

DATA_TYPE = LSB_UNSIGNED_INTEGER

START_BYTE = 5822

BYTES = 1

DESCRIPTION = "This flag is set to 1 if there are problems

with the processed echo."

END_OBJECT = COLUMN

Date	Description	Sections affected
28 April 2006	Version 0.1 Initial Draft by R. Orosei	All
30 July 2007	Version 1.0 revised by R. Orosei	All

Item	Description	Affected sections