MARS EXPRESS – MARSIS TO PLANETARY SCIENCE ARCHIVE INTERFACE CONTROL DOCUMENT INFOCOM TECHNICAL REPORT NO. 024.005.2003 ISSUE 3.2 MAY 28, 2008 Prepared by: Roberto Orosei Richard L. Huff Anton B. Ivanov Raffaella Noschese Approved by: Giovanni Picardi Jeffrey J. Plaut Distribution List ------------------------------------------------------------------ |Recipient| Organisation | ------------------------------------------------------------------ | | | ------------------------------------------------------------------ | | | ------------------------------------------------------------------ Change Log ---------------------------------------------------------------------- |Date |Sections Changed | Reasons for Change | ---------------------------------------------------------------------- |24-09-2007 |Section 3.4.3.2 |Completed description of the INDEX| | | |directory. | ----------------------------------------------------------------------- |26-11-2007 |All sections |Modifications following review | | | |by PSA | ------------------------------------------------------------------------ Table of Contents 1 INTRODUCTION 6 1.1 PURPOSE AND SCOPE 6 1.2 ARCHIVING AUTHORITIES 6 1.3 CONTENTS 6 1.4 INTENDED READERSHIP 6 1.5 APPLICABLE DOCUMENTS 6 1.6 RELATIONSHIPS TO OTHER INTERFACES 7 1.7 ACRONYMS AND ABBREVIATIONS 7 2 OVERVIEW OF INSTRUMENT DESIGN, DATA HANDLING PROCESS AND PRODUCT GENERATION 9 2.1 SCIENTIFIC OBJECTIVES 9 2.2 INSTRUMENT DESCRIPTION 10 2.2.1 Antennas 10 2.2.2 Frequencies 10 2.2.3 Transmitted Waveforms 10 2.3 ON-BOARD PROCESSING 11 2.3.1 Analogue-to-Digital Conversion 11 2.3.2 I/Q Synthesis 11 2.3.3 Doppler Processing 11 2.3.4 Range Processing 11 2.3.5 Multi-look 12 2.3.6 Data Compression 12 2.3.7 Individual Echoes Collection 12 2.3.8 Data Storage in Flash Memory 12 2.3.9 Acquisition Phase 13 2.3.10 Active Ionosphere Sounding 14 2.3.11 Passive Ionosphere Sounding 14 2.3.12 Operative Modes 14 2.4 INSTRUMENT OPERATION 15 2.4.1 Operation Sequence Table 15 2.4.2 Parameter Table 16 2.5 DATA DESCRIPTION 17 2.5.1 Frames 17 2.5.2 Time Series and Spectra 18 2.5.3 Sample Types 18 2.6 DATA STRUCTURE 19 2.6.1 Frame Structure 19 2.6.2 Ancillary Data Structure by Instrument Mode 20 2.6.3 Scientific Data Structure by Instrument Mode 20 2.6.4 Individual Echoes 21 2.6.5 Flash Memory 21 2.7 DATA HANDLING PROCESS 23 2.8 PRODUCT GENERATION 24 2.9 OVERVIEW OF DATA PRODUCTS 25 2.9.1 Pre-Flight Data Products 25 2.9.2 Sub-System Tests 25 2.9.3 Instrument Calibrations 25 2.9.4 In-Flight Data Products 25 2.9.5 Ancillary Data Usage 25 3 ARCHIVE FORMAT AND CONTENT 26 3.1 FORMAT AND CONVENTIONS 26 3.1.1 Deliveries and Archive Volume Format 26 3.1.2 Data Directory Naming Convention 26 3.1.3 File Naming Convention 26 3.1.4 Special observation : Phobos 27 3.2 STANDARDS USED IN DATA PRODUCT GENERATION 28 3.2.1 PDS Standards 28 3.2.2 Time Standards 28 3.2.3 Reference Systems 29 3.3 DATA VALIDATION 29 3.4 CONTENT 29 3.4.1 Volume Set 29 3.4.2 Data Set 29 3.4.3 Directories 31 4 DETAILED INTERFACE SPECIFICATIONS 34 4.1 STRUCTURE AND ORGANISATION OVERVIEW 34 4.2 EXPERIMENT DATA RECORD DATA SET: DEFINITION AND CONTENT 35 4.3 EXPERIMENT DATA RECORD DATA PRODUCT DESIGN 36 4.3.1 AIS_EDR, CAL_EDR, RXO_EDR and SSx_yyy_CMP_EDR Data Product Design 36 4.3.2 SSx_yyy_IND_EDR Data Product Design 37 4.3.3 SSx_yyy_UNC_EDR data products 38 4.3.4 SSx_yyy_RAW_EDR Data Product Design 38 4.4 REDUCED DATA RECORD SUBSURFACE DATA SET: DEFINITION AND CONTENT 39 4.5 REDUCED DATA RECORD SUBSURFACE DATA PRODUCT DESIGN 40 4.5.1 SSx_RDR Data Product Design 40 4.5.2 USING SSX_RDR DATA PRODUCTS 41 APPENDIXES 45 A EXAMPLE PDS LABEL FOR MARSIS DATA PRODUCT FILES 45 B ANCILLARY DATA 47 C AUXILIARY DATA STRUCTURES 48 D SCIENTIFIC DATA STRUCTURE 59 E KEYWORD LISTING FOR GEO FILES 60 F KEYWORD LISTING FOR PDS LABELS 62 1 INTRODUCTION 1.1 PURPOSE AND SCOPE The purpose of this EAICD (Experimenter to Archive Interface Control Document) is two folds. First it provides users of the MARSIS instrument with detailed description of the product and a description of how it was generated, including data sources and destinations. Secondly, it is the official interface between the MARSIS team and the Planetary Science Archive (PSA) of ESA. This document is also intended to provide user specification to the developers of the MARSIS data processing software. The specifications in this document apply to all MARSIS Data Products that are produced during the Mars Express mission through the MARSIS Principal Investigator institution, namely the INFOCOM Department of the University of Rome “La Sapienza”. 1.2 ARCHIVING AUTHORITIES The Planetary Data System Standard is used as archiving standard by NASA for U.S. planetary missions, and is implemented by PDS and ESA for European planetary missions. ESA implements an online science archive, the PSA, to support and ease data ingestion and to offer additional services to the scientific user community and science operations teams such as * search queries that allow searches across instruments, missions and scientific disciplines; * several data delivery options as direct download of data products, linked files and data sets or ftp download of data products, linked files and data sets. 1.3 CONTENTS This document describes the data flow of the MARSIS instrument on Mars Express from the S/C until the insertion into the PSA for ESA. It includes information on how data were processed, formatted, labelled and uniquely identified. The document discusses general naming schemes for data volumes, data sets, data and label files. Standards used to generate the product are explained. Software that may be used to access the product is described. The design of the data set structure and of the data product is provided. Examples of these and further explanatory material are given in the appendixes. 1.4 INTENDED READERSHIP The staff of archiving authority (Planetary Data System for NASA and Planetary Science Archive for ESA) design team and any potential user of the MARSIS data. Typically, these individuals would be software engineers, data analysts, or planetary scientists. 1.5 APPLICABLE DOCUMENTS [AD01] MARSIS Flight User Manual, Issue 3, INFOCOM ID-MAR-0008-INF, 18 December 2003 [AD02] MARSIS DES Operation Sequence Table, Issue 1, LABEN TL 19392, 29 January 2003 [AD03] MARSIS DES Parameters Table, Issue 3, LABEN TL 18546 [AD04] MARSIS Packet Structure Definition, Issue 6, LABEN TL 16927, 3 February 2003 [AD05] Mars Exploration Rover Project Planetary Constants and Models, Version 2, JPL IOM 312.F-02-003, 4 October 2002 [AD06] Mars Express Archive Generation, Validation and Transfer Plan, Revision 1.0, ESA-MEX-TN-4009, 21 June 2001 [AD07] Mars Express Auxiliary Data Conversion into SPICE Kernels and Distribution, Issue 1.0, MEX-EST-PL-10210, 20 September 2002 [AD08] Mars Express Master Science Plan, Draft 1.0, MEX-EST-PL-11912, 12 May 2003 [AD09] Planetary Data System Data Preparation Workbook, Version 3.1, JPL D-7669, Part 1, 17 February 1995 [AD10] Planetary Data System Standards Reference, Version 3.6, JPL D-7669, Part 2, 3 August 2003 [AD11] Planetary Science Data Dictionary, Revision D, JPL D-7116, 15 July 1996 [AD12] Planetary Science Archive - Experiment Data Release Concept, Issue 1.14, SOP-RSSD-TN-015, 22 October 2004 [AD13] Planetary Science Archive - Required Keywords, Issue 1.4, SOP-RSSD-LI- 004, 27 January 2004 [AD14] Planetary Science Data Archive Technical Note - Geometry and Position Information, Issue 3, Revision 4, SOP-RSSD-TN-010, 9 November 2004 1.6 RELATIONSHIPS TO OTHER INTERFACES Other interfaces that have an impact on MARSIS data set generation, packaging, distribution, and documentation include: -| MARSIS calibration data/software: reprocessing of calibration data or a change to the software may have a direct impact on the generation of the data sets. -| Release Concept: Changes would directly impact data set generation, packaging, distribution, and documentation. -| PSA Archive Delivery Requirements: Any delivery requirement changes will directly impact the MARSIS datasets. -| SPICE Data: Changes to these data will affect any geometry information contained in data products and geometry index files. -| Geolib and SPICE Software Libraries: As above. -| PVV Software: Changes to this validation software could result in changes to labels or data sets. 1.7 ACRONYMS AND ABBREVIATIONS ACQ Acquisition phase AIS Active Ionosphere Sounding mode ASDC ASI Science Data ASI Agenzia Spaziale Italiana (Italian Space Agency) CAL Calibration mode CD-ROM Compact Disk - Read Only Memory CMP Compressed data DCG Digital Chirp Generator DVD Digital Versatile Disk EAICD Experimenter to Planetary Science Archive Interface Control Document ESA European Space Agency ESOC European Space Operation Centre ESTEC European Space Technology Centre FFT Fast Fourier Transform IND Individual Echoes LOL Loss of Lock MARSIS Mars Advanced Radar for Subsurface and Ionosphere Sounding MEX Mars Express PSA Planetary Science Archive NPM Noise Power Measurement OST Operation Sequence Table PIS Passive Ionosphere Sounding mode PT Parameter Table PVV PSA Volume Verifier RAW Raw data RXO Receive Only mode S/C Spacecraft SCET Spacecraft Elapsed Time SS1-SS5 Subsurface Sounding modes 1-5 TC Telecommand TM Telemetry TRK Tracking phase UNC Uncompressed data 2 OVERVIEW OF INSTRUMENT DESIGN, DATA HANDLING PROCESS AND PRODUCT GENERATION 2.1 SCIENTIFIC OBJECTIVES The primary objective of MARSIS is to map the distribution of water, both liquid and solid, in the upper portions of the crust of Mars. Detection of such reservoirs of water will address key issues in the hydrologic, geologic, climatic and possible biologic evolution of Mars, including: -| the current and past global inventory of water, -| mechanisms of transport and storage of water, -| the role of liquid water and ice in shaping the landscape of Mars, -| the stability of liquid water and ice at the surface as an indication of climatic conditions, -| the implications of the hydrologic history for the evolution of possible Martian ecosystems. Three secondary objectives are defined for the MARSIS experiment: subsurface geologic probing, surface characterisation, and ionosphere sounding. 1. The first objective consists in probing the subsurface of Mars, to characterise and map geologic units and structures in the third dimension. Detection of subsurface geologic boundaries will allow: -| determination of the thickness and properties of sedimentary units, such as outflow channel deposits and possible lacustrine materials, -| mapping of the thickness of polar layered deposits, and measurements of their physical properties that are likely to record climate variations, -| an inventory of mobile materials such as dust and sand deposits, -| study of volcanic stratigraphy to understand eruptive processes and crust evolution, -| mapping of subsurface geologic structures (e.g., folds and faults) to understand tectonics of the Martian crust and address such issues as the nature of the global dichotomy and the history of the Tharsis plateau. 2. An additional secondary objective consists in acquiring information about the surface of Mars. The specific goals of this part of the experiment are to characterise the roughness of the surface at scales of tens of meters to kilometres, to measure the radar reflection coefficient of the surface and to generate a topographic map of the surface at approximately 15-30 kilometres lateral resolution. These data sets can be used to address a wide range of scientific questions, including: -| the large-scale surface roughness of various geologic units, and implications for the processes of emplacement and modification, -| determination of the bulk density (providing constraints on the composition) of upper crust materials, -| a global topographic data set to complement those derived by other techniques. 3. A final secondary objective is to use MARSIS as an ionosphere sounder to characterize the interactions of the solar wind with the ionosphere and upper atmosphere of Mars. Radar studies of the ionosphere will allow: -| global measurements of the ionosphere electron density, -| investigation of the influence of the Sun and the solar wind on the electron density. Although the instrument is expected to detect dielectric discontinuities in the Mars subsurface, it may not always provide precise indications of their nature. Unambiguous detection of liquid water and ice reservoirs will require mapping the presence of discontinuities over the surface of the planet, and studying their correlation with depth, latitude, surface topography and local geologic units. Sounding data at multiple frequencies will be used to characterise the dielectric discontinuities, and to help distinguish possible water-related interfaces from lithologic ones. 2.2 INSTRUMENT DESCRIPTION MARSIS is a multi-frequency nadir-looking pulse-limited radar sounder and altimeter, which uses synthetic aperture techniques and a secondary receiving antenna to enhance subsurface reflections. MARSIS can be effectively operated at any altitude lower than 800 km in subsurface sounding mode, and below 1200 km in ionosphere sounding mode. The instrument consists of two antenna assemblies and an electronics assembly. Maximum penetration depths are achieved at the lowest frequencies, and penetration will be in the order of a few kilometers , depending on the nature of the material being sounded. On the dayside of Mars, the solar wind-induced ionosphere does not allow subsurface sounding at frequencies below approximately 3.5 MHz, as the signal would be reflected back at the radar without reaching the surface. To achieve greater subsurface probing depths, operations on the night side of Mars are thus strongly preferred. For subsurface sounding, a “chirp” signal will be generated and transmitted at each operating frequency for a period of about 250 microseconds. The instrument then switches to a receive mode and records the echoes from the surface and subsurface. The total transmit-receive cycle lasts a few milliseconds, depending on altitude. The received signals are passed to an analogue-to-digital converter and compressed in range and azimuth. The azimuth integration accumulates a few seconds of data and results in an along-track footprint size of 10 km. The cross-track footprint size is on the order of 20 km. Digital on-board processing greatly reduces the output data rate to 75 kilobits per second or less. For each along-track footprint, echo profiles will show the received power as a function of time delay, with a depth resolution of 50-100 m, depending on the wave propagation speed in the crust. Active ionosphere sounding consists of transmitting a pulse from MARSIS at a frequency f, and then measuring the intensity of the reflected radar echo as a function of time delay. For a radar signal incident on a horizontally stratified ionosphere, a strong specular reflection occurs from the level where the wave frequency is equal to the electron plasma frequency. By measuring the time delay for the reflected signal (controlled by the group delay), the plasma frequency, and therefore the electron density can be derived as a function of height. The frequency of the transmitted pulse is systematically stepped to yield time delay as a function of frequency. 2.2.1 ANTENNAS MARSIS antenna assembly consists of two antennas, a dipole and a monopole. The primary dipole antenna, parallel to the surface and to the direction of spacecraft motion, is used for transmission of pulses and for reception of pulse echoes reflected by the Martian surface, subsurface and ionosphere. The secondary monopole antenna, oriented along the nadir, has a null in the nadir direction, and it is thus sensitive to off-nadir surface returns. Such surface returns could mask subsurface echoes arriving at the same time, and are thus an undesired contribution to the received echoes (“clutter”): the monopole antenna is used in subsurface sounding to remove clutter from the signal received by the dipole. 2.2.2 FREQUENCIES MARSIS is an ultra-wideband radar sounder capable of transmitting at frequencies ranging from approximately 10 kHz up to 5.5 MHz. For subsurface sounding, the transmitted signal has a 1 MHz bandwidth, centred at either 1.8 MHz, 3 MHz, 4 MHz or 5 MHz. For ionosphere sounding, transmission frequencies will range from about 10 KHz to 5.5. MHz, with a transmitted bandwidth of 10.937 kHz and an identical frequency granularity. 2.2.3 TRANSMITTED WAVEFORMS For subsurface sounding, the transmitted waveform 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 to achieve good signal-to-noise ratio the pulse would require a peak power exceeding the limits imposed by the mission design. The chirp allows a resolution that depends on the bandwidth of the pulse rather than on its duration, but requires processing of the received signal: with a bandwidth B, the approximate time resolution of the output pulse, after processing, is 1/B. MARSIS is capable of transmitting two chirps having different frequencies in close succession, thus allowing effective simultaneous subsurface sounding at two different bands. Also in subsurface sounding mode, MARSIS can transmit a train of four short unmodulated pulses: with this transmission scheme, time resolution is determined by the duration of the signal, while the signal-to-noise ratio is increased, compared to the echo from a single pulse, by summing the four pulse echoes. For ionosphere sounding, the transmitted waveform is simply a short pulse at a constant frequency, resulting in an almost monochromatic tone. 2.3 ON-BOARD PROCESSING Due to limits in permitted data rate for data transmission between the instrument and the solid state mass memory of the spacecraft, and constraints on the data volume that can be down-linked to Earth, most data processing will be performed within the instrument itself. Major tasks performed by MARSIS digital processing unit are Doppler processing, range processing, surface echo acquisition and tracking, and multi-looking. Different operative modes will require all, some or none of these capabilities: this section aims at providing a general description of the working of on-board processing from a subsurface sounding perspective, but differences with other operative modes will be noted as well. 2.3.1 ANALOGUE-TO-DIGITAL CONVERSION Any signal received from the antennas is converted to digital numbers by means of an analogue-to-digital converter, sampling the waveform at a frequency of 2.8 MHz. To adequately represent the characteristics of a signal containing frequencies higher than the sampling frequency, as for example in the case of subsurface echoes at bands centred at 3 MHz, 4 MHz or 5 MHz, the signal is lowered to a carrier frequency of 0.7 MHz through a mixer before sampling takes place. 2.3.2 I/Q SYNTHESIS Digital numbers produced by the signal sampling process are represented as 1-byte signed integers, which, aside from a scaling factor, are actual voltages from the real signal. For a more convenient numerical treatment of the signal during digital processing, such samples are converted to single-precision complex numbers (four bytes for both the real and imaginary part) by means of a numerical interpolation scheme called I/Q synthesis, which exploits the fact that real functions have symmetric Fourier transforms to represent signal properties by means of a complex function with only half of the samples of the original real function. 2.3.3 DOPPLER PROCESSING Conceptually, Doppler processing of pulse echoes consists in artificially adding a delay, corresponding to a phase shift of the complex signal, to the samples of each pulse, and then in summing the samples so as to allow the constructive sum of the signal component whose delay (phase shift) from one pulse to the next corresponds to a desired direction (usually nadir or close to nadir). This is called also synthetic aperture processing, and is used to improve both horizontal resolution in the along-track direction and signal-to-noise ratio: horizontal resolution becomes that of an equivalent antenna whose length is equal to the segment of the spacecraft trajectory over which pulse echoes are summed coherently, whereas signal-to-noise ratio improves by a factor equal to the number of coherently summed pulses. In MARSIS subsurface sounding, the same group of echoes undergoing synthetic aperture processing can be used to focus multiple points on the surface, by changing the phase shift from echo to echo so as to produce constructive interference in different directions. The resulting processed echoes are also called Doppler filters. 2.3.4 RANGE PROCESSING Range processing consists in computing the correlation between the transmitted pulse and received echoes. If the transmitted amplitude is constant during the pulse, the correlation with an echo identical to the transmitted signal takes the form of a (sin x)/x pulse, whose amplitude is Bt times the amplitude of the input signal (t is the chirp duration). This process, called also range compression, is performed on ground for most subsurface sounding modes, on the digitally sampled data, to properly compensate ionospheric effects: accurate coherent pulse compression requires in fact detailed knowledge of the modulation of the returning signals, whose phase structure is distorted in their (two-way) propagation through the ionosphere. 2.3.5 MULTI-LOOK Multi-look processing is the non-coherent sum of echoes (that is, phase information in the complex signal is ignored), after both Doppler and range processing, performed to increase the signal-to-noise ratio and reduce speckle, this last being the effect of random fluctuations in the return signal observed from an area-extensive target represented by one pixel. Because this process requires that multiple observations of the same area are available for the summing, it spans across several frames in which the same spot on the surface is observed at slightly different angles of incidence in different adjacent synthetic apertures. 2.3.6 DATA COMPRESSION After the completion of on-board processing, to conveniently reduce data volume, digitalized radar echoes can be converted from four-byte real numbers to one-byte integer numbers by extracting and storing the exponent of the sample with the largest absolute value, and by normalizing the entire echo by that exponent. Because the mantissa of a four-byte real number is 23 bits long instead of the 8 bits available in a single-byte representation, data compression causes a loss of precision: this, however, is deemed to be negligible, as the available dynamic range for signal representation is estimated to be above the signal-to-noise ratio. At the end of the processing described in the previous subsection, compression is performed by first calculating the highest exponent in the numerical vector of real numbers containing the echo. Such exponent is reported with 8-bit precision in the auxiliary data accompanying the frame to which the echo belongs. Then, the vector is normalized to the maximum exponent by shifting to the right the bits of the mantissa of each real sample by a number of positions equal to the difference between the sample exponent and the maximum exponent: this causes the loss of the rightmost bits of the sample mantissa, as only the first 8 bits remaining after the shift are stored for download. It is to be noted that the so-called hidden bit in the IEEE 4-byte representation of a real number is accounted for in the right shifting of the mantissa bits. 2.3.7 INDIVIDUAL ECHOES COLLECTION MARSIS can be programmed to skip all on-board processing and down-link raw data as they come out of the analogue-to-digital converter. This option allows the storage of a number of individual echoes in a memory buffer, for subsequent transmission as science telemetry packets. Because the data production rate of individual echoes is much higher than the data rate possible on the spacecraft data bus, raw data are acquired only for very limited time intervals, and are then transferred over a much longer time span from MARSIS to the spacecraft mass memory. It is important to remember that individual echoes collection is possible only during subsurface sounding, and that such echoes always come in addition to the processed data, which are transmitted to the ground in any case. Thus, individual echoes are the unprocessed version of data which are also received, after processing, as part of the scientific telemetry of the instrument. 2.3.8 DATA STORAGE IN FLASH MEMORY Another option available in MARSIS for the retrieval of raw data is the use of flash memory chips within the instrument itself. Collection of echoes from the analogue-to-digital converter is similar to that of individual echoes, but data are stored in a different physical device, a long-term memory that can be read and cleared for subsequent overwriting only by means of a specific telecommand, which causes a dump of its entire content to the spacecraft on-board mass memory. Also, flash memory can be used to store processed data before the final step of data compression is performed: this option is used mainly to check if truncation of data precision is affecting the results. It is important to remember that storage of data in the flash memory is possible only during subsurface sounding, and that such data always come in addition to the processed data, which are transmitted to the ground in any case. Thus, the flash memory will contain unprocessed data which are also received, after processing, as part of the scientific telemetry of the instrument. Image.1 Conceptual diagram of MARSIS on-board processing during subsurface sounding. TM (20,3) is the normal scientific telemetry produced by the instrument during operation, while TM (6,6) is the telemetry produced by the instrument following a request to dump the flash memory. 2.3.9 ACQUISITION PHASE Subsurface sounding is critically dependent on an accurate knowledge of the time delay between transmission and reception to correctly perform the collection and sampling of echoes. Such delay is significantly affected by properties of the Martian ionosphere such as maximum plasma frequency and total electron content, about which very little information is available. MARSIS is thus capable of performing a preliminary determination of the two-way travel time of the transmitted pulse by means of a special way of operating called acquisition phase. Unless programmed to skip acquisition, whenever the instrument enters a new subsurface sounding sub-mode or uses a different frequency band, it starts transmitting a much longer pulse having a much smaller bandwidth (200 kHz), and collecting echoes over a much longer receiving window. During acquisition, on-board processing of the echoes is aimed at determining the time at which the received power is the greatest, under the assumption that such strong reflection is caused by the surface. Once successfully determined, this time is used to place the receiving window for subsequent sounding in the nominal way of operating, called tracking. During tracking, a check of the received power is continuously performed to determine if changes of the ionosphere have put the echo outside the receiving window: in such instance, the instrument reverts to acquisition until a new time delay between transmission and reception can be determined. 2.3.10 ACTIVE IONOSPHERE SOUNDING Each active ionosphere sounding observation consists in transmitting and receiving echoes from 160 short, narrow-banded pulses at different frequencies. When a pulse reaches the layer in the ionosphere where the plasma frequency is equal to its frequency, it is reflected back at the radar. Because the detailed variation of the plasma frequency in the ionosphere is unknown, the time delay of each echo cannot be predicted, and it is thus necessary to have an extremely long receiving window to ensure that useful data are collected. To reduce data volume, the receiving window is divided into 80 segments, each of which is as long as the transmitted pulse: power received within each segment is computed, and the result is stored for down-link. Even after this processing, the resulting data rate is still too high for the spacecraft data bus, and it is thus necessary to transfer ionosphere data from MARSIS to the spacecraft mass memory over a time span six times longer than the one used for their acquisition. 2.3.11 PASSIVE IONOSPHERE SOUNDING Passive ionosphere sounding is performed during every subsurface sounding observation, by opening the receiver and collecting the signal produced by the ionosphere plasma around the spacecraft. A weak, thermally excited emission line can often be detected in ionosphere plasmas at the electron plasma frequency: the spectrum of the recorded signal will thus allow the determination of the local electron density, as derived from the plasma frequency. Passive Ionosphere Sounding consists in acquiring signal samples, converting them to complex numbers through I/Q synthesis, performing an FFT on them and extracting the square modulus of the resulting spectrum. 2.3.12 OPERATIVE MODES In addition to subsurface and ionosphere sounding, MARSIS is capable of two more data collection modes that are not science-related, but are rather used for the testing of the instrument. Hardware calibration mode and receive-only mode are identical in their sequencing of data acquisition, differing only for the fact that in receive-only mode no pulses are actually transmitted. In both modes, 80 echoes are collected from both antennas at one of the frequency bands used in subsurface sounding, stored in a buffer as they come out of the analogue-to-digital converter, and, because the resulting data rate would be too high for the spacecraft data bus, transferred to the spacecraft mass memory over a time span eighty times longer than the one used for data acquisition. Because of the many possible options in programming the instrument, subsurface sounding has been specialized into five different sub-modes, each of which is characterized by a defined set of pulse transmission, echo reception and on-board processing choices. Their different characteristics, as well as those of all remaining operative modes, are summarized in the table below. Image 2. Characteristics of pulse transmission, echo reception and on- board processing for MARSIS operative modes. 2.4 INSTRUMENT OPERATION MARSIS has been designed to perform subsurface sounding at each orbit when the altitude is below 800 Km. A highly eccentric orbit such as the Mars Express orbit places the spacecraft within 800 Km from the surface for a period of about 26 minutes. This would allow mapping of about 100 degrees of arc on the surface of Mars each orbit, allowing extensive coverage at all latitudes within the nominal mission duration. To achieve this global coverage MARSIS has been designed to support both day side and night side operations, although performances are maximized during night time (solar zenith angle >90°), when the ionosphere plasma frequency drops off significantly and the lower frequency bands, which have greater subsurface penetration capability, can be used. Active Ionosphere Sounding will be also carried out by MARSIS at certain passes when the spacecraft is below 1200 Km of altitude, both during day and night time. The instrument is commanded by means of two tables, the Operations Sequence Table (OST) and the Parameters Table (PT), which are up-linked from ground as part of the instrument programming and commanding, and loaded in the instrument memory at switch-on. They are described below. 2.4.1 OPERATION SEQUENCE TABLE The OST contains commands, which specify selection of operative modes and their duration for the current orbit. Contents of the OST are prepared on the ground, based on the Science Team decisions on which antenna configuration (dipole only or dipole and monopole), frequency and mode duration to use in a particular part of the orbit. In addition, the OST contains necessary parameters to perform Passive Ionosphere Sounding, parameters for SS2 mode, transmission power, ground acquisition presets and flash memory management. The maximum number of rows in an OST is 512. It is possible to execute two tables during the same orbit, but this requires rebooting the instrument to force the upload of another OST. The following table contains a brief description of fields in the OST. For more information on these fields, refer to [AD02]. Image 3. Parameters and values contained in the Operation Sequence Table. 2.4.2 PARAMETER TABLE The Parameters Table specifies values that apply to all Operational Modes and to the general behaviour of the instrument. The Parameter Table is a permanent table that is stored in the MARSIS instrument, in contrast to the OST, which is uploaded for every orbit. This tables stores parameters necessary for MARSIS operations and on- board data processing. Values of parameter table are documented in [AD03]. Some values in the PT are physical constants (e.g. speed of light) and some (e.g. coefficients for range to surface, radial and tangential velocity polynomials) are later reported as part of the ancillary data accompanying scientific data. Contents of the PT that are relevant for on-board processing are reported in the ancillary data of the instrument. A default copy of the PT is maintained in a permanent memory area and it is loaded in the volatile portion of the memory upon instrument boot. During flight, it is possible to change or update the value of one or more parameters stored in the volatile copy of the PT, by means of a dedicated telecommand. It is also possible to update or change the value of parameters stored in the default copy of the PT, in the permanent memory, by means of the standard memory patch services. 2.5 DATA DESCRIPTION In this section, the organization of scientific data produced by MARSIS will be discussed; this is relevant for the use of low-level data products, because their structure is identical to that of the scientific telemetry down-linked from the instrument. MARSIS data are organized into groups of echoes called frames. A frame contains one or more echoes, with or without on-board processing. Each echo, depending on the kind of processing it underwent, is recorded either as a time series of signal samples, or as the complex spectrum of the signal itself produced by means of a FFT. Scientific data in a frame are complemented by a set of ancillary data, produced by the instrument and recording parameter values used in pulse transmission, echo reception and on-board processing. 2.5.1 FRAMES A frame is a collection of received echoes with or without on-board processing, together with instrument ancillary information, and constitutes a single observation of the instrument. The content of a frame depends on the operative mode of the instrument, and, for subsurface sounding only, on the state of the instrument (that is, if MARSIS was in acquisition or tracking phase) and on the processing path followed by the data (raw data in flash memory and individual echoes contain all echoes required for Doppler processing, while uncompressed data in flash memory and down-linked processed data contain only a fixed number of Doppler filters). Also, uncompressed data in flash memory and down-linked processed data frames contain Passive Ionosphere Sounding measurements. Furthermore, because the number of pulses used in Doppler processing is dependent on the altitude of the spacecraft (see [AD01]), frames of raw data in flash memory and individual echoes contain a variable number of echoes. Ancillary data, produced by the instrument to record parameter values used in pulse transmission, echo reception and on-board processing, are available for all data, but those stored in flash memory have only limited information available (see [AD04]). It is perhaps worth reminding, however, that data passing through flash memory are the raw form of data downloaded also in processed form, for which full ancillary data are available. The following table summarizes the structure of data frames according to instrument mode and state, and data processing form. Image 4. Structure of MARSIS data frames according to instrument mode and state, and data processing form. 2.5.2 TIME SERIES AND SPECTRA Within a frame, an echo is recorded either as a time series of signal samples, or as the complex spectrum of the signal itself produced by means of a FFT, depending on the kind of processing it underwent. Calibration, Receive Only, Subsurface Sounding SS2, and Individual Echoes and Raw Data from all Subsurface Sounding modes report time series of measured echoes. Subsurface Sounding modes SS1, SS3, SS4 and SS5, both in compressed and uncompressed form, report spectra that have been processed on board. Each spectrum contains 512 real and 512 imaginary values for each of the Doppler filters, ordered as separate vectors (that is, all real values are listed before all imaginary values). Active Ionosphere Sounding and Passive Ionosphere Sounding report spectral power, that is values of signal power as a function of frequency: thus, the phase information that would alow reconstruction of the received signal through an inverse FFT is not sent to ground. 2.5.3 SAMPLE TYPES Sample types inside a time series or spectrum depend on operative mode, instrument state and on-board processing. Table 3.5.3 - 1 describes all possible formats and lengths of individual samples. Image 5. Formats and lengths of individual samples in time series or spectra, according to operative mode, instrument state and data form. Data types are defined according to [AD10]. 2.6 DATA STRUCTURE In the following sections, details of the structure and organization of data,as they are produced by the instrument, will be provided. This information is relevant for lowest-level data products, as data files are built by collecting and ordering in time instrument data frames without further editing or modification. 2.6.1 FRAME STRUCTURE MARSIS data frames consist of up to two parts: the first contains ancillary data produced by the instrument, and used to interpret scientific data, and the second is science data themselves. Science data are organized into time series or spectra, and complex spectra are further subdivided into real and imaginary part. Time series or spectra within the scientific data of a frame are ordered according to the time of acquisition. For processed data of Subsurface Sounding modes, which are produced using all echoes acquired during a frame, time series or spectra are ordered first according to the antenna through which they were received, then by transmitted band, and finally by Doppler filter. Only exception is the Operative Mode SS2, where the signal is transmitted to the ground already compressed in time and also after a multi-looking processing. In this case the 512 samples represent the power of the signals obtained with two different frequencies. |------------------------------------------------------------------------ | MARSIS DATA FRAME (SS1 MODE) | ------------------------------------------------------------------------ |DIPOLE F1 | DIPOLE F2 | MONOPOLE F1 | MONOPOLE F2 | |Doppler | Doppler | Doppler | Doppler | |Filter(0) | Filter(0) | Filter (0) | Filter (0) | ------------------------------------------------------------------------ |512 |512 |512 |512 |512 |512 |512 |512 | |samples| samples|samples| samples| samples| samples|samples | samples | |(8 bit/|(8 bit/ |(8 bit |(8 bit/ |(8 bit/ |(8 bit/ |(8 bit |(8 bit/ | |sa RE)|sa RE | sa RE)|sa RE | sa RE) |sa RE | sa RE) |sa RE | ----------------------------------------------------------------------- |------------------------------------------------------------------------ | MARSIS DATA FRAME (SS2 MODE) | ------------------------------------------------------------------------ |DIPOLE F1 | DIPOLE F2 | |Multi-look | Multi-look | ------------------------------------------------------------------------ |512 |512 | |samples | sample | |(8 bit/sa RE) |(8 bit/sa RE) | ------------------------------------------------------------------------ |------------------------------------------------------------------------ | MARSIS DATA FRAME (SS3 MODE) | ------------------------------------------------------------------------ |DIPOLE F1 | DIPOLE F2 | |Doppler | Doppler | Doppler | |Filter(-1,0,1) | Filter (-1,0,1) | Filter (-1,0,1) | ------------------------------------------------------------------------ |512 |512 |512 |512 | |sample |samples | samples | samples | |(8 bit/sa RE) |(8 bit/sa IM) |(8 bit/sa RE) |(8 bit/sa IM) | ------------------------------------------------------------------------ |------------------------------------------------------------------------ | MARSIS DATA FRAME (SS4 MODE) | ------------------------------------------------------------------------ |DIPOLE F1 | MONOPOLE F1 | |Doppler | Doppler | |Filter(-2,-1,0,1,2) | Filter (-2,-1,0,1,2) | ------------------------------------------------------------------------ |512 |512 |512 |512 | |sample |samples | samples | samples | |(8 bit/sa RE) |(8 bit/sa IM) |(8 bit/sa RE) |(8 bit/sa IM) | ------------------------------------------------------------------------ |------------------------------------------------------------------------ | MARSIS DATA FRAME (SS5 MODE) | ------------------------------------------------------------------------ |DIPOLE F1 | MONOPOLE F1 | |Doppler | Doppler | |Filter(-1,0,1) | Filter (-1,0,1) | ------------------------------------------------------------------------ |512 |512 |512 |512 | |sample |samples | samples | samples | |(8 bit/sa RE) |(8 bit/sa IM) |(8 bit/sa RE) |(8 bit/sa IM) | ------------------------------------------------------------------------ An exception to this ordering criterion is constituted by Passive Ionosphere Sounding data, which are attached at the end of the scientific data of a frame, as illustrated in Image 6. Image 6. Scheme of the MARSIS Subsurface Sounding frame structure. 2.6.2 AUXILIARY DATA STRUCTURE BY INSTRUMENT MODE Each frame of MARSIS data (with the exception of frames stored in flash memory) carries a 228 byte header of ancillary data, containing necessary information for subsequent analysis of the data and further processing. The exact content of the ancillary data depends on instrument mode. There are four major structure types of the ancillary data : acquisition, tracking / individual echoes for subsurface modes, calibration / receive only and active ionosphere. Tables explaining parameters in these structures are shown in Appendix C. 2.6.3 SCIENTIFIC DATA STRUCTURE BY INSTRUMENT MODE The structure of scientific data within a frame depends on operative mode, instrument state and on-board processing, resulting in a large number of different combinations: complete description of all possible formats can be found in Appendix C. 2.6.4 INDIVIDUAL ECHOES A single frame of SSx tracking Individual Echoes contains a variable quantity of data. More precisely, a variable number of PRIs, being a PRI a fixed size data set (in general 980 bytes, with the exception of SS5). -| the following format is adopted inside the FRM file (Image 7): Where index data (16 bits: 15, 14,...1, 0) is formatted as follow: -| 10 bits (15-6): PRI number -| 6 bits (5-0):frequency/antenna (Dipole_F1, Dipole_F2, Monopole_F1, Monopole_F2) The number of samples in an echo, called PRI_Size, is listed below (Image 8): 2.6.5 FLASH MEMORY The following data types may be stored for each SSx Operative Mode in Flash Memories (FM): - RAW Tracking data - RAW Acquisition data - Uncompressed Tracking data - Uncompressed Acquisition Data Given the particular strategy adopted for writing data into FM ([AD04]- §7.6.6), the following storage format shall be considered: data are stored into FM as a single stream of bytes, being this stream a sequence of frames, each one of them is composed by an header followed by data themselves (Image 9) FM Frames differ from common Science Frame though. In general, a common Science Frame includes data collected from all Antennas/Frequencies involved in the selected Operative Mode. For example, an SS1 Science Frame includes: - Dipole F1 Data - Dipole F2 Data - Monopole F1 Data - Monopole F2 Data In case of FM, the same SS1 data are split into two separate Frames: one FM Frame including: - Dipole F1 Data - Monopole F1 Data another FM Frame including: - Dipole F2 Data - Monopole F2 Data In general, a single Science Frame is always split into two FM frames. Information on FM Frame data content are provided by the Frame header in fields BAND and CHANNEL (see [AD04]-§7.6-1). The FM Frame header is also quite different from the Science Frame one: no Ancillary/Auxiliary data are present; there is only a 44 bytes header, (see [AD04]-§7.6-1).. RAW data case -| the following format is adopted inside the FRM file (Image. 10) : Where index data (16 bits: 15, 14, ...1, 0) is formatted as follow: -| 10 bits (15-6): PRI number -| 6 bits (5-0):spare The number of samples in an echo, called PRI_Size, is listed below (Image. 11): Uncompressed data case -| the following format is adopted inside the FRM file (Image. 12): Where the size in bytes of a frame, called Op_Mode_Frame_Data_Size, is listed below (Image. 13): 2.7 DATA HANDLING PROCESS Data products are generated by the MARSIS team according to the following scheme. -| The PI Institution (INFOCOM) receives the MARSIS instrument data records (Level 1a data) at the MARSIS data processing facility from the Mars Express Project Data Distribution System (DDS). -| From the raw data, INFOCOM generates Level 1b data files (including necessary ancillary data files) in agreed formats, and makes these data files available on the MARSIS ASDC server. -| The Level 1a and Level 1b data files are then automatically transferred to the Iowa MARSIS processing facility on a regular basis via the data mirroring function. -| Once made available on the MARSIS ASDC server, Level 1b data can be retrieved by authorized data users for scientific analysis. Data retrieval is performed by each data user by means of FTP. -| Subsurface data products of Level 2 and higher are generated at the data processing facility located in ThalesAlenia Space (MOC –Marsis Operation Center). Ionospheric data products of Level 2 and higher are generated at Iowa. -| Following internal validation, the Level 2 and higher level subsurface data products are made available on the MARSIS ASDC server, where can be retrieved by authorized data users for scientific analysis. Data retrieval is performed by each data user by means of FTP. -| Following internal validation, the Level 2 and higher level ionospheric data products are made available in the Iowa MARSIS processing facility for access via a Web browser-based display tool (restricted to authorized data users). -| The processed Ionospheric Sounding data products are made PDS-compliant, and, at approximately 6-month intervals, following final internal validation, are delivered to the MARSIS PI (INFOCOM) via the MARSIS ASDC server, as described in [AD01]. -| On pre-defined dates, currently foreseen at 6-month intervals (see [AD06]), validated, PDS-compliant data of Level 1b and 2, both subsurface and ionosphere, are delivered to the ESA Planetary Science Archive by means of the ESA-provided tool PVV. 2.8 PRODUCT GENERATION Level 1b processing starts from the telemetry data, as produced by the C&DH system on the spacecraft and passed to the telemetry subsystem: data are still in the form of transfer frame packets organised by contacts or ground tests data. Processing starts by cleaning, merging and time-ordering the packets. This means that duplicate data have been deleted, missing packets are padded out, and the data are organised by orbits. Data then need to be sorted by instrument data types and instrument modes. MARSIS Level 1b processing orders data in a useful way for the intended users (i.e. radar scientists) and applications (i.e. quick look to monitor hardware performance and higher-level processing), altering and manipulating them as little as possible to avoid the risk of introducing errors and, at the same time, including all necessary information from all relevant sources. Level 1b data are in scientifically useful form, i.e. individual spectra. These data are still uncalibrated. MARSIS Level 1b data products consist of the data produced by the instrument reconstructed from the scientific telemetry, sorted by instrument state and data type, and provided with spacecraft position, velocity and attitude information. Any other spacecraft telemetry relevant for calibration and processing (e.g. temperature of the receiver) is also included. Level 1b processing requires the acquisition of MARSIS scientific telemetry and any relevant spacecraft auxiliary data from the Mars Express Data Disposition System (DDS) in ESOC, and of SPICE kernels describing the spacecraft state and attitude from the Auxiliary Data Conversion System (ADCS) in ESTEC. Both instrument telemetry and ancillary data are stored at the PI processing facility as they accumulates over the course of the mission, to provide the capability to reprocess data in case of errors or to accommodate new information referring to existing data sets. Level 1b data distribution to the Co-Is and to the Mars Express mission archive is performed by ASDC. It is required by ESA that data products are delivered in batches of six-months worth of data within six months from the last data take (i.e. one year after the beginning of that particular data collection period), but it is necessary that level 1b processing be completed in a much shorter period, to allow enough time for level 2 data processing and data analysis within the MARSIS team before the expiration of the data proprietary period (which is the same six-month time span). 2.9 OVERVIEW OF DATA PRODUCTS 2.9.1 PRE-FLIGHT DATA PRODUCTS Because of its 40m long antenna, it was not possible to fully test MARSIS on ground in conditions that can be considered representative of actual operations: thus, the MARSIS team does not plan to release pre-flight data products, as they would be useless for the analysis an interpretation of data acquired at Mars. 2.9.2 SUB-SYSTEM TESTS Sub-system tests performed on MARSIS are useful only for engineering purposes: thus, the MARSIS team does not plan to release sub-system test data products, as they would be useless for the analysis and interpretation of data acquired at Mars. 2.9.3 INSTRUMENT CALIBRATIONS Calibration runs of the instrument involved mainly the determination of the instrument performance at different temperatures, where it was found that the instrument receiver is indeed sensitive to temperature. Data accumulated during on -ground tests are thus used for the calibration of scientific data, but they are not released as a separate data set. Rather, they have been processed to produce calibration files that are part of standard data product releases. 2.9.4 IN-FLIGHT DATA PRODUCTS Data sets are homogeneous in terms of processing level of the data, and can thus be classified according to the definition of Processing Levels for Science Data Sets contained in [AD06]. Currently, two levels of processing are foreseen for MARSIS data: -| Level 1b: telemetry data that have been cleaned and merged , time ordered, sorted by instrument data types and instrument modes. Data are in scientifically useful form, but still uncalibrated. -| Level 2: Level 1b with calibration and corrections applied to yield Data in scientific units. Level 1b data are also called Experiment Data Records (EDR’s for short), Level 2 data Reduced Data Records (RDR’s). The resulting list of data sets, together with their official names defined according to the PDS standard used for their archiving [AD10], is provided in the table below (Image. 14). Image.14 – MARSIS Data Sets. 2.9.5 ANCILLARY DATA USAGE Ancillary data used in MARSIS data product generation are needed to correctly reference observations in space and time. Geometric information accompanying instrument data is produced by means of software based on the SPICE library, released by the Navigation and Ancillary Information Facility (NAIF) of JPL. Spacecraft trajectory and attitude data produced by ESOC is thus accessed through the SPICE library in the form of pre-processed data files (called kernels) produced by NAIF according to the standards described in [AD07]. 3 ARCHIVE FORMAT AND CONTENT This section describes the features of the MARSIS Standard Product Archive volumes, including the file names, file contents, and file types, which apply to all MARSIS data sets. Specialization of this information to each single data set is provided in Section 4. 3.1 FORMAT AND CONVENTIONS 3.1.1 DELIVERIES AND ARCHIVE VOLUME FORMAT Delivery of data from the MARSIS team to the PSA for archiving is done through the Internet, according to the incremental data release concept described in [AD12]. In conformity with guidelines also provided in [AD12], data are organized so that one MARSIS data set coincides with a single logical volume, as defined in the PDS standard [AD10]. For the nominal mission the Data Set ID is showed in Table 3.1.1-1: Image.15-Table 3.1.1 – 1 MARSIS Data Sets, Data Set ID’s and corresponding Volume ID’s. For extended phases of the mission beyond its nominal duration, Data Set Names and Data Set ID’s are changed to denote that they refer to data from the extended mission: Image. 16 Table 3.1.1 – 2 MARSIS Data Set Names and Data Set ID’s for extended mission phases. Where “y” is an integer number used to identify the extended mission phase. 3.1.2 DATA DIRECTORY NAMING CONVENTION Because it is expected that a large number of data files is present on a volume, the directory containing them is further divided into a number of subdirectories, each containing data collected over ten orbits. These subdirectory are named so as to make clear which data products they contain and when such data were collected. Their name is in the form pppoooX, where ppp is a group of letter denoting the kind of data product contained in the subdirectory (EDR for Experiment Data Records, RDR for Reduced Data Records,), and ooo are the digits common to numbers of the orbits in which data were acquired: for example, the subdirectory named EDR188X contains all files of Level 1b data collected from orbit 1880 to orbit 1889. 3.1.3 FILE NAMING CONVENTION All data product files throughout different MARSIS data sets are named using the same file naming convention. File names are built by a concatenation of three-letter components separated by underscore characters (“_”). Each component provides one type of information on the content of the file. Components are concatenated in the following order, although not all of them are necessarily present in any given file name: _____. File type refers to the type of data file: as it will be detailed in the following sections, MARSIS data products can consist of up to two files each, the first of which contains the data proper, and is called a “frame file” (the corresponding component is FRM), while the second, called a “geometry file” (GEO in short) contains geometric information used to locate observations in space and time. Operative modes, instrument states, data forms and data product types have been defined in Section 2, while the orbit number is a four-digit number identifying an orbit according to rules defined by the Mars Express mission control. File extension defines the format of data contained in the file: the extension is usually “.DAT”, denoting that the file contains a binary table object (data objects are defined according to [AD10]). Permitted values for different file name components are listed in the table below (Image.17) Image.17- Table 3.1.3 – 1 File name components for MARSIS data product files: refer to Section 1.7 for an explanation of the meaning of acronyms. As it will be illustrated in section dealing with naming schemes applied to individual Data Sets, the maximum length of data files will never exceed the 27 character limit, as not all name components listed in Table 3.1.3 – 1 are used in each individual file name. 3.1.4 SPECIAL OBSERVATION : PHOBOS The data products relative to Phobos have the same content and structure as the standard data products, the difference being only a different naming convention. The files names are built using standard rules, adding the suffix “_PH”. Image. 18- Table 3.1.4 – 1 File name components for MARSIS data product files: PHOBOS 3.2 STANDARDS USED IN DATA PRODUCT GENERATION 3.2.1 PDS STANDARDS All data released by the MARSIS Team for archiving are required to be compliant with the Planetary Data System (PDS) standard [AD09, AD10, AD11]. 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. 3.2.2 TIME STANDARDS 3.2.2.1 START_TIME AND STOP_TIME FORMATION The PDS formation rule for dates and time in UTC is: YYYY-MM-DDThh:mm:ss.fff or YYYY-DDDThh:mm:ss.fff, with -| YYYY year (0000-9999) -| MM month (01-12) -| DD day of month (01-31) -| 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) 3.2.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.52×10-5 seconds. Thus the OBT is represented as a two integer numbers separated by a point, the first of which represents the integer part of the clock count, and the second of which represents the fractional second part of the clock count. 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. 3.2.2.3 OBT TO UTC TIME CONVERSION Universal Time Coordinate (UTC) is a function of the time correlation packages and the on-board time. The time correlation packages are archived and distributed in the SPICE auxiliary data set and contain a linear segments that map the on-board time to UTC time. The linear segment is represented by a time offset and a time gradient. The conversion function is: Time in UTC = offset + ( OBT(seconds) + ( OBT(fractional part) * 2-16 ) ) *Gradient 3.2.3 REFERENCE SYSTEMS Locations on the surface of Mars are expressed in planetocentric coordinates. Longitude is comprised in the range 0° – 360°. 3.3 DATA VALIDATION Validation of data is performed at different levels of detail and using different procedures. A dedicated tool, called Monitoring Tool, exists in the MARSIS ground segment software to verify the completeness of data received from the spacecraft. Simple control of the syntax of data product labels and of the correct implementation of the directory structure is performed by means of software tools available from PDS. Finally, scientific validation of the data takes place during the proprietary period as MARSIS Co-I’s perform their scientific analysis and examine in detail the content of each data product. 3.4 CONTENT This section contains all the information that is data product- and detector-independent but is usually the same for all data sets. 3.4.1 VOLUME SET As the concept of a volume as defined in the PDS standard is based on physical media, e.g. CD-Rs, the PSA does not use the name volume. Instead, the concept of deliveries is defined for the PSA and the term delivery is used for the PSA. However, here and in the following sections we will use the word “volume” to refer to a standard PDS directory structure for a data set in which the entire data set consists of a single (virtual) volume. Different MARSIS data sets are organized as separate virtual volumes, and the concept of volume set is not used. 3.4.2 DATA SET MARSIS data sets are organized into one data set on one virtual volume, using the standard PDS volume structure. Such structure is described in Section 19.3 of [AD10], and shown in the Imageure below. ROOT | |- AAREADME.TXT | |- ERRATA.TXT | |- VOLDESC.CAT | |- [DATA] | | | |- DATAINFO.TXT | | | |-[EDRXXXX] | | | | |- [CATALOG] | | | |- CATINFO.TXT | |- DATASET.CAT | |- RELEASE.CAT | |- MISSION.CAT | |- INSTHOST.CAT | |- INST.CAT | |- PERSON.CAT | |- REFERENCE.CAT | |- SOFT.CAT | |- [INDEX] | | | |- INDXINFO.TXT | |- INDEX.TAB | |- INDEX.LBL | |- GEO_MARS.TAB | |- GEO_MARS.LBL | |- [DOCUMENT] | |- DOCINFO.TXT | |- MARSIS_EAICD.PDF | |- MARSIS_EAICD.TXT | |- MARSIS_EAICD.LBL | |- MARSIS_PSD.PDF | |- MARSIS_PSD.LBL | |- MARSIS_PT.PDF | |- MARSIS_PT.LBL | |- MARSIS_OST.PDF | |- MARSIS_OST.LBL | |- MARSIS_FUM.PDF | |- MARSIS_FUM.LBL | |- [LABEL] | |- LABINFO.TXT | |- *.FMT Imageure 3.4.2 – 1 Standard PDS volume set organization: one data set, one volume. The content of each directory shown in Imageure 3.4.2 – 1 is detailed in the following sections. 3.4.3 DIRECTORIES 3.4.3.1 ROOT DIRECTORY Files in this directory are provided by the MARSIS science team. Image. 19-Table 3.4.3.1 – 1 Files located in the root directory of a MARSIS data volume. 3.4.3.2 INDEX DIRECTORY This directory contains indexes, that is files with information that allows a user to locate data of interest. Within the Planetary Science Archive (PSA), index files fulfil two more purposes. First, some index files are read by database software and allow the ingestion of additional parameters into the database. Secondly, the PSA is using the index files to check for correct deliveries of data set releases and revisions into the PSA. Indexes are written as INDEX_TABLE objects, that is a specific type of PDS ASCII TABLE objects, and are provided with detached PDS label files. All index files below the INDEX directory within a data set release are unique and are valid for the actual data set and all previous ones. This means that the content of an index file covers all previous data set releases. The set of index files for MARSIS, as required in [AD12], is: Image. 20-Table 3.4.3.2 – 1 Files located in the INDEX subdirectory of a MARSIS data volume. All index files are patterned according to the standards defined in [AD10], the only difference being the name of the individual columns forming the INDEX_TABLE. The GEO_MARS.TAB file includes all the geometrical and position information listed in [AD14]. This file contains one entry for every frame acquired by the instrument (such entry is called a “line”), and each entry provides values for line description parameters, certain required non-geometrical parameters, generic position parameters, geometry and position information, solar related parameters, spacecraft related parameters and instrument viewing related parameters 3.4.3.3 DOCUMENT DIRECTORY Files in this directory are provided by the MARSIS science team, and will remain the same across different volumes. Image.21-Table 3.4.3.3 – 1 Files located in the DOCUMENT subdirectory of a MARSIS data volume. This directory contains additional documentation provided for a better understanding of the data and their use. 3.4.3.4 LABEL DIRECTORY This directory contains files referred to by ^STRUCTURE pointers included in labels of files in the DATA subdirectory. The content of these files is the description in ODL language of PDS Data Objects contained in Data Product files themselves. As it will be detailed in Section 4.1, MARSIS Data Products consist of tables, and the content of this directory is the description of table columns for different Data Product file types. There is one file for each Data Product file type. These files have a .FMT extension, and are named according to the file naming convention described in Section 3.1.3, without the use of a four-digit orbit number or a ten-digit spacecraft clock count. For example, the table format description file for a data product file named FRM_SS1_TRK_CMP_EDR_XXXX.DAT (where XXXX can be any orbit number) is called FRM_SS1_TRK_CMP_EDR.FMT. 3.4.3.5 CATALOG DIRECTORY Files in this directory are catalogue files, that is files containing PDS catalogue objects. Such objects provide high-level information suitable for loading into a database to facilitate searches across data sets, collections and volumes. The catalogue objects included on a PDS volume also provide local, high-level documentation. The full set of catalogue objects, listed below, is required in the CATALOG directory of every PDS archive volume. Such files are provided by the MARSIS science team, with the concurrence of the PSA. Image.22-Table 3.4.3.5 – 1 Files located in the CATALOG subdirectory of a MARSIS data volume. 3.4.3.6 CALIB DIRECTORY The CALIB directory contains instrument performance reports and engineering telemetry data tables relative to data in the current Data Set. It is organized into subdirectories named according to the same scheme used for subdirectories in the DATA directory (see Section 3.1): thus, for example, all data anomaly reports for orbits 1885-1889 in the EXPERIMENT DATA RECORD Data Set (see Table 2.9.4 - 1) are contained in a CALIB subdirectory named EDR188X. The reports themselves are in the form of detached-label Spreadsheet Data Objects, called logs. Each row in a log lists the value of a number of parameters identifying a data take, describing the quality of the data, and some geometric information provided for ease of reference. The log themselves are contained in files named LOG_ddd_nnnn.CSV, where: -| ddd is an identification of the data set they belong to, -| nnnn is the number of the orbit for which a log is provided. For example, the instrument performance report for orbit 1886 in the EXPERIMENT DATA RECORD Data Set is contained in the CALIB subdirectory EDR0188X and is named LOG_EDR_1886.CSV. The file containing the corresponding detached label is called LOG_EDR_1886.LBL For subsurface data sets of higher processing level than EDR’s (see Table 2.9.4 - 1), the CALIB directory contains reports describing the outcome of processing applied to lower-level data to produce the current data set, in a format similar to the one just described. Furthermore, calibration files used in producing the current data set are also provided, together with information on their use. In the REDUCED DATA RECORD SUBSURFACE Data Set, processing consists essentially in range processing, i.e. correlation of the received signal with the transmitted waveform (see Section 2.3.4). The distortion introduced by the ionosphere makes so that even the echo from an ideal mirror-like surface will not be identical to the transmitted pulse, so that modelling is necessary to predict the distortion caused by the ionosphere under different solar illumination conditions and in different locations. From the processing point of view, this results in a set of functions used for correlation with the received echo, each of which is appropriate under certain conditions. Thus, in the CALIB directory, this set of functions is provided together with explanations of how they are to be used. In the CALIB directory there are also files reporting engineering parameters of the instrument, called MARSIS_APID20_C_yyyy.CSV, MARSIS_APID20_T_yyyy.CSV, MARSIS_APID20_V_yyyy.CSV files where yyyy is the number of the orbit. These spreadsheets report respectively currents, temperatures and voltages measured within the instrument during a single orbit. The files containing the corresponding detached label MARSIS_APID20_C_yyyy.LBL, MARSIS_APID20_T_yyyy.LBL, MARSIS_APID20_V_yyyy.LBL 3.4.3.7 DATA DIRECTORY The DATA directory contains actual data products generated by the MARSIS team. Data files are organised into subdirectories, each containing data collected over ten orbits. Subdirectories in the DATA directory is named according to the scheme described in Section 3.1.3. An example of the organisation of the DATA directory into subdirectories is provided in section 3.1. 4 DETAILED INTERFACE SPECIFICATIONS 4.1 STRUCTURE AND ORGANISATION OVERVIEW As discussed in Section 2.9.4, MARSIS data sets are homogeneous in terms of processing level of the data, and, with the exception of lowest-level data, of the type of observation (i.e. either subsurface or ionosphere): -| Level 1b data (Data Set MARS EXPRESS MARS MARSIS EXPERIMENT DATA RECORD V1.0) consists of the instrument telemetry correlated with the auxiliary information needed to locate observations in space and time. Level 1b data users are mainly radar scientists interested in redoing the entire processing of the received signal, while the fact that unprocessed Subsurface Sounding echoes do not show any obvious indication of subsurface interfaces makes EDR’s of little use for geologists. -| Level 2 Subsurface Sounding data (Data Set MARS EXPRESS MARS MARSIS REDUCED DATA RECORD SUBSURFACE V1.0) consists of Level 1b data that have been processed to produce calibrated echoes of subsurface reflections: thus, they are the data set of choice for geological analysis of the structure and layering of the Martian subsurface. MARSIS raw data are processed to produce Level 1b data, i.e. data which have been edited, and provided with auxiliary information to locate them in space and time. Level 1b data differ from raw data in that they have extra files providing auxiliary information on spacecraft position, observation geometry and the like that cannot be derived from MARSIS data alone. Level 1b data are further processed to produce Level 2 data, i.e. data which have been calibrated, range-compressed and corrected for ionosphere distortion. Auxiliary information for Level 2 data is not modified, and thus the volume of auxiliary data accompanying Level 2 data is the same as for Level 1b data. Scientific data, however, are converted from 1-byte integer counts from the analogue-to-digital converter of the instrument to 4-byte real voltages, producing an increase of science data volume by a factor of four. As already described in Section 3.1.1, data products within a Data Set are organised into subdirectories, each containing data collected over ten orbits. Subdirectories in the DATA directory are named according to the scheme described in Section 3.1.2. In Imageure 3.4.2 – 1 the structure of the DATA directory for the MARS EXPRESS MARS MARSIS EXPERIMENT DATA RECORD V1.0 Data Set is shown for illustration. Data organization remains the same for all MARSIS Data Sets. The only difference is the group of three letters preceding the orbit number in the naming of subdirectories: EDR is changed to RDR for MARS EXPRESS MARS MARSIS REDUCED DATA RECORD SUBSURFACE V1.0 Data Sets. Each MARSIS Data Product is an aggregation of MARSIS frames. A frame is a collection of received echoes with or without on-board processing, and constitutes a single observation of the instrument. Each Data Product contains data from one or more frames collected using the same operation mode, instrument status and on-board processing scheme. Thus, the content of each MARSIS data product is highly variable in terms of number of frames, and depends on how operations for the instrument were planned during a given data collection period. Because each frame is a sequence of time samples of a received signal, complemented by auxiliary information, the natural organization for frames within a Data Product is a table, in which each line contains data from a single frame, and each column contains the value of a single parameter or time sample across different frames. Each Data Product consists of up to two files: a binary file containing the data themselves, and a binary table of quantities describing the geometry of observation, generated on-ground from spacecraft navigation data. Each Data Product file is described by an attached PDS label. Format files for table data objects contained in data files, of which several exist according to operation mode, instrument status and on-board processing scheme, are contained in the LABEL directory of each Data Set Volume. A PDS label provides descriptive information about the associated file. The PDS label is an object-oriented structure consisting of sets of 'keyword = value' declarations. PDS labels for all MARSIS Data Sets have the same standardised structure that is used for all labels (see , Appendix A and Appendix F for details on each keyword). 4.2 EXPERIMENT DATA RECORD DATA SET: DEFINITION AND CONTENT The MARS EXPRESS MARS MARSIS EXPERIMENT DATA RECORD V1.0 Data Set contains scientific telemetry generated by the instrument, edited to remove duplications, zero-padded for missing packets, and correlated with geometric information needed to locate observations in space and time. No other kind of processing is applied to the data. Because of this, subsurface sounding data for all modes except SS2 need to be range-processed (see Section 2.3.4) before subsurface reflections can be detected. In Imageure 23 a simulated subsurface echo is shown before range processing to illustrate the point: the plot represents the power received by the instrument as a function of time, and vertical bars mark instants of time in which echoes from each subsurface layer reach the radar. It can be seen that, before on-ground range processing, the received echo does not bear any obvious indication of the existence of subsurface layers. Imageure 23 Plot of a received unprocessed echo produced by means of a simple one-dimensional simulation of signal propagation through a plane parallel stratigraphy. Red vertical bars mark instants of time in which echoes from each subsurface layer reach the radar. This Data Set contains all different data types produced by the instrument described in Section 2.3.12. Within a Data Product, the structure of individual frames is not modified, and is thus the one described in Sections 2.5 and 2.6. Data Products need to accommodate the very different data structures resulting from the different modes and states of the instrument, and from the method used in on-board processing. Thus, there are several types of Data Products in this data Set, which are listed in the table below. Image.24-Table 4.2 – 1 List of EDR data Products. The “x” used in the Data Product Types column stands for a number between 1 and 5, while “yyy” stands either for ACQ or TRK (See Section 3.1.3 for explanations). Data Product files are named according to the convention defined in Section 3.1.3. As it will be described in the following section, AIS_EDR, CAL_EDR, RXO_EDR and SSx_yyy_CMP_EDR Data Product files contain data acquired throughout a single orbit, and are thus identified by a four- digit orbit number, while SSx_yyy_IND_EDR, SSx_yyy_UNC_EDR and SSx_yyy_RAW_EDR Data Product files contain data from a single frame, and are thus named after the ten-digit spacecraft clock count at the time of data acquisition. Furthermore, AIS_EDR, CAL_EDR, RXO_EDR and SSx_yyy_CMP_EDR Data Products possess geometric information that is written in a separate file, and thus each Data Product consists of a file containing instrument frames (FRM file) and one containing geometric information (GEO file). 4.3 EXPERIMENT DATA RECORD DATA PRODUCT DESIGN 4.3.1 AIS_EDR, CAL_EDR, RXO_EDR AND SSX_YYY_CMP_EDR DATA PRODUCT DESIGN AIS_EDR, CAL_EDR, RXO_EDR and SSx_yyy_CMP_EDR Data Products are made by two files, each of which contains a PDS binary TABLE object preceded by a PDS attached label describing its structure. The first file, called Frame file (FRM) contains the instrument data proper, exactly in the same format (bit by bit) as they were produced by the instrument (see Sections 2.5 and 2.6 for a complete description). Each frame corresponds to a record in the file, which is also a row in the PDS binary TABLE object into which frames are organised. A Data Product contains all frames acquired using the same instrument mode, in the same instrument state and after the same type of on-board processing during a single orbit. The resulting structure, for the specific case of subsurface sounding data is illustrated in Image 25. Image 25- FRM file structure for subsurface data. Ancillary data for different instrument modes are listed and explained in Appendix C, while the structure of scientific data is described in Appendix D. In Image 25, the zero padding refers to the requirement for a PDS attached label to have a length which corresponds exactly to an integer number of records; if this length is constant: in the case shown in Image 25, the size of a record is the size of the frame for that particular data type. To this end, the label is padded with space characters (ASCII 32 decimal) by adding spaces after the label's END statement and before the data so that the total of the label (in bytes) is an integral multiple of the record length of the data. Thus, the LABEL_RECORDS keyword in the label (see Appendix F) is calculated by dividing the total padded length of the label section, in bytes, by the stated value of RECORD_BYTES. Image 26 Relationship between an FRM file and the corresponding GEO file. The second file constituting an EDR is called a Geometry file (GEO), and contains one record, corresponding to one line of the PDS binary TABLE object into which data are organised, for every frame in the corresponding FRM file (See Image 26). Columns of the table contains the values of parameters describing the geometry of observation for the corresponding frame. The parameters contained in a GEO table are listed in Appendix E. 4.3.2 SSX_YYY_IND_EDR DATA PRODUCT DESIGN Subsurface data from Individual Echoes are the unprocessed version of data that are also down-linked in processed form, as explained in Section 2.3.7. A frame of Individual Echoes consists of a variable number of raw echoes, because, to produce a constant along-track ground resolution, synthetic aperture (Doppler) processing performed on board (see Section 2.3.3) requires a number of echoes that increases with altitude of the spacecraft. Because of this, the data structure described in the previous section, storing processed frames as individual rows within a table, cannot be used. It has been thus chosen to produce one Data Product per each frame of Individual Echoes, rather than one per orbit. The Data Product consists in just one file containing a PDS header and the data themselves, because any additional geometric information would just duplicate similar information already provided in SSx_yyy_CMP_EDR GEO data files. File names contains the first ten digits of the spacecraft clock count corresponding to the time at which data were acquired. Each record in a file contains a single unprocessed echo, preceded by auxiliary data and by a counter starting from 0 and increasing by one at each new echo. Echoes are ordered according to the time at which they were collected. Ancillary data for different instrument modes are listed and explained in Appendix C. Ancillary information is produced once per frame, and is thus the same for all echoes in a file: this duplication has been deemed necessary to simplify the data structure as much as possible. The number of echoes required in Doppler processing is a function of frequency, as well as of spacecraft altitude. In a dual-frequency mode, the exact number of echoes collected at each frequency is contained in the Ancillary data (see Appendix C), and echoes within a frame are ordered by frequency before being ordered in time. An example of file structure for a dual-frequency Individual Echoes Data Product is shown in Image 27. Image 27 File structure for a SSx_yyy_IND_EDR Data Product in a dual-frequency mode. NA_1 is the number of echoes collected using the first band, while NA_2 is the corresponding number for the second band. 4.3.3 SSX_YYY_UNC_EDR DATA PRODUCTS Subsurface UNC data are the uncompressed version of data that are also down-linked in fully processed form, as explained in Sections 2.3.6 and 2.3.8. Because they are structured exactly as CMP data, the only difference being the compression of individual echo samples from 4-byte IEEE real numbers to 1-byte integers, it has been chosen to produce one Data Product per orbit, just as for CMP data. The Data Product consists in just one file containing a PDS header and the data themselves, because any additional geometric information would just duplicate similar information already provided in SSx_yyy_CMP_EDR GEO data files. File names contain the four-digit number of the orbit at which data were acquired The structure of UNC Data Products is identical to the one used in CMP FRM files shown in Image 25. Because UNC data are down-linked through a dump of the flash memory, rather than through the scientific telemetry of the instrument, they do not come with a full set of ancillary data. 4.3.4 SSX_YYY_RAW_EDR DATA PRODUCT DESIGN Subsurface Raw Data are the unprocessed version of data that are also down-linked in processed form, as explained in Section 2.3.8. A frame of Raw Data consists of a variable number of raw echoes, because, to produce a constant along-track ground resolution, synthetic aperture (Doppler) processing performed on board (see Section 2.3.3) requires a number of echoes that increases with altitude of the spacecraft. Because of this, it has been chosen to produce one Data Product per each frame of Raw Data, rather than one per orbit, similarly to Individual Echoes. The Data Product consists in just one file containing a PDS header and the data themselves, because any additional geometric information would just duplicate similar information already provided in SSx_yyy_CMP_EDR GEO data files. File names contain the first ten digits of the spacecraft clock count corresponding to the time at which data were acquired. The structure of RAW Data Products is identical to the one used in IND files shown in Image 27. Because RAW data are down-linked through a dump of the flash memory, rather than through the scientific telemetry of the instrument, they do not come with a full set of ancillary data. 4.4 REDUCED DATA RECORD SUBSURFACE DATA SET: DEFINITION AND CONTENT The MARS EXPRESS MARS MARSIS REDUCED DATA RECORD SUBSURFACE V1.0 Data Set contains subsurface-sounding data from the MARS EXPRESS MARS MARSIS EXPERIMENT DATA RECORD V1.0 Data Set that have been uncompressed (See Section 2.3.6), calibrated and, except for data acquired using the SS2 mode, range-processed (see Section 2.3.4) after correcting for the distortion of the transmitted signal caused by the ionosphere. It is important to note that echoes collected in the acquisition (ACQ) phase (see Section 2.3.9), having a much smaller bandwidth, cannot be processed to achieve a vertical resolution sufficient for scientific analysis, and aren’t thus used in generating Reduced Data Records. Geometric information needed to locate observations in space and time is also provided in the Data Set. Image 28 shows the simulated echo of Image 24 after correlation with the transmitted signal, i.e. after range processing. No ionosphere distortion of the signal or instrument noise effects were introduced in the simulations. Now, 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 arte fact of the range compression processing (“side lobes”): they must not be confused with echoes from subsurface layers. Image 28 Plot of a received echo produced by means of a simple one- dimensional simulation of signal propagation through a plane parallel stratigraphy, after correlation with the transmitted signal. Red vertical bars mark instants of time in which echoes from each subsurface layer reach the radar. This Data Set contains data produced by the instrument using all subsurface sounding modes described in Section 2.3.12. After ground processing, data referring to the same observation but multiply down- linked, following different types of on-board processing, produce a single processed observation. Although processed echoes have a different size and content with respect to unprocessed echoes, within a Data Product the structure of individual frames is not modified, and it is the one described for compressed (CMP) data in Sections 2.5 and 2.6 and in Appendix C. Data Products need to accommodate the different data structures produced by different modes of the instrument. Thus, there is a single type of Data Product in this Data Set, which is specialized into five different subtypes, one for each subsurface sounding mode, following the same general structure detailed in the previous section. Image. 29 List of RDR-SS data Products. The “x” used in the Data Product Types column stands for a number between 1 and 5 (See Section 3.1.3 for explanations). Data Product files are named according to the convention defined in Section 3.1.3. As it will be described in the following section, SSx_RDR Data Product files contain data acquired throughout a single orbit, and are thus identified by a four-digit orbit number. Furthermore, SSx_RDR Data Products possess geometric information that is written in a separate file, and thus each Data Product consists of a file containing instrument frames (FRM file) and one containing geometric information (GEO file). 4.5 REDUCED DATA RECORD SUBSURFACE DATA PRODUCT DESIGN 4.5.1 SSX_RDR DATA PRODUCT DESIGN SSx_RDR Data Products are made by two files, each of which contains a PDS binary TABLE object preceded by a PDS attached label describing its structure. The first file, called Frame file (FRM) contains the instrument data proper, organised into individual frames having an identical structure as the one described for compressed (CMP) data in Sections 2.5 and 2.6 and in Appendixes B and C. Each frame corresponds to a record in the file, which is also a row in the PDS binary TABLE object into which frames are organised. A Data Product contains all frames acquired using the same instrument mode in tracking (TRK) state during a single orbit. The resulting structure is illustrated in Image 4.3.1 - 1. The second file constituting an EDR is called a Geometry file (GEO), and contains one record, corresponding to one line of the PDS binary TABLE object into which data are organised, for every frame in the corresponding FRM file (See Image 4.3.1. - 2). Columns of the table contain the values of parameters describing the geometry of observation for the corresponding frame. The parameters contained in a GEO table are listed in Appendix E. 4.5.2 USING SSX_RDR DATA PRODUCTS This section briefly lists the most important quantities contained in a data product and their use, to help new users of the data set getting started with data analysis. Starting from the attached PDS label, the most important information is reported through the following keywords: - RECORD_BYTES - LABEL_RECORDS - FOOTPRINT_POINT_LATITUDE - FOOTPRINT_POINT_LONGITUDE The label length in bytes is given by RECORD_BYTES X LABEL_RECORDS. Beyond the end of the attached PDS label, each record in a MARSIS FRM data product file is simply an instrument telemetry frame in which raw spectra have been substituted with processed echoes. Thus, each record begins with 28 bytes of Ancillary Data describing the instrument settings during data acquisition, and it is then followed by 228 bytes of Auxiliary Data, in which values for parameters used in the on-board software processing of the data are reported. The exact content of the auxiliary data depends on instrument mode (see Appendix A ,B). After the first 256 bytes, the frame contains processed echoes. The number of echoes in the frame varies with the instrument mode, and depends on the antenna(s) used to receive echoes (see Section 2.2.1), on the number of different frequencies transmitted by the radar (Section 2.2.2), and on the number of synthetic apertures produced through on-board processing (Section 2.3.3). The resulting length of the record segment containing processed radar echoes is reported in the following table: Table 4.5.2 – 1 Scheme of the SSx Data Products The exact ordering of echoes within a frame is reported in the format description files contained in the LABEL directory of the MARSIS PDS archive, and is condensed in the following tables: Table 4.5.2 – 2 Scheme of the SSx Data Products Structure records Table 4.5.2 – 3 Scheme of the SSx Data Products Structure records After the processed echoes, the FRM file record contains data acquired by the radar without transmitting, used to characterize the local electron radio emission, called Passive Ionosphere Sounding (PIS) data. The resulting organization of data within a data product is illustrated in the following diagram: ------------ | HEADER | | | ------------- | DATA | | | -------------- | PIS | ------------- | | | ------------ | HEADER | | | ------------- | DATA | | | -------------- | PIS | ------------- Users interested in analyzing subsurface reflections should start from echoes received through the dipole antenna, as the monopole is in fact insensitive to echoes coming from nadir. Both frequencies are important, but lower frequencies are expected to penetrate deeper, and thus subsurface reflections are usually stronger at the lower frequency. The Doppler filter containing most information should be the one pointing directly to nadir, which is usually labelled as "Filter 0"; filters looking forward (identified through a negative number) or backward (identified through a positive number) with respect to the direction of motion of the spacecraft usually contain more information than the nadir filter only if the surface of Mars beneath the spacecraft is tilted (such as when going up the flanks of Olympus Mons, for example). All processed echoes are 512 samples long. Because of the methods used in ground processing, the processed radar echo is a complex quantity, contained in two vectors of 512 32-bit floating point values, the first of which represents the modulus of the echo, while the second contains the echo phase. Most users will just need the modulus, which describes the echo power as a function of time. The echo power could be used to produce radargrams, that is a two- dimensional visualization of subsurface structures as seen by the radar. The user needs to extract from the data product the matrix containing the echo modulus for all echoes acquired with the same antenna, at the same frequency, and processed through the same Doppler filter. This matrix contains echoes as columns, and a graphic representation of such matrix as an image in which the brightness of the pixel is proportional to the strength of the echo will produce the radargram. Because of the large dynamic range of the data, subsurface echoes will become discernible only if a logarithmic scaling is applied to echo samples before visualization. An example of results from this procedure (after some tidying) is shown in the following picture: Figure 4.5.2 – 1 Plot of a L2 (Radargram) Quantitative analysis of echoes is severely hindered by the fact that the antenna is not calibrated, and that antenna gain changes with the frequency being used by the radar. Thus, all quantitative information extracted from data is relative to that frequency. Furthermore, the receiver works through an automated gain control setting, and thus the values of echo strength need to be normalized to a common gain level before comparison, as the gain setting can in principle change from one echo to the next. This is done through the use of a parameter extracted from the Auxiliary Data of the frame, called AGC_SA_LEVELS_Current_Frame_F1 (for the first frequency) or AGC_SA_LEVELS_Current_Frame_F2 (for the second frequency). These parameters are integer numbers reporting the number of discrete 4-dB attenuation steps applied by the receiver to the signal. The formula to convert a value of echo module into a normalized power expressed in dB is the following: 10*log10 |Module|2+Gain Where Gain = (AGC_SA_LEVELS_Current_Frame_F1/F2)*4+2 APPENDIXES A EXAMPLE PDS LABEL FOR MARSIS DATA PRODUCT FILES The following label is taken from the MARSIS data file FRM_SS3_TRK_CMP_EDR_1886.DAT, and illustrates the use of keywords described in Appendix E. PDS_VERSION_ID = PDS3 LABEL_REVISION_NOTE = "2004-12-06 R. Orosei: draft; 2005-07-08 R. Orosei: revised; 2006-10-25 R. Orosei: revised." RECORD_TYPE = FIXED_LENGTH RECORD_BYTES = 006912 FILE_RECORDS = 0965 FILE_NAME = "FRM_SS3_TRK_CMP_EDR_1886.DAT" LABEL_RECORDS = 0002 ^TABLE = 0003 DATA_SET_ID = "MEX-M-MARSIS-2-EDR-V1.0" DATA_SET_NAME = "MARS EXPRESS MARS MARSIS EXPERIMENT DATA RECORD V1.0" PRODUCT_ID = FRM_SS3_TRK_CMP_EDR_1886 PRODUCT_TYPE = EDR PRODUCT_CREATION_TIME = 2007-07-19T08:30:27.356 RELEASE_ID = 0001 REVISION_ID = 0000 MISSION_NAME = "MARS EXPRESS" INSTRUMENT_HOST_ID = MEX INSTRUMENT_HOST_NAME = "MARS EXPRESS" INSTRUMENT_NAME = "MARS ADVANCED RADAR FOR SUBSURFACE AND IONOSPHERE SOUNDING" INSTRUMENT_ID = MARSIS TARGET_NAME = MARS TARGET_TYPE = PLANET MISSION_PHASE_NAME = "MR PHASE 6" MISSION_ID = MEX START_TIME = 2005-07-04T20:08:58.067 STOP_TIME = 2005-07-04T20:34:53.758 SPACECRAFT_CLOCK_START_COUNT = "1/0068587732.55509" SPACECRAFT_CLOCK_STOP_COUNT = "1/0068589288.35273" ORBIT_NUMBER = 1886 PRODUCER_ID = MARSIS_TEAM PRODUCER_FULL_NAME = "GIOVANNI PICARDI" PRODUCER_INSTITUTION_NAME = "UNIVERSITY OF ROME LA SAPIENZA" DATA_QUALITY_DESC = "-1: percentage of corrupted data not available 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 = 0 INSTRUMENT_MODE_DESC = "In this mode, the instrument transmits two frequency-modulated waveforms in close succession, each having a 1 MHz bandwidth but centered at a different frequency. The signal is acquired through both the dipole and the monopole antennas. An altitude-dependent number of echoes (of the order of hundred) is collected in a single batch. Doppler processing adds a delay to the samples of each echo, and then sums the samples so as to allow the constructive sum of the signal component coming from a desired direction. Each coherent sum of the echoes is called a synthesized filter: this mode produces 3 filters. Data are converted from four-byte real numbers to one-byte integer numbers by extracting and storing the exponent of the sample with the largest absolute value, and by normalizing the entire echo by that exponent. Passive ionosphere sounding is also performed, by opening the receiver and collecting the signal produced by the ionosphere plasma around the spacecraft." INSTRUMENT_MODE_ID = SS3_TRK_CMP INSTRUMENT_TYPE = RADAR PROCESSING_LEVEL_ID = 2 PROCESSING_LEVEL_DESC = "Corrected for telemetry errors and split or decommutated into a data set for a given instrument. Sometimes called Experimental Data Record. Data are also tagged with time and location of acquisition. Corresponds to NASA Level 0 data." OBJECT = TABLE INTERCHANGE_FORMAT = BINARY ROWS = 0963 ROW_BYTES = 006912 ^STRUCTURE = "FRM_SS3_TRK_CMP_EDR.FMT" COLUMNS = 75 END_OBJECT = TABLE FOOTPRINT_POINT_LATITUDE = ((-18.26,-9.222,-0.641), (-0.48,11.021,22.319), (22.413,45.195,71.076), (71.228,72.709,74.075)) FOOTPRINT_POINT_LONGITUDE = ((207.741,207.641,207.563), (207.561,207.507,207.54), (207.541,208.164,212.984), (213.061,213.891,214.809)) END B ANCILLARY DATA --------------------------------------------------------------------- |Field name |Description |Size (bits) |Type | |SCET |It is the Operative | | | | |Phase start time. | 48 |unsigned int| | |The first FRAME of the | | | | |first | | | | |Operative Mode starts | | | | |at the first PRI start | | | | |time after SCET*. | | | ---------------------------------------------------------------------- |OST line |number Sequential | | | | |number of the OST line |16 |unsigned int | | |relevant to the current| | | | |frame. The counter | | | | |starts from zero. | | | ---------------------------------------------------------------------- | OST line |It is the number of the| | | | |OST line relevant | 96 |unsigned int | | |to Scientific Data | | | | |contained in the packet| | | ---------------------------------------------------------------------- |FRAME ID |The Frame Identifier is| 16 |unsigned int | | |the number of the Frame| | | | |in which the Scientific| | | | |Data contained in the | | | | |packed have been | | | | |acquired. The counter | | | | |starts from zero and it| | | | |is reset for each new | | | | |OST line. | | | --------------------------------------------------------------------- |Scientific | The Scientific Data | | | |Data Type | Type sub-field | | | | | distinguishes the | 2 | unsigned int| | |different ones | | | | |according to the codes | | | | |defined in the table 1.| | | --------------------------------------------------------------------- |Scientific | Counter The Source | 14 | unsigned int| |Data Source | Sequence Counter | | | |Seq. | specifies | | | | |the order of the | | | | |packets in which the | | | | |Scientific Data | | | | |acquired in a single | | | | |frame are subdivided; | | | | |in a self standing | | | | |packet, the counter | | | | |shall assume the only | | | | |value zero. | | | | |In case of Scientific | | | | |Data Types 00 and 11 | | | | |acquired in the same | | | | |frame, two different | | | | |counters shall be | | | | |considered. | | | | |The counters starts | | | | |from zero and they are | | | | |reset for each new | | | | |Frame ID value. | | | ---------------------------------------------------------------------- |Scientific |In case of data | 2 |unsigned int | |Data Seq. |segmentation, this | | | |Flags | field implements | | | | |packet grouping so | | | | |defined: | | | | |01b ->First source | | | | | packet of a group| | | | |00b ->Continuation | | | | | source packet | | | | | of a group | | | | |10b ->Last source | | | | | packet of a group| | | | |10b ->As elf standing | | | | | source packet | | | | |not belonging to a | | | | |group" | | | --------------------------------------------------------------------- |Spare | | 30 | | --------------|-----------------------|----------------| | |Total | | 224 bits | | | | | (28 Bytes) | | ---------------------------------------------------------------------- C AUXILIARY DATA STRUCTURES The following table contains structure for Calibration (CAL), Receive Only (RXO) and Active Ionospheric Sounding (AIS) modes. Practically all elements in this structure are similar except for 4 fields that have different names and one extra field that only contains data in the AIS mode. ------------------------------------------------------------------------- |Field name |Description |Size (bytes) |Type | ------------------------------------------------------------------------- |First PRI of the Frame |First PRI of the Frame | 4 |unsigned | | | | | int | ------------------------------------------------------------------------- |SCET_FRAME |SCET time of the frame | 6 |unsigned | | | | |int | | | | |-6 bytes | ------------------------------------------------------------------------- |SCET_PERICENTER |SCET time of the | |unsigned | | |Pericenter pass | 6 | int -6 | | | | |bytes | ------------------------------------------------------------------------ |SCET_PAR |Number of seconds in | | | | |SCET time to the | 6 |unsigned | | | pericenter passing | | int -6 | | |This is the basis for | |bytes | | |calculation of all | | | | |parameters in the Orbit| | | | |Determination block | | | ------------------------------------------------------------------------ |H_SCET_PAR | Range to the surface | 4 | signed | | | at the pericenter | | int | ------------------------------------------------------------------------- |VT_SCET_PAR |Tangential velocity of | | float | | |the spacecraft | 4 | 4bytes | | at the pericenter | | | ------------------------------------------------------------------------- |VR_SCET_PAR |Radial velocity of the | 4 | Float | | |spacecraft | | | | |at the pericenter | | | ------------------------------------------------------------------------- | No | No is an offset | 4 | signed | | | equal to 36 PRIs | | int | ------------------------------------------------------------------------- | DS_MIN | The space to be | 4 | Float | | | covered by | | | | |at the pericenter | | | | |the spacecraft during | | | | |NB pulses | | | | |deltaSmin=5500m | | | ------------------------------------------------------------------------ |NB_MIN | PRIs shall be grouped | 2 | unsigned| | |in sets of NB | | int | | | each representing a | | | | |“Frame”.NB is computed | | | | | adaptively during | | | | | the flyby.NB_min = 160| | | ------------------------------------------------------------------------- |ah0 |Polynomial coefficients| 4 | Float | | |for onboard | | | | |range to the surface | | | | |determination | | | | | (even coefficients) | | | |ah2 | | 4 | Float | |ah4 | | 4 | Float | |ah6 | | 4 | Float | ------------------------------------------------------------------------ |ar1 |Polynomial coefficients| 4 | Float | | |for onboard | | | | | radial velocity | | | | |determination | | | | | (even coefficients) | | | |ar3 | | 4 | Float | |ar5 | | 4 | Float | |ar7 | | 4 | Float | ------------------------------------------------------------------------- |at0 |Polynomial coefficients| 4 | Float | | |for onboard | | | | | tangential velocity | | | | |determination | | | | | (even coefficients) | | | |at2 | | 4 | Float | |at4 | | 4 | Float | |at6 | | 4 | Float | ------------------------------------------------------------------------ |DS_SCET_PAR | | 4 | Float | ------------------------------------------------------------------------- |NB_160_dec | | 2 | Unsigned| | | | |int | ------------------------------------------------------------------------- |AGC_CAL_PT_Value |Automated gain control | | | |AGC_RO_PT_Value | PT Values (db). | | | | |Note different names , | 4 | Float | |AGC_AIS |for CAL,RXO and AIS | | | | |modes. | | | ------------------------------------------------------------------------- |AGC_CAL_Level |Automated gain control | | | | |levels. | 1 |unsigned | |AGC_RO_Level |HW register, binary. | | byte | | |Note different | | | | |names for CAL, RXO and | | | |AGC_AIS_Level | AIS modes. | | | ------------------------------------------------------------------------- |RX_Trig_CAL_comp |Receive Trigger | | | |RX_Trig_RO_comp |Compression (ms)for | |unsigned | |RX_Trig_AIS |CAL, RXO and AIS modes.| 2 |int | | |Note different names | | | | |for CAL,RXO and AIS | | | | |modes. | | | ------------------------------------------------------------------------- |RX_Trig_CAL_progr |Receive Trigger Program| | | |RX_Trig_RO_progr |for CAL,RXO and AIS | 2 |unsigned | |RX_Trig_AIS_progr |modes. HW registerNote | | int | | |different names for | | | | |CAL,RXO and AIS modes. | | | ------------------------------------------------------------------------- |AISMaxOutputData |Only applicable in AIS | | | | | mode.AIS Maximum | 1 |unsigned | | |output data exponent | |byte | ------------------------------------------------------------------------- |Ah1 |Polynomial coefficients| 4 | Float | |Ah3 |for onboard range | 4 | Float | |Ah5 |to the surface | 4 | Float | |Ah7 |determination. | 4 | Float | | |(odd coefficients) | | | |------------------------------------------------------------------------ |ar0 |Polynomial coefficients| 4 | Float | |ar2 |for onboard radial | 4 | Float | |ar4 |velocity determination.| 4 | Float | |ar6 |(odd coefficients) | 4 | Float | ------------------------------------------------------------------------- |at1 |Polynomial coefficients| 4 | float | |at3 |for onboard tangential | 4 | float | |at5 |velocity determination.| 4 | float | |at7 |(odd coefficients) | 4 | float | ------------------------------------------------------------------------- |Spare | Not used here | 72 | | ------------------------------------------------------------------------ | Total | 228 | | ------------------------------------------------------------------------- Auxiliary data structure for all Calibration, Receive Only and Active Ionosphere Sounding modes. Auxiliary Data for Acquisition Phase ------------------------------------------------------------------------- |Field name |Description |Size (bytes) |Type | ------------------------------------------------------------------------- |First PRI of the Frame |First PRI of the Frame | 4 |unsigned | | | | | int | ------------------------------------------------------------------------- |SCET_FRAME |SCET time of the frame | 6 |unsigned | | | | |int | | | | | | ------------------------------------------------------------------------- |SCET_PERICENTER |SCET time of the | |unsigned | | |Pericenter pass | 6 | int | | | | | | ------------------------------------------------------------------------ |SCET_PAR |Number of seconds in | | | | |SCET time to the | 6 |unsigned | | | pericenter passing | | int | | |This is the basis for | | | | |calculation of all | | | | |parameters in the Orbit| | | | |Determination block | | | ------------------------------------------------------------------------ |H_SCET_PAR | Range to the surface | 4 | signed | | | at the pericenter | | int | | | | | | ------------------------------------------------------------------------- |VT_SCET_PAR |Tangential velocity of | | float | | |the spacecraft | 4 | | | | at the pericenter | | | ------------------------------------------------------------------------- |VR_SCET_PAR |Radial velocity of the | 4 | Float | | |spacecraft | | | | |at the pericenter | | | ------------------------------------------------------------------------- | No | No is an offset | 4 | signed | | | equal to 36 PRIs | | int | ------------------------------------------------------------------------- | DS_MIN | The space to be | 4 | Float | | | covered by | | | | |at the pericenter | | | | |the spacecraft during | | | | |NB pulses | | | | |deltaSmin=5500m | | | ------------------------------------------------------------------------ |NB_MIN | PRIs shall be grouped | 2 | unsigned| | |in sets of NB | | int | | | each representing a | | | | |“Frame”.NB is computed | | | | | adaptively during | | | | | the flyby.NB_min = 160| | | ------------------------------------------------------------------------- |ah0 |Polynomial coefficients| 4 | Float | | |for onboard | | | | |range to the surface | | | | |determination | | | | | (even coefficients) | | | |ah2 | | 4 | Float | |ah4 | | 4 | Float | |ah6 | | 4 | Float | ------------------------------------------------------------------------ |ar1 |Polynomial coefficients| 4 | Float | | |for onboard | | | | | radial velocity | | | | |determination | | | | | (even coefficients) | | | |ar3 | | 4 | Float | |ar5 | | 4 | Float | |ar7 | | 4 | Float | ------------------------------------------------------------------------- |at0 |Polynomial coefficients| 4 | Float | | |for onboard | | | | | tangential velocity | | | | |determination | | | | | (even coefficients) | | | |at2 | | 4 | Float | |at4 | | 4 | Float | |at6 | | 4 | Float | ------------------------------------------------------------------------ |DS_SCET_PAR |Marsis footprint size | 4 | Float | | |at the pericenter | | | ------------------------------------------------------------------------- |NB |Number of frames taken | 2 |Unsigned | | |in order to accommodate| |int | | |DS | | | ------------------------------------------------------------------------- |AGC_PIS_PT_Value_B1 |AGC PIS PT Value Band1 | 4 | Float | |AGC_PIS_PT_Value_B2 |and Band2 | 4 | | ------------------------------------------------------------------------- |AGC_PIS_Levels_B1 |AGC PIS Levels Band1 | 1 | byte | |AGC_PIS_Levels_B2 |and Band2 | 1 | | ------------------------------------------------------------------------- |K_PIM |Parameter used in the | 1 | byte | | |Passive Noise | | | | |Measurement Processing | | | | |which cannot exceed | | | | |the value of 5 | | | ------------------------------------------------------------------------- |PIS Maximum data exp | PIS Maximum output | 1 | | |[B1] | data exp [B1]/[B2] | | byte | |PIS Maximum data exp | | 1 | | |[B2] | | | | ------------------------------------------------------------------------- |AGC_NPM_PT_Value |Automatic Gain Control | | | | |value used during | 4 | Float | | |the Noise Power | | | | |Measurement Phase. | | | ------------------------------------------------------------------------- |AGC_NPM_Levels |Single Automatic Gain | | | | |Control value used | | | | |during the Noise Power | | | | |Measurement Phase. | | | | |There are two levels. | 1 | byte | | |The second one is used | | | | |only after the | | | | |Acquisition has failed | | | | |for the first one. | | | ------------------------------------------------------------------------ |NPM_Int_F1 |This parameter is | 4 | | |NPM_Int_F2 |evaluated during the | 4 | | | |Noise Power Measurement| | Float | | |Phase (dB). | | | | |For the Frequency F1 | | | | |and F2. | | | ------------------------------------------------------------------------ | | Treshold for Power | | | | X_F1 | X_F2 |Control for S0 dipole | 1 | byte | | |F1 and F2.MMMMNNNN | | | | |M-bits represent X_F1 | | | | |N-bits represent X_F2 | | | ------------------------------------------------------------------------ |AGC_COLL_X_F1 |Automatic Gain Control | 4 | | |AGC_COLL_X_F2 |value used during | 4 | Float | | |echoes collection. | | | | |There are four values | | | | |for each frequency. | | | ------------------------------------------------------------------------ |AGC_COLL_X_Levels_F1 |Single Automatic Gain | | | |AGC_COLL_X_Levels_F2 |Control value used | 1 | byte | | |during echoes | | | | |Collection (dB). | | | ------------------------------------------------------------------------ |RX_Trig_ACQ_comp |Starting position of | |Unsigned | | |the Receiving Window | 2 |int | | |during the Acquisition | | | | |Phase. | | | ------------------------------------------------------------------------- |RX_Trig_ACQ_prog |Parameter used during | |Unsigned | | |the evaluation of the | 2 |int | | |receiving window | | | | |position. | | | ------------------------------------------------------------------------- |AGC_SA_for_TRK_Frame_F1|Automatic Gain Control | 4 | | |AGC_SA_for_TRK_Frame_F2|value evaluated during | 4 | | | |the Acquisition Phase | |Float | | |and used by the first | | | | |frame of the Tracking | | | | |Phase (dB). | | | | |For frequency F1 | | | | |and F2. | | | ------------------------------------------------------------------------- |RX_Trig_SA_for_TRK |Receiving Window | 2 | | |_Frame_F1 |position evaluated | |Unsigned | | |during the Acquisition | |int | | |Phase and used by the | | | |RX_Trig_SA_for_TRK |first frame of the | 2 | | |_Frame_F2 |Tracking Phase. | | | | |For frequency F1 | | | | |and F2. | | | ------------------------------------------------------------------------ |DET_Thresh_F1 |Threshold used during | 4 | | |DET_Thresh_F2 |the Noise Power | 4 | Float | | |Measurement Phase | | | | |for the frequency F1 | | | | |and F2 | | | ------------------------------------------------------------------------- |K_DET_Thres_F1 |Multiplicative factor | 4 | | |K_DET_Thres_F2 |used during the Noise | 4 | Float | | |Power | | | | |Measurement Phase | | | | |for the frequency F1 | | | | |and F2 | | | ------------------------------------------------------------------------- |K_DET_Thres_min_F1 |Threshold used during | 4 | | |K_DET_Thres_min_F2 |the Noise Power | 4 | Float | | |Measurement Phase | | | | |for the frequency F1 | | | | |and F2 | | | ------------------------------------------------------------------------- |PHI_ACQ_F1 (Real) |Azimuth Compression | 4 | Float | | |(Doppler Filter) | | | | |parameter value | | | ------------------------------------------------------------------------- |PHI_ACQ_F1 |Azimuth Compression | 4 | Float | |(Immaginary |(Doppler Filter) | | | | |parameter value | | | ------------------------------------------------------------------------- |PHI_ACQ_F2 (Real) |Azimuth Compression | 4 | Float | | |(Doppler Filter) | | | | |parameter value | | | | | | | | ------------------------------------------------------------------------- |PHI_ACQ_F2 |Azimuth Compression | 4 | Float | |(Immaginary |(Doppler Filter) | | | | |parameter value | | | | | | | | ------------------------------------------------------------------------- |N_D |Parameter used for the | 2 |Unsigned | | |evaluation of the | |int | | |AGC_SA. It is stored | | | | |in the PT. | | | ------------------------------------------------------------------------- |K_AGC |Parameter used for the | 4 |Float | | |evaluation of the | | | | |AGC_SA. It is stored | | | | |in the PT. | | | ------------------------------------------------------------------------- |Aref |Parameter used for the | 4 |Float | | |evaluation of the | | | | |AGC_SA. It is stored | | | | |in the PT. | | | ------------------------------------------------------------------------- |Ref_Fun_Flag_F1 |This parameter shows | 1 |Unsigned | |Ref_Fun_Flag_F2 |if for the range | 1 |int | |0=default |compression has been | | | |1=corrected |used the default | | | | |reference function or | | | | |the corrected | | | | |reference | | | | |function,for frequency | | | | |F1 and F2. | | | ------------------------------------------------------------------------- |i_le_F1 |Position of the first | 2 |Signed | |i_le_F2 |sample of the signal | 2 | | | |that exceed the Noise | | | | |threshold (Leading Edge| | | | |Detection algorithm). | | | | |For frequency F1 and F2| | | ------------------------------------------------------------------------- |T_le_F1 |Time of the first | 4 |Signed | |T_le_F2 |sample of the signal | 4 | | | |that exceed the Noise | | | | |threshold (Leading Edge| | | | |Detection algorithm). | | | | |For frequency F1 and F2| | | ------------------------------------------------------------------------- |Maximum RE output data |Maximum data output | 1 |Unsigned | |exponent[OP_F1] |exponent. Order: pairs | | | | |of exponents for real | | | |Maximum IM output data |and imaginary parts of | 1 | | |exponent[OP_F1] |the spectra for the | | | | |Doppler filter, | | | | |frequency F1 | | | ------------------------------------------------------------------------- |Maximum RE output data |Maximum data output | 1 |Unsigned | |exponent[OP_F2] |exponent. Order: pairs | | | | |of exponents for real | | | |Maximum IM output data |and imaginary parts of | 1 | | |exponent[OP_F2] |the spectra for the | | | | |Doppler filter, | | | | |frequency F1 | | | ------------------------------------------------------------------------- |NS_LED |Parameter used by the | 2 | | | |Leading Edge Detection | |Unsigned | | |algorithm | | | ------------------------------------------------------------------------- |Processing_PRF |Value of the actual PRF| 4 |Float | | |used by the radar | | | ------------------------------------------------------------------------- |Total | 225 | | ------------------------------------------------------------------------- |Spare | 3 | | Auxiliary data structure for all subsurface modes. ------------------------------------------------------------------------ |Field name |Description |Size(bytes)| Type | Applicable modes | ----------------------------------------------------------------------- |First PRI |First PRI | 4 |unsigned |SS1,SS2,SS3,SS4, | |of the Frame|of the Frame | |int |SS5 | ------------------------------------------------------------------------ |SCET_FRAME |SCET time | 62 |unsigned |SS1,SS2,SS3,SS4 | | |of the frame | |int - 6 |SS5 | | | | |bytes | | ------------------------------------------------------------------------ |SCET_ |SCET time | |unsigned |SS1,SS2,SS3,SS4, | |PERICENTER |of the | 6 |int - 6 |SS5 | | |Pericenter pas | |byte | | ----------------------------------------------------------------------- |SCET_PAR |Number of | | signed |SS1,SS2,SS3,SS4, | | |seconds in | | int - 4 |SS5 | | |SCET time to | 6 | byte | | | |the pericenter | |unsigned | | | |passing.This is| |int – 2 | | | |the basis for | |bytes | | | |calculation of | | | | | |all parameters | | | | | |in the Orbit | | | | | |Determination | | | | | |block. | | | | ----------------------------------------------------------------------- |H_SCET_PAR |Range to the | | signed |SS1,SS2,SS3,SS4, | | |surface at the | | int |SS5 | | |pericenter. | 4 | | | | | | | | | ----------------------------------------------------------------------- |VT_SCET_PAR |Tangential | 4 | float |SS1,SS2,SS3,SS4, | | |velocity of the| | 4 bytes |SS5 | | |spacecraft at | | | | | |the pericenter | | | | ---------------------------------------------------------------------- |VR_SCET_PAR |Radial velocity| 4 | FLOAT |SS1,SS2,SS3,SS4, | | |of the | | |SS5 | | |spacecraft | | | | | |at the | | | | | |pericenter | | | | ----------------------------------------------------------------------- |N0 |No is an offset| 4 | unsigned |SS1,SS2,SS3,SS4, | | |equal to 36 | | int |SS5 | | |PRIs | | | | ----------------------------------------------------------------------- |DS_MIN |The space to be| 4 | float |SS1,SS2,SS3,SS4, | | |covered by the | | |SS5 | | |spacecraft | | | | | |during | | | | | |NB pulses | | | | | |TSmin=5500m | | | | ----------------------------------------------------------------------- |NB_MIN |PRIs shall be | | | | | |grouped in sets| 2 | unsigned |SS1,SS2,SS3,SS4, | | |of NB each | | int |SS5 | | |representing a | | | | | |“Frame”. | | | | | |NB is | | | | | |computed | | | | | |adaptively | | | | | |during | | | | | |the flyby. | | | | | |NB min = 160 | | | | ----------------------------------------------------------------------- |M_OCOG_F1 |Maximum of the | | |SS1,SS2,SS3,SS4, | | |signal power | 4 | float |SS5 | | |in the OCOG | | | | | |window for | | | | | |the frequency | | | | | |F1 | | | | ---------------------------------------------------------------------- |M_OCOG_F2 |Maximum of the | 4 | float | SS1,SS2,SS3 | | |signal power | | | | | |in the OCOG | | | | | |window for | | | | | |the frequency | | | | | |F2 | | | | ---------------------------------------------------------------------- |Index_OCOG |OCOG position | | unsigned |SS1,SS2,SS3,SS4, | |_F1 |value sampled | 2 | int |SS5 | | |(Range: | | | | | |1 to 512) for | | | | | | frequency F1 | | | | ---------------------------------------------------------------------- |Index_OCOG |OCOG position | | unsigned |SS1,SS2,SS3 | |_F2 |value sampled | 2 | int | | | |(Range: | | | | | |1 to 512) for | | | | | | frequency F2 | | | | ---------------------------------------------------------------------- |TRK_ |Loss of Lock | | |SS1,SS2,SS3,SS4, | |Threshold_F1|threshold, | 4 |float |SS5 | | |evaluated | | | | | |starting from | | | | | |the noise | | | | | |level. For | | | | | |frequency F1 | | | | ---------------------------------------------------------------------- |TRK_ |Loss of Lock | | |SS1,SS2,SS3 | |Threshold_F2|threshold, | 4 |float | | | |evaluated | | | | | |starting from | | | | | |the noise | | | | | |level. For | | | | | |frequency F2 | | | | ---------------------------------------------------------------------- |ini_ind_ |First sample | | |SS1,SS2,SS3,SS4, | |TRK_ |( Range : | | |SS5 | |Threshold |1 to 512) | | unsigned | | |_F1 |of a sub-window| 2 |int | | | |located in the | | | | | |receiving | | | | | |window, used to| | | | | |evaluate the | | | | | |noise level and| | | | | |then the TRK_ | | | | | |Threshold_F1 | | | | ---------------------------------------------------------------------- |ini_ind_ |First sample | | |SS1,SS2,SS3 | |TRK_ |( Range : | | | | |Threshold |1 to 512) | | unsigned | | |_F2 |of a sub-window| 2 |int | | | |located in the | | | | | |receiving | | | | | |window, used to| | | | | |evaluate the | | | | | |noise level and| | | | | |then the TRK_ | | | | | |Threshold_F2 | | | | ---------------------------------------------------------------------- |Last_ind_ |Last sample | | |SS1,SS2,SS3,SS4, | |TRK_ |(Range: | 2 | unsigned |SS5 | |Threshold_F1|1 to 512) | |int | | | |of a sub-window| | | | | |located in the | | | | | |receiving | | | | | |window, used to| | | | | |evaluate the | | | | | |noise level and| | | | | |then the TRK_ | | | | | |Threshold_F1 | | | | ---------------------------------------------------------------------- |Last_ind_ |Last sample | | |SS1,SS2,SS3 | |TRK_ |(Range: | 2 | unsigned | | |Threshold_F2|1 to 512) | |int | | | |of a sub-window| | | | | |located in the | | | | | |receiving | | | | | |window, used to| | | | | |evaluate the | | | | | |noise level and| | | | | |then the TRK_ | | | | | |Threshold_F2 | | | | ---------------------------------------------------------------------- |ini_ind_FSRM| Parameters for| | | SS1,SS2,SS3,SS4,| |_F1 |processing | 2 | unsigned | SS5 | | |using | | int | | | |FSR method | | | | | |(range : | | | | | |1 to 512) for | | | | | |F1 | | | | ---------------------------------------------------------------------- |ini_ind_FSRM| Parameters for| | | SS1,SS2,SS3 | |_F2 |processing | 2 | unsigned | | | |using | | int | | | |FSR method | | | | | |(range : | | | | | |1 to 512) for | | | | | |F2 | | | | ---------------------------------------------------------------------- |Last_ind_ |Parameters for | | | | |FSRM_F1 |processing | | unsigned | SS1,SS2,SS3,SS4,| | |using FSR | 2 | int |SS5 | | |method | | | | | |(range : | | | | | |1 to 512) for | | | | | |F1 | | | | ---------------------------------------------------------------------- |Last_ind_ |Parameters for | | | | |FSRM_F2 |processing | | unsigned | SS1,SS2,SS3 | | |using FSR | 2 | int | | | |method | | | | | |(range : | | | | | |1 to 512) for | | | | | |F2 | | | | ---------------------------------------------------------------------- |Spare (0x0) |Not used here. | 12 Byte | |SS1,SS2,SS3,SS4, | | | | | |SS5 | ---------------------------------------------------------------------- |DS_SCET_PAR |MARSIS | | |SS1,SS2,SS3,SS4, | | |footprint size | 4 | float |SS5 | | |at the | | | | | |pericenter | | | | ---------------------------------------------------------------------- |NB_SCET_PAR |NB - number of | | |SS1,SS2,SS3,SS4, | | |frames taken | 2 | unsigned |SS5 | | |in order to | | int | | | |accommodate DS.| | | | ---------------------------------------------------------------------- |NA_1_SCET |NA is the | | |SS1,SS2,SS3,SS4 | |_PAR |actual | 2 | unsigned |SS5 | | |number of | | int | | | |pulses | | | | | |over which the | | | | | |aperture was | | | | | |acquired for | | | | | |frequency 1 | | | | ---------------------------------------------------------------------- |NA_2_SCET |Same as NA1, | | |SS1,SS2,SS3,SS4 | |_PAR |but for the | 2 | unsigned |SS5 | | |second | | int | | | |frequency | | | | | |(mode | | | | | |dependent) | | | | ----------------------------------------------------------------------- |a2_ini_cm_F1|a2 starting | | |SS1,SS2,SS3,SS4 | | |value for the | |float |SS5 | | |on board | 4 | | | | |Contrast Method| | | | | |for the | | | | | |frequency F1 | | | | ---------------------------------------------------------------------- |a2_ini_cm_F2|a2 starting | | |SS1,SS2,SS3 | | |value for the | |float | | | |on board | 4 | | | | |Contrast Method| | | | | |for the | | | | | |frequency F2 | | | | ---------------------------------------------------------------------- |a2_opt_F1 |a2 optimum | | |SS1,SS2,SS3,SS4 | | |value evaluated| 4 |float |SS5 | | |by the on board| | | | | |Contrast Method| | | | | |for the | | | | | |frequency F1 | | | | ---------------------------------------------------------------------- |a2_opt_F1 |a2 optimum | | |SS1,SS2,SS3,SS4 | | |value evaluated| 4 |float |SS5 | | |by the on board| | | | | |Contrast Method| | | | | |for the | | | | | |frequency F1 | | | | ---------------------------------------------------------------------- |a2_opt_F2 |a2 optimum | | |SS1,SS2,SS3 | | |value evaluated| 4 |float | | | |by the on board| | | | | |Contrast Method| | | | | |for the | | | | | |frequency F2 | | | | ---------------------------------------------------------------------- |Ref_CA_opt |Optimum value | | |SS1,SS2,SS3,SS4, | |_F1 |of the | | |SS5 | | |integrated | | | | | |modulus of the | 4 | | | | |signal, | | float | | | |evaluated by | | | | | |the on | | | | | |board Contrast | | | | | |Method to | | | | | |estimate the | | | | | |a2_opt_F1 | | | | ---------------------------------------------------------------------- |Ref_CA_opt |Optimum value | | |SS1,SS2,SS3 | |_F2 |of the | | | | | |integrated | | | | | |modulus of the | 4 | | | | |signal, | | float | | | |evaluated by | | | | | |the on | | | | | |board Contrast | | | | | |Method to | | | | | |estimate the | | | | | |a2_opt_F2 | | | | ---------------------------------------------------------------------- |dt_F1 |Signal peak | | |SS1,SS2,SS3,SS4, | | |position | | |SS5 | | |(Range: | 2 | unsigned | | | |1...512) | | int | | | |evaluated by | | | | | |the on board | | | | | |FSR Method | | | | | |for F1. | | | | | |(Dt_F1= 0 | | | | | |in case of FSRM| | | | | |failure) | | | | ---------------------------------------------------------------------- |dt_F2 |Signal peak | | |SS1,SS2,SS3 | | |position | | | | | |(Range: | 2 | unsigned | | | |1...512) | | int | | | |evaluated by | | | | | |the on board | | | | | |FSR Method | | | | | |for F2. | | | | | |(Dt_F2= 0 | | | | | |in case of FSRM| | | | | |failure) | | | | ---------------------------------------------------------------------- |Sf_F1 |Peak value of | | |SS1,SS2,SS3,SS4, | | |the signal | | |SS5 | | |square modulus | 4 | float | | | |evaluated by | | | | | |the on board | | | | | |FSR Method | | | | | |for F1. | | | | | |(Sf_F1= 0 in | | | | | |case of FSRM | | | | | |failure) | | | | ---------------------------------------------------------------------- |Sf_F2 |Peak value of | | |SS1,SS2,SS3 | | |the signal | | | | | |square modulus | 4 | float | | | |evaluated by | | | | | |the on board | | | | | |FSR Method | | | | | |for F2. | | | | | |(Sf_F2= 0 in | | | | | |case of FSRM | | | | | |failure) | | | | ---------------------------------------------------------------------- |I_c_F1 |Sample | | |SS1,SS2,SS3,SS4, | | |(range: 1..512)| | |SS5 | | |where the | 2 | unsigned | | | |signal | | int | | | |square modulus | | | | | |exceeds the | | | | | |threshold in | | | | | |the FSR Method | | | | | |(I_c_F1 – -1 | | | | | |in case of | | | | | |threshold | | | | | |comparison | | | | | |failure) | | | | ---------------------------------------------------------------------- |I_c_F2 |Sample | | |SS1,SS2,SS3 | | |(range: 1..512)| | | | | |where the | 2 | unsigned | | | |signal | | int | | | |square modulus | | | | | |exceeds the | | | | | |threshold in | | | | | |the FSR Method | | | | | |(I_c_F2 – -1 | | | | | |in case of | | | | | |threshold | | | | | |comparison | | | | | |failure) | | | | ---------------------------------------------------------------------- |AGC_SA_for_ |AGC = Automated| | |SS1,SS2,SS3,SS4, | |Next_Frame |Gain Control | 4 | float |SS5 | |_F1 |Setting for | | | | | |Next Frame (db)| | | | ---------------------------------------------------------------------- |AGC_SA_for_ |AGC = Automated| | |SS1,SS2,SS3 | |Next_Frame |Gain Control | 4 | float | | |_F2 |Setting for | | | | | |Next Frame (db)| | | | ---------------------------------------------------------------------- |AGC_SA_ | This value is | | |SS1,SS2,SS3,SS4, | |Levels | reported in | 1 BYTE | |SS5 | |_Current | samples. | | | | |_Frame_F1 | | | | | ---------------------------------------------------------------------- |AGC_SA_ | This value is | | |SS1,SS2,SS3 | |Levels | reported in | 1 BYTE | | | |_Current | samples. | | | | |_Frame_F2 | | | | | ---------------------------------------------------------------------- |RX_Trig_SA _|RX window | | |SS1,SS2,SS3,SS4, | |for_Next_ |position for | 2 | unsigned |SS5 | |Frame_F1 |the current | | int | | | |frame F1 –(µs) | | | | ---------------------------------------------------------------------- |RX_Trig_SA _|RX window | | |SS1,SS2,SS3 | |for_Next_ |position for | 2 | unsigned | | |Frame_F2 |the current | | int | | | |frame F2 –(µs) | | | | ---------------------------------------------------------------------- |RX_Trig_SA_ |RX windows | | |SS1,SS2,SS3,SS4, | | progr_F1 |position for | 2 | unsigned |SS5 | | |the current | | int | | | |frame F1 | | | | ---------------------------------------------------------------------- |RX_Trig_SA_ |RX windows | | |SS1,SS2,SS3 | | progr_F2 |position for | 2 | unsigned | | | |the current | | int | | | |frame F2 | | | | ---------------------------------------------------------------------- |ini_ind_OCOG|Initial index | | |SS1,SS2,SS3,SS4, | | |for OCOG | 2 | unsigned |SS5 | | |(range 1 . 512)| | int | | ---------------------------------------------------------------------- |Last_ind |last index for | | |SS1,SS2,SS3,SS4, | |_OCOG |OCOG | 2 | unsigned |SS5 | | |(range 1 . 512)| | int | | ---------------------------------------------------------------------- |OCOG_F1 |OCOG position | 4 | float |SS1,SS2,SS3,SS4, | | |value for F1 | | |SS5 | ---------------------------------------------------------------------- |OCOG_F2 |OCOG position | 4 | float |SS1,SS2,SS3 | | |value for F2 | | | | ---------------------------------------------------------------------- |A_F1 |Signal energy | 4 | float |SS1,SS2,SS3,SS4, | | |for the AGC | | |SS5 | | |tracker error | | | | | |evaluation for | | | | | |frequency F1 | | | | ---------------------------------------------------------------------- |A_F2 |Signal energy | 4 | float |SS1,SS2,SS3 | | |for the AGC | | | | | |tracker error | | | | | |evaluation for | | | | | |frequency F2 | | | | ---------------------------------------------------------------------- |C_LoL_F1 |Loss of Lock – | | |SS1,SS2,SS3,SS4, | | |frequency F1. | 2 | unsigned |SS5 | | |Tracking status:| | int | | | |>=0 no tracking | | | | | |<0 tracking | | | | ---------------------------------------------------------------------- |C_LoL_F2 |Loss of Lock – | | |SS1,SS2,SS3 | | |frequency F1. | 2 | unsigned | | | |Tracking status:| | int | | | |>=0 no tracking | | | | | |<0 tracking | | | | ---------------------------------------------------------------------- |SS2_DCEX_1 |Internal Radar | |unsigned |SS2 | |SS2_DCEX_2 |parameter | 2 | int | | |SS2_DCEX_3 | | | | | ---------------------------------------------------------------------- | |Maximum data | | | | | |output exponent.| | | | | |Order : pairs of| | | | | |exponents for | | | | | |real and | | | | | |imaginary parts | | | | | |of the spectra | | | | | |for Doppler | | | | | |filter, | | | | | |Frequency, | | | | | |Antenna. | | | | | |So an array of | | | | | |values would | | | | | |look like this | | | | | |MaxOutExp | | | | | MaxCmpOut |(Re/IM, | 20 | unsigned |SS1,SS3,SS4,SS5 | | |Ndoppler, | | | | | |Nfreq, Nant), | | | | | |where Re/Im is | | | | | |1/2, Ndoppler | | | | | |is 1 to 5, | | | | | |Nfreq is 1 or 2,| | | | | |Nant is 1 for | | | | | |dipole, 2 for | | | | | |monopole). | | | | | |See note | | | | | |on order of | | | | | |doppler | | | | | |filters in this | | | | | |array.In SS4 | | | | | |mode only one | | | | | |band is used. | | | | ---------------------------------------------------------------------- |AGC_PIS_PT |AGC PIS PT | 4 | float |SS1,SS2,SS3,SS4 | |_Value_B1 |Value Band 1(db)| | |SS5 | ---------------------------------------------------------------------- |AGC_PIS_PT |AGC PIS PT | 4 | float |SS1,SS2,SS3,SS4 | |_Value_B2 |Value Band 2(db)| | |SS5 | ---------------------------------------------------------------------- |AGC_PIS |AGC PIS Levels | 1 byte | | SS1,SS2,SS3,SS4 | |_Levels_B1 |Band 1, HW | | |SS5 | | |register, binary| | | | ---------------------------------------------------------------------- |AGC_PIS |AGC PIS Levels | 1 byte | | SS1,SS2,SS3,SS4 | |_Levels_B2 |Band 2, HW | | |SS5 | | |register, binary| | | | ---------------------------------------------------------------------- |K_PIM |Parameter used | 1 byte | |SS1,SS2,SS3,SS4 | | |in the Passive | | |SS5 | | |Noise | | | | | |Measurement | | | | | |Processing, | | | | | |which cannot | | | | | |exceed the value| | | | | |of 5 | | | | ---------------------------------------------------------------------- |PISMaXOut |PIS Maximum | 1 byte | |SS1,SS2,SS3,SS4 | |DataExp_B1 |output data | | |SS5 | | |exp [B1] | | | | ---------------------------------------------------------------------- |PISMaXOut |PIS Maximum | 1 byte | |SS1,SS2,SS3,SS4 | |DataExp_B2 |output data | | |SS5 | | |exp [B2] | | | | ---------------------------------------------------------------------- |Processing |Processing | 4 | float |SS1,SS2,SS3,SS4 | |_PRF |PRF (pulse | | |SS5 | | |repetition | | | | | |frequency) | | | | ---------------------------------------------------------------------- |Spare (0x0)|Not used here. | 1 Byte | |SS1,SS2,SS3,SS4, | | | | | |SS5 | ---------------------------------------------------------------------- |Total bytes :| | 228 | | ---------------------------------------------------------------------- D SCIENTIFIC DATA STRUCTURE The following table summarizes the information contained in Sections 2.5 and 2.6. Image. 30 . Formats and sizes of frames, according to instrument mode and state, and data form, as derived from [AD04]. E KEYWORD LISTING FOR GEO FILES The following table lists the parameters contained in a GEO (geometry auxiliary information) file accompanying instrument data files. The listed keywords are column names in the Table Object contained in the GEO file. |Parameter Name | Data Type | Bytes | Units| Description | ------------------------------------------------------------------------ |SCET_GEO_WHOLE |MSB_INTEGER | 4 | |Spacecraft clock count | | | | | |at | | | | | |the beginning of the | | | | | |frame,coarse part. | ----------------------------------------------------------------------- |SCET_GEO_FRAC |MSB_INTEGER | 2 | |Spacecraft clock count at | | | | | |the beginning of the frame| | | | | |fine part. | ------------------------------------------------------------------------ |EPHEMERIS_TIME |IEEE_REAL | 8 | |Seconds elapsed since Jan,| | | | | |1, 2000, 12:00 UTC | | | | | |corresponding to | | | | | |SCET_FRAME | ------------------------------------------------------------------------ |GEOMETRY_EPOCH |CHARACTER | 23 | |Time, corresponding to | | | | | |SCET_FRAME, at which the | | | | | |geometrical and position | | | | | |parameters are computed, | | | | | |expressed in UTC | ------------------------------------------------------------------------ |MARS_SOLAR_ | IEEE_REAL | 4 |DEGREES|Angle between the Mars-Sun| |LONGITUDE | | | |line at the time of | | | | | |interest and the Mars-Sun | | | | | |line at the vernal equinox| ------------------------------------------------------------------------ |MARS_SUN | IEEE_REAL | 4 | |Distance from the centre | |_DISTANCE | | | |of Mars to centre of the | | | | | |Sun | ------------------------------------------------------------------------ |ORBIT_NUMBER | IEEE_REAL | 4 | |Number of the current | | | | | |orbital revolution of the | | | | | |Mars Express spacecraft | | | | | |around Mars. | ------------------------------------------------------------------------ |TARGET_NAME |CHARACTER | 6 | |Name of the celestial | | | | | |body being observed by | | | | | |MARSIS at the time | | | | | |corresponding to SCET_GEO.| ------------------------------------------------------------------------ |TARGET_SC_ | |24 | |Position vector of the | |POSITION_VECTOR | | | |Mars Express | | | | | |spacecraft in the | | | | | |reference frame of the | | | | | |target body at the time | | | | | |corresponding to SCET_GEO,| | | | | |expressed in Km (along | | | | | |x, y, z axes) | ------------------------------------------------------------------------ |SPACECRAFT_ |IEEE_REAL | 4 | |Distance from the | | ALTITUDE | | | |spacecraft to the | | | | | |reference surface of Mars | | | | | |measured normal | | | | | |to the surface | ------------------------------------------------------------------------ |SUB_SC_EAST_ |IEEE_REAL | 8 ||East longitude of the | | LONGITUDE | | | |point on the target body | | | | | |that lies directly beneath| | | | | |the Mars Express | | | | | |spacecraft at the time | | | | | |corresponding to SCET_GEO,| | | | | |expressed in degrees and | | | | | |in the [ 0 -360 ] range | | | | | |frame. | ------------------------------------------------------------------------ |SUB_SC_ |IEEE_REAL | 4 ||Planetocentric | |PLANETOCENTRIC | | | |latitude of the point on | |_LATITUDE | | | |the target body that lies | | | | | |directly beneath the Mars | | | | | |Express spacecraft at the | | | | | |time corresponding to | | | | | |SCET_GEO, | | | | | |expressed in degrees | ------------------------------------------------------------------------ |TARGET_SC_ |IEEE_REAL |24 ||MEX velocity relative to | |VELOCITY_ | | | |body(Vx ,Vy ,Vz component)| |VECTOR | | | | | ------------------------------------------------------------------------ |TARGET_SC_ |IEEE_REAL | 8 ||The radial component | |RADIAL_ | | | |of the Mars Express | |VELOCITY | | | |spacecraft velocity vector| | | | | |in the reference frame of | | | | | |the target body at the | | | | | |time corresponding to | | | | | |SCET_GEO | ------------------------------------------------------------------------ |TARGET_SC_TANG | | 8 | |Tangential component of | |_VELOCITY | | | |the Mars Express | | | | | |spacecraft velocity vector| | | | | |in the reference frame of | | | | | |the target body at the | | | | | |time corresponding to | | | | | |SCET_GEO | ------------------------------------------------------------------------ |LOCAL_TRUE_SOLAR|IEEE_REAL | 8 |DEGREES|Angle between the | |TIME | | | |extension of the vector | | | | | |from the Sun to Mars and | | | | | |the projection on Mars' | | | | | |ecliptic plane of a vector| | | | | |from the center of the | | | | | |target body and the point | | | | | |on the target body surface| | | | | |that lies directly beneath| | | | | |the Mars Express | | | | | |spacecraft at the time | | | | | |corresponding to SCET_GEO,| | | | | |expressed on a 24-hour | | | | | |clock with decimal | | | | | |fractions of the hour. | ------------------------------------------------------------------------ |SOLAR_ZENITH |IEEE_REAL | 8 |DEGREES|Angle between the zenith | |_ANGLE | | | |and the apparent | | | | | |position of the Sun | | | | | |measured at the point on | | | | | |the target body surface | | | | | |that lies directly beneath| | | | | |the Mars Express | | | | | |spacecraft at the time | | | | | |corresponding to SCET_GEO,| | | | | |expressed in degrees | ------------------------------------------------------------------------ |DIPOLE_UNIT |IEEE_REAL | 24 ||Unit vector directed | |_VECTOR | | | |along MARSIS dipole | | | | | |Antenna in the | | | | | |reference frame of | | | | | |the target body at | | | | | |the time corresponding | | | | | |to SCET_GEO | ------------------------------------------------------------------------ |MONOPOLE_UNIT_VECTOR|IEEE_REAL| 24 ||Unit vector directed along| | | | | |MARSIS monopole Antenna | | | | | |in the reference | | | | | |frame of the target body | | | | | |at the time corresponding | | | | | |to SCET_GEO Keyword list | | | | | |and value formats for GEO | | | | | |files. | F KEYWORD LISTING FOR PDS LABELS Different PDS keywords are used in labels of different PDS file labels. The following table lists which keywords are used in which file type label. Image. 31 Keywords used in different file types within the MARSIS data archive. In the following table, a description and valid values for the PDS keywords used in file labels is provided. |Keyword name | Definition |Type |Valid values | ------------------------------------------------------------------------ |COLUMNS |Number of columns | | | | |in each row of a |Integer | Variable | | |data object. | | | ------------------------------------------------------------------------ |DATA_QUALITY_DESC |This element | |-1: percentage of | | |describes the data| |corrupted data not | | |quality which is | |data | | |associated with a | |0: no corrupted data | | |particular | |1: less than 2% | | |DATA_QUALITY_ID | String | corrupted data | | |value. The various| |2: less than 5% | | |values of | | corrupted data | | |DATA_QUALITY_ID | |3: less than 10% | | |and | | corrupted data | | |DATA_QUALITY_DESC | |4: more than 10% | | |are instrument | | corrupted data | | |dependent. | | | ------------------------------------------------------------------------ |DATA_QUALITY_ID |This element | | | | |provides a numeric| | | | |key which |String |-1,0,1,2,3,4 | | |identifies the |(3) | | | |quality of data | | | | |available for a | | | | |particular time | | | | |period. | | | ------------------------------------------------------------------------ |DATA_SET_ID |This element is a | |MEX-M-MARSIS-2-EDR-V1.0| | |unique | |MEX-M-MARSIS-3-RDR-SS- | | |alphanumeric | |V1.0 | | |identifier for a | |MEX-M-MARSIS-2-EDR-EXT1| | |data set or a data| String |-V1.0 | | |product. In most |(40) |MEX-M-MARSIS-3-RDR-SS- | | |cases it is an | |EXT1-V1.0 | | |abbreviation of | | | | |the DATA_SET_NAME.| | | ------------------------------------------------------------------------ |DATA_SET_NAME |This element | |MARS EXPRESS MARS | | |provides the full | |MARSIS EXPERIMENT DATA | | |name given to a | |RECORD V1.0 | | |data set. | | | | |It typically | String |MARS EXPRESS MARS | | |identifies the |(60) |MARSIS REDUCED DATA | | |instrument that | |RECORD SUBSURFACE V1.0 | | |acquired the data,| | | | |the target of that| |MARS EXPRESS MARS | | |instrument, | |MARSIS EXPERIMENT DATA | | |and the | |EXTENSION_1 V1.0 | | |processing level | | | | |of the data. | |MARS EXPRESS MARSIS | | | | |RDR SUBSURFACE DATA | | | | |EXTENSION_1 V1.0 | ------------------------------------------------------------------------ |FILE_NAME |This element | |The name of the file | | |provides the |String |itself | | |location |(120) |FRM_SS3_TRK | | |independent name | |_IND_EDR_1886.DAT | | |of a file. | | | ------------------------------------------------------------------------ |FILE_RECORDS |This element | |Equal to the total file| | |indicates the | |length divided by | | |number of physical| Integer |RECORD_BYTES | | |file records, | | | | |including both | | | | |label records and | | | | |data records. | | | ------------------------------------------------------------------------- |FOOTPRINT_POINT_ |This data element | | | |LATITUDE |provides an array | | | | |of values that | | | | |represent the | | | | |latitudes of | Real | Variable | | |points along | | | | |the edge of an | | | | |image footprint | | | | |on the planet's | | | | |surface. Latitude | | | | |values are | | | | |planetocentric. | | | ------------------------------------------------------------------------ |FOOTPRINT_POINT_ |This data element | | | |LONGITUDE |provides an array | | | | |of values that | | | | |represent the | | | | |longitudes of | Real | Variable | | |points along | | | | |the edge of an | | | | |image footprint | | | | |on the planet's | | | | |surface. | | | | |Longitude | | | | |values are | | | | |planetocentric. | | | ------------------------------------------------------------------------ |INSTRUMENT_HOST_ID| This element | | | | |provides a unique | | | | |identifier for the| String | MEX | | |host where an |(11) | | | |instrument is | | | | |located. | | | ------------------------------------------------------------------------ |INSTRUMENT_HOST |This element | | | |_NAME | provides | String | MARS EXPRESS | | |the full name of |(120) | | | |the host on which | | | | |an instrument is | | | | |based. | | | ------------------------------------------------------------------------ |INSTRUMENT_ID |This element | | | | | provides | String | MARSIS | | | an abbreviated |(12) | | | |name or acronym | | | | |which identifies | | | | |an instrument | | | ------------------------------------------------------------------------ |INSTRUMENT_MODE_ |This element | | | |DESC |describes the | String | MARSIS | | | an abbreviated |(12) | | | |name or acronym | | | | |which identifies | | | | |an instrument | | | ------------------------------------------------------------------------ |INSTRUMENT_MODE | This element | | | |_DESC |describes the | | | | |instrument mode | String | See Appendix A | | |which is | | for an example | | |identified | | | | |by the | | | | |INSTRUMENT_MODE_ID| | | | |element. | | | ------------------------------------------------------------------------ |INSTRUMENT_MODE_ID| This element | | AIS, CAL, RXO, | | |provides an | | SS1_ACQ, SS1_TRK, | | |instrument- | | SS2_ACQ, SS2_TRK, | | |dependent | | SS3_ACQ, SS3_TRK, | | |designation of | | SS4_ACQ,SS4_TRK, | | |operating mode. | String | SS5_ACQ, SS5_TRK | | |This may be simply| (20) | | | |a number, letter | | | | |or code, or a word| | | | |such as 'normal', | | | | |'full resolution',| | | | |'near encounter', | | | | |or 'fixed grating'| | | ------------------------------------------------------------------------ |INSTRUMENT_NAME |This element | |MARS ADVANCED RADAR | | |provides the full | String |FOR SUBSURFACE AND | | |name of an | (60) |IONOSPHERE SOUNDING | | |instrument. | | | ------------------------------------------------------------------------ |INSTRUMENT_TYPE |This element | | RADAR | | |identifies the | String | | | |type of an | (30) | | | |instrument. | | | ------------------------------------------------------------------------ |INTERCHANGE_FORMAT| Manner in which |String | | | |data items are | (6) | BINARY | | |stored. | | | ------------------------------------------------------------------------ |LABEL_RECORDS |This element | |The number of data | | |indicates the | |is determined by | | |number | |subtracting the | | |of physical file | Integer |value | | |records that | |of LABEL_RECORDS | | |contain | |from the value of | | |only label | | FILE_RECORDS. | | |information. | | | ------------------------------------------------------------------------ |LABEL_REVISION |This element is | |2003-11-20, | |_NOTE |a free-form | |Roberto Orosei (INAF) | | |unlimited length | | initial release; | | |character string | |2004-05-07, updated. | | |providing | | | | |information | | | | |regarding the | | | | |revision status | String | | | |and authorship | (75) | | | |of a PDS label. | | | | |This should | | | | |include | | | | |the latest | | | | |revision date and | | | | |author of | | | | |the current | | | | |version, but may | | | | |include a more | | | | |complete history. | | | ------------------------------------------------------------------------ |MISSION_ID |This element | | | | |provides a synonym| | | | |or mnemonic for |String | MEX | | |the MISSION_NAME | | | | |element. | | | ------------------------------------------------------------------------ |MISSION_NAME |This element | | | | |identifies a major| | | | |planetary mission | String | MARS EXPRESS | | |or project. | (60) | | | |A given | | | | |planetary mission | | | | |may be associated | | | | |with one or more | | | | |spacecraft. | | | ------------------------------------------------------------------------ |MISSION_PHASE_NAME| This element | | | | |provides the | String | PRIMARY MISSION | | |commonly-used | (30) | EXTENDED MISSION | | |identifier of | | | | |a mission phase. | | | ------------------------------------------------------------------------ |ORBIT_NUMBER |This element | | Any value used | | |identifies the | | by the Mars | | |number of the | Integer | Express project | | |orbital revolution| | | | |of the | | | | |spacecraft around | | | | |a target body. | | | ------------------------------------------------------------------------ |PDS_VERSION_ID |This data element | | | | |represents the | | | | |version number | String | PDS | | |of the PDS | (6) | | | |standards | | | | |documents that | | | | |is valid when a | | | | |data product label| | | | |is created. | | | ------------------------------------------------------------------------ |PROCESSING_LEVEL_ |This data element | |For a fuller | | DESC |provides the | |definition of CODMAC | | |CODMAC standard | String |please refer to the PDS| | | definition | (75) |Standards Reference | | | corresponding | |[AD10]. | | |to a particular | | | | |PROCESSING_LEVEL_ | | | | |ID value | | | | | | | | ------------------------------------------------------------------------ |PROCESSING_LEVEL |This data element | | | |_ID |identifies the | | 2, 3 | | |processing level | String | | | |of a set of data | (1) | | | |according | | | | |to the to the | | | | |standard. | | | ------------------------------------------------------------------------ |PRODUCER_FULL_NAME| This element | | | | |provides | | | | |the full name of | String | | | |the individual | (60) | GIOVANNI PICARDI | | |mainly | | | | |responsible for | | | | |the production of | | | | |a data set. | | | ------------------------------------------------------------------------ |PRODUCER_ID |This element | | | | |provides a short | | | | |name or acronym | String | | | |for the producer | (20) | MARSIS_TEAM | | |or producing | | | | |team/group of | | | | |a dataset. | | | ------------------------------------------------------------------------ |PRODUCER_ |This element | | | |INSTITUTION_NAME |identifies a | | | | |university, | | | | |research centre, | String | | | |NASA centre or | (60) |UNIVERSTY OF ROME | | |other institution | |LA SAPIENZA | | |associated with | | | | |the production of | | | | |a data set. | | | ------------------------------------------------------------------------ |PRODUCT_CREATION |This element | | Formation rule is | |_TIME |defines | |YYYY-MM-DDThh:mm:ss.fff| | |the UTC system | Time | | | |format | | | | |time when a | | | | |product was | | | | |created. | | | ------------------------------------------------------------------------ |PRODUCT_ID |This data element | |For FRM and GEO | | |represents a | |files of any | | |permanent, unique | String |MARSIS data set, | | |identifier | (40) |PRODUCT_ID is | | |assigned | |the file name | | |to a data product | |without extension | | |by its producer. | |For LOG files of | | | | |any MARSIS data set, | | | | |PRODUCT_ID is the | | | | |file name without | | | | | extension. | ------------------------------------------------------------------------ |PRODUCT_TYPE |This data element | | | | |identifies the | String | EDR, RDR | | |type or category | (40) | | | |of a data product | | | | |within a | | | | |data set. | | | ------------------------------------------------------------------------ |RECORD_BYTES | | |When RECORD_BYTES | | |This element | |describes a file with | | |indicates the |Integer |RECORD_TYPE = STREAM | | |number of bytes | |(e.g. a SPREADSHEET), | | |in a physical | |its value is set to | | |file record, | |the length of the | | |including record | |longest record | | |terminators and | | in the file. | | |separators. | | | ------------------------------------------------------------------------ |RECORD_TYPE |This element | String | | | |indicates the | (20) | FIXED_LENGTH STREAM | | |record format | | | | |of a file. | | | ------------------------------------------------------------------------- |RELEASE_ID |This element | | | | |defines the unique| | | | |identifier | | From 0001 to 9999 | | |associated with | String | | | |a specific release| (4) | | | |of a data set. | | | | |All initial | | | | |releases should | | | | |use a RELEASE_ID | | | | |value of ’’0001’. | | | | |Subsequent | | | | |releases | | | | |should use a value| | | | |that represents | | | | |the next increment| | | | |over the previous | | | | |RELEASE_ID | | | | |(e.g., the second | | | | |release should use| | | | | a RELEASE_ID | | | | | of ‘0002’). | | | | |Releases are done | | | | |when an existing | | | | |data set or | | | | |portion of a | | | | | data set becomes | | | | |available for | | | | |distribution. | | | ------------------------------------------------------------------------ |REVISION_ID |This element is | | | | |a unique | | | | |identifier | | | | |associated with | | | | |a specific | | | | |revision of a | | | | |data set | | | | |release. A data |String | From 0001 to 9999 | | |set revision | (4) | | | |contains the | | | | |initial data | | | | |of a data set | | | | |release or it | | | | |might comprise | | | | |supplementary | | | | |files, that shall | | | | |be appended to | | | | |the data set | | | | |release, | | | | |or updated files, | | | | |that shall replace| | | | |existing files in | | | | |the data set | | | | |release, | | | | |or files existing | | | | |in the release | | | | |that shall be | | | | |deleted | | | | |from the data | | | | |set release. | | | ------------------------------------------------------------------------ |ROWS |Number of rows in |Integer |Number of Data Block | | |a data object. | |in the Data Producy | ----------------------------------------------------------------------- |ROW_BYTES |Number of bytes in| | | | |each data object |Integer | Variable | | |row. | | | ------------------------------------------------------------------------ |SPACECRAFT_CLOCK |This element | |Formation rule is | |_START_COUNT |provides the value| |p/cccccccccc.fffff | | |of the spacecraft |String |where p is the | | |clock at the | (30) |partition number, c | | |beginning of | |stands for | | |an observation. | |SCET_COARSE, and | | | | |f for SCET_FINE | ------------------------------------------------------------------------ |SPACECRAFT_CLOCK | This element | |Formation rule is | |_STOP_COUNT |provides the value| |p/cccccccccc.fffff | | |of the spacecraft |String | where p is the | | |clock at the end | (30) | partition number, c | | |of an observation | | stands for | | | | | SCET_COARSE, and | | | | |f for SCET_FINE | ------------------------------------------------------------------------ |START_TIME |This element | |Formation rule is | | |provides the date | |YYYY-MM-DDThh:mm:ss.fff| | |and time of the | Time | | | |beginning of an | | | | |observation in | | | | |UTC system format.| | | ------------------------------------------------------------------------ |STOP_TIME |This element | |Formation rule is | | |provides the | |YYYY-MM-DDThh:mm:ss.fff| | |date and time | Time | | | |of the end of | | | | |an observation | | | | |in UTC | | | | |system format. | | | ------------------------------------------------------------------------ |TARGET_NAME |This element | String | | | |identifies a | (30) | MARS, PHOBOS | | |target. | | | ------------------------------------------------------------------------ |TARGET_TYPE |This element | String | | | |identifies the | (20) | PLANET, SATELLITE | | |type of a named | | | | |target | | | ------------------------------------------------------------------------ |^INDEX_TABLE |Data objects are | |In an attached label | |^SPREADSHEET |the actual data | |the value is an | |^TABLE |for which the | |integer number | | |structure and | |denoting the first | | |attributes are | String |record of the data | | |defined in a PDS | |object within the file:| | |label. Each data | |the first n-1 | | |product file | |records are part of | | |contains one data | |the attached label, | | |object. The | |and thus n should be | | |PDS uses a pointer| |equal to | | |within the product| |LABEL_RECORDS + 1. | | |labels to identify| |In a detached label, | | |the file location | |the value is the | | |for the object | |name of the file | | |in a data product.| | containing the data | | | | |product, enclosed in | | | | |quotes | ------------------------------------------------------------------------ |^STRUCTURE |This element | |The value is the | | |identifies the | |name of the file | | |name of a file | |located in the | | |located in the | String |LABEL directory | | |LABEL directory | |containing the | | |and containing | |definition of the | | |the definition of | |data object structure, | | |the data object | |enclosed in quotes. | | |structure. | |Such file is | | | | |called just like the | | | | |corresponding data | | | | |file without the | | | | | orbit number, and | | | | | with the extension | | | | | changed to .FMT | | | | | Meaning and valid | | | | | values for keywords | | | | | used in different file| | | | | types within the | | | | | MARSIS data archive. |