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,

To determine the radiation dose rate and equivalent dose rates for humans on the surface of Mars,
To enable validation of Mars atmospheric transmission models and radiation transport codes,
To provide input to the determination of the radiation hazard and mutagenic influences to life, past and present, at the Martian surface,
To provide input to the determination of the chemical and isotopic effects of energetic particles on the Martian surface and atmosphere.

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 surface 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 present. Radiation is an important source of biological mutations, and as such may have been the dominant 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/16^th 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/8^th, 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/16^th 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/16^th 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:

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 2^nd 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
Frame Name (Label Keyword Value)	Short Name (SAPP FDD)	Reference Frame (Used to Define)	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.

Figure 4 - Rover Navigation (RNAV) Coordinate Frame

The Rover Nav frame is specified via an offset from the current Site frame, and a quaternion that represents the rotation between the two. A new instance of the Rover Nav frame, with a potentially unique offset/quaternion, is created every time the ROVER_MOTION_COUNTER increments.

Orientation of the rover (and thus Rover Nav) with respect to Local Level or Site is also sometimes described by Euler angles as shown in Figure 5, where y is heading, q is attitude or pitch, and f is bank or roll. For the purposes of RAD observations the RAD coordinate frame is identical to the Rover Nav Frame.

Figure 5– Yaw, Pitch and Roll Definitions

4.2.5 Rover Mechanical (Rover Mech) Frame

The Rover Mechanical (RMECH) frame is oriented identically to the Rover Nav frame. The origin is forward of Rover Nav by x=0.09002 meters. In other words, given a point expressed in Rover Mech, if you add (0.09002, 0.0, 0.0) you will get the same point expressed in Rover Nav. Rover Mech is not used by any nominal products (EDR or RDR) but could appear in certain special products, generally having to do with arm kinematics.

4.2.6 Local Level Frame

The Local Level frame is coincident with the Rover Nav frame, i.e. they share the same origin at all times. The orientation is different, however. The +X axis points North, +Z points down to nadir along the local gravity vector, and +Y completes the right-handed system. Thus the orientation matches the orientation of Site frames.

Local Level frames are defined by an offset from the current Site frame, with an identity quaternion.

4.2.7 Site Frame

Site frames are used to reduce accumulation of rover localization error. They are used to provide a common reference point for all operations within a local area. Rover Nav and Local Level frames are specified using an offset from this origin. When a new Site is declared, that becomes the new reference, and the offset is zeroed. In this way, long-term localization error is relegated to the offset between Sites, becoming irrelevant to local operations, because the positions are reset with each new Site.

When a Site frame is declared, it is identical to the Local Level frame, sharing both orientation and position. However, the Site frame is fixed to the Mars surface; when the rover moves, Local Level moves with it but Site stays put. Therefore, for the Site frame, +X points North, +Z points down to nadir along the local gravity vector, and +Y completes the right-handed system.

Sites are indexed, meaning there are multiple instances. Site 1 by definition represents the landing location. New Sites are declared as needed during operations, as the rover moves away from the local area. See Figure 6.

Text Box:
Figur 6 – Site and Rover Frames

The PLACES database stores the set of all site-to-site offsets; such offsets are not in the image label.

4.2.8 RSM Frame

The RSM frame is attached to the Remote Sensing Mast (RSM) camera head, and moves with it. See the PPPCS for specific definition. It is expressed as an offset and quaternion from the Rover Nav frame.

4.2.9 Arm Frames

The frame representing the currently selected arm tool is reported in the arm coordinate system group. The selected tool, given by ARTICULATION_DEV_INSTRUMENT_ID, is arbitrary for any given image and may be surprising; for example MAHLI may not be the selected tool for a MAHLI image. The various tool frames are attached to and aligned with the tool in some manner specific to that tool. See the PPPCS [Ref 1] for actual frame definitions.

4.3 Data Validation

Validation of the MSL EDRs will fall into two primary categories: automated and manual. Automated validation will be performed on every EDR product produced for the mission. Manual validation will only be performed on a subset.

Automated validation will be performed as a part of the archiving process, and will be done simultaneously with the archive volume validation. Validations performed, will include such things as verification that the checksum in the label matches a calculated checksum for the data product (i.e., that the data product included in the archive is identical to that produced by the real-time process), a validation of the PDS syntax of the label, a check of the label values against the database and against the index tables included on the archive volume, and checks for internal consistency of the label items. The latter include such things as verifying that the product creation date is later than the earth received time, and comparing the geometry pointing information with the specified target. As problems are discovered and/or new possibilities identified for automated verification, they will be added to the validation procedure.

Manual validation of the data will be performed both as spot-checking of data throughout the life of the mission, and comprehensive validation of a subset of the data (for example, a couple of days' worth of data). These products will be viewed by a human. Validation in this case will include inspection of the image or other data object for errors (like missing lines) not specified in the label parameters, verification that the target shown / apparent geometry matches that specified in the labels, verification that the product is viewable using the specified software tools, and a general check for any problems that might not have been anticipated in the automated validation procedure.

5 Data Product Specifications

5.1 Data Product Structure and Organization

The structure of the RAD EDR consists of a detached ASCII PDS label and binary science data files. Binary data is delivered as a data “blob”. No re-formatting or processing of the science data is done. The .LBL and .FMT files describe the format of all files. The binary format of each observation packet (blob) within the file is complex. The contents can vary depending on the operational mode of RAD and on changes in the observation configuration. The complete data structure and meaning of each byte within the binary EDR data is defined within previously given tables. Byte ordering is BigEndian. The individual elements of the observation packet are further described below.

5.2 Label and Header Descriptions

5.2.1.1 PDS Label

RAD EDR data products have detached PDS labels stored as ASCII. A PDS label is object-oriented and describes the objects in the data file. The PDS label contains keywords for product identification and for data object definitions. The label also contains descriptive information needed to interpret or process the data objects in the file.

PDS labels are written in Object Description Language (ODL). PDS label statements have the form of "keyword = value". Each label statement is terminated with a carriage return character (ASCII 13) and a line feed character (ASCII 10) sequence to allow the label to be read by many operating systems. Pointer statements with the following format are used to indicate the location of data objects in the file:

^object = location

where the carat character (^, also called a pointer) is followed by the name of the specific data object. The location is the starting record number for the data object within the file.

Each PDS keyword defined for the RAD label will always be included in the PDS label. If a keyword does not have a value, a value of NA will be given as the keyword value.

5.2.1.2 PDS Data Objects

A RAD EDR consists of several data objects that are described in the PDS label as tables. The first data object is the high level structure with pointers to more detail structures.

6 Applicable Software

There is no applicable software.

7 Archive Volume Contents, Format, and Generation

Refer to Appendix E in Document 2 and Document 4 referenced in Section 1.2.

Appendix A – Compression

32-bit to 16-bit compression

Within the observation packets, many of the reported counts and bins are reported as 16-bit compressed values. Below is the C- code for performing this compression.

/*****************************************************************************/
/**
*@memo FUNCTION: compressCounts()
*@doc DESCRIPTION: convert 32-bit counters to 16-bit float for telemetry.
*          the format for this, since it is compressing counters
*                   and we don't need sub-integer values is as follows
*                   exp 4-bit - mant 12-bit
*                   |eeee|mmmmmmmmmmmm|
*                   where e is 0-15; the original count is obtained as
*                   count = (m+0x1000)<<(e-1);
*                   there is an implied 1 at the 13-bit of the mantissa
*                   When e==0 the count is non-normalized, count = m.
*
* @param   DWORD count
* @return FLOAT_16 - custom float, it is sizeof(WORD)
*/
/*****************************************************************************/
WORD compressCounts(DWORD count)
{
     FLOAT_16 compressed;
     BYTE DATA i;

     //compressed.bits.exp=0;
     //compressed.bits.mantissa = ((WORD)(0x00000FFF&count));
     compressed.value = count;

     //start with 13-bit,if we are greater than 13-bits, so we must
     //calculate some values
     //the case 0x0001xxx is when e==1, count=value !
     if(count&0xFFFFE000)
     {
          //if there is a bit set higher than 12-bit, then we have to
          //calc more stuff
          for(i=27;i>0;i--)
          {
               if(count>>i)
               {
                    if(i==27)
                    {
                         //if a bit is set higher than 27th bit, we
                         //are overflowed
                         compressed.value=0xFFFF;
                         break;
                    }
                    else
                    {
                         //once we get here, we have found the highest bit set
                         //so we record that as the mantissa
                         compressed.bits.mantissa = count>>(i-12);
                         compressed.bits.exp=(i-11);//minus 12bits that are stored in mantissa
                         break;
                    }
               }
          }
     }
     return compressed.value;
}

Log_RAD() compression

In order to compress the energy data from 24-bit to 8-bit, and keep an appropriate range, some energy data will be stored in “log” values. The customized log_RAD() is very close to log2(), but tailored for RAD hardware.

The format of the output should be as follows:

eeeee.mmm (an 8 bit value)

where:

e are 5 bit exponent [bits 7-3]

m are a 3-bit mantissa [bits 2-0]

The decimal is implied in the format. The exp part of this result must cover 24-bit range of the original value (5-bits == 32 bit range). The exponent portion of the result shall indicate the bit position of the most significant ‘1’ of the 24-bit input. The mantissa shall be determined based on the next five bits following the most significant ‘1’ by the Look-Up-Table

Input	Output
0x00	0x0
0x01	0x0
0x02	0x0
0x03	0x1
0x04	0x1
0x05	0x1
0x06	0x1
0x07	0x2
0x08	0x2
0x09	0x2
0x0A	0x3
0x0B	0x3
0x0C	0x3
0x0D	0x3
0x0E	0x4
0x0F	0x4
0x10	0x4
0x11	0x4
0x12	0x5
0x13	0x5
0x14	0x5
0x15	0x5
0x16	0x6
0x17	0x6
0x18	0x6
0x19	0x6
0x1A	0x6
0x1B	0x7
0x1C	0x7
0x1D	0x7
0x1E	0x7
0x1F	0x7

DATE	SECTIONS CHANGED	REASON FOR CHANGE	REVISION
04 Nov 2008	-	1^st 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

SECTION	DESCRIPTION