Mars Science Laboratory Radiation Assessment Detector

Experiment Data Record

Software Interface Specification

 

                                                         

Version 5.1

5 July 2013

                                                                                                                                         

Prepared by

Scot C. R. Rafkin

RAD Project Scientist


 

Mars Science Laboratory (MSL)

Software Interface Specification

RAD Experimental Data Record (EDR)

 

 

GDS Generating Elements

Operational Product Generation Subsystem (OPGS)

 

Signatory TBD                                         Date


GDS Receiving Elements

Operational Product Generation Subsystem (OPGS)

 

 

Signatory TBD                                         Date

 

 

Concurrence:

 

 

RAD Principal Investigator

Donald Hassler

 

PI                                                                           Date

 

 

RAD Project Scientist

Scot Rafkin

 

 

Project Scientist                                                  Date

 

 

RAD Science Operations Center Manager

Joe Peterson

 

 

RAD SOC Manager                                          Date

 

 

TBD MSL Official

 

 

 

Signatory TBD                                         Date

 


CHANGE LOG

DATE

SECTIONS CHANGED

REASON FOR CHANGE

REVISION

04 Nov 2008

   -

1st Draft Version Released

1.0

30 Sep 2010

All

Removed RDR Descriptions; These will go in RDR SIS

1.1

30 Sep 2010

All

Updated EDR data products list to reflect changes from Sept. RAD Science Team Mtg.

1.1

06 Oct 2010

All

Cleaned up dates/version in header.  Added non-science data descriptions

2.0

12 Oct 2010

Table 1

Replaced with Eddie W. Spreadsheet that is more comprehensive.

2.1

04 March 2011

All

Updated version received from JPL via Helen Mortensen

 

06 April 2011

All

Replaced APXS with RAD throughout document.

3.0

06 April 2011

 

Clarified time parameters

3.0

06 April 2011

 

EDRs now in binary, not ASCII

3.0

06 April 2011

Table 1

Removed “Instrument” column

3.0

06 April 2011

2.1.3 (Dosimetry)

Cleaned up the description of LET and dost histograms.  Updated description to reflect inclusion of dose weighted energy for B and E.

3.0

06 April 2011

3.1.2 Product Generation

“and the original version will be overwritten” has been replaced by “and the version number will be incremented”

3.0

06 April 2011

3.1.3 Data Flow

Similar change to 3.1.2 regarding incrementing EDR versions.  Also specified that even incomplete EDRs will be placed in FEI.

3.0

06 April 2011

3.1.2 and 3.1.3

Removed the reference to “padding with zeroes”.  This cannot be done, since it is not possible to know how long a complete EDR file will be.

3.0

06 April 2011

3.1.4 Naming Convention

Updated to reflect RAD preferences, including the use of underscore between meta data fields

3.0

06 April 2011

Product Identifier Code

Product code for Diagnostic RAE was changed from “EDR” to “ERA”. 

3.0

06 April 2011

4. Detailed Product Description

The EDR consists of a detached label and multiple binary

y files, not just one.  This is now reflected in the description.

3.0

26 April 2011

Products

Added EDM, ETX, EEW products

3.0

26 April 2011

Table 1

Removed Table 1 description of obs packet structure.  Now reference command document.

3.0

04 February 2013

New RAD Model Section

Added description of RAD modes, including a table of modes.

4.0

05 February 2013

Major Update

Added tables describing byte by byte description of data.  Added info on RAD ops modes.

5.0

25 June 2013

All

Minor corrections following peer review

5.1

 


TBD ITEMS

SECTION

DESCRIPTION

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


 

 

CONTENTS

 

1.      INTRODUCTION.. 1

1.1          Purpose and Scope of Document. 1

1.2          Applicable Documents. 1

1.3          EDR SIS Content Overview.. 1

1.4          RAD Science Overview.. 1

2       RAD Operational Modes. 5

2.1          Boot Mode. 6

2.2          Checkout Mode. 6

2.3          Science Mode. 6

2.4          Sleep Mode. 7

2.5          RAD Boot Process and Timing. 7

2.5.1       Initial Power On from MSL. 7

2.5.2       Waking from Sleep. 8

2.5.3       Observation timing. 9

2.5.4       Boot and Sleep time calculation. 10

3       RAD Data Sets. 10

3.1          Observation Packet. 11

3.2          Observation Packet. 11

3.2.1       Histograms. 13

3.2.2       Dosimetry Format. 18

3.2.3       Counters. 19

3.2.4       PHA data. 20

4       Data Processing. 28

4.1.1       Data Processing Level 28

4.1.2       Data Product Generation. 28

4.1.3       Data Flow.. 29

4.1.4       Labeling and Identification. 29

4.2          Standards Used in Generating Data Products. 33

4.2.1       PDS Standards. 33

4.2.2       Time Standards. 33

4.2.3       Coordinate Systems. 34

4.2.4       Rover Navigation (Rover Nav) Frame. 35

4.2.5       Rover Mechanical (Rover Mech) Frame. 37

4.2.6       Local Level Frame. 37

4.2.7       Site Frame. 38

4.2.8       RSM Frame. 39

4.2.9       Arm Frames. 39

4.3          Data Validation. 39

5       Data Product Specifications. 39

5.1          Data Product Structure and Organization. 39

5.2          Label and Header Descriptions. 40

6       Applicable Software. 40

7       Archive Volume Contents, Format, and Generation. 40

Appendix A – Compression. 41

32-bit to 16-bit compression. 41

LogRAD() compression. 42

 

 

 


LIST OF FIGURES

 

Figure 1.  RAD state transition diagram.

Figure 2.  Wakeup flowchart for RAD.

Figure 3.  Decision tree for histograms.

Figure 4.  RNAV coordinate frame.

Figure 5.  Yaw, pitch, and roll definitions.

Figure 6.  Site and rover frames.

 


 

LIST OF TABLES

 

Table 1.  RAD Modes

Table 2.  Typical timeline for example 900 second active time

Table 3.  Format of the RAD Observation Packet.

Table 4.  VIRENA Configuration.

Table 5.  Historgram Types.

Table 6.  Valid APIDs for stopping histograms.

Table 7.  Format for stopping histograms.

Table 8.  Valid APIDs for penetrating histograms.

Table 9.  Format for stopping histograms.

Table 10. Valid APIDs for neutral histograms.

Table 11.  Format for 1-D neutral histograms.

Table 12.  Format for D vs. E neutral histograms.

Table 13.  Dosimetry format.

Table 14.  Format for counter values.

Table 15.  PHA CCSDS packet format.

Table 16.  Housekeeping, System Information and Messages.

Table 17.  Current Message Packet.

Table 18.  Format of individual messages.

Table 19.  wDATA message format.

Table 20.  System information.

Table 21.  System information format.

Table 22.  Processing levels.

Table 23.  Coordinate frames used for MSL.

 

 

GLOSSARY

 

ADC – Analog to Digital Converter

BC-432 – Bicron ™ 432 plastic scintillator used as the “E” and “F” detectors in RAD

CME—Cornoal mass ejection

CODMAC—Committee On Data Management And Computation

CsI – Cesium Iodide, an inorganic scintillating material used as the “D” detector in RAD

Dose – Energy deposited per unit mass, usually in units of Gray (Gy), 1 Gy = 1 joule/kg

Dose Equivalent – Dose weighted by biological effectiveness of the radiation field as determined by integrating the LET distribution against the Quality Factor, with the result given in units of Sieverts (Sv).

DSN – Deep Space Network

EDR – Experimental Data Record

EEPROM – Electrically Erasable Programmable Read-Only Memory

ERT – Earth Receive Time

eV – Electron volt

EVIL— Electronics for VIRENA Logic

FEI – File Exchange Interface: Used to transfer files from OPGS to RAD team

FPGA—Field programmable gate array

GeV – Giga-electron volt, or 109 eV.

GCR—Galactic cosmic rays

HZE – High Charge Particles

keV – Kilo-electron volt, or 103 eV.

JPL – Jet Propulsion Laboratory

L2 – Level 2 processing of RAD data (performed by on-board software)

L3 – Level 3 processing of RAD data (performed by on-board software)

LEO—Low Earth orbit

LET – Linear Energy Transfer, the amount of energy deposited by an energetic particle per unit track length in matter, usually in units of keV/micron where the medium is assumed to be water.

LST – Local solar time

MER—Mars Exploration Rover

MeV – Mega-electron volt, or 106 eV.

MeV/nuc – Unit of kinetic energy for protons and heavy ions.

MOLA—Mars Orbiter Laser Altimeter

MPCS— Mission Data Processing and Control Subsystem

MSL—Mars Science Laboratory

Quality Factor – A dimensionless quantity representing biological effectiveness as a function of LET, usually written Q(L).

OPGS—Operations Product Generation Subsystem

PDS – Planetary Data System.

PHA – Pulse Height Analysis or Pulse Height Analyzed

Quality Factor – Empirically-determined factor to characterize the biological effectiveness of various types of particle radiation.

PROM – Programmable Read-Only Memory

RAD – Radiation Assessment Detector.

RAE – RAD Analog Electronics.

RAM – Random Access Memory

RCE – Rover Compute Element

RCLK – RAD Clock

RCT – Record Creation Time

RDE – RAD Digital Electronics.

RDR – Reduced Data Record

REB – RAD Electronics Box.

RNAV – Rover Navigation

RSE – RAD Sleep Electronics.

RSH – RAD Sensor Head.

SCET – Spacecraft Event Time

SCLK – Spacecraft Clock

SEP—Solar Energetic particle event

SIS—Software Interface Specification

TLST – True local solar time

UTC – Universal coordinate time

VIRENA – Voltage-Input Readout Electronics for Nuclear Applications.

 


1.  INTRODUCTION

1.1    Purpose and Scope of Document

This document describes the format and content of the Mars Science Laboratory (MSL) Radiation Assessment Detector (RAD) Experiment Data Record (EDR).  The Planetary Data System (PDS) compliant EDR data archives satisfy in part the data obligations and requirements for the MSL RAD experiment.  The Reduced Data Record, containing higher level calibrated and processed data, completes the obligation.  RDRs are described in the RDR Software Interface Specification document.

 

1.2    Applicable Documents

 

1. Mars Exploration Program Data Management Plan, R. E. Arvidson et al., Rev. 4.0, June 15, 2011.

 2. MSL Experiment Data Record (EDR) and Engineering Cameras Reduced  Data Record (RDR) Archive Volume Software Interface Specification (SIS),  VERSION 1.0 Draft, JPL D-64995, July 26, 2012.



3. Mars Science Laboratory Archive Generation, Validation, and Transfer Plan,  J. Crisp and P. Theisinger, JPL D-35281, MSL-214-1333, May 28, 2010.


4. MSL Radiation Assessment Detector (RAD) Science Team and PDS Planetary Plasma Interactions Node Interface Control Document (ICD), PDS PPI Node, Version 1.0, February 3, 2006.

 

1.3    EDR SIS Content Overview

This EDR software interface specification (SIS) describes the format, content, and generation of the RAD Experiment Data Record for the production of PDS archive volumes.

 

1.4    RAD Science Overview

The Radiation Assessment Detector (RAD) investigation is an investigation to detect and analyze the most biologically-significant energetic particle radiation on the Martian surface as a key element of the Mars Science Laboratory (MSL) mission. Fully characterizing and understanding the radiation environment on Mars is fundamental to quantitatively assessing the habitability of the planet, and is essential for future crewed Mars missions. RAD also addresses significant aspects of the MSL investigation, including the radiation effects on biological potential and past habitability, as well as keys to understanding the chemical alteration of the regolith due to impinging space radiation.

The RAD Level 1 Science Objectives are:

·         To characterize the energetic particle spectrum at the surface of Mars,

 

 

 

 

Characterize the Energetic Particle Spectrum on Mars

Galactic cosmic rays (GCRs) are high energy (100 MeV/nuc to 10 GeV/nuc and above) particles thought to be produced by supernovae shocks outside the heliosphere and are composed of roughly 89% protons, 10% alpha particles (He), and 1% heavier nuclei. GCRs are modulated by the solar wind and the 11-year solar cycle, with roughly 30% higher flux at solar minimum, and show variability with respect to elemental composition and energy. Specifically, near solar minimum, substantially higher fluxes of lower-energy particles can access the inner heliosphere compared to times near solar maximum. Because of their high energies and continuous nature, GCRs are the dominant source of background radiation at the Martian surface, and are responsible for the production of secondary particles via complex interactions in the atmosphere and regolith. The radiation dose from these secondary particles is comparable to that from the primary GCR.

The Earth's magnetic field (magnetosphere) and deep atmosphere (~ 1000 g cm-2) effectively shield us from most of the hostile interplanetary radiation environment. No primary cosmic rays reach the surface of the Earth. However, this is not the case for Mars. Mars has no significant magnetosphere and only ~1-2% of the atmospheric mass of Earth. In the thick terrestrial atmosphere, most of the GCR energy deposition, and secondary particle production, occurs in the first 20 km altitude, while in the thin Martian atmosphere this occurs at ground level.

The secondary particles generated within the atmosphere include neutrons and gamma rays that, due to their lack of electric charge, penetrate the remaining column of the Martian atmosphere rather freely. The gamma rays do not contribute significantly to the radiation dose at the surface, but the neutrons do.  Also, some secondary neutrons generated within the regolith backscatter to the surface, where they contribute to the dose. GCR heavy ions also collide with carbon and oxygen in the atmosphere and regolith to produce a flux of energetic charged nuclear fragments at the surface. Some GCR heavy ions, such as C, N, and O are relatively abundant and have a significant probability to survive traversal of the atmosphere intact. Despite their relatively limited range in matter, these particles have high quality factors and therefore need to be considered in radiation risk assessments.

Solar energetic particles (SEPs) are produced by the Sun as a result of shocks from coronal mass ejections (CMEs) associated with large solar storms and flares; they are dominantly protons. Although most SEPs have energies lower than 100 MeV/nuc, the flux of SEPs is highly variable and can vary by more than 5 orders of magnitude on time scales of hours to days, reaching energies as high as several GeV. About 140 MeV/nuc of kinetic energy is needed for protons and helium ions to penetrate the Martian atmosphere. Typical SEP events produce a flux composed of 98% protons, 1% alpha particles and 1% heavier nuclei. Because most SEPs have energies below 100 MeV, much of their flux does not reach the Martian surface. However, large events produce a significant SEP flux at energies above 100 MeV/nuc. Thus, although sporadic, SEP events may overwhelm the background GCR radiation at the Martian surface.

Determine the Radiation Dose Rate for Humans on Mars

Presently, no radiation exposure limits are established for surface Mars missions, but limits for low Earth orbit (LEO) provide a reasonable baseline from which to compare astronaut safety and risk.  The LEO limits are classified into short (30-day), annual, and career durations, and are also a function of the exposed organs.  Astronauts conducting Martian surface operations would be exposed to continuous GCR radiation, and potentially large bursts of SEP radiation. Although the GCR flux is less at solar maximum, the probability of large SEP events is greater, and the combined dose equivalent can easily approach annual exposure limits for blood forming organs, particularly at high elevations where the atmospheric column above is minimal.  Thus, it is critical to quantify through direct measurement the total radiation environment, including the baseline GCR flux and the secondaries it produces, as well as the range of episodic SEP radiation at the surface of Mars well in advance of any future manned missions in order to properly assess the safety risks and to develop potential mitigation strategies. RAD will provide the precursor measurements necessary to fully characterize GCR and SEP radiation, assess potential risks, and enable mitigation strategies to be adequately designed in preparation for future manned Mars missions.

 

Transport of High-Charged (HZE) Particles through the Martian Atmosphere

The lack of direct observations necessitates the use of radiation transport models of the Mars atmosphere (e.g., HZETRN, SIREST).  However, radiation transport models that provide input to dosimetry models are static, driven by radiation inputs at the top of the atmosphere and MOLA topographic data only.  Unfortunately, the true nature of the surface radiation environment is still highly uncertain.  The model outputs need to be tested, and compared to observational ground truth in order to be validated and considered complete to the point of ensuring astronaut safety on future manned missions. Measurements from RAD will be compared to output from existing models of these interactions.  Disagreement between observations and model results elucidate weaknesses in the model physics, or the understanding of the modelled interactions, and will be used as feedback for improvement.

Characterize the Radiation Hazard for Extant Life on Mars

The radiation hazards for indigenous Martian life forms are unknown, but most current studies assume that life elsewhere will be based on polymeric organic molecules, and will in an overall sense, share with terrestrial life the vulnerability to energetic radiation.  Thus the risks to extant organisms are assumed to be analogous to the risks to future human explorers.  Energetic charged particles ionize molecules along their tracks.  This ionization creates OH and other damaging free radicals which can in turn break DNA strands within cells. Double strand breaks are most significant, as they may be mis-repaired, leading to mutagenesis. Surviving cells may become cancerous.  While Martian life may not be based on DNA, most astrobiologists assume that it will require some system of heredity based on large polymeric organic molecules.  Thus it will likely have similar vulnerability to energetic radiation. 

RAD will quantify the flux of biologically hazardous radiation at the surface of Mars today, and measure how these fluxes vary on diurnal, seasonal, solar cycle and episodic (flare, storm) timescales.  Through such measurements, we can learn how deep life would have to be today for natural shielding to be sufficient.  This depth can be compared to the calculated diffusion depth of strong oxidants which will destroy organic molecules in the near surface environment of Mars today, and thus learn whether radiation or oxidizing chemistry will determine the minimum depth needed to drill to look for extant life on Mars today.

Much attention has been given to the possibility of life in subsurface voids (caves) that will be protected from the surface radiation environment.  It has been noted that the cave environments likely to exist on Mars could possibly facilitate the evolution of macroscopic life in the subsurface, as opposed to merely microbial life.  The shielding required to make such an environment suitable for life will depend on the surface radiation.  Measurements of the surface radiation will allow us to determine how deeply buried such voids must be to be safe from the high-energy radiation environment at the surface.  This, in turn, will directly impact future strategies involving drilling and digging to search for subsurface life.

While the idea that life exists today on Mars is controversial, the idea of life on Mars in the past is much less so. The recent discoveries by the Mars Exploration Rovers (MER) and Mars Express of evidence for abundant surface liquid water in the past reinforce the widespread view that Mars, in the past, may have been a habitable planet.  In seeking to understand the limits of sur­face habitability in the past on Mars, it is important to be able to characterize the radiation environment during past epochs when surface water existed, the climate was more moderate, and presumably the atmosphere was substantially thicker than at pre­sent.  Radiation is an important source of biological mutations, and as such may have been the domi­nant source of genetic diversity in the past on Earth and presumably on any planet (perhaps including Mars) where life is based on a genetic code (which is part of most definitions of life). How would the thicker past atmosphere, required for a warm, wet early Mars, modify the radiation environment?  According to accepted models of atmospheric evolution, how have the dose rates of radiation capable of doing tissue damage, and radiation-induced mutation, varied throughout Martian history?  How would extreme radiation events (solar flares, gamma ray bursts) have affected evolution of past organic life on Mars?  For any effort to understand this past radiation environment of Mars, the starting point must be a more thorough understanding of the role that the current atmosphere plays in modulating and altering the radiation from space. Understanding how radiation interacts with the contemporary atmosphere permits the extrapolation of this interaction with the ancient, thicker atmospheres.

Chemical and Isotopic Effects of Radiation on the Martian Surface and Atmosphere

Space “weathering” is a well-known but fairly poorly understood phenomenon that alters the chemistry and appearance of the surfaces of airless bodies.  It usually consists of two components, that due to micrometeorite bombardment, and that caused by the impingement of charged particles on the surface of asteroids and airless satellites. An enormous fluence of high-energy charged primary and secondary particles has interacted with the Martian regolith throughout its history. There is thus reason to believe that radiation contributes significantly to the unique chemistry of the Martian surface.  The unique space weathering on Mars can only be understood and quantified with direct observations of energetic particles at the surface.

One of the primary objectives of the MSL mission is to emplace mobile analytical chemistry instruments at the surface of Mars, including those that can quantify light elements. A detailed analysis of the makeup of both bulk rocks and their surfaces will pave the way for a far greater understanding of the weathering and alteration processes active on Mars. RAD will supply the basic input to chemistry models that up to now has been lacking - the space radiation environment of the surface of Mars. Together with the analytic chemistry experiments on MSL, RAD will provide real constraints on how primary rocks weather to their current, highly altered state.

2    RAD Operational Modes

The RAD instrument is designed to operate autonomously from the MSL Rover Compute Element (RCE) to the maximum extent possible, thus minimizing the impact of the instrument on the RCE systems. RAD modes (Table 1) are used to control the instrument activities and can be transitioned either autonomously or via commands from the RCE.   Figure 1 below shows the RAD state transition diagram with allowed transitions between modes and transition methods.  The dotted lines show the autonomous transition paths and the solid lines indicate commanded transition options. 

 

Table 1.  RAD Modes

State

Description

Data Produced

Off

The power to the RAD is off

None

Boot

Check PROM and EEPROM integrity.

Configure instrument for current environment.

None

Science

Radiation science data is collected and processed

Science Data is accrued, but

any command producing data

packet will inherently

change mode to Checkout

Checkout

Memory loads, dumps, RAM checkout, self-diagnostics and data transfer to RCE.

Simulated-Science, Messages Housekeeping

Shutdown

Shutdown transition to sleep state.  Once shutdown has begun RAD will be powered for ~5 seconds however it will be unresponsive to commands. If a sleep time >0 then RAD will transition to 'Sleep' state. If sleep time==0 then RAD will go to 'BOOT' state.

Obs packet is stored, but no data is transmitted by RAD.

Sleep

Rover power to RAD is on. Power converter within RAD is off. (RDE not powered)  RAD-RSE monitors receive line for activity, or waits prescribed sleep duration.

None

Text Box:  
Figure 1. RAD state transition diagram.

2.1    Boot Mode

As the RAD instrument transitions through the Boot mode it will initialize and configure the instrument for science operations according to the latest loaded configuration data and the determined current environment. The RAD instrument will transition through the Boot mode upon a power on cycle and upon exit from the Sleep mode. Any changes to configuration parameters which have occurred since the last cycle through Boot will be applied. The RAD instrument takes approximately 20 seconds to complete the Boot up initialization and configuration activities. In addition to setting configuration parameters, the current radiation environment is checked during the Boot sequence and parameters are set accordingly.

2.2    Checkout Mode

Checkout mode is the mode used for communication sessions between the RCE and the RAD instrument.  The RCE can transition RAD into the Checkout mode via commands. When RAD is in Sleep mode, it will take multiple commands to transition the system into Checkout mode.  The first command will cause a toggle on the RCE command line that will trigger RAD to transition into Boot mode. Once RAD transitions through Boot mode to Science mode, the RCE will then have 60 seconds to send another command to cause a transition into Checkout mode. As during normal Science mode operations any command other than Noop, Shutdown, State, or time_sync will cause a transition into Checkout mode. If a transition to Checkout mode does not occur, and a time_sync is not received by RAD within the 60 second window, RAD will automatically transition back to Sleep mode. In nominal operations, RAD will be placed in Checkout mode by the RCE to perform data transfers or change observation configuration parameters. 

2.3    Science Mode

Science mode is the operational setting whereby the data contained in the EDR is produced.  In science mode RAD collects and processes science data. Science mode is entered autonomously each time the RAD instrument transitions through Boot mode. Exiting science mode can occur via a command or via an autonomous transition into sleep at the end of a data taking sequence. Science mode is automatically transitioned to Checkout mode when any commands other than Reset, Noop, Shutdown, State, or time_sync are received. The length of the data taking sequence is controlled via the ‘On Time’ parameter in the active configuration block. At the end of each data collection cycle, the science data is processed and then stored in non-volatile memory each time a nominal transition into Sleep mode occurs. This transition is initiated either via a timeout or a ‘Shutdown’ command or Checkout mode occurs. NOTE: Commanding RAD into the Sleep mode using the ‘State (SLEEP)’ command will cause a transition to sleep.

2.4    Sleep Mode

The Sleep mode places RAD in a low power state between science activities. The RAD Detector Electronics (RDE) is powered off in this mode. The RAD Sleep Electronics (RSE) monitors the command Rx line for activity or waits until the sleep duration time expires. When the RSE detects a command or an expiration of the sleep duration, a transition to Boot mode is initiated. Note – since RAD is not in an active state during Sleep, any command sent in this state will simply cause a transition to Boot mode. The command itself will not be processed. RAD is placed into Sleep mode at the completion of a science observation or via a State (SLEEP) or Shutdown command. Transitions caused by the completion of a science observation or via the Shutdown command will cause RAD to save any collected science data to non-volatile memory. A commanded State (SLEEP) command will cause a transition to Sleep mode without saving data.  If RAD wakes from a nominal sleep, RAD firmware will calculate the current timestamp based on the duration of sleep cycle. However, if RAD is awakened early, or initially powered (these are handled identically for RAD firmware), then it is assumed the Rover Compute Element (RCE) is active. In either of these cases, RAD does not know what time it is, and it relies on the RCE to send a timestamp command within 60 seconds of powering or waking RAD.

2.5       RAD Boot Process and Timing

RAD can enter the Boot mode via either an initial power up or by waking from Sleep.  Awakenings can occur in two ways – via a toggle on the command Rx line or via expiration of the sleep time period.  The following sections outline the activities which occur in each case.  The boot up process takes approximately 20 seconds and during this time no commands will be processed by RAD.

2.5.1  Initial Power On from MSL

When the RAD instrument is initially powered on from the MSL, it immediately enters the BOOTUP state.  In the nominal case where the code/table image located in the EEPROM has no errors, the image (code/table) is copied to RAM and control of the software transfers to RAM code.  RAD will then “pre-configure” the sensor head in order to obtain a preliminary assessment of the radiation environment. RAD will then configure the RAE accordingly.  This begins the “observation” cycle for the RAD instrument.  The observation will continue for N minutes, and, unless interrupted by MSL activities (commanding, checkout, power off), will be followed by shutdown (essentially storing data to non-volatile RAM), and finally sleep cycle.

In summary, the typical Steps for initial power on from the MSL are:

·         MSL powers RAD.

·         Firmware begins RSH initialization for “pre-observation” data.

·         Firmware begins RSH configuration for observation based on preliminary count rates. Depending on # of events, firmware will configure subsequent observation as “nominal” or “solar event”.

·         RAD begins observation.

·         Text Box:  
Figure 2. Wakeup flowchart for RAD.
RAD receives current mission time from Rover Compute Element (RCE). If RCE is powered. If not powered, RAD will determine estimate of time by sleep duration.

2.5.2  Waking from Sleep

In nominal sleep preparation, RAD firmware will first store appropriate system information into persistent memory storage, then load the sleep duration to the RSE, and finally initiate the “sleep” cycle by setting a flag.  The RSE will power off the RDE and RAE portions of RAD, and then proceed to “countdown” the sleep time.  At the conclusion of the full sleep duration, the RSE will then power up the RDE and RAE, and RAD will begin bootup.  The RSE will provide a flag indicating if RAD is “waking” from sleep (nominal sleep), was prematurely awakened (due to serial line toggling from the MSL), or if it is an initial power on from the MSL.  The only difference between “nominal” sleep and either waking early or being initially powered is the handling of the timestamp for data collected.  

If RAD wakes from a nominal sleep, RAD firmware will calculate the current timestamp based on the duration of sleep cycle.  However, if RAD is awakened early, or initially powered (these are handled identically for RAD firmware), then it is assumed the Rover Compute Element (RCE) is active.  In either of these cases, RAD does not know what time it is, and it relies on the RCE to send a timestamp command within 60 seconds of powering or waking RAD.  All these processes are summarized in Figure 2.

2.5.3  Observation timing

For an observation, there are several epochs and durations defined relative to timing.  Further complicating the observation timing is the coarse resolution of the sleep timer and the 1/16 timestamp for events.  Below (Table 2) is an example timeline and associated timing.  Actual timings may differ during operation.

Table 2: Typical timeline for example 900 second active time.

Event

RAD FPGA Time(s)

Comment

Wake up

0

Or initial power on.

Boot

~6

Code has initialized (BOOT MET)

Config RAE

6

Configure for pre-observation

Pre-obs

9

Pre-obs start (currently 10 seconds for complete pre-obs)

Config RAE

19

Configure for main observation

Start Obs

22

Begin the regular observation (default or solar) (Start Obs timestamp & Observation Timestamp.

End Obs

900

The observation ends with RAD FPGA Time == active duration Sleep Observation timestamp

Store obs

900

Start storing observation to NVM

Sleep

904

RAD goes to sleep.

The active observation time is less than the on time by several seconds.  It is the 'End Obs' - 'Start Obs' times, for this example (900 seconds 'on time' with 10 second pre-obs), it would be 878 seconds (900-22).

Internally, RAD divides the 'on_time' into 16 equal time segments, and uses 4 bits to represent in which 1/16 the event occurred.  The active observation duration is updated to be the next largest integer value divisible by 16.   E.g. if  300s is requested, RAD will update to 304 seconds because 304 is the next highest value that is divisible by 16. 

The observation packet contains a timestamp that is equal the RAD FPGA clock when science observation begins.  This time is known as RAD Clock (RCLK).  Also, within the observation the RCLK contained in the Housekeeping portion (see below) will indicate when the observation has concluded and RAD is preparing for storage and shutdown.  So the duration of the observation can be calculated from these two RCLKs.  See 4.2.2. for a description of time standards.

 

2.5.4  Boot and Sleep time calculation

The RAD boot time is determined one of three ways:

 

1. From power-on or external source wakes RAD up.

RAD does not know what time it is and will set the boot time equal to zero.

 

2. Normal wakeup from sleep.

RAD will copy the NextWakeupMET system variable that was stored at the conclusion of the previous shutdown as the current boot RCLK.  This is RADs best estimate as to when RAD would next wake-up.

 

3. Receiving time sync command.

RAD will use the timesync() SCLK and subtract the internal timer.  The internal timer is a 1-sec timer that starts incrementing at power up. 

 

The desired sleep duration is divided by the RAD sleep tick timer to obtain an integer number of ticks. (the finest resolution of the sleep timer).  Then to more accurately approximate the next wake SCLK, RAD multiples the ticks by the estimated sleep tick timer value (which is adjusted with temperature).

 

Note that the RAD timing (RCLK) is only synchronized during communication with the RCE and can drift with respect to SCLK due to the temperature dependent timing of the RAD tick timer.  Although the tick timer calculation factors in the temperature dependence, some error is expected, and this error can increase as the time between RCE communication increases.  The times reported in the EDR are RCLK and no attempt has been made to adjust those to SCLK.

3    RAD Data Sets

Two types of data generated from the RAD experiment will be delivered to PDS.  The first type is the EDR containing NASA Level 0 data that mirror the raw instrument data obtained from telemetry (Table 1), but packaged in a PDS compliant format.  JPL OPGS is responsible for PDS compliant packaging of the EDR.  The second type is the RDR that contains NASA Level 1 and higher data products produced and derived from EDR data input.  The RAD project is responsible for generating PDS compliant RDR archives.  The RDR products are described in the RDR SIS document.

 

The EDR data are organized into files containing all observations taken over a Mars day (sol) as determined by the start time of the observation. A single RAD observation is nominally to be taken over a 15 minute period, but the length and cadence of the observation is commandable and will typically range from 5-30 minutes in length and once per hour to continuous. Consequently, there could be anywhere from 1-48+ RAD observations in an EDR data file with each observation being anywhere from 5-30 minutes in length. The actual number of observations will vary depending on the operations on a given sol. In the case of the EDR, observations are concatenated chronologically. 

 

3.1    Observation Packet

 

A raw RAD observation packet telemetered to Earth contains five major elements in the following order: housekeeping, system information, messages, science, and PHA records. PHAs are considered science, but are given their own element because of their variable length. Within the science element, there are histograms (described in detail below) and count data.  The RAD observation packet is highly configurable.  Housekeeping, system information and messages will always be present.  Science and PHA records may not be present, or may be present with a variable number of products within.  Table 3 summarizes the format of the RAD observation packet. 

 

An EDR data file contains all the raw RAD observations taken over a Mars day (sol) as determined by the start time of the observation. Therefore, it is possible that an observation may begin in one sol and extend into the next, but it will be archived only as data within the starting sol.  The contents of the EDR mirror the telemetry packet sent by RAD.  The data is, however, split into individual files for each of the data products within the packet. 

 

A RAD Science EDR data file consists of binary data with a detached ASCII PDS label that can be one of types: ESD or EHP.  Both file types have the same structure and format as described in Section 3.  A science data observation is 16400 bytes.  Since the number of observations in a sol are variable, the total size of the science data is N*16400 where N is the number of observations started within a given sol.  Additionally, OPGS adds 12 bytes in the front of the file and 4bytes at the end.  These bytes are padding and can be ignored.  The total files size is then N*16400+12+4.

3.2       Observation Packet

Table 3.  Format of the RAD Observation Packet

Field

Size (bytes)

Optional?

Description

CCSDS prime

6

N

Overall CCSDS header with SCLK

CCSDS SCLK

4

N

SCLK timestamp of obs packet.

Block writes

2

N

Number of times this block has been written

Block

2

N

Bitfield: upper 4 bits= test mode lower 12 bits = block number

Houskeeping

88

N

See 3.2.4.1

System Information

 

N

See 3.2.4.1

Messages

100

N

See 3.2.4.1

Science CCSDS

6

N

CCSDS for science products (no SCLK in this CCSDS only primary).

Stopping A1

400

Y

See 3.2.1

Stopping A2

400

Y

See 3.2.1

Penetrating A2

160

Y

See 3.2.1

Neutral D

112

Y

See 3.2.1

Neutral E

112

Y

See 3.2.1

Neutral DE

144

Y

See 3.2.1

Counters

226

N

See 3.2.3

Dosimetry

314

Y

See 3.2.2

Science xsum

4

N

Fletcher xsum for Science CCSDS packet

VIRENA

222

Y

CCSDS VIRENA settings See Table 4: VIRENA Configuration structure for a single channel.

PHA CCSDS

6

Y

CCSDS wrapper for PHA data.

PHA

var

Y

8-bit compressed ADC PHA data. Fills remaining space of 16k obs packet.

See 4.4.6

PHA xsum

4

Y

PHA CCSDS xsum

Detect Select

5

N

Indicate the detect select used

Obs packet xsum

4

N

Last 4 bytes of obs packet (bytes 16381-16384)

Extra PHA

vary

Y

Extra 16k packet of all PHA data.

L2 Configuration

 

Y

Dump of L2 configuration used.

 

The VIRENA configuration consists of 48-bit field for each of the 36 channels.  The configuration uses 6 bytes per channel.

            Table 4: VIRENA Configuration structure for a single channel.

Field

bits

Description

unused

47-41

msb

chan1

35-40

Channel number

unused

34

unused

ecal

33

ecal

sshape

31-32

Slow shaper setting

ingain

29-30

Input buffer gain

pdown

28

Power down

unused

27

unused

fshape

25-26

Fast shaper setting

peak

21-24

Peak shaper

unused

20

unused

fdac

12-19

Fast DAC threshold

unused

11

unused

sdac

3-10

Slow DAC threshold

ena_s

2

Enable slow trigger

ena_f

1

Enable fast trigger

fm

0

Follower mode

 

3.2.1  Histograms

Due to storage and telemetry limitations, it is not possible to transmit all valid events as PHA records. However, data from all valid events are stored in histograms.  Using count data, and with the reasonable assumption that the stored PHA data are an unbiased sample of the entire collection of events taken during the observation, full spectra can be reconstructed.

 

Histograms are one- or two-dimensional arrays.  The units on for the dimension of each histogram vary, but correspond to some variant of energy deposited in a detector (see below).  The value of the array element is the number of valid events in that bin. Detector energies are determined by the onboard L2 data analysis algorithm, which uses nominal calibration factors.

 

In onboard Level 3 (L3) processing, either slow trigger tokens, or explicit analysis of detector energies, determine the histogram to which a given event belongs. Twenty histograms are defined in the L3 software, in seven distinct categories. Unlike PHAs, which are time tagged to within 1/16th of an observation, a histogram is constructed from an entire observing period, with the exception of the dosimetry histograms from the B the E detector,  which have 16 bins to explicitly track energy vs time.

 

The light output of the E detector (a plastic scintillator) is non-linear with deposited energy. This effect is known as “quenching” of the light output.  Quenching produces a complex, non-linear relationship between the light output of the scintillator and the energy deposited. Quenching is not taken into account in the EDRs. 

 

To determine histogram binning, an onboard function called RDE_log2 was used, which takes a value (deposited energy, in units of 2 keV) and returns a compressed 8-bit value with a 5-bit mantissa and 3-bit fraction.   The fraction represents the value, in units of 1/8th, to the right of the decimal point, while the mantissa represents the power of 2. For example, for an input value of 37, RDE_log2 returns a decimal value of 41, equal to 29 hexadecimal and also to 00101001 binary. The bottom 3 bits give a value of 1, so to the right of the decimal point we have a value of 0.125. The top five bits are 00101, or 5 decimal, so that the total result is 5.125 decimal. The actual base-2 logarithm of 37 is 5.21 decimal. As a further example, for an input of 37000, log2_RDE returns 79 hexadecimal, or 01111001, or 15.125 after translation; the actual base-2 logarithm of 37000 is 15.175. Thus the RDE_log2 function as implemented produces only minor losses in fidelity.

 

A “stopping” event is one in which a charged particle enters RAD but does not pass completely through the instrument. These are charged particles that stop in B, C, D, or E. Validity tests performed in L3 look for sensible patterns of energy deposition within the stack and determine the stopping point.  Four two-dimensional histograms handle these events. There are two hardware priorities (low and high, corresponding to low-LET and high-LET events, respectively), and two segments of the A detector (A1 and A2) which can be hit. Simple logic determines which of the four cases applies and which of the four histograms will be filled. In each histogram, the quantity RDE_log2[E(A) × E(total)] is the y-axis variable and RDE_log2[E(total)/E(A)] is the x-axis variable, where E(A) is the deposited energy in the A detector and E(total) is the sum of deposited energies in the A, B, C, D, and E detectors. 

Text Box:   Figure 3.  Decision tree for histograms.

A “penetrating” event is caused by a charged particle that passes entirely through all RAD detectors (These are higher-energy charged particles hitting A2, B, C, D, E, and F2).  In most cases it is not possible to determine the total energy for these highly relativistic particles. To be considered a penetrating particle, the relevant detectors must record hits, and the event must pass additional sanity tests on either the pattern of fast tokens or on the pattern of deposited energy. The valid penetrating particle histogram is a two-dimensional array of RDE_log2[E(ABC)] vs. RDE_log2[E(E)/E(ABC)]. The notation E(ABC) refers to the sum of energy deposited in the A, B, and C detectors. The flowchart in Fig. 3 illustrates the logic used to populate the four histograms for both penetrating and stopping charged particles. 

 

Note that all 2-D histograms are stored in C-style rank-order format.

Table 5.  Histogram types and specifications

Histogram Group

# of histograms in group

Description

Quantity Plotted or Summed

Comments

Stopping charged particles (2-d)

4

Low-energy charged particles that stop in C, D, or E.

x=log(T/A)

y=log(T*A) where

T=A+B+C+D+E

A1 or A2 hit,

2 priorities

Penetrating charged particles (2-d)

2

Higher-energy charged particles hitting either A2, B, C, D, and E.

x=log(A+B+C)

y=log[E/(A+B+C)]

A2 hit,

2 priorities

 

 

Neutral particles (2-d)

2

Neutral particles that deposit energy in D and/or E

x=log(D)

y=log(E)

2 priorities

Neutral (1-d)

4

Neutral particles in D and E

log(D), log(E)

2 priorities

 

There are two types of neutral histograms.  The first type is one-dimensional; there are two such histograms, one for binned energy counts in RDE_log2[E(D)]  and one for binned energy counts RDE_log2[E(E)]. The second type of histogram 2-dimensional, with RDE_log2[E(D)] plotted against RDE_log2[E(E)]. One set of these three histograms exists for each of the two hardware priorities, so that there are 6 neutral particle histograms in total.

 

Table 5 summarizes the histograms defined in Level 3. Here the quantity “T” stands for total energy, that is, the summed energy depositions in A, B, C, D, and E. The designation “log” in the table refers to the log2_RDE function explained above.  All histograms are obtained by binning over the entire observation period.

3.2.1.1     Stopping Histogram Format

There are up to four distinct stopping histograms stored in a single observation packet.  The following table lists the valid apids:

 

Table 6: Valid APIDs for stopping histograms.

APID

Description

0x210

Events pass through A1 with low priority

0x211

Events pass through A2 with low priority

0x212

Events pass through A1 with high priority

0x213

Events pass through A2 with high priority

 

Table 7. Format for Stopping histograms in observation packets.

Field

Size (bytes)

Compress?

Description

Sync

2

n

0xede9

Apid

2

n

See Table 6: Valid APIDs for stopping histograms.

Length

2

n

Length in bytes of packet

numXbin

1

n

Number of xbins

numYbin

1

n

Number of y bins

Overflow

2

y

Sum of all counts above max Y

underflow

2

y

Sum of all counts below min Y

counts[16][12]

384

y

Data

checksum

4

n

Fletcher xsum

Compressed fields use the 32-16bit compression as given in Appendix A.

3.2.1.2     Penetrating Histogram Format

There are up to two distinct penetrating histograms stored in a single observation packet.  Because of geometry inconsistencies, RAD does not provide penetrating histograms that pass through A1.  Table 6 lists the valid apids:

 

Table 8.  Valid APIDs for Penetrating Histograms

APID

Description

0x221

Events pass through A2 with low priority

0x223

Events pass through A2 with high priority

 

Table 9.  Format for Penetrating histograms in observation packets.

Field

Size (bytes)

Compress?

Description

sync

2

n

0xede9

apid

2

n

See Table 8: Valid APIDs for penetrating histograms.

length

2

n

Length in bytes of packet

numXbin

1

n

Number of xbins

numYbin

1

n

Number of y bins

overflow

2

y

Sum of all counts above max Y

underflow

2

y

Sum of all counts below min Y

counts[24][3]

144

y

Data

checksum

4

n

Fletcher xsum

Compressed fields use the 32-16bit compression as given in Appendix A.

3.2.1.3     Neutral Histogram Format

There are up to six distinct neutral histograms stored in a single observation packet.  The following table lists the valid apids:

 

Table 10. Valid APIDs for neutral histograms.

APID

Description

0x230

Events pass through D with low priority

0x231

Events pass through E with low priority

0x233

Events pass through D with high priority

0x234

Events pass through E with high priority

0x232

Events pass through D and E with low priority  (DvE histogram)

0x235

Events pass through D and E with high priority (DvE histogram)

 

Table 11.  Format for 1-dimensional neutral histograms in observation packets.

Field

Size (bytes)

Compress?

Description

sync

2

n

0xede9

apid

2

n

See Table 10: Valid APIDs for neutral histograms.

length

2

n

Length in bytes of packet

numXbin

1

n

Number of xbins

numYbin

1

n

Number of y bins

overflow

2

y

Sum of all counts above max Y

underflow

2

y

Sum of all counts below min Y

counts[48]

96

y

Data

checksum

4

n

Fletcher xsum

 

Table 12. Format for D vs E neutral histograms in observation packets.

Field

Size (bytes)

Compress?

Description

sync

2

n

0xede9

apid

2

n

See Table 10: Valid APIDs for neutral histograms.

length

2

n

Length in bytes of packet

numXbin

1

n

Number of xbins

numYbin

1

n

Number of y bins

overflow

2

y

Sum of all counts above max Y

underflow

2

y

Sum of all counts below min Y

counts[8][8]

128

y

Data

checksum

4

n

Fletcher xsum

Compressed fields use the 32-16bit compression as given in Appendix A.

3.2.2  Dosimetry Format

Total energy deposited is recorded in both the B and E detectors.  For both the B and E detector, the energy is stored as a one-dimensional histogram of the (summed) energy accumulated in the detector over 1/16th periods of the observation. Even though these are histograms similar to those previously described, they are encapsulated into the dosimetry packet.  The definition of radiation dose is the energy deposited in a volume divided by the mass contained in the volume. Thus the dosimetry histograms are not truly in units of dose, rather each time bin of the histogram contains the sum of the energy depositions within that measurement interval. 

 

The Dose Weighted Energy in B and E are also recorded.  The total energy within 16 energy bins integrated over the entire observation period are stored as a histogram of E(B) or E(E) vs DE(B) or DE(E), respectively.

 

Finally, RAD records Linear Energy Transfer (LET) spectra for events detected in B (charged particles). To do this, RAD measures energy deposited in the A silicon detector in front of B. LET histograms are one-dimensional histograms of the counts in the B detector within a given energy bin DE(B) over the entire observation period. There are 44 LET energy bins.  Cuts are made to require reasonable consistency between DE(B) and DE(A), noting that a valid charged particle energy deposition in B requires a roughly similar energy deposition in A. Both A-inner and A-outer are used, so two LET histograms are kept. LET spectra are binned by RDE_log2[E(B)]>>1.  The energy values need to be divided by the thickness of the Si detector to obtain proper LET units of energy deposition per distance. 

Table 13: Dosimetry format for observation packet.

Field

Size (bytes)

Compress?

Description

sync

2

n

0xede9

apid

2

n

0x250 or 0x251

length

2

n

Length in bytes of packet

tdose_B[16]

32

y

total dose of B with 16 time incrementing entries

tenergy_B[16]

32

y

Energy spectrum of B

tdose_E[16]

32

y

Total dose of E in 16 time incrementing entries.

tenergy_E[16]

32

y

Total energy of E power spectrum

LET_A1[44]

88

y

LET spectra of A1

LET_A2[44]

88

y

LET spectra of A2

checksum

4

n

Fletcher xsum

Compressed fields use the 32-16bit compression as given in Appendix A.

3.2.3  Counters

The number of events detected by the L1 and L2 logic are recorded by counters.  For the L1 logic, there are 36 possible VIRENA channels of which only a maximum of 32 may be active at any given time.  The EVIL table configuration determines which of the 36 VIRENA channels are active.  This EVIL configuration is stored on the ground and is crossreferenced by using a unique checksum to match it with the EDR data acquired under that configuration.  For each of the selected channels, the number of fast and slow triggers are recorded.  Processing of the events requires a short, but finite amount of time for which the detector is “dead”.  The system live and dead time are also recorded.  For the L2 Trigger Menu logic, there are 16 entries, each of which corresponds to configurable logic for coincidence between channels.  Both the number of events that match the criteria for each entry, and the number of events that are correspondingly read are counted.  The L2 Trigger Menu also determines what channels are read, depending on the matching logic for the respective entry.

 

Table 14. Format for counter values in observation packet.

Field

Size (bytes)

Compress?

Description

sync

2

n

0xede9

apid

2

n

0x701 for counters

length

2

n

Length in bytes of packet

fasttoken[32]

64

y

Fast token trigger counts

slowtoken[32]

64

y

Slow token trigger counts

L2Trig_cntrs[16]

32

y

L2 matching counts

L2Trig_reads[16]

32

y

L2 matching readouts

lo_pri_cnt

2

y

Low priority counts

hi_pri_cnt

2

y

Hi priority counts

lo_pri_readout

2

y

Low priority readouts

hi_pri_readout

2

y

High priority readouts

fast_trig_cnt

2

y

Fast trigger counts all channels

dead_time_cnt

2

y

Dead time counter (10.67uS ticks)

alive_time_cnt

2

y

Live time counter in (10.67uS ticks)

reserved

2

y

reserved

PHA_pri_3

2

y

PHA software priority 3 counts (highest)

PHA_pri_2

2

y

PHA software priority 2 counts

PHA_pri_1

2

y

PHA software priority 1 counts

PHA_pri_0

2

y

PHA software priority 0 counts (lowest)

checksum

4

n

Fletcher xsum

Compressed fields use the 32-16bit compression as given in Appendix A.

3.2.4  PHA data

All particle events recorded by RAD are in the form of PHA event records, consisting of the energies recorded in the various detectors. Not all of these are returned to the ground.  A subset of these event records are stored in the observation packet and telemetered for ground analysis. The PHA records stored during an observation are referred to as a PHA packet. Each event within the packet contains a time tag with granularity of 1/16th of an observation period, the priority of the event, the L2 slow token mask, the readout token, the L2 Matching bits, and a compressed ADC value in each of the channels that hold a TRUE value in the readout token as specified in the EVIL configuration table.  As previously mentioned, PHAs are technically part of the RAD science data, but are given their own packet.

 

Table 15. PHA CCSDS packet format in observation packet.

Field

Size (bytes)

Compress?

Description

Ccsds

6

n

CCSDS header for all of pha data

Pha

var

n

PHA events fill up remaining memory. There will be many PHA events that fill this memory space.  All formatted as defined in following table.

See Table 16: Individual PHA event format used in observation packet.

Ccsds xsum

4

n

Fletcher xsum for PHA ccsds packet.

 

Table 16.  Individual PHA event format used in observation packet.

Field

Size (bytes)

Compress?

Description

Sync

2

n

0xBEEF is the sync word

Timetag

4 bits

n

16 value timestamp during observation. (bits 4-7)

Priority

2 bits

n

Software priority based on histogram binning (bits 2-3)

hw_priority

1 bit

n

Hardware based priority based on L2 matching

Spare

1 bit

n

unused

slowtoken

4

n

Slow tokens

Readout

4

n

Readout token

Matching

2

n

L2 matching bits

edata[N]

N

y

Equal to number of bits in readout field.

See LogRAD() compression in Appendix A for PHA edata.

3.2.4.1             Housekeeping, System Information and Messages

 

Embedded within the every EDR science data product is a small block of diagnostic and housekeeping information.  These data are generally not useful to the end user and can be ignored, but are described here since they are part of the observation.

 

Table 17. Housekeeping Packet format.

Field

bytes

Description

Ccsds

6

Primary CCSDS Header

dwEndMET

4

RCLK at the end of observation

byCmdAcc

1

Commands Accepted

byCmdRej

1

Commands Rejected

byNumObs

1

Number of observations not yet transmitted.

byVersion

1

Firmware Version

dwCodeChecksum

4

Fletcher xsum of code image

bfImage

3 bits

Which image is executing 0-RAM;1-EEP;2-PROM)

bfState

2 bits

RAD firmware state (0-Boot;1-science;2-checkout;3-shutdown)

bfUARTSide

2 bits

Which UART is commanding (0-prime;1-redundant;2-both)

bfWakeup

1 bit

Normal wakeup 0; Unexpected wake 1

Obs-byConfigIndex

3 bits

Which observation config index was used.

Obs-eType

3 bits

Which type of observation

Obs-spare

2 bits

Reserved

Obs-byEVILIndex

3 bits

Which EVIL index was used.

Obs-byTempIndex

3 bits

Which Temperature table index was used.

Obs-spare2

2 bits

reserved

Obs-wSleepDuration

2

Prescribed Sleep duration in seconds

Obs-wActiveDuration

2

Active duration for science collection.

Obs-eObsError

1

Observation Error Codes

dwEVILFletcher

4

Fletcher for EVIL table used

dwTempTblFletcher

4

Fletcher for temperature table used

dwHistSetupFletcher

4

Fletcher for setup table used.

byRDEVersion

1

Version of RDE FPGA

byRAEVersion

1

Version of RAE FPGA (EVIL FPGA)

wAOUT_SE

2

ADC reading of VIRENA output

wA_GND_1

2

Analog Ground ADC reading

wA_GND_2

2

Analog Ground ADC reading 2

wADCCalHi

2

Voltage that is 1/2% from max hi for ADC 

wADCCalLo

2

Voltage that is 1/2% higher than ADC minimum

wVoltCalLow

2

Voltage that is 15 mV higher than VRefLow   

wVoltRefLow

2

upply voltages that go to VIRENA

wDACRef

2

Reference  to VIRENA

wBias70

2

Bias Current

wPos5Sensor

2

+5 Voltage for RSH

wNeg5Analog

2

-5 V for analog

wPos5Analog

2

+5 V for analog

wTemp4

2

CDH Temperature

wTemp3

2

RSH internal temp

wTemp2

2

RSH internal temp

wTemp1

2

RSH internal temp

sBeginTemps_4

2

CDH Temperature at beginning of observation

sBeginTemps_4

2

RSH internal temp at beginning of observation

sBeginTemps_4

2

RSH internal temp at beginning of observation

sBeginTemps_4

2

RSH internal temp at beginning of observation

dwpreObsCounts

4

Counts accumulated during pre-observation

Fletcher

4

Fletcher xsum of HK packet.

 

3.2.4.2             Current Messages

RAD messages generate both nominal information packets and off-nominal error packets. Up to 10 messages will be included in the observation packet, however if interactive diagnostics are needed, the message list can be queried by the rad_diag(Message Queue) command. The following are the types of messages produced by RAD.

 

Table 18. Current Messages packet.

Field

bytes

Description

Ccsds

6

CCSDS header

messages[10]

90

Array of messages see Table 20: Format of individual message.

Fletcher

4

Fletcher xsum

 

Table 19.  Format of individual message.

Field

bytes

Description

dwMET

4

RCLK time of message

byID

1

Message ID

ByVersion

1

Software version

byIntPend

1

Typically shows interrupts that are pending.

wData

2

See Table 18.

 

 

Table 20.  wData message Format

Id

Name

Description

When?

Returns

0

MSG_NONE=0,

No message

 

 

6

MSG_LEN_ERR,

Length Error

Wrong length for command packet.

[1] address of checkDataLength()

[2] length<<8|expected length

7

MSG_CHKSUM_ERR,

Checksum error

Not used.

NA

8

MSG_MEMLD_ERR,

Memory Load Error

[1]Out of scratch range.

[2]error patching EEPROM.

[1]&memory_load_data()

[2]&memory_load_patch()

9

MSG_MEMDP_ERR,

Memory Dump Error

Any memory dump error.

&memory_dump()

10

MSG_A2D_ERR, //0xa

A2D Error

Not used.

 

11

MSG_SERIAL_ERR,

Serial error

If CC_Status is off-nominal from incoming command.

Condition code

15

MSG_STATE_ERR,

State violation

[1] Internal invalid state option.

[2]Tried to change RAD state during memory loading.

[3]Commanded to invalid state option.

[1]&setRADState()

[2] &state()

[3] &state()

16

MSG_NVRAM_ERR,//0x10

Errors with Non-volatile memory access

[1] General NVM access error.

[2] Error updating observation header

[3]Error storing system information

[1] NVM status error bits

[2] &updateNewObsHeader()

[3] &storeSystemInfo()

19

MSG_RAE_ERR,  //0x13

Configuration problems with RAE board.

Specific config error with RAE.

&address of offending function. See code linker map for addresses.

 20

MSG_RAE_INT,  //0x14

Communicationproblems with RAE.

Initiated by RAE, error in comm.

&rae_error();

21

MSG_SENDOBS_ERR,  //0x15

Error with send_data()

[1] Invalid parameter for send_data()

[2] Trying to send data when doing memory operations.

[1]&send_data()

[2]&send_data()

22

MSG_CMD_ERR,      //0x16

Any error with incoming command format.

Any error with incoming command format.

ccStatus<<8|byOpcode

23

MSG_BLOCK_ERASE_ERR,

NVM Block erase error

Error erasing block while updating NVM page.

&updateXmtObsHeader()

24

MSG_BAD_BLOCK,

Bad NVM Block detected

[1]Bad block while looking for next available block.

[2]Never found a new valid block

[1]block number

[2] 0x8000|block number

25

MSG_RAE_PROCESS_ERR,

Off-nominal processing for an RAE packet

Packet length not consistent with packet type.

Packet type ID

30

MSG_SLEEP_ERR,

Sleep option error

Invalid option for shutdown.

&shutdown()

32

MSG_CONFIG_ERR,//0x20

Error setting configuraiton

Error in RAE configuration.

&address of offending function. (see code linking for function addressing)

33

MSG_TBL_LOAD_ERR,

Error loading table

Error loading table.

&memory_load_table()

34

MSG_STORE_OBS_ERR,

Error storing observation

Any error while storing an observation packet.

&createObsPacket()

35

MSG_BAD_EVIL_TBL,

Bad EVIL Table

[1] Not EVIL table found.

[2]Invalid EVIL table.

[1] &init_RAE()

[2] &startEVIL

36

MSG_BAD_TEMP_TBL,

Invalid temperature table

No valid temperature table found.

Calculated checksum

37

     MSG_BAD_PRIORITY_TBL,//0x25

Invalid setup table

Invalid setup tables within setup table.

Calculated xsum for invalid table image.

39

MSG_NVM_MARK_BAD_ERR,

Error Marking of detected bad block

Error while trying to mark a bad block.

NVM status error bits

40

 MSG_RFF_INT         

Detected  RAE FIFO is full

This ISR is disabled so this should never happen.

&rae_fifo_isr()

41

     MSG_NVM_UP_SYS_BACK_ERR, //0x29

Error updating system backup

Any error while updating the backup copy of the system information to NVM.

NVM status error bits.

Messages below are information messages only.

129

MSG_CHKSUM_INFO,

Code image checksum

At the end of system initialization.

Lower 2 bytes of code checksum

130

MSG_WDOG_INFO,

Not used

 

 

131

MSG_CMD_INFO,

Command module address

Indicates RAD can accept commands *ONLY IN DEBUG MODE, NOT IN FLIGHT.

&monitorBuffer()

132

MSG_PREOBS_INFO,

Information about pre-observation setup

[1]Sent at beginning of pre-observation.

[2]Sent at end of pre-observation.

[1]Active time<<8|count rate threshold

[2] pre-obs counts

133

MSG_SOLAR_INFO,

Information for solar event setup

Start of solar observation.

Active duration<<8|EVIL index

134

MSG_START_INFO,

Information for observation setup

Indicates the start of the regular observation.

Active duration

135

MSG_SHUTDOWN_INFO,

Info on sleep time

Occurs immediately after system info is stored to NVM.

sleeptime

136

MSG_SOFT_RESET_INFO,

Internal soft reset of RAE has occurred

[1] Soft reset called.

[2]Commanded  soft reset in RAE command task.

[1]&softRAEreset

[2] &RAECmdTask

137

MSG_EVIL_TBL_INFO,

Information on EVIL table loaded

On successful load of EVIL table.

EVIL_window<<8|EVIL index

138

MSG_TEMP_TBL_INFO,

Information on temperature table entry

Successful load of specific entry of temp table.

Temperature label for entry

139

MSG_PRI_TBL_INFO,

Information on SETUP table loaded

Successful load of setup table.

Lower 2 bytes of table checksum

140

MSG_DEFAULT_INFO,

Information about default observation

Beginning of observation.

Active time<<8|EVIL index

141

MSG_FORCE_INFO,

Information about forced observation

Beginning of observation.

Active time<<8|EVIL index

143

MSG_NVM_INFO,

Not used in flight

Only used in special NVM debug mode on ground.

 

144

MSG_DAN_INFO,

Information about DAN observation

Beginning of observation.

Active time

145

MSG_SYS_BKUP_INFO

Backup system information flag

If the backup system information had to be used, this message is sent. It implies that primary copy was corrupted.

0

 

 

 

System information packets are also stored in each observation packet.  When stored in the observation packet, the system information detailed below is wrapped with a CCSDS header and a fletcher checksum.

 

Table 21: System information within observation packet.

Field

bytes

Description

Ccsds

6

CCSDS header, apid = 0x102

System info packet

102

See format below

Fletcher

4

Xsum of packet.

 

 

Table 22: System Information format.              

Name

bytes

Description

dwBootMET

4

Time RAD last booted. 

dwStartMET;   

4

The RCLK for the beginning of the observation.

dwSleepMET

4

The time RAD thinks it is going to sleep.

dwNextWakeupMET

4

The time RAD expects to wake up next time.

dwCurrentMET

4

Current time.

boolMETUpdated

1 bit

Has the start RCLK been updated for this observation by RCE?(0-no;1-yes)

rebootImage  

3 bits

Image to use as default on next boot.

validSysStore 

1 bit

Was the storage of the sys data retrieved (0-no;1-yes)

testmode      

2 bits

Is RAD in a test mode?

backup        

1 bit

Set to 1 if this is the backup copy from NVM.

bSystemFPGA

1

What is the system info in the FPGA status register.

wNoise;  

2

Active count of times RAD detects noise (UART errors)

eImage

3 bits

Which code image is being used currently.

eState

2 bits

The current state of the software.

bfUART 

2 bits

What UART's have been used.

bfWakeup

1 bit

How did RAD wake-up? (0-normal; 1-woke from RCE (power or command)

Obs-byConfigIndex

3 bits

Which observation config index was used.

Obs-eType

3 bits

Which type of observation

Obs-spare

2 bits

Reserved

Obs- byEVILIndex

3 bits

Which EVIL index was used.

Obs-byTempIndex

3 bits

Which Temperature table index was used.

Obs-spare2

2 bits

reserved

Obs-wSleepDuration

2

Estimate, based on sleep tick adjustments, of the upcoming sleep period.

Obs-wActiveDuration

2

Adjusted time for science observation. RAD adjusts the time to be multiple of 16.

Obs-eObsError

1

Observation Error Codes

sObsTables[8]

48

Configuration options (8 entries 6 bytes each)

wLastBlockUsed

2

keep an account of the last NVRAM block used for data storage.

wStoredObs  

2

Number of stored observations not yet transmitted.

wTotalObs

2

Total number of observations stored to date.

dwCodeChecksum

4

Fletcher checksum of code image.

dwEDACCount  

4

Count of EDAC errors since boot.

dwOutofSync  

4

Number of times the RAE buffer has lost sync.

checksum   

4

Fletcher checksum of this structure.

 

4    Data Processing

4.1.1  Data Processing Level

This SIS uses the Committee On Data Management And Computation (CODMAC) data level numbering system to describe the processing level of the EDR data product. RAD EDR data products are considered CODMAC “Level 1” or “Raw Data” (equivalent to NASA level 0) products. The EDR data files are generated from “Level 1” or “Raw Data”, which are the telemetry packets within the project specific Standard Formatted Data Unit (SFDU) record. Refer to Table 23 for a breakdown of the CODMAC and NASA data processing levels.

Table 23: Processing Levels for Science Data Sets

NASA

CODMAC

Description

Packet data

Raw – Level 1

Telemetry data stream as received at the ground station, with science and engineering data embedded.

Level-0

Edited – Level 2

Instrument science data (e.g., raw voltages, counts) at full resolution, time ordered, with duplicates and transmission errors removed.

Level 1-A

Calibrated - Level 3

Level 0 data that have been located in space and may have been transformed (e.g., calibrated, rearranged) in a reversible manner and packaged with needed ancillary and auxiliary data (e.g., radiances with the calibration equations applied).

Level 1-B

Resampled - Level 4

Irreversibly transformed (e.g., resampled, remapped, calibrated) values of the instrument measurements (e.g., radiances, magnetic field strength).

Level 2

Derived - Level 5

Geophysical parameters, generally derived from Level 1 data, and located in space and time commensurate with instrument location, pointing, and sampling.

Level 3

Derived - Level 5

Geophysical parameters mapped onto uniform space-time grids.

 

4.1.2  Data Product Generation

The RAD EDR data products is generated by the OPGS at JPL. The EDR data products are raw, uncalibrated data reconstructed from telemetry data products and formatted according to this EDR SIS. Meta-data acquired from the telemetry data headers will be used to populate the PDS label. If telemetry packets are missing during the initial downlink from the rover memory, partial data sets will be created. The data will be reprocessed after all data are received and the version number will be incremented.  Thus, there may be multiple versions of an RAD EDR, but only the most current version will be delivered to the PDS.  Format files (.FMT) and label files (.LBL) in the PDS volume describe the binary format of the data in the EDR science data files.

4.1.3  Data Flow

The RAD EDR data products generated by OPGS during operations are created collectively from: a) MPCS data products b) SPICE kernels, and c) a meta-data database. The products are then deposited into the File Exchange Interface (FEI) for electronic distribution to remote via a secure subscription protocol. After a data validation period, the RAD EDR data products are collected with other science data and delivered to the Planetary Data System for archiving.

The size of the RAD EDR data file varies depending on the number of observations taken during the sol. The RAD EDR will be generated no less than 60 seconds after the data product for the EDR has been received by OPGS. The RAD data will be reprocessed only if packets in the original downlink are not received or when additional data from the same sol is received in a later transmission. The RAD EDR will be placed into FEI for distribution immediately upon creation, even if the file is only partially complete.  The RAD EDR will be reprocessed after all data is retransmitted and received and the version number will be incremented and placed into FEI for distribution.

4.1.4  Labeling and Identification

There is a file naming scheme adapted for the MSL image and non-image data products.  The scheme applies to the EDR and several RDR data products. The file naming scheme adheres to the Level II 36.3 filename convention to be compliant with PDS standards.  The file naming scheme also contains a minimal level of meta-data that retains uniqueness and is searchable.

The MSL RAD EDR data product can be uniquely identified by incorporating into the product filename the Rover Mission identifier, the Instrument identifier, the Starting Spacecraft Clock count (SCLK) of the sol, the data Product Type, the Site location, the rover Position within the site, a Sequence Number or Custom Identifier, the product Creator identifier and a Version number.  The metadata fields are separated by an underscore “_” and have been selected based on MER and Phoenix mission lessons learned.

Each RAD EDR has a detached PDS label associated with the RAD binary data file. The file naming scheme for the RAD EDR and RDR data products is formed by:

<instr>_<config>_<sclk>_<prod>_<sol>_<site>_<drive>_<venue/who>_<ver>.<ext>

 

where,

Instr

=

(2 alpha character)  Instrument ID, denoting the source MSL science or engineering instrument that acquired the data.

Valid values for Instrument ID’s are:

 

Valid values for:

 

RD  -  RAD

 

Config

=

(2 alphanumeric)  Instrument Configuration, an operational attribute of the Instrument that assists in characterizing the data.

Valid values for the RAD instrument is:

 

                   

              Instrument

Configuration

Values

Description

 

RAD

A_

“B_”

A and B indicate the RCE string used to downlink the data.  The 2nd character is undefined and can be used to define something.

 

 

Sclk

=

(9 alphanumeric)  Spacecraft Clock Start Count, in units of seconds.

For RAD, the value is to contain the SCLK corresponding to the start of a sol.

 

The valid values, in their progression, are as follows (non-Hex):

Range   000000000 thru    999999999 -  000000000”,   000000001”,  999999999

Range 1000000000 thru  1099999999 -  A00000000,  A00000001, … A99999999

Range 1100000000 thru  1199999999 -  B00000000”, “B00000001”, … “B99999999

                                                                  ·

                                                                  ·

                                                                  ·

Range 3500000000 thru  3599999999 -  Z00000000”,  Z00000001”,  Z99999999

 

 

Prod

=

(3 char) Product Type identifier:

ESD- for EDR science data

or

EHP-for EDR High Priority science data.

sol

=

(4 numeric)  Sol  for the SCLK value of the EDR or _DOY (Day of year) for non-surface data (i.e., cruise).

 

site        

=

(3 alphanumeric)  Site location count, from the RMC.

This field has the following rules-of-thumb:

     a) Site -  If value is any 3 alphanumeric characters, or 3 underscores (denoting value is out-of-range), then content represents Site index extracted from RMC.

 

The valid Site values, in their progression, are as follows (non-Hex):

Range   000 thru   999 -   000”, 001”,  999

Range 1000 thru 1099 -  A00, A01,  A99

Range 1100 thru 1199 -  B00”, “B01”,B99

                                             ·

                                             ·

                                             ·

Range 3500 thru 3599 -  Z00”, Z01”,Z99

drive         

=

(4 alphanumeric)  Drive (position-within-Site) location count, from the RMC.

This field has the following rules-of-thumb:

     a) Drive -  If value is any 4 alphanumeric characters, or 4 underscores (denoting value is out-of-range), then content represents Drive index extracted from RMC.

 

 

The valid Drive values, in their progression, are as follows (non-Hex):

Range   0000 thru   9999 -   0000”, 0001”,  9999

Range 10000 thru 10999 -  A000, A001,  A999

Range 11000 thru 11999 -  B000”, “B001”, … “B999

                                             ·

                                             ·

                                             ·

Range 35000 thru 35999 -  Z000”, Z001”,Z999

Range 36000 thru 36099 -  AA00”, AA01”,AA99

Range 36100 thru 36199 -  AB00”, AB01”,AB99

                                             ·

                                             ·

                                             ·

Range 38500 thru 38599 -  AZ00”, AZ01”,AZ99

Range 38600 thru 38699 -  BA00”, BA01”,BA99

Range 38700 thru 38799 -  BB00”, BB01”,BB99

                                             ·

                                             ·

                                             ·

Range 41100 thru 41199 -  BZ00”, BZ01”,BZ99

Range 41200 thru 41299 -  CA00”, CA01”,CA99

                                             ·

                                             ·

                                             ·

Range 65400 thru 65499 -  LI00”, LI01”,LI99

Range 65500 thru 65535 -  LJ00”, LJ01”,LJ35

venue     / who

=  

(1 alpha character)  Venue and Product Producer ID shared in the same field.

Venue denotes Flight Model versus Engineering Model in data acquisition.  Product Producer ID identifies the institution that generated the product.

This field has the following rules-of-thumb:

     a) Venue -  A value in the range “A - P” indicates Flight Model rover.  A value in the range

             Q - Z” indicates Engineering (testbed) rover.  The range “N - O” is not used.

     b) Producer -  If value is “P” (for Flight) or “Y” (for Engineering), the provider of the product

             is the Principal Investigator.  Except for MIPL as the provider (“M” for Flight or “Z” for

             Engineering), the remaining characters are assigned to Co-investigator providers at

             the discretion of the P.I. and will be identified in due time.  Within the instrument of

             the P.I., characters are unique.  Across instruments, characters are reusable.

See the following table of valid values:

 

Venue

                                                                                                                     by Producer

 

Flight   Model

Eng.

 Model

 

M

Z

MIPL (OPGS at JPL)

 

P

Y

Principal Investigator of Instrument …

 

 

 

     Instrument                          Principal Investigator

     MMM Cameras                   MSSS (San Diego, CA)

     ChemCam RMI & SOH       LANL (Los Alamos, NM)

     ChemCam LIBS                  CNES (France)

 

A - L

Q - X

Co-Investigators (to be identified by P.I. per instrument)

 

See the following table of valid values for Instruments not covered by this SIS:

 

Venue

                                                                                                                     by Producer

 

Flight   Model

Eng.

 Model

 

M

Z

MIPL (OPGS at JPL)

 

P

Y

Principal Investigator of Instrument …

 

 

 

     Instrument              Principal Investigator

     SAM                        GSFC (Goddard, MD)

     REMS                     Ministry of Education & Science (Spain)

     DAN                        Federal Space Agency (Russia)

     RAD                        SwRI (Boulder, CO)

     CheMin                   Ames Research Center (Mountain View, CA)

     APXS                      Max-Planck Institute (Canada)

     SA/SPaH                JPL

 

A - L

Q - X

Co-Investigators (to be identified by P.I. per instrument)

Ver

=

(1 alphanumeric)  Version identifier.

 

The valid values, in their progression, are as follows (non-Hex):

Range 1 thru 10          -  1, 2”, 9”, 0

Range 11 thru 36        -  A”, B”,Z

Range 37 and higher  -  _” (underscore)

The Version number increments by one whenever an otherwise-identical filename would be produced.  Note that not every version need exist, e.g. versions 1, 2 and 4 may exist but not 3.  In general, the highest-numbered Version represents the “best” version of that product.

NOTE:   To be clear, this field increments independently of all fields, including the Special

              Processing field.

Ext

=

(2 to 3 alpha characters)  Product type extension.

 

Valid values for nominal operations non-camera data products:

 DAT

LBL

TAB

-

-

-

-

Non-imaging instrument data

Detached label in PDS or ODL format

Table data

 

 

Example #1:      RD_XY_013760215_ESD_0001_093_0008_M1.IMG

 where,

Instr

=

“RD”

=

RAD

Config

=

“X”

=

TBD

Spec

=

“Y”

=

TBD

Sclk

=

013760215

=

SCLK Count of 13760215 secs corresponding to start of

Image EDR

prod

=

ESD”

=

EDR Science Data

sol

=

“0001”

=

Sol 1

site

=

093

=

Site 93

drive

=

008

=

Drive (Position within site) 8

Venue/who

=

M

=

Flight Model data /produced by MIPL (at JPL)

ver

=

1

=

Version 1 of the product for the given sol

ext

=

DAT

=

Data product with PDS label

 

4.2    Standards Used in Generating Data Products

4.2.1  PDS Standards

The RAD EDR complies with Planetary Data System standards for file formats and labels, as specified in the PDS Standards Reference and the Planetary Science Data Dictionary Document.

4.2.2  Time Standards

The following time standards and conventions are used throughout this document, as well as the MSL project for planning activities and identification of events. 

 

Time Format

Definition

SCET

Spacecraft event time.  This is the time when an event occurred on-board the spacecraft, in UTC.  It is usually derived from SCLK.

SCLK

Spacecraft Clock. This is an on-board 64-bit counter, in units of nano-seconds and increments once every 100 milliseconds. Time zero corresponds to midnight on 1-Jan-1980.

ERT

Earth Received Time. This is the time when the first bit of the packet containing the current data was received at the Deep Space Network (DSN) station.  Recorded in UCT format.

Local Solar Time

Local Solar Time (LST). This is the local solar time defined by the local solar days (sols) from the landing date using a 24 “hour” clock within the current local solar day (HR:MN:SC). Since the Mars day is 24h 37m 22s long, each unit of LST is slightly longer than the corresponding Earth unit.  LST is computed using positions of the Sun and the landing site from SPICE kernels. If a landing date is unknown to the program (e.g. for calibration data acquired on Earth) then no sol number will be provided on output

            LST examples:

                            SOL 12  12:00:01

                            SOL 132 01:22:32.498

                            SOL 29

RCT

Record Creation Time.  This is the time when the first telemetry packet, containing a give data, set was created on the ground.  Recorded in UTC format.

 

True Local Solar Time

This is related to LST, which is also known as the mean solar time.  It is the time of day based on the position of the Sun, rather than the measure of time based on midnight to midnight “day”.  TLST is used in all OPGS generated products.

SOL

Solar Day Number, also known as PLANET DAY NUMBER in PDS label.  This is the number of complete solar days on Mars since landing.  The landing day therefore is SOL zero.

RCLK

The internal RAD time in milliseconds, and is used to determine when to awake from a SLEEP state.  RCLK is synchronized to SCLK during communication with the RCE. 

Because RCLK is only synched to SCLK during communication with the RCE, and because the RAD internal clock is not as precise as the RCE on the spacecraft, RCLK and SCLK can potentially drift apart in between communication sessions.  The longer the time between communication, the greater the drift that is possible.  Observations taken by RAD are internally stamped with an RCLK time.  In order to resynchronize on the ground the observational times as best as possible with RCLK, an additional data set, EVRs are provided as part of the EDR.  EVR data are comma separated fields in ASCII that give the SCLK times of RAD commands and events.  These can be crosscorelated with the RCLK time in the observations.

 

4.2.3  Coordinate Systems

The MSL Frame Manager defines several dozen coordinate frames, which can be used for commanding pointing among other things.  Refer to the Pointing, Positioning, Phasing and Coordinate Systems document or the Surface Attitude, Positioning and Pointing Functional Design Description for more details on all these coordinate frames.  Only a few of them are used by the products and processes described by this SIS.  This subset is described in detail in this section.  The only place in this SIS where the full set of frames can appear is in the INSTRUMENT_COORD_FRAME_ID label.

 

A subset of these frames needed for a specific image or data set are defined by the *_COORDINATE_SYSTEM groups.

Table 23 - Coordinate Frames Used for MSL Surface Operations

Frame Name

(Label Keyword Value)

Short Name

(SAPP FDD)

Reference Frame

(Used to Define)

Coordinate Frame

Origin

Orientation

ROVER_NAV_FRAME

RNAV

Enclosing SITE_FRAME

Attached to rover

Aligned with rover

ROVER_MECH_FRAME

RMECH

Enclosing SITE_FRAME

Attached to rover

Aligned with rover

LOCAL_LEVEL_FRAME

LL

Enclosing SITE_FRAME

Attached to rover (coincident with Rover Nav Frame)

North/East/Nadir

SITE_FRAME

SITE(n)

Previous SITE_FRAME

Attached to surface

North/East/Nadir

RSM_HEAD_FRAME

RSM_HEAD

ROVER_NAV_FRAME

Attached to mast head

Aligned with pointing of mast head.  This corresponds to RSM_HEAD in the Frame Manager

Arm Frames:

   ARM_TURRET_FRAME

   ARM_DRILL_FRAME

   ARM_DRT_FRAME

   ARM_MAHLI_FRAME

   ARM_APXS_FRAME

   ARM_PORTION_FRAME

   ARM_SCOOP_TIP_FRAME

   ARM_SCOOP_TCP_FRAME

Arm Frames:

   TURRET

   DRILL

   DRT

   MAHLI

   APXS

   PORTION

   SCOOP_TIP

   SCOOP_TCP

ROVER_NAV_FRAME

Attached to the tool; see PPPCS for the specific tool frame.

Aligned with tool in some way; see PPPCS [Ref 1] for the specific tool Frame.

 

4.2.4   Rover Navigation (Rover Nav) Frame

The Rover Nav frame (RNAV) is the one used for surface navigation and mobility.  By definition, the frame is attached to the rover, and moves with it when the rover moves while on the surface.  Its Z origin is defined to be 0.5 mm above the deck, with the Y origin centered on the rover and the X origin aligned with the middle wheels’ rotation axis for the deployed rover and suspension system on a flat plane.  The +X axis points to the front of the rover, +Y to the right side, and +Z down (perpendicular to the chassis deck).  See Figure 4.