Radiation Belt Storm Probes Ion Composition Experiment

(RBSPICE)

Science Operations Center (SOC)

RBSPICE Science Data Handbook

Revision: f

Written by

Jerry W. Manweiler, Ph.D.

and

Heather Zwiener

August 20, 2019

Lou Lanzerotti, RBSPICE Principal Investigator

Don Mitchell, RBSPICE Instrument Scientist

Jerry W. Manweiler, RBSPICE SOC Lead

Document Change Log

Date	Version Number	Reason for Change
September 18, 2013		Original Draft
January 29, 2014	Rev a	Added Field Name Descriptions Table for the Calibration Tables
February 28, 2014	Rev b	Revised L3 pitch angle quality flags
August 18, 2015	Rev c	Added section for Pitch Angles and Pressures (PAP), and Table of Acronym Definitions
April 12, 2017	Rev d	Added information regarding additional field of particle direction velocity unit vector in Level 3 data files.
February 13, 2018	Rev e	Added information regarding effects of high rates on the RBSPICE microchannel plates on derived intensities: Accidentals
August 20, 2019	Rev f	Revised algorithms (v2.11) for R_in vs R_out rate calculation for TOFxPH and TOFxE data products

RBSPICE Data Handbook

1 Introduction. 5

1.1 Document Purpose. 5

1.2 Document Scope. 5

1.3 Applicable Documentation. 5

RBSPICE Instrument Paper 5

2 Links to Data files, calibration tables and software. 6

2.1 RBSPICE A and B data files 6

2.2 RBSPICE A and B calibration tables 6

2.3 Software required and recommended to use RBSPICE data. 7

3 RBSPICE SOC Archive Data Products 7

3.1 RBSPICE Data Categories 7

3.2 RBSPICE Data Products Specification. 8

3.3 RBSPICE Data Product Production Specifications 9

3.4 RBSPICE Data Products and related Instrument Data Modes 10

3.5 RBSPICE Data Product Production Steps (High Level Overview) 12

3.6 RBSPICE Data Product Production Steps (Detailed Processing Algorithms) 13

3.6.1 Level 0 Processing Algorithms 13

3.6.2 Level 1 Processing Algorithms 21

3.6.3 Level 2 Processing Algorithms 25

3.6.4 Level 3 Processing Algorithms 28

4 RBSPICE SOC Data Repository Directory Structure. 35

4.1 Van Allen Probes MOC Data Directory structures 35

4.2 RBSP Spacecraft Data Organization. 35

4.3 EMFSIS Data Organization. 36

4.4 RBSPICE Data Organization. 37

4.5 Product Directory Naming. 37

5 Production Filename Convention. 38

5.1 RBSP CDF Filenames 39

5.2 RBSPICE Specific File Name Conventions 41

5.3 RBSPICE Data Release Plans 42

5.3.1 Publicly Accessible RBSPICE Data. 42

5.3.2 Release of data to NSSDC archive. 42

5.3.3 Web Services Access 42

6 RBSPICE Data Product Field Descriptions 42

6.1 RBSPICE Level 1 Product Field Descriptions 43

6.2 RBSPICE Level 2 Product Field Descriptions 54

7 References 72

1 Introduction

1.1 Document Purpose

This is the Data Analysis Handbook for the Van Allen Probes’ Radiation Belt Storm Probes Ion Composition Experiment (RBSPICE). This handbook is intended to guide RBSPICE data users in locating, identifying and understanding the content of the RBSPICE data files maintained by the RBSPICE Science Operations Center (SOC). As data products are added or changed, or other changes are made to the system for storing and accessing the RBSPICE data, this document will be updated accordingly.

1.2 Document Scope

This document contains lists, descriptions and/or explanations pertaining to the following RBSPICE data assets:

Data directory structure and file naming convention;

Data products produced and utilized by the RBSPICE SOC data processing system and data publication system;

Produced and published data products for the RBSPICE instrument aboard each Van Allen Probes satellite, A and B, which are available to the general public; and

Processes used to convert the data and generate data products according to specifications from Level 0 through Level 4.

Users who wish to work with either telemetry or commanding data or who have other questions not addressed in this document concerning data maintained by the RBSPICE SOC should contact RBSPICE SOC Lead Engineer Jerry W. Manweiler, Ph.D. at Manweiler@ftecs.com.

1.3 Applicable Documentation

Originally named the Radiation Belt Storm Probes (RBSP), the mission was re-named the Van Allen Probes, following successful launch and commissioning. For simplicity and continuity, the RBSP short-form has been retained for existing documentation, file naming, and data product identification purposes. The RBSPICE investigation including the RBSPICE Instrument SOC maintains compliance with requirements levied in all applicable mission control documents.

1.4 Acronym Definitions

[Insert table of data products, with acronyms, and explain what the data products are and how they are used. Maybe organize the table by protons, non-protons, ions, etc.]

RBSPICE Instrument Paper

One key document that every user of the RBSPICE data should read is the RBSPICE Instrument Paper. The abstract can be found at http://link.springer.com/article/10.1007%2Fs11214-013-9965-x, along with a link to the full paper.

2 Links to Data files, calibration tables and software

2.1 RBSPICE A and B data files

Publicly accessible data files for spacecraft A are found at http://rbspicea.ftecs.com.

Publicly accessible data files for spacecraft B are found at http://rbspiceb.ftecs.com.

2.2 RBSPICE A and B calibration tables

Calibration Tables – Field Name Descriptions

SC	Name of spacecraft either RBSPA or RBSPB
ProductType	One of the product types listed in the beginning of the cal file
Telescope	Identifies which of the six telescopes the cal information corresponds
StartUTC	The starting time for this calibration record in UTC string format (CCYY-MM-DDTHH:MM:SS:hhh)
StartET	The starting time for this calibration record in Ephemeris Time using the J2000 epoch
StopUTC	The ending time for this calibration record in UTC string format (CCYY-MM-DDTHH:MM:SS:hhh)
StopET	The ending time for this calibration record in Ephemeris Time using the J2000 epoch
Species	The primary species for which this calibration record is responsive – note that this does not identify all species that this channel will detect but the species that it is designed to detect, some channels are responsive to multiple species and depending upon the situation the primary species differs from time to time. E.g. TOFxPH products are generally responsive to protons but some of the channels are responsive to Oxygen or Helium although when those species are not present the channel will detect background proton rates
Channel	The energy channel number for this calibration record
E_Low	The bottom energy of the passband in MeV
E_High	The upper energy of the passband in MeV
E_Mid	The calculated midpoint energy of the passband in MeV. Note that this is not always the geometrical mean since some passbands are more sensitive to lower energies even though they allow for higher energy ranges
G_Small	The small pixel geometrical factor in cm^2*sr. See the RBSPICE Data Handbook for more information about pixel sizes
G_Large	The large pixel geometrical factor in cm^2*sr. See the RBSPICE Data Handbook for more information about pixel sizes
Eff	The efficiency of the energy channel.
Notes	Any specific notes about this energy channel.

Calibration tables for spacecraft A are found at http://rbspice.ftecs.com/RBSPICEA_Calibration.html.

Calibration tables for spacecraft B are found at http://rbspice.ftecs.com/RBSPICEB_Calibration.html.

2.3 Software required and recommended to use RBSPICE data

CDF Files

Access and use of the RBSPICE data requires the most recent version of NASA’s common data format (CDF) software, CDF V3.6.0, which supports the CDF_TIME_TT2000 variable and properly handles the new leapsecond added on June 30, 2015. This software is available for download at http://cdf.gsfc.nasa.gov.

CSV Files

CSV files can be opened with PKZip, which can be found at this website: http://www.pkware.com/software/pkzip.

Data visualization

MIDL is used and recommended by the RBSPICE team to visualize RBSPICE data. This software is available for download at http://sd-www.jhuapl.edu/rbspice/MIDL.

3 RBSPICE SOC Archive Data Products

The RBSPICE SOC data system contains data products derived from other RBSP mission-related data sources, as well as that data which is produced by the RBSPICE SOC, both intermediary and final. Organizationally this can be viewed as a collection of data categories, data product specifications, and data production specifications. Each of the following sections provides details of these organizational perspectives on the RBSPICE data.

3.1 RBSPICE Data Categories

Table 3‑3‑1 lists the various RBSPICE data categories representing the highest level perspective on the data that is to be contained by the RBSPICE SOC Data Repository system. These categories do not necessarily represent a directory structure, but do drive the final structure presented in Section 4.

Table 3‑3‑1 Top level list of RBSPICE Data Categories

Data Category	Data Source	Publication/Access Level
MOC Data Products – not instrument specific	MOC	RBSPICE team only
EMFISIS Mag Data Products	MOC/EMFISIS SOC	RBSPICE team only
RBSPICE Instrument Data (telemetry/Level 0)	MOC	RBSPICE team only
RBSPICE Level 1, 2, 3 Data	RBSPICE SOC	General Public
RBSPICE Level 3 PAP data	RBSPICE SOC	General Public
RBSPICE Level 4 Data – modeling data	RBSPICE Science Team	RBSP
RBSPICE Level 4 Data – results data	RBSPICE Science Team	General Public
RBSPICE Intermediate Data	RBSPICE SOC	RBSPICE SOC only

3.2 RBSPICE Data Products Specification

Table 3‑3‑2 lists the collection of data products contained in the RBSPICE SOC Data Repository that are specific to the RBSPICE Instrument measurements, as well as any other data elements required to process and understand/interpret the RBSPICE data. The Level 0 data products are downloaded directly from the Mission Operations Center (MOC), stored locally within the RBSPICE SOC Data Repository, and used for production of the higher level data products. This table provides a high level characterization of the important variables defining the various data products and drives the final structure of the RBSPICE SOC Data Repository.

For a more complete discussion of each of the higher level data products and the controlling variables, see http://link.springer.com/article/10.1007%2Fs11214-013-9965-x for the abstract and a link to the full paper.

Table 3‑3‑2 RBSPICE SOC Data Products

Product	Species	Energy Bins	L0 Data Type	L1 Data Type	L2 Data Type	L3 Data Type	L4 Data Type
Ion Basic Rate	Ions	NA	Count	Rate
Electron Basic Rate	Electrons	NA	Count	Rate
Low Energy Resolution High Time Resolution Electron Species Rate¹	Electrons	14	Count	Spectra	Spectra Flux	PAD, Aggregates	PSD, 2nd, 3rd Adiabat,
High Energy Resolution Low Time Resolution Electron Species Rate¹	Electrons	64	Count	Spectra	Spectra Flux	PAD, Aggregates	PSD, 2nd, 3rd Adiabat,
High Energy Resolution Low Time Resolution Ion Species Rate¹	Ions	64	Count	Spectra	Spectra Flux	PAD, Aggregates	PSD, 2nd, 3rd Adiabat,
High Energy Resolution Low Time Resolution TOFxPH Proton Rate	Protons	32	Count	Spectra	Spectra Flux	PAD, Aggregates	PSD, 2nd, 3rd Adiabat,
TOFxE Proton Rate	Protons	14	Count	Spectra	Spectra Flux	PAD, Aggregates	PSD, 2nd, 3rd Adiabat,
TOFxE non Proton Rate	Heavy Ions	28	Count	Spectra	Spectra Flux	PAD, Aggregates	PSD, 2nd, 3rd Adiabat,
Low Energy Resolution High Time Resolution TOFxPH Proton Rate	Protons	10	Count	Spectra	Spectra Flux	PAD, Aggregates	PSD, 2nd, 3rd Adiabat,
TOFxE Ion Species	Ions	64	Count	Spectra	Spectra Flux	PAD, Aggregates	PSD, 2nd, 3rd Adiabat,
Space Weather Rates	All	NA	Count	Rate	Flux
Ion Species Basic Rate	Ions	NA	Count	Rate
Priority Events	NA	NA	Event
Ion Energy Diagnostic Rate	Ions	NA	Count	Rate
Ion Species Diagnostic Rate	Ions	NA	Count	Rate
Raw Ion Species Events	Ions	NA	Event
Raw Electron Energy Events	Electrons	NA	Event
Raw Ion Energy Events	Ions	NA	Event
Auxiliary Data	NA	NA	Aux
Critical Housekeeping Data	NA	NA	HSK
Magnetometer Data and Pointing Information			Mag			Pitch Angles

^{1: Use of the term “species” in these products descriptions is
misleading since these three data products utilize the energy collection mode of the RBSPICE instrument, rather than the species collection
mode. See below for more details about which products use which instrument
modes.}

3.3 RBSPICE Data Product Production Specifications

Table 3‑3‑3 lists the various data products that exist within the RBSPICE SOC Data Repository and are either produced or used by the RBSPICE SOC Processing System and stored within the RBSPICE SOC Data Repository. This table provides the critical variables that drive the final storage solution including the expected requirements on the final data volume. These requirements drive not only the size of the file system but also characterize the performance of the database where the data resides for quick access and use by the publication system.

Table 3‑3‑3 RBSPICE SOC Data Product Production Specifications

Data Level	Product Title	Contents	Volume	Format	Latency	Frequency
L0	Raw telemetry	Raw de-commutated telemetry received at RBSPICE-SOC	414 MB / day - TBR	Binary	from Receipt (T₀)	daily
L1	Count Rates	Sorted, time-tagged, instrument separated cts/sec	750 MB / day - TBR	ISTP Compliant CDF & ASCII (CSV	T₀ + < 14 days	daily
L2	Calibrated Flux	Calibrated and corrected physical units	1200 MB / day - TBR	ISTP Compliant CDF & ASCII (CSV	T₀ + < 1 month	daily
L3	Pitch Angle and Moments	Pitch angle distributions, plasma moments	1500 MB / day - TBR	ISTP Compliant CDF & ASCII (CSV	T₀ + < 3 months*	daily
L4	Phase Space Density	PSD units, adiabatic invariants, mag coordinates	30 MB / day	ISTP Compliant CDF & ASCII (CSV	T₀+ < 1 year	daily

3.4 RBSPICE Data Products and related Instrument Data Modes

RBSPICE Flight Software spin-based sectoring is used to break each spin into 36 sectors. The sectoring information is then used to drive the accumulation periods for each of the counting data products. Table 3-4 identifies the various data products collected by the RBSPICE instrument on each spacecraft. The accumulation time of each measurement is dependent upon the frequency strings shown in the table.

The Frequency column uses the following key phrases:

As needed	This product is only produced at certain times and is not a regular product
On Demand	This product is only produced at certain times and is not a regular product
On Demand	This product is like the “On Demand” but has a 1 record per second default frequency
Commandable	The frequency of this product is configurable
Every Second	A record is produced every second the instrument is on
Every Spin	A record is produced once per spin
S Sectors	A record is produced every S sectors; S is a configurable number in the flight software (fsw)
S*N1 Sectors	A record is produced every S*N1 sectors where S and N1 are configurable in the fsw
SN1N2 Sectors/Spins	Accumulation occurs over multiple spins for every SN1N2 sectors where the actual number of Spins and the values of S, N1, and N2 are all configurable in the fsw.
180 Seconds	A record is produced every 180 seconds.

The Mode column uses the following key phrases:

NA	Not Applicable to a data mode collection pattern
Ion Species	Data is collected using the Ion Species Instrument mode¹
Ion Energy	Data is collected using the Ion Energy Instrument mode¹
Electron Energy	Data is collected using the Electron Energy Instrument mode¹

^{1 – See the instrument paper for a description of the
various instrument modes.}

Certain strings in the Product Names relate to the accumulation time and resolution of the energy spectra. These strings are best interpreted as:

LEHT	Low Energy Resolution High Time Resolution
HELT	High Energy Resolution Low Time Resolution

Table 3‑4 RBSPICE Data Products and Instrument Modes

APID	Product	ProductName	Frequency	Mode
301	Command Echo	Commands	As needed	NA
302	Alarm	Alarms	As needed	NA
303	Memory Checksum	MemoryChecksum	On Demand	NA
304	Memory Dump	MemoryDump	On Demand, 1/sec	NA
305	Status	Status	Commandable	NA
306	Boot Status	BootStatus	Commandable	NA
307	Macro Dump	MacroDump	On Demand, 1/sec	NA
308	Macro Checksums	MacroChecksums	On Demand	NA
309	Monitor Limits	MonitorLimits	On Demand	NA
30A	Parameters	Parameters	On Demand	NA
30B	Text	Text	On Demand	NA
30C	Pixel Parameters	PixelParameters	On Demand	NA
30D	NA
30E	NA
30F	NA
310	Critical Housekeeping	CHSK	Every Second	NA
311	Space Weather	SW	Every Spin	Ion Species
312	Electron Energy Basic Rates	EBR	S Sectors	Electron Energy
313	Ion Energy Basic Rates	IBR	S Sectors	Ion Energy
314	Ion Energy Diagnostic Rates	IEDR	S Sectors	Ion Energy
315	Ion Species Basic Rates	ISBR	S Sectors	Ion Species
316	Ion Species Diagnostic Rates	ISDR	S Sectors	Ion Species
317	LER-HTR Electron Spectra	ESRLEHT	S Sectors	Electron Energy
318	HER LTR Ion Spectra	ISRHELT	SN1N2 Sectors/Spins	Ion Energy
319	HER LTR Electron Spectra	ESRHELT	SN1N2 Sectors/Spins	Electron Energy
31A	TOFxEnergy Ion Energy Spectra	TOFxE_Ion	SN1N2 Sectors/Spins	Ion Species
31B	TOFxEnergy Proton Rates	TOFxE_H	S Sectors	Ion Species
31C	TOFxEnergy Non-Proton Rates	TOFxE_nonH	S*N1 Sectors	Ion Species
31D	LRHTR TOFxPH Proton Rates	TOFxPH_H_LEHT	S Sectors	Ion Species
31E	HRLTR TOFxPH Proton Rates	TOFxPH_H_HELT	SN1N2 Sectors/Spins	Ion Species
31F	Raw Electron Energy Events	REEE	S Sectors	Electron Energy
320	Raw Ion Energy Events	RIEE	S Sectors	Ion Energy
321	Raw Ion Species Events	RISE	S Sectors	Ion Species
322	Priority Events	Priority	S Sectors	Ion Species
323	Auxiliary	Aux	Every Spin	NA
324	ERM Data	ERM	180 seconds	NA

3.5 RBSPICE Data Product Production Steps (High Level Overview)

The RBSPICE automation system performs the following processing steps, in the order listed:

1) Download Processing
Nightly, a set of download scripts is triggered to bring down data that require processing.

a. SPICE Files

b. Mission Operations Center (MOC) Telemetry Files

c. EMFISIS Level 2 Magnetic Field Files

d. ECT Level 2 Magnetic Ephemeris Files

2) SPICE Processing
Key XML scripts are modified in this step to integrate new SPICE kernels into the overall system.

3) MOC Data Organization
RBSPICE data downloaded from the MOC is moved to a final directory within the overall repository directory structure, based upon the APID of the data product.

4) Data Characterization
The system does a full file read to provide a detailed characterization of each file including the actual start and stop times of the data, the total number of records, and other relevant information. This information is entered into a processing control database, which is the primary driver for subsequent data processing.

5) Level 0 Processing – Daily Files in which each record start time occurs in the specified day/year
A Processing Script is read, identifying which Level 0 Data Products are to be produced.

a. Telemetry data files for each product are then read.

b. The data is extracted into the database.

c. A Comma Separated Values (CSV) text-based Level 0 data file is produced.

d. A Common Data Format (CDF) Level 0 data file is produced.

6) Level 1 Processing
A Processing Script is read, identifying which Level 1 Data Products are to be produced.

a. Counting data files for each product are then read.

b. The counts for each record are then converted into a rate, in units of Counts/Second.

c. A CSV text-based Level 1 data file is produced.

d. A CDF Level 1 data file is produced.

7) Level 2 Processing
A Processing Script is read, identifying which Level 2 Data Products are to be produced.

a. Rate data files for each product are then read.

b. The rates for each record are then converted, using the RBSPICE calibration data, into particle intensities (flux) in units of counts/(sec*sr*cm²*MeV).

c. A CSV text-based Level 2 data file is produced.

d. A CDF Level 2 data file is produced.

8) Level 3 Processing
A Processing Script is read, identifying which Level 3 Data Products are to be produced.

a. Intensity data files for each product are then read.

b. The Magnetic Field data for the time frame is then loaded.

c. The Magnetic Ephemeris data for the time frame is then loaded.

d. Pitch Angles for each telescope look direction are calculated, using the SPICE system.

e. A CDF Level 3 data file is produced.

9) Level 3 Pitch Angle and Pressure (PAP) Processing
A Processing Script is read, identifying which Level 3 PAP Data Products are to be produced.

a. Level 3 data files for each product are then read

b. The intensity data is binned according to a specified pitch angle binning schema

c. The aggregate data (pressures, density, omnidirectional flux, integrated flux) are calculated

d. A CDF Level 3 PAP data file is produced

3.6 RBSPICE Data Product Production Steps (Detailed Processing Algorithms)

The RBSPICE SOC software system is comprised of a set of processing workflows (see previous section) in which the underlying software system triggers different processing code for each workflow. The following sections detail the algorithms used in the creation of the Level 0 Count Files, the Level 1 Rate files, the Level 2 Intensity (flux) files, and the Level 3 Pitch Angle files. Details presented for each of these steps are sufficient to allow other software developers to write their own translation workflow. (Note that only the RBSPICE SOC data files are considered the Official release of the data, and any files produced by outside agents using these algorithms are considered unofficial even though they might be identical in content.)

3.6.1 Level 0 Processing Algorithms

Level 0 data is generated by directly decoding telemetry into binary data values. The encoding is described completely in the RBPSICE Instrument Flight Software and needs no additional description. Specific aspects of the telemetry to Level 0 processing are explained below.

The data fields described are used throughout the various workflows to generate products for Level 0 through Level 3.

Timing values

Field Name	Type	Description	Allowed Values
SCLOCK	UInt32	The value of the SCLOCK at the beginning of the spin	0…4294967295
Fine SCLOCK	UInt16	The value of the RBSPICE high resolution clock at the beginning of the spin units of (1/2¹⁶₎ seconds One tick of the Fine SCLOCK value is equivalent to 15.25855624… microseconds	0…65535
Spin	UInt16	The current spin number as received from the SC in the 1 PPS signal	0…65535
Spin Duration	UInt32	The value of the spin period in milliseconds used by the RBSPICE flight SW in units of milliseconds	5000…20000

Accumulation Mode values – used in the calculation of accumulation duration to convert counts to rates (see below)

Field Name	Type	Description	Values
Integration Sectors –S	Byte	Number of sectors used in the RBSPICE fast accumulation mode	1-36
Integration Multiplier 1 – N1	Byte	Multiplication factor used to control the number of sectors accumulation in medium modes	1-36
Integration Multiplier 2 – N2	Byte	Multiplication factor used to control the number of sectors accumulated in slow modes	1-36
Integration Spin - Spin_I	Byte	Number of spins to include in the slow accumulation mode	1-20

Pixel Size Values – used in the calculation of intensity (flux)

Field Name	Type	Description	Values
Electron Pixel - e_pixel	Bool	Identifies whether we are using the small pixel (0) or the large pixel (1) size in electron energy mode	0-1
Ion Energy Pixel - IE_pixel	Bool	Identifies whether we are using the small pixel or the large pixel in ion energy mode	0-1
Ion Species Pixel - IS_pixel	Bool	Identifies whether we are using the small pixel or the large pixel in ion species mode	0-1

Data Collection Pattern - used in the calculation of accumulation start/stop times and duration to convert counts to rates

Field Name	Type	Description	Values
Subsector 1 – DCP[0]	Byte	Identifies what accumulation mode is used in the first half of the sector 0=Electron Energy, 1=Ion Energy, 2=Ion Species	0-2
Subsector 2 – DCP[1]	Byte	Identifies what accumulation mode is used in the third quarter of the sector	0-2
Subsector3 – DCP[2]	Byte	Identifies what accumulation mode is used in the fourth quarter of the sector	0-2

Spin Data – used in the calculation of pitch angles

Field Name	Type	Description	Values
Spin Data Valid – valid_spin	Bool	Identifies if the spin value from the SC is valid or not, 0=invalid, 1=valid	0-1
Mag Data Valid - valid_mag	Bool	Identifies if the magnetic field value from SC is valid or not	0-1
Mag Phase Valid - valid_phase	Bool	Identifies if the magnetic field phase value from SC is valid or not	0-1

Time Stamp Generation

The telemetry product X323 (Auxiliary) is the only component of the received RBSPICE telemetry that provides the ability to create a high time resolution conversion from spacecraft clock (SCLOCK) plus the RBSPICE instrument internal timer (Fine SCLOCK), which is used for data accumulation in the counters, to ephemeris time (ET) representing the real time on a clock. The X323 packets are generated by the RBSPICE instrument at the end of each spin. The packets include a time stamp derived from the timing information provided by the spacecraft in the “1 PPS (Pulse Per Spin) SC to Instrument” data packet. The SCLOCK value cycles from 0 to 4294967295 and then repeats. The Fine SCLOCK value cycles from 0 to 65535 and is in units of (1/2¹⁶) seconds. In general, each tick of the SCLOCK is approximately 1 second, although this relationship can drift depending upon the heating and cooling of the spacecraft. The SCLOCK value is not a unique value, but repeats every 136.19 years. Since the Van Allen Probes Mission is a nominal two-year mission, it is expected that the SCLOCK value never repeats over the life of the mission. However, environmental factors could trigger a reset of the SCLOCK.

Because the Van Allen Probes spacecraft orbit through extreme radiation environments, it is expected that at some time a Single Event Upset (SEU) will occur, causing the SCLOCK to reset on one or both of the spacecraft. One of the mission requirements assigned to the Mission Operations Center (MOC) is to ensure the SCLOCK value is unique and monotonic throughout the life of the mission, including extended mission phases, even in the event of an SEU. The RBSPICE SOC has written the processing software with the assumption that the SCLOCK value provided to the RBSPICE instrument is unique and will never repeat. When combined with the Fine SCLOCK value, the resulting time value provides RBSPICE scientists the ability to meet the 2-3 millisecond resolution requirement definition specified for inter-instrument calculations, as specified in the instrument requirement documents.

The X323 telemetry record time stamps are decoded by the RBSPICE SOC software system and the resulting SCLOCK and Fine SCLOCK values are converted into a time stamp using the following algorithm:

1. The Fine value is converted into seconds as fine*(1/2¹⁶) and then converted into SPICE fine seconds (1/5x10⁴) i.e. in units of 20 milliseconds per tick.

2. The SCLOCK data value from telemetry along with the Fine SCLOCK value (see step 1) is converted into a timestamp by use of the JPL SPICE software system and the MOC-provided RBSP (A/B) SPICE SCLOCK kernels. (Note that the SPICE system has a high resolution mapping kernel that relates SCLOCK values to ET, which is defined in the J2000 EPOCH.)

3. The next step in the process is to get the ET value at the start of each sector. The RBSPICE flight software divides a spin into 36 sectors. At the end of the spin, the spin duration value of the just finished spin is reported in the X323 telemetry record. With the ET value (from step 2) of the start of the spin and the spin duration in milliseconds, it is possible to directly calculate the ET value at the start of each sector:

Most other telemetry packets received from the RBSPICE instrument contain the spin and sector numbers at the start of the telemetry packet, so that ET at the start of an accumulation can be easily calculated.

Duration of Measurement and Start/Stop Times

During the process of generating the timestamp for each measurement, the level 0 processing system also calculates the duration of each measurement. This is not as simple as merely calculating the start time of each measurement and subtracting it from the start of the previous measurement since the RBSPICE instrument has three possible measurement modes which can be assigned to one of the three available subsector measurement time frames.

To understand this fully, it is necessary to understand how the RBSPICE instrument takes measurements. Each sector is divided into three subsectors. Subsector 0 spans the first half of the sector; subsector 1 spans the third quarter of the sector, and subsector 2 spans the fourth quarter of the sector.

Figure 3‑1 Sector and subsector scheme used by RBSPICE also showing inter-subsector dead times.

The RBSPICE instrument can be commanded to use one of the three measurement modes (electron energy, ion energy, and ion species) during each of the subsectors, providing the ability to simultaneously measure electrons and ions within a sector or, alternatively, to use a single type of measurement for higher resolution science. Also shown in the diagram is the instances of “dead time” which occur at the end of each subsector due to the instrument must reconfiguring itself for the next subsector. This portion of the subsector time must be subtracted from the overall time of the subsector to properly calculate the total duration of the measurement. The response of the RBSPICE electronics shows that a transition from subsector 2 to subsector 0 takes 4.04 milliseconds and a transition from subsector 0 to 1 or subsector 1 to 2 takes 3.95 milliseconds.

The key values required to properly calculate the measurement duration are found in the X323 telemetry packet (see above): Spin Duration (in seconds), Accumulation Mode Values (S, N1, N2, and Spin) and Data Collection Pattern (DCP). For each time measurement, the timing system queries the Auxiliary data from the RBSPICE database for the current running value of each of these variables. The timing system also identifies the type of data product being processed. By using the following table, the system understands the frequency of the measurement for the product and which DCP mode applies to the measurement.

Table 3‑4 Data Collection Pattern and Frequency by APID

APID	Product	Product Name	Frequency	DCP mode
301	Command Echo	Commands	As needed	NA
302	Alarm	Alarms	As needed	NA
303	Memory Checksum	MemoryChecksum	On Demand	NA
304	Memory Dump	MemoryDump	On Demand, 1/sec	NA
305	Status	Status	Commandable	NA
306	Boot Status	BootStatus	Commandable	NA
307	Macro Dump	MacroDump	On Demand, 1/sec	NA
308	Macro Checksums	MacroChecksums	On Demand	NA
309	Monitor Limits	MonitorLimits	On Demand	NA
30A	Parameters	Parameters	On Demand	NA
30B	Text	Text	On Demand	NA
30C	Pixel Parameters	PixelParameters	On Demand	NA
30D	NA
30E	NA
30F	NA
310	Critical Housekeeping	CHSK	Every Second	NA
311	Space Weather	SW	Every Spin	Ion Species
312	Electron Energy Basic Rates	EBR	S Sectors	Electron Energy
313	Ion Energy Basic Rates	IBR	S Sectors	Ion Energy
314	Ion Energy Diagnostic Rates	IEDR	S Sectors	Ion Energy
315	Ion Species Basic Rates	ISBR	S Sectors	Ion Species
316	Ion Species Diagnostic Rates	ISDR	S Sectors	Ion Species
317	LER-HTR Electron Spectra	ESRLEHT	S Sectors	Electron Energy
318	HER LTR Ion Spectra	ISRHELT	SN1N2 Sectors/Spins	Ion Energy
319	HER LTR Electron Spectra	ESRHELT	SN1N2 Sectors/Spins	Electron Energy
31A	TOFxEnergy Ion Energy Spectra	TOFxE_Ion	SN1N2 Sectors/Spins	Ion Species
31B	TOFxEnergy Proton Rates	TOFxE_H	S Sectors	Ion Species
31C	TOFxEnergy Non-Proton Rates	TOFxE_nonH	S*N1 Sectors	Ion Species
31D	LRHTR TOFxPH Proton Rates	TOFxPH_H_LEHT	S Sectors	Ion Species
31E	HRLTR TOFxPH Proton Rates	TOFxPH_H_HELT	SN1N2 Sectors/Spins	Ion Species
31F	Raw Electron Energy Events	REEE	S Sectors	Electron Energy
320	Raw Ion Energy Events	RIEE	S Sectors	Ion Energy
321	Raw Ion Species Events	RISE	S Sectors	Ion Species
322	Priority Events	Priority	S Sectors	Ion Species
323	Auxiliary	Aux	Every Spin	NA
324	ERM Data	ERM	180 seconds	NA

The timing system calculates the duration of the measurement using the following algorithm:

1) Use the current Spin Duration and calculate:

a. Accumulation time of a sector – acc_sector

b. Duration of ¼ of a sector (or a subsector) - dur_subsector

2) Identify the Product Accumulation Factor (S, S*N1, S*N1*N2, S*N1*N2/Spins) from the above table

a. Use the values of S, N1, N2, and Spin_I to calculate the multiplication factor

i. factor = S;

ii. factor = S*N1; or

iii. factor = S*N1*N2

b. If this measurement is done over multiple spins, i.e. (S*N1*N2/Spins), then we also need to query the database for the spin duration of each spin included in the measurement so that the timing can be calculated as precisely as possible for each spin in the measurement, i.e. acc_sector and dur_subsector are recalculated for each value of spin duration.

3) For the current product, identify which subsectors (0, 1, or 2) are involved in this measurement for the DCP mode derived from the table.
Note that this measurement mode could be used in all possible combinations of subsectors (0, 1, and/or 2), but since we are working with a particular product with real data, there has to be at least one subsector involved (otherwise we wouldn’t have data for the product!)

4) Create two variables to capture the durations:

a. AccumTime – to capture the total amount of sector/subsector time available in the measurement

b. DeadTime – to capture the amount of dead time involved in the measurement

5) For each spin that is involved in the measurement, calculate the sector and subsector times based upon the spin duration for each spin:

a. For each DCP that is involved in the measurement

i. Add the subsector time (sub0=2*dur_subsector, sub1=dur_subsector, sub2=dur_subsector) to the current AccumTime

ii. Add the specific DeadTime to the DeadTime duration

1. In going from subsector 2 to subsector 0, the DeadTime is 4.04 millseconds

2. In going from subsector 0 to 1 or 1 to 2, the DeadTime is 3.95 milliseconds

6) Calculate the duration of the measurement (Duration) as: (AccumTime – DeadTime)*factor for each spin.

7) Calculate the start/stop time for the accumulation

a. The start time is the start of the accumulation at the start of the first subsector involved in the measurement.

b. The stop time is the end time of the last subsector involved in the measurement.

i. For products accumulated over a single spin, this becomes simply
endET = startET + duration + DeadTime; or endET = startET + AccumTime;

ii. For products accumulated over multiple spins

1. For the first spin, add in the time from the start of the measurement to the end of the last subsector of the last sector measured in that spin.

2. For each subsequent spin (except the last), add in the total time of the spin.

3. For the last spin, add in the time to go from the start of the spin to the end of the last subsector of the last sector of the measurement.

8) Calculate the Midpoint time for the accumulation:

a. For single spin measurements, this is startET + (endET-startET)/2

b. For multiple spin measurements, this is a very complex problem since the midpoint from startET to endET would not necessarily occur in the middle of the sectors that are participating in the accumulation.
This can be seen most clearly in the following table in which we are starting our accumulation in sector 0 and accumulating over 4 sectors and 10 spins, i.e. S = 1, N1 = 2, N2 = 2, and Spin_I = 10. The sectors involved in the measurement are identified in the table as green with two white squares in the middle; the location of the start and end times are obvious. The red square outside the actual accumulation time is the false midpoint time taken as simply the startET + (endET – startET)/2, showing that this algorithm does not work correctly. The actual midpoint time is shown in the middle of the two white squares and is based upon the correct calculation of the midpoint time. This table (and others) were used to generate an algorithm to properly calculate what the actual midpoint of the measurement is, based upon the starting sector, the number of sectors involved, and the number of spins involved.

Table 3‑5 Sample multi-spin accumulation showing the false (red) and true (white) midpoint times of the accumulation.

Start ET	SpinDur	Sector	SubSec	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31	32	33	34	35
410270537.6	10.884	0.302333333	0.075583333
410270548.4	10.883	0.302305556	0.075576389
410270559.3	10.882	0.302277778	0.075569444
410270570.2	10.882	0.302277778	0.075569444
410270581.1	10.883	0.302305556	0.075576389
410270592	10.882	0.302277778	0.075569444
410270602.9	10.882	0.302277778	0.075569444
410270613.7	10.882	0.302277778	0.075569444
410270624.6	10.883	0.302305556	0.075576389
410270635.5	10.883	0.302305556	0.075576389

RBSPICE Status Control information

The telemetry product X305 (Status) includes a small number of values that are necessary to one or more of the workflows as the data is processed from Level 0 to Level 3. These fields are described below:

Field Name	SoftName	Description	Values
TOFxPH Deprecation	TOFxPH	Identifies how the TOFxPH events are collected: 0-disabled (TOFxPH isn’t used) 1-Enable All 2-Enable 1 of 2 (i.e. collect 1 out of every 2) 3-Enable 1 of 4 4-Enable 1 of 8 5-Enable 1 of 16 6-Enable 1 of 32 7-Enable 1 of 64	0-7

RBSPICE Basic Rate Information (EBR, IBR, and ISBR)

There are three telemetry products related to collection of basic rate statistics that are critical in processing RBSPICE data from Level 0 to Level 1, and are part of the R_in versus R_out algorithms described in the Level 1 Processing Algorithms section (3.6.2).

The fields from each of these three telemetry products are as follows:

Electron Basic Rates (X312) and Ion Energy Basic Rates (X313) – Ancillary Data Values

Field Name	SoftName	Description	Units	Type	Values
SSD Counters	SSD[0..5]	Counts events above the SSD energy threshold for each telescope	Counts	UINT32[6]	0…
SSD Dead Time	SSDDead[0..5]	Integrates the amount of dead time in each SSD for each telescope	100ns	UINT32[6]	0…
State Machine Idle	SMI or IDLE	Event State Machine Idle Time	100ns	UINT32	0…
Multiple Hit Reject	MHR	Counts number of events rejected due to simultaneous energy channel events	Counts	UINT32	0…
Valid Energy Events	VEE	Counts the number of valid energy events	Counts	UINT32	0…
Valid Events Queued	VEQ	Counts the number of valid energy events placed in the FIFO	Counts	UINT32	0…
Valid Events Processed	VEP	Counts the number of valid energy events processed by the flight software	Counts	UINT32	0…

Ion Species Basic Rates (X315) – Ancillary Data Values

Field Name	SoftName	Description	Units	Type	Values
Start 0 Anode	Start0	Counts the number of events above the start0 anode threshold	Counts	UINT32	0…
Stop 0 Anode	Stop0	Counts the number of events above the stop0 anode threshold	Counts	UINT32	0…
TOF Coincidence	TOFCOIN	Counts the number of events where the start and stop are within the 200ns window	Counts	UINT32	0…
Pulse Height	PH	Counts the number of events above the TOF pulse height threshold	Counts	UINT32	0…
Start Counters	Start[0..5]	Counts the number of events calculated to be at the given start position per telescope	Counts	UINT32	0…
SSD Counters	SSD[0..5]	Counts the number of events above the SSD threshold	Counts	UINT32[6]	0…
SSD Dead Time	SSDDead[0..5]	Integrates the amount of dead time in each SSD for each telescope	100ns	UINT32[6]	0…
State Machine Idle	SMI or IDLE	Event State Machine Idle Time	100ns	UINT32	0…
Multiple Hit Reject	MHR	Counts the number of events rejected due to simultaneous energy channel events	Counts	UINT32	0…
Valid TOFxPH Events	V_PH=VTOFxPH	Counts the number of valid TOFxPH events	Counts	UINT32	0…
Valid TOFxE Events	V_E =VTOFxE	Counts the number of valid TOFxE events	Counts	UINT32	0…
Valid Events Queued	VEQ	Counts the number of valid energy events placed in the FIFO	Counts	UINT32	0…
Valid Events Processed	VEP	Counts the number of valid energy events processed by the flight software	Counts	UINT32	0…
TOF Coincidence	TOF_Coin	Determine the number of valid TOF and SSD events occur at the same time	Counts	UINT32	0…

Level 0 File Version number information

As of the writing of this revision, e, the following table presents the minimum level 0 file data format version number and file data revision version number that is considered reasonably correct and usable for subsequent calculation of higher-level data products.

3.6.2 Level 1 Processing Algorithms

The primary activity in processing the Level 0 data into Level 1 data is to convert the count data into rate data. This is done in a series of algorithmic steps in which the Level 0 count data is read into memory, the duration of the measurement is loaded from the Level 0 file, the counts themselves are adjusted according to the R_in vs R_out algorithm, and the rate data is then written to a Level 1 file. The following constants and variables are used throughout the subsequent sections:

Name	Description	Type	Value(s)
Max_IDLE	Maximum number of 100ns intervals for which data can be accumulated	UInt32
Clk_Period	Number of nanoseconds in the RBSPICE DPU clock period	UInt32	100
ST_Dead	Start counter dead time due to synchronization logic	UInt32	2
SP_Dead	Stop counter dead time due to synchronization logic	UInt32	2
SP_Veto	Interval in which additional stop pulses cause the event to be discarded	UInt32	2
RDT_Veto	Interval for inhibiting start and stop counter during chip TOF reset	UInt32	1
PKD_Reset	Interval for resetting the peak detector	UInt32	4
PUR_Veto	Interval during which a second SSD pulse causes event to be discarded	UInt32	7
TOFxE_PUR_Veto	Interval during which a second SSD pulse causes event to be discarded (changed in software configuration file for TOFxE only)	UInt32	24
K_{1E_E}	Correction constant term for valid TOFxE events	Float	0.3
K_{1E_PH}	First order correction constant term for valid TOFxPH events	Float	0.15
K_{2E_PH}	Second order correction constant term for valid TOFxPH events	Float	0.15
ST_MISS	The number of FPGA clock cycles are missed each sector Code variable names: _tofxph_RvsR_EFact or _tofxe_RvsR_Efact	UInt32	2
Cssd	FPGA clock ticks or the required value to reproduce MHR from FPGA, based upon the IBSR record only	UInt32	2
C_phSC	Represents the factor for which PH counts miss from the start0 counts	Float	C_phA=0.860 C_phB=0.775

R_in vs R_out Algorithm and Formulae

Basic Rates

EBR (X312), IBR(X313), and ISBR(X315) telemetry includes the measured counts (SSD) and dead time (SSDDead) for each telescope. These values are converted to a rate value using the following algorithm:

For each telescope (where “tele” goes from 0 to 5)

Energy Rates

Conversion of the counts obtained for the ESRLEHT(X317), ISRHELT(X318), and ESRHELT(X319) telemetry is somewhat more complicated, because the algorithm requires an understanding of the spin information (X323) and the basic rate data (EBR for ESRLEHT and ESRHELT, IBR for ISRHELT) to fully convert the count data into a rate. For purposes of this algorithm, the count values in the telemetry are called h_ij, where i refers to the telescope number and j refers to the energy channel of the measurement. Following is the algorithm used in the RBSPICE SOC software for each telescope and each energy channel:

1) If the count is zero, return a rate of 0.0

2) Identify the number of sectors involved in the measurement, based upon the frequency of the product (S, S*N1, S*N1*N2,Spins) – for an example see table 3-5.

3) Calculate the default rate as: (as above)

4) If the measurement spans a single spin
Get the basic rate energy data object (erd) for the current SCLOCK, Spin, and Sector

5) If the measurement spans multiple spins
Get a conglomerate basic rate energy data object (erd) for the current SCLOCK, Spin, and Sector for each involved spin which adds all basic rate measurements together to form a single ERD

6) If erd = null, return the defaultrate (i.e. we cannot do R vs R correction without the basic rate data)
(Note that there are some scenarios in which this is possible, but they are extremely rare.)

7) Get the following variables from the erd object:
vee = valid energy events
vep = valid events processed
idle = state machine idle
ssd = basic count for the current telescope
ssddead = basic count dead time for the current telescope

8) Calculate the basic rate, brate, (see section above) using the values returned in the erd object

Calculate each of the following terms (cipkd_reset and cipur_veto) using the following formula:

This algorithm can produce rates that are smaller than the default rate at somewhat low counting times. The SOC software tests for this condition and returns the default rate if the calculated rate is smaller. Note that the SOC software has conditions on the level of failure built into the processing, such that if the percent error of the calculated rate versus the default rate (in an error condition) is significantly high, then a particular file will fail so that more investigation can be made to better understand the situation. Eventually the file will be allowed to succeed, once it has been understood and recognized that no significant processing issue is involved.

Species TOFxPH Rates

The conversion of the species mode TOFxPH measurements for products TOFxPHHLEHT (X31D) and TOFxPHHHELT (X31E) follows a similar algorithm as discussed for the calculation of Energy Rates (see above). The key difference is in the values used from the Ion Species Basic Rate data object (erd) and the formulas of step 9:

7) Get the following variables from the erd object:
V_E= vtofxe = valid TOFxE events
V_PH = vtofxph = valid TOFxPH events
vep = valid events processed
idle = SMI =State machine idle
ssd = basic count for the current telescope
ssddead = dead time for the current telescope – using in calculation of duration in basic rate
start0 = Counts number of events above start0 threshold
stop0 = Counts number of events above the stop0 threshold
sumSSD = summation of all SSD values for all telescopes for the current record
TOF_coin = Number of valid TOF and SSD coincident events
ph = number of events above the TOF pulse height threshold

9) Calculate each of the following terms:

Species TOFxE Rates

The conversion of the species mode TOFxE measurements for products TOFxEIon (X31A), TOFxEH (X31B), and TOFxEnonH (X31C) follows a similar algorithm as discussed above for Energy Rates and Species TOFxPH rates (see above). Again, the key difference is what values are acquired in Step 7 and the formula in Step 9.

9) Calculate each of the following terms:

Error Calculations for Rate Files

As counts are converted into rates, the Level 1 files capture the statistical Poisson error so that the information can be used in understanding and calculating the error propagation for scientific publications. The errors placed in the Level 1 files are done for each telescope and energy channel measured. Given a count, n, the calculated values are the percent error calculated as:

3.6.3 Level 2 Processing Algorithms

The primary activity in processing the Level 1 data into Level 2 data is to convert the rate data into particle intensity (flux) data. This is done in a series of algorithmic steps in which the Level 1 rate data is read into memory, the calibration data for the SC and product are loaded, the intensities are calculated, and the intensities are then written to a Level 2 file. Additional fields are added to the Level 2 file to match the Panel on Radiation Belt Environmental Modeling (PRBEM) standards for such data. See http://craterre.onecert.fr//prbem/home.html for a complete specification of this standard. Note that the Level 2 files do not include all required variables to meet the PRBEM standard, but instead those variables are added to the files to create the Level 3 final data products.

Conversion of Field Names into PRBEM standards

The PRBEM standards require all variables to fit specific field name guidelines. The RBSPICE SOC team has made every effort to utilize these guidelines. The Level 1 rate files contain variables of rate data with a CSV common name of T#_R where # represents the telescope, and a CDF common name of T#_Rates. The Level 2 PRBEM standard requires a variable that is species-specific, so the standard Intensity (Flux) variables contained in the Level 2 files are of the standard for F?DU, where “?” is a character representing the species of the variable. The individual characters have the following meaning:

Character	Interpretation	RBPSICE Values
F	Represents an Intensity or Flux
?	Identifies the Species	I=Ion, H=Proton(Hydrogen), He=Helium, O=Oxygen, E=Electron
D	Identifies that the intensities are Differential in energy
U	Identifies that the intensities are unidirectional and not omni-directional

It should be noted that several RBSPICE products contain multiple intensity variables, because some of the products energy channels are responsive to different species of particles. While the variable names match the PRBEM standard, the variable sizes do not. When creating the intensity variables, it was prudent to create a two-dimensional array that contains the intensity for each telescope and channel combination. Energy channels that are NOT responsive to the particular species are written with a fill value in the CDF files and an empty field value in the CSV files.

Calculation of Intensities (Flux)

RBSPICE calibration data can be found at the following locations:
http://rbspice.ftecs.com/RBSPICEA_Calibration.html and http://rbspice.ftecs.com/RBSPICEB_Calibration.html.

The data is organized by product type and contains the necessary information needed to convert RBSPICE rate data into intensity (flux) data. The calibration data fields are described in the following table.

Name	Description	Type	Units	Values
SC	Identifies the SC for this record	String	NA	RBSPA or RBSPB
Product Type	Identifies the applicable product	String	NA	ESRHELT, ISRHELT, ESRLEHT, TOFxEIon, TOFxEH, TOFxEnonH, TOFxPHHHELT, and TOFxPHHLEHT
Telescope	Allows the values to vary per telescope as the instrument starts degrading	Integer	NA	0 … 5
StartUTC	Identifies when this calibration record is applicable	String	Time	Standard format of CCYY-MM-DDTHH:MM:SS.hhh
StartET	Identifies the Ephemeris Time when this record is applicable	Real	Seconds	315576066.183925 … 788961666.183928
StopUTC	Identifies when ending time when this record is applicable	String	Time	Standard format of CCYY-MM-DDTHH:MM:SS.hhh
StopET	Identifies the ending ET when this record is applicable	Real	Seconds	315576066.183925 … 788961666.183928
Species	Identifies the primary species of the measurement	String	NA	e=electron, Ion(Ions)=ion, H=proton, P=proton, He=Helium, O=Oxygen, X=not used
Channel	Energy channel	Integer	NA	0 … total number of energy channels – 1
E_Low	Low end of the energy passband	Real	MeV
E_High	High end of the energy passband	Real	MeV
E_Mid	Midpoint of the energy passband	Real	MeV
G_Small	Geometrical factor when the small pixels are used (See X323 data)	Real	cm²
G_Large	Geometrical factor when the large pixels are used (See X323 data)	Real	cm²
Eff	Efficiency of the passband	Real	NA
Notes	Relevant information about channel	String	NA

Rates are converted into Intensities using the following equation:

The specific value used of the geometrical factor, G, is based upon the current pixel value (small or large) contained in the X323 auxiliary data packet (see Level 0 processing for more information). The final CDF variable that is created to contain the intensities is a two-dimensional variable of type Real and sized as F?DU[tele,ch] so that it contains the data for each telescope and channel combination.

Additional Variables Added to Level 2 Data

A number of additional variables are added to the Level 2 data file during conversion. The following paragraphs and tables describe these variables and how they are calculated. Note the following notations: Real[ch] indicates a Real array with a size equivalent to the number of energy channels, Real[tl] indicates a Real array with a size equivalent to the number of telescopes, and Real[tl,ch] indicates a Real two-dimensional array with a size equivalent to the number of telescopes and energy channels.

Field	Description	Type	Units	Limits	Algorithm
L	Value of the McElwain L Shell for a Dipole Field	Real	R_E	0.0 to 10.0
Position_SM	Position of SC in Solar Magnetospheric Coordinates	Real[3]	R_E	-10.0 to 10.0	SPICE
F?DU_Error	The Poisson statistical percent error (see Level 1 error)	Real[tl,ch]	%	0.0 to 100.0
F?DU_Crosscalib_RMS	This variable is not used in the Level 2 files but exists for consistency with the PRBEM standards. Once inter-instrument calibration is finished this variable might be used to contain that information	Real[tl,ch]	NA
F?DU_Energy	Midpoint energy for each energy channel	Real[tl,ch]	MeV	0.01 to 10
F?DU_Energy_Range	The high and low energy values for the Channel Note that this variable does NOT follow the standard which asks for the delta low and high values	Real[tl,2,ch]	MeV	0.01 to 10
FEDU_Quality	The data quality flag using the PRBEM standard. Note that currently the automation system only sets the value to 10 which is that the quality is unknown. As algorithms are developed to clarify the quality of the data this value will be changed.	Integer[tl,ch]	NA	0 to 10

Inter-Instrument Calibration

The RBSPICE energy measurements have been cross-calibrated with the MagEIS and HOPE energy measurements for similar energy channels. These calibration activities have resulted in adjustments to the efficiencies in the calibration table. At some time in the future the details of these calibration activities will be presented in this section.

RBSPICE Background

The current data files produced by the RBSPICE SOC are NOT background corrected for contamination due to energetic electrons and cosmic rays. At some time in the future this section will be completed with steps that describe the process required to background correct the RBSPICE intensity data.

3.6.4 Level 3 Processing Algorithms

The primary activity in processing the Level 2 data into Level 3 data is to calculate the pitch angles of the six telescopes, based upon the measured magnetic field received from the EMFISIS instrument. This processing is done in a series of algorithmic steps in which the EMFISIS magnetic field data is loaded, the ECT Magnetic Ephemeris data is loaded, the Level 2 intensity data file is copied, and the pitch angles are calculated and placed into the copied Level 2 file, creating a Level 3 file. Additional fields are added to the Level 3 file to fulfill the full standards of the PRBEM for such data. See http://craterre.onecert.fr//prbem/home.html for a complete specification of this standard.

Note that the Level 3 files are only created as CDF files. It was determined that the number of fields in the Level 2 CSV files was becoming excessive and that the additional fields added to the Level 3 files would make this even more cumbersome. The RBSPICE SOC can provide a CSV equivalent file for a small specific set of days, if a scientist does not have software to read-in the CDF files. These queries should be emailed to the RBSPICE SOC Lead.

EMFISIS Magnetic Field Data

The Level 2 UVW EMFISIS 60 hertz magnetic field data files were chosen to be used to calculate the RBSPICE pitch angles. These files contain data sampled at 60 Hz, so contain around 5 million samples per data file. In order to reduce the overall memory utilization and to reduce the overall processing requirements, these files were deprecated by a specific programmable number before being used to calculate Pitch Angles. . Currently the deprecation is set at a factor of 8. There is no filtering used during the deprecation stage of loading the magnetic field data into the database, but instead every 8^th value was included.

ECT Magnetic Ephemeris Data

Some of the additional fields included in the RBSPICE Level 3 CDF files have data taken directly from the ECT Magnetic Ephemeris data files. The definitive Olsen Pfitzer 1977 quiet time files were used in this processing. The data fields chosen from these files are deemed relevant to understanding the RBSPICE energetic particle data.

Calculation of Particle Flow Direction

The particle flow direction has been added to the RBSPICE Level 3 files since file version x.1.10. The particle flow direction is calculated by utilizing the definitive SPICE CK and FK kernels for each spacecraft at the time of the observations. The calculation is made by utilizing the SPICE function pxform_c(FROM, TO, M) for each telescope. The “FROM” reference frame in the transformation is the RBSPICE telescope reference frame written as RBSPA/B_RBPSICE_T{0…5}, e.g. RBSPB_RBSPICE_T3 would represent telescope 3 for the RBSPICE instrument on the Van Allen Probes B spacecraft. The “TO” reference frame in the transformation is the “SM” reference frame. The relationship between the RBSPICE telescopes and the spacecraft UVW or XYZ reference frames can be found in the Van Allen Probes frame kernels: rbspa_vxxx.tf and rbspb_vxxx.tf. Once the transformation matrix is derived then the boresight unit vector for each telescope (also defined in the RBSPICE frame kernels) is multiplied by the transformation matrix as: where M is the transformation matrix from the telescope reference frame to the SM reference frame and B is the boresight unit vector for the specific telescope and i represents the telescope index.

The particle flow direction is then calculated as the negative or reverse of the telescope boresight unit vector transformed into the SM reference frame, e.g. . If there is an exception thrown during the transformation, i.e. there is either something wrong with the SPICE CK kernel or else the transformation is not possible at the particular Ephemeris Time (ET), then the particle flow direction unit vector returned is which represent an unknown look direction. NOTE: there are a few files in which bad particle flow direction unit vectors are defined as which was incorrectly defined as the original definition of a failed look direction calculation. If a user of this data encounters this anomalously defined bad particle flow direction unit vector then the user can examine the pitch angle quality flag to determine if this value is truly bad or else if this is an acceptable look direction.

Calculation of Pitch Angles

The pitch angle calculation uses the following algorithms in the order listed:

1) Verify that magnetic field data and magnetic ephemeris data exist; otherwise fail processing.

2) Verify that SPICE C-Kernels are available for the time frame to be processed.

3) For each record of the Level 2 intensity variable, do the following:

a. Get spin segment that applies to this record

i. This recognizes data products that accumulate over multiple spins

b. Create an array of start and stop times based upon the accumulation sectors for each spin involved and the available magnetic field data, i.e. this is start/stop for the actual B vectors, not for the accumulation time point.

c. Get a set of magnetic field vectors for each time point contained in the time segments defined in b.

d. Calculate the look direction for each telescope and each time point contained in the time segments defined in b.

e. Calculate a pitch angle for each look direction/magnetic field vector combination

f. Average all pitch angles to get a final pitch angle representative of the accumulation for this measurement

g. Set the pitch angle quality flag, as follows:

i. Quality = 0 (good)

ii. Quality = 1 (bad – poorly defined virtual spin period)

iii. Quality = 2 (bad – no magnetic field data available)

h. Set the minimum and maximum pitch angle values from the list of pitch angles as calculated above.
Note that the pitch angle range data is written in the F?DU_AlphaRange variable for each species in the file.

i. Write the pitch angle data, as well as the other new variables for this measurement

Additional Level 3 Variables

A number of additional variables are added to the Level 3 data file while the pitch angles are being calculated. The following paragraphs and tables describe these variables and how they are calculated. Note the following notations: Real[ch] indicates a Real array with a size equivalent to the number of energy channels, Real[tl] indicates a Real array with a size equivalent to the number of telescopes, and Real[tl,ch] indicates a Real two-dimensional array with a size equivalent to the number of telescopes and energy channels.

Field	Description	Type	Units	Limits	Algorithm
Position	Position of SC in GSE coordinates	Real	R_E	-10.0 to 10.0	SPICE
Position_GSM	Position of SC in GSM Coordinates	Real[3]	R_E	-10.0 to 10.0	SPICE
Position Quality	PRBEM position quality flag, 0=good, 1=bad	Integer	NA	0 to 1	Always 0
Alpha	Calculated pitch angle for each telescope	Real[tl]	Degrees	-90 to 90	See above
Alpha_Quality	Quality of the pitch angles calculated, 0=good, 1=bad	Real	NA	0 to 1	See above
ParticleDir_SM	Calculated particle velocity unit vector in the SM reference frame, set to (0,0,0) or (-1,-1,-1) if undefined	Real[3]	NA	-1.0 to 1.0
L_Eq	Geocentric distance to B_min point for FL threading vehicle (i.e. \|P_min\|)	Real	R_E	1.0 to 10	ECT Data
L_Star	Generalized Roederer L-shell value	Real	R_E	1.0 to 10	ECT Data (L_Simple)
L_StarArr	Modified McElwain L parameter for each telescope	Real[tl]	R_E	1.0 to 10	ECT Data
I	Integral invariant for average pitch angle	Real			ECT Data
IArr	Integral invariant for each telescope pitch angle	Real[tl]			ECT Data
K	Second Invariant ( I*sqrt(Bm) ) for average pitch	Real			ECT Data
Karr	Second Invariant ( I*sqrt(Bm) ) for each pitch angle	Real[tl]			ECT Data
MLT	Magnetic Latitude of SC	Real	Degrees	-90 to 90	ECT Data
F?DU_Alpha	Copy of Alpha required in PRBEM standard	Real[tl]	Degrees	-90 to 90	See above
F?DU_AlphaRange	Minimum/Maximum values of pitch angle over the accumulation period	Real[tl,2]	Degrees	-90 to 90	See above

3.6.5 Level 3 Pitch Angle and Pressure (PAP) Processing Algorithms

The primary activity in processing the Level 3 data into Level 3 PAP data is to read the pitch angle data (flux (intensity) and pitch angles) from the Level 3 files for each set of measurements that occur within a single spin and to bin the observed intensities during this spin as a function of the pitch angle data for each energy channel. The final step of the system is to utilize the pitch angle binned data to calculate a variety of aggregate values for the data. The aggregate data includes the following fields: perpendicular partial particle pressure, parallel partial particle pressure, particle density for the given energy channels, the omnidirectional flux (intensity) observed for each energy channel, and finally the integrated particle flux (intensity). This processing is done in a series of algorithmic steps in which the level 3 RBSPICE data is loaded for the targeted product, the Level 3 error data is recalculated based upon the pitch angle binning weights, and the aggregate data is calculated. All of the new data is then placed into a Level 3 PAP file for each species of each data product.

The binned pitch angles are binned for all data that is available for each spin. A separate product is created for each species within any specific level 3 product. I.e. the TOFxE_nonH Level 3 data is used to create TOFxE_He and TOFxE_O data products. A pitch angle binning scheme is created for each product based upon input parameters associated with each product. At this time, all products utilize the same pitch angle binning scheme. This scheme creates seventeen (17) pitch angle bins. The first and last bins are fifteen (15) degrees wide and all other bins are ten (10) degrees wide). The scheme is symmetric and the center bin is centered on ninety (90) degrees and each subsequent bin both decreasing and increasing (except for boundaries) are centered on ten (10) degree decrements. I.e. the pitch angle center array for this schema can be expressed as:
{7.5, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 172.5}.

Binning of Pitch Angles and calculation of aggregate data

PAP data calculation uses the following algorithms in the order listed:

1) Verify that RBSPICE Level 3 data exists; otherwise do nothing.

2) Create a pitch angle binning scheme based upon input parameters, currently 10 degree bins with 15 degree ends.

3) For each spin record of the Level 3 intensity variable, do the following:

a. Create a binned intensity array and initialize all records to -1.

b. Create a binned intensity weight array and initialize all records to 0.

c. Create a binned count array and initialize all records to 0.

d. Create an array per energy channel to contain the maximum and minimum observed binned intensities

e. For each record of the spin

i. If the pitch angle quality flag is bad go to the next record otherwise

ii. Get the pitch angle array which identifies the pitch angle of the observed particle for each telescope

iii. For each telescope of the intensity variable (for the specified species)

1. Calculate the bin number for the pitch angle associated with this telescope

2. If the value of the intensity bin position is -1 then set the value of the bin to the intensity

3. Otherwise add the intensity to the binned intensity array

4. Increment the weight number by one (1) for the intensity weight array

5. Get the Poisson statistics error array and recalculate the counts and add to binned count array

6. If the current binned intensity is greater than the max then set the max to the intensity

7. If the current binned intensity is greater than zero but smaller than the min
then set the min to the binned intensity

f. Divide the binned intensity array by the weight number array

g. Calculate the weighted error for each bin based upon the recalculated binned counts

h. Copy the other variables needed for the spin data record such as data quality flags, etc.

i. Calculate the mid-point and stop time of the spin record

j. Calculate the aggregate values – see the following table for a description of the energy channel indexes and energy ranges that are used in the calculation of the aggregate values:

i. Perpendicular/Parallel Partial Particle Pressure:

ii. Density:

iii. Omni-directional intensity per energy channel:

iv. Integrated Intensity:

k. Write the data record to the PAP data file

The following table presents as a function of the data product which energy channel indices (absolute reference into the calibration table and relative reference into the species specific channel range) and the energy channel energy passband ranges included in the calculation of the Aggregate values. Note that if a product is set to none, i.e. no aggregate is calculated, and NA for the energy passbands, then the specific product has been identified by the RBSPICE science team as untrustworthy either in data or in calibration. Those products identified as untrustworthy also have their associated data quality flags set to a value other than 0=good or 10=unknown implying that the data should not be used for science.

As of the writing of this version of this handbook the TOFxPH Oxygen observations are deemed unreliable and no aggregate values are calculated within the PAP data files but the data is provided as a product so that the RBSPICE team can update the calibration information and reprocess the data once the causes of the data are understood and the resulting newly calibrated data is considered usable for science.

Ions (~1.0 AMU)

Level 3 PAP data fields and interpretations

Level 3 Pitch Angle and Pressure (PAP) data products are only created as CDF files and they contain the following set of fields. Note that the source identifies if the field is a calculated field (as in an aggregate or binned value), if it is copied from the Level 3 data source data, or if it an averaged value or otherwise how the data is calculated.

Field	Description	Type	Units	Limits	Algorithm
Epoch	Time stamp of the midpoint of the spin	CDF_TT2000	Time		Start+ (Duration/2)
UTC	UTC string representing the time stamp of the midpoint of the spin	String	Time		Start+ (Duration/2)
DDOY	Decimal Day of Year	Double	Days	1.0 – 365.999	Calculated
ET	Ephemeris time stamp of the beginning of the spin	Double	Seconds		Copied
MidET	Ephemeris time stamp of the midpoint of the spin	Double	Seconds		Start + (Duration/2)
StopET	Ephemeris time stamp of the end of the spin	Double	Seconds		Start + Duration
Duration	Duration of the spin	Double	Seconds		Calculated
OrbitNumber	Assigned orbit number that includes start ET	Integer	NA	1-9999	Copied
Spin	Spin number for the data record	Integer	NA	0-65535	Copied
FspDU	Unidirectional Differential Flux units for species(sp)	Double[nE,nP]	#/(mm^2srMeV*s)	-1 = unsampled 0.0 – Big	See algorithm
FspDU_Weight	Weighting array used to normalize the binned flux	Integer[nE,nP]	NA	0-17	See algorithm
FspDU_PerpPressure	Perpendicular Partial Particle Pressure for species	Double	nPa	0.0-100	See algorithm
FspDU_ParaPressure	Parallel Partial Particle Pressure for species	Double	nPa	0.0-100	See algorithm
FspDU_Density	Calculated particle density for specific energy channels	Double	#/cm^3	0.0-100	See algorithm
FspDU_IntegralFlux	Integrated flux (intensity) for specific energy channels	Double	#/(mm^2srMeV*s)	0.0 – Big	See algorithm
FspDU_OmniFlux	Omnidirectional flux (intensity) for each energy channel	Double[nE]	#/(mm^2srMeV*s)	0.0 – Big	See algorithm
FspDU_MinimFlux	Observed minimum intensity (excluding zero) for energy	Double[nE]	#/(mm^2srMeV*s)	0.0 – Big	See algorithm
FspDU_MaximFlux	Observed maximum intensity for each energy channel	Double[nE]	#/(mm^2srMeV*s)	0.0 – Big	See algorithm
FspDU_Error	Poisson Statistical error of FspDU variable	Integer[nE,nP]	NA	0 – 100	See algorithm
FspDU_Energy	Midpoint Energy of each energy passband	Double	MeV	0.0 – 10.0	Copied
FspDU_EnergyRange	Minimum/Maximum energies of each energy passband	Double	MeV	0.0 – 10.0	Copied
FspDU_Quality	Quality flag associated with FspDU variable	Integer	NA	0 – 10	See quality above
Position	Position of SC in GEO reference frame	Real[3]	R_E	-10.0 to 10.0	Copied
Position_SM	Position of the SC in SM reference frame	Real[3]	R_E	-10.0 to 10.0
Position_GSM	Position of SC in GSM Coordinates	Real[3]	R_E	-10.0 to 10.0	SPICE
Position Quality	PRBEM position quality flag, 0=good, 1=bad	Integer	NA	0 to 1	Always 0
L	L value calculated using a dipole magnetic field	Real	R_E	1.0 – 10.0	Calculated
MLT	Magnetic latitude of SC calculated using Position_SM	Real	Hours	0 – 23.999	ECT Data
L_Eq	Geocentric distance to B_min point for FL threading vehicle (i.e. \|P_min\|)	Real	R_E	1.0 to 10	ECT Data
L_Star	Generalized Roederer L-shell value	Real	R_E	1.0 to 10	ECT Data (L_Simple)
I	Integral invariant for average pitch angle	Real			ECT Data
PA_Midpoint	Midpoint of each pitch angle bin	Real[nP]	Degrees	0.0 – 180.0	Binning schema
PA_Range	Pitch Angle range for each pitch angle bin	Real[2]	Degrees	0.0 – 180.0	Binning schema
Channel	Indexing array for the number of energy channels	Integer[nE]	NA	0 – 59
Bin	Indexing array for the number of pitch angle bins	Integer[nP]	NA	0 – 17	Binning schema
Axis	Indexing array for the position axes	Integer[3]	NA	0 – 2
MinMaxRange	Indexing array for the min/max energy/PA arrays	Integer[2]	NA	0 – 1

4 RBSPICE SOC Data Repository Directory Structure

The top level structure of the RBSPICE SOC Data Repository is reflected in the figures in the following subsections. These figures show the overall structure of the directories and how the data is contained. As much as possible, the structure attempts to represent the overall structure of the management of the Van Allen Probes, itself. This is done to facilitate ease of access to any particular piece of data.

4.1 Van Allen Probes MOC Data Directory structures

Figure 4-1 describes the high level look at the directory structures used to represent the MOC data that is transferred to the RBSPICE SOC. The folder called MOCTelemetry is the Van Allen Probes MOC Data Products folder as downloaded directly from the MOC. The MOCTelemetry folder contains subfolders for each spacecraft (A and B). Within each of those folders is the specific data that the RBSPICE SOC utilizes for data production and scientific analysis. The folders themselves are logical views mapped to the original source folders within the folder structure.

RBSPICE->Data_Root->MOCTelemetry folder as downloaded from the MOC:

4.2 RBSP Spacecraft Data Organization

Figure 4-2 represents the rest of the directory organization that contains the instrument specific data. The secondary level is organized by software and data subdirectories called “Software” and “Data_Root.” Each of these subdirectories contains a production folder and a development folder. Contained within each production and development folder are subfolders for each spacecraft (A and B). Each spacecraft folder contains the instruments’ data for that spacecraft. It is recognized that the RBSPICE SOC Data Repository might not contain data from any instruments other than EMFISIS and RBSPICE, but the directories will be maintained for completeness.

\RBSPICE

\---Data_Root

                        \---Development

                                     \---RBSP

                                                 \---RBSPA

                                                             +---ECT

                                                            +---EFW

                                                            +---EMFISIS

                                                            +---PSBR

\---RBSPICE

            +---Data

+...RBSPB (see RBSPA)

            \---Production

                                     \---RBSP

                                                 \---RBSPA

                                                             +---ECT

                                                            +---EFW

                                                            +---EMFISIS

                                                            +---PSBR

                                              \---RBSPICE

                                                            +---Data

+...RBSPB (see RBSPA)

Figure 4-2 RBSP Spacecraft Data Directory Structure

4.3 EMFSIS Data Organization

Figure 4-3 represents the extent of the EMFISIS data that is needed to be contained within the RBSPICE Data Repository.

4.4 RBSPICE Data Organization

In this structure, there will be multiple products contained within the RBSPICE Data directories; however, this figure shows only a sample product A. Table 4-1shows the products that are to be maintained and the directory names that will be used for each. Table 3-2 shows the various levels for each of the data products that are to be produced. Each product directory will contain a list of the relevant data for that product. This list of data includes the Mission Simulation data, Integration and Testing data (IT), Commissioning data, any relevant calibration data for the particular product, the telemetry received from the MOC, the Level 0 data received from the MOC, the Level 1-3 data products produced, any internally required data used in the generation of Level 4 data, the publishable Level 4 data, interim data needed in production, and finally the database repository that contains the relevant data for that product.

Figure 4-4 represents the RBSPICE data organizational structure that will be contained within the RBSPICE SOC Data Repository. Each spacecraft directory will contain its own respective data. Not all folders exist or are populated at this time.

Note: Product Mapping Directory follows in Section 4.5

4.5 Product Directory Naming

Table 4-1 shows the list of data products, key variables, and the short directory names

Table 4-1 Mapping of Product to Short Directory Name

Product	Short Directory Name	Species	Energy Bins
Ion Basic Rate	IBR	Ion	NA
Electron Basic Rate	EBR	Electron	NA
Low Energy Res, High Time Res, Electron Species Rates	ESRLEHT	Electron	14
High Energy Res, Low Time Res, Electron Species Rates	ESRHELT	Electron	64
High Energy Res, Low Time Res, Ion Species Rates	ISRHELT	Ion	64
High Energy Res, Low Time Res, TOFxPH Proton Rates	TOFxPHHHELT	Protons	32
TOFxE Proton Rates	TOFxEH	Protons	14
TOFxE Non Proton Rates	TOFxEnonH	Heavy Ions	28
Low Energy Res, High Time Res, TOFxPH Proton Rates	TOFxPHHLEHT	Proton	10
TOFxE Ion Species Rates	TOFxEIon	Ion	64
Space Weather Rates	SWR	All	NA
Ion Species Basic Rates	ISBR	Ion	NA
Priority Events	PriorityEvents	NA	NA
Ion Energy Diagnostic Rates	IEDR	Ion	NA
Ion Species Diagnostic Rates	ISDR	Ion	NA
Raw Ion Species Events	RISE	Ion	NA
Raw Electron Energy Events	REEE	Electron	NA
Raw Ion Energy Events	RIEE	Ions	NA
Auxiliary Data	Aux	NA	NA
Critical Housekeeping Data	HSKP	NA	NA
Pitch Angles	PA	All	NA

Table 4-2 Mapping of Product to Short Directory Name for Level 3 PAP products – note that the energy bins can vary over the duration of the mission based upon the channel assignments in the flight software

Product	Short Directory Name	Species	Energy Bins
Time of flight by energy Proton data	TOFxEH	Protons	14
Time of flight by energy Helium data	TOFxEHe	Helium	9
Time of flight by energy Oxygen data	TOFxEO	Oxygen	9
Time of flight by pulse height Proton data High Energy Low Time resolution	TOFxPHHHELT	Protons	20
Time of flight by pulse height Oxygen data High Energy Low Time resolution	TOFxPHOHELT	Oxygen	11
Time of flight by pulse height Proton data Low Energy High Time resolution	TOFxPHHLEHT	Protons	7
Time of flight by pulse height Oxygen data Low Energy High Time resolution	TOFxPHOLEHT	Oxygen	3

5 Production Filename Convention

The filename convention used by the RBSPICE SOC Data Production software is derived directly from the recommended file naming convention suggested by the Van Allen Probes SOC Lead. The following is a direct copy from the document titled “Filename Convention for Radiation Belt Storm Probes Common Data Format data files” written by R. Freidel and modified by R. Barnes. Tables that are specific to the RBSPICE data files are presented following the basic naming convention specifications.

Multiple file formats will be produced by the RBSPICE SOC; however, the primary “flat file” storage format is in Common Data Format (CDF) as specified by the Space Physics Data Facility at Goddard Space Flight Center and more specifically by ISTP compliance requirements. Other formats will include ASCII Comma Separated Value (CSV) flat file versions of the RBSPICE data.

5.1 RBSP CDF Filenames

RBSP CDF files are comprised of a number of variable-length alphanumeric fields, followed by a filename suffix (“cdf”). All fields are required and are delineated by a field separator character, an underscore (“_”). Fields can be further divided into sub-fields, delineated by a dash (“-”). The distinction between a field and a sub-field is that a field is a required element that must always be included in the filename, and a sub-field is an optional element that may or may not be present. A filename parser can be safely coded to extract all fields from a filename and can optionally further extract sub-fields as needed.

The filename is of the form:

<source>_<type>_<descriptor>_<date>_<version>.cdf

Field	Description	Example
<source>	Data source identifier, comprised of sub-fields for mission (“rbsp”), spacecraft (“a” or “b”), and optionally the instrument suite.	“rbsp-a-ect”, “rbsp-b-emfisis”, “rbsp-a”
<type>	Data type, comprised of sub-fields for a short mnemonic data type identifier.	“pre”, “fnl-001”
<descriptor>	A short descriptor of the data included in the file.	“mag-L2”, “rbspice-L3”, “rps-ap003-l3”
<date>	Start date of the file in Universal Coordinated Time (UTC). Dates can either be in the form, “yyyymmdd” or “yyyymmddhhMMss”.	“20120201”, “20120830103000”
<version>	Version number consisting of the form “X.Y.Z-R”, where X is the major (interface) number, Y is the minor (quality number), Z is the revision number and R is an optional release number	“v1.1.1”, “v1.2.1”, v2.2.1-100”
<ext>	Filename suffix identicating Common Data Format or compressed Comma Separated Value file using GZIP	“.cdf” or “.csv.gz”

Notes:

<source>

The source specifies the mission, the spacecraft (“a” or “b”), and may also include the instrument suite (e.g., rbspice).

<type>

The data type identifier is used to specify the providence of the data, for example: preliminary data (“pre”), final data (“fnl”). Instrument teams are free to define additional types as needed for specific modes or products.

<descriptor>

The descriptor field is a short, human readable description of the data product. It should include the instrument and the data product level. Finer levels of description down to measurement type and even APID may be used if deemed appropriate.

<date>

The date is specified in Universal Coordinated Time (UTC). The length of the date field defines both the format of the date and the length of the file. Dates of the form “yyyymmdd” represent files that contain one UTC day of data. Files with the longer “yyyymmddhhMMss” specification represent files containing one orbit of data.

Yyyy	Year
Mm	Month
Dd	Day
Hh	Hour
MM	Minute
Ss	Second

<version>

The version number uses a variant of the industry standard version scheme for software of the form “vX.Y.Z”

· X is the interface number. Increments in this number represent that a significant change to the processing software or to the contents of the file has been made. These changes would require code changes to software readers and possibly changes to processing algorithms. The user should consult the appropriate meta-data for or change logs.

· Y is the quality number. This number represents a change in the quality of the data in the file, such as change in calibration or increase in fidelity. Changes should not impact software, but may require consideration when processing data.

· Z is the bug fix/revision number. This number changes to indicate minor changes to the contents of the file due to reprocessing of missing data.

· R is the optional release number. This number can be used to group a collection of data products which may have different version numbers. Depending on each instrument team’s method of data processing, a file may or may not have a release number. If the release number is omitted, it is assumed to be zero, so that if a team later decides to use release numbers, this change in procedure will not cause a subsequent problem in identifying release numbers. The release number is a monotonically increasing integer that is used to capture a set of data products at a point in the mission defined by the instrument team. Individual data products may have different version numbers, representing different versions of analysis software and calibration, yet have a common release number.

Time Conversion and splitting data files:

The filenames for Level 0 PTP files use the mission elapsed day within the filename. The files are generated to match the UTC day as closely as possible; however, there will be some discrepancies. In generating higher level data products, the actual UTC should be found from the contents of the CCSDS telemetry packets and should be used to generate the correct filename for that packet.

Parsing Filenames:

Filenames can be parsed by first breaking the filename down into the various fields, and then decoding them. As all fields are required, the extraction of fields is a trivial case of string tokenization. In C this can be done using the “strtok” function, in IDL by using “strpos” and in shell scripts by using simple pattern expansion operators.

Filename Ordering:

Release numbers, version, and sub-version numbers do not have leading zeros; therefore, a simple alphanumeric sort will not necessarily return the file names in the ascending version order, e.g. “V1.9.1” will precede “V.1.10.1” in a file listing. To avoid this problem filenames should be sorted by parsing the filename. This can be accomplished under UNIX in the form of shell scripts using a combination of the “find” command and the “sort” command:

find . –name “rbsp*.cdf” | sort –t ‘.’ –kA,Bn –kC,Dn

Compression:

For efficiency, RBSP CDF files will use the built-in compression capability of the CDF file format. It is strongly suggested that time variables are NOT compressed to allow for quick time based searching of data. CSV files are compressed using GZIP.

5.2 RBSPICE Specific File Name Conventions

The following table lists those filename convention specifics as applied to the RBSPICE data.

Table 5‑5‑1 RBSPICE Specific File Name conventions

Item	RBSPICE Value(s)
<source>	rbsp-a-rbspice rbsp-b-rbspice
<type>	Derived from the RBSPICE Product Directory cal = calibration com = commissioning it = integration and test lev-0 = level 0 lev-1 = level 1 lev-2 = level 2 lev-3 = level 3 lev-3-pap = Level 3 Pitch Angle and Pressure data files lev-4 = level 4 for release lev-4-m = level 4 not for release ms-3 = mission sim 3 ms-4 = mission sim 4 tel = telemetry
<descriptor>	See directory short names in Table
<date>	yyyymmdd (file boundaries occur at day boundaries)
<version>	vX.Y.Z-rr X = Data Format Version Y = Software Production Version Z = Data Revision Number rr = Data Release Number
<ext>	.cdf = Common Data Format .csv.gz = Comma Separated Value, compressed using GZIP

A sample filename is rbsp-b-rbspice_lev-1_TOFxPHHHELT_20130512_v1.0.0-00.cdf which represents level 1 data produced for the time of flight by pulse height proton rates taken at high energy resolution and low time resolution on May 12, 2013. As data is processed and reprocessed the file version numbers will increment appropriately.

5.3 RBSPICE Data Release Plans

5.3.1 Publicly Accessible RBSPICE Data

The RBSPICE data is released through the RBSPICE data web sites. There is a specific web site for each spacecraft instrument, i.e. RBSPICEA and RBSPICEB located at: RBSPICEA.FTECS.com and RBSPICEB.FTECS.com.

No security precautions are applied to the publicly released data; it is accessible from generally any web browser as a file listed directory. At the time of writing, the public access data will start at Level 1 data files and will include all data through Level 3 PAP. Some Level 4 data and models will be provided as the RBSPICE team decides to release such data/models for public use.

Level 0 data derived from the original payload telemetry packets will not be released to the general public.

5.3.2 Release of data to NSSDC archive

The National Space Science Data Center (NSSDC) located at Goddard Spaceflight Center (GSFC) will have access to the RBSPICE data through password protected websites. The NSSDC published web sites are currently planned at:

RBSPICEA.FTECS.com/NSSDC and RBSPICEB.FTECS.com/NSSDC and will provide access to the Level 0 data files as well as all publicly accessible data files.

5.3.3 Web Services Access

A web services interface is currently planned to be built for access to the RBSPICE data files accessible to the general public. At the time of this writing, the web services interface is in concept and has not fully been designed. As time becomes available after primary development activities and mission simulations, the design of the web services interface will begin with full release documentation to be incorporated into this document. It is conceivable that password protected access to other areas of the data files will become available thru this interface so that organizations such as the NSSDC can have more programmatic access to the RBSPICE data thru the interface.

6 RBSPICE Data Product Field Descriptions

The following tables provide file field descriptions for each RBSPICE Level 1 and Level 2 data product, in both CDF and CSV formats:

6.1 RBSPICE Level 1 Product Field Descriptions

Table 6.1-1 EBR_L1 Product Field Descriptions

Table 6.1-2 ESR_HELT_L1 Product Field Descriptions

Table 6.1-3 ESR_LEHT_L1 Product Field Descriptions

Table 6.1-4 IBR_L1 Product Field Descriptions

Table 6.1-5 ISBR_L1 Product Field Descriptions

Table 6.1-6 ISR_HELT_L1 Product Field Descriptions

Table 6.1-7 TOFxE_H_L1 Product Field Descriptions

Table 6.1-8 TOFxE_Ion_L1 Product Field Descriptions

Table 6.1-9 TOFxE_nonH _L1 Product Field Descriptions

Table 6.1-10 TOFxPH_H_HELT _L1 Product Field Descriptions

Table 6.1-11 TOFxPH_H_LEHT _L1 Product Field Descriptions

6.2 RBSPICE Level 2 Product Field Descriptions

Table 6.2-1 ESR_HELT_L2 Product Field Descriptions

Table 6.2-1 ESR_HELT_L2 Product Field Descriptions (cont.)

Table 6.2-2 ESR_LEHT_L2 Product Field Descriptions

Table 6.2-2 ESR_LEHT_L2 Product Field Descriptions (cont.)

Table 6.2-3 ISR_HELT_L2 Product Field Descriptions

Table 6.2-3 ISR_HELT_L2 Product Field Descriptions (cont.)

Table 6.2-4 TOFxE_H_L2 Product Field Descriptions

Table 6.2-4 TOFxE_H_L2 Product Field Descriptions (cont.)

Table 6.2-5 TOFxE_Ion_L2 Product Field Descriptions

Table 6.2-5 TOFxE_Ion_L2 Product Field Descriptions (cont.)

Table 6.2-6 TOFxE_nonH_L2 Product Field Descriptions

Table 6.2-6 TOFxE_nonH_L2 Product Field Descriptions (cont.)

Table 6.2-7 TOFxPH_H_HELT_L2 Product Field Descriptions

Table 6.2-7 TOFxPH_H_HELT_L2 Product Field Descriptions (cont.)

Table 6.2-8 TOFxPH_H_LEHT_L2 Product Field Descriptions

Table 6.2-8 TOFxPH_H_LEHT_L2 Product Field Descriptions (cont.)

7 References

Appendix A - Q&A

Q: What does "TOFx" stand for? Through http://athena.jhuapl.edu/data_finder I found TOFxEH, TOFxEIon, TOFxEnonH, TOFxPHHHELT, and TOFxPHHLEHT for RBSP-B, but did not find the "TOFx"s for RBSP-A. Will they ever be posted?

A: TOFx stands for Time of Flight by …, the … is either Energy or Pulse Height so we have TOFxE or TOFxPH data products.
This product designation has to do with the mode in which we are taking the data and whether there is enough energy to trigger the SSD portion of the instrument.
In general the TOFxE products calculate the total energy using the time of flight and then utilize the SSD energy deposition to further clarify the species.
The TOFxPH products calculate the total energy using the time of flight and then utilize the pulse height to identify the species since the energy of the species is not enough to penetrate into the SSD. The alternative counting data product that we have is the ESRHELT, ESRLEHT, and ISRHELT products in which these products are taken only using the “energy” mode of the RBSPICE instrument. That means that we have no understanding of the species of the particle (barring electron versus ion).
ESR products stand for Electron Species products and ISR stand for Ion Species.
In everything, the HELT stands for High Energy Low Time resolution and the LEHT stands for Low Energy High Time resolution.

Unfortunately during January 17, the RBSPICE A instrument was not programmed to produce any of the TOFx data products.
This capability was turned off due to some instrument issues observed in early November 2012 and then once they were resolved it was turned back on January 26, 2013.
The RBSPICE B instrument was fully operational during the time frame that you are looking at.
I point you to our production report pages at http://rbspicea.ftecs.com/RBSPICEA_Production_Status_Report.htm (click on the counting tab at the bottom) and
http://rbspiceb.ftecs.com/RBSPICEB_Production_Status_Report.htm to see what counting data products are available for the mission.

Q: I found H fluxes in TOFxEH, He and O fluxes in TOFxEnonH, H and O fluxes in TOFxPHHHELT and TOFxPHHLEHT. Which file(s) should I use to get the fluxes? Are they all sector (not spin-averaged) data?

A: In regards to which files to use first understand that the Level 0 files are counts, the Level 1 files are rate, and the Level 2 files are intensity (differential flux) (units of counts/(MeV*cm^2*sr*sec).

In regards to density you need to combine all of the particle data from each of the products which contain the species for which you are interested.
For instance, if you want the density of oxygen ions (note that we don’t have anything that separates O⁺, O⁺⁺, etc) then you need to work with the TOFxEnonH and one of TOFxPHHLEHT or TOFxPHHHELT. The decision on which of the TOFxPH products to use is based upon what time resolution you want to work with in regards to your production of the densities.
As a note, the TOFxEnonH oxygen energy starts around 123KeV and the TOFxPHHHELT ends around 177 KeV so there are measurements that overlap between the two products. The overlap is there to help us make sure that our calibration is working correctly and to provide the option on which products we use in regards to the how we calculate the macro properties like density. You need to make sure that you are not combining all of the data from all of the channels though because you would then over calculate the densities at certain energies.
I would also discourage you from using the very bottom energy channels of any of the data products since they have a tendency to be contaminated.

None of the data are Spin Averaged from a traditional sense of higher level data products.
Instead the accumulation periods vary from product to product. To start off, the RBSPICE instrument breaks a spin into 36 sectors and the accumulation period of the products is individually defined so that some products accumulate in very high time resolution and others accumulate in low time resolution and some in a somewhat medium time resolution.
The TOFxEnonH data product have 20 energy channels and are accumulated over a single spin but the number of sectors of the accumulation can vary over the mission. You can look at the data files to determine how many sectors are included in the accumulation by the sector cadence within any spin, i.e. in 2012 for spin= 64424 the sector numbers step as 0, 2, 4, 6, i.e. accumulating over 2 sectors for each data point.
The TOFxPHHLEHT data product are also accumulated in a single spin with generally a higher angular resolution compared to the TOFxEnonH data products but the energy resolution is limited to 10 energy channels and only 3 or 4 are oxygen.
The TOFxPHHHELT data product has 32 energy channels 11 of which are counting oxygen ions but the product itself is accumulated over multiple spins for each of the sector groups that are involved in the accumulation. To be more specific, the accumulation breaks a spin into X number of larger “sectors” and each “sector” is then accumulated over 10 spins.
For instance, during much of the mission (maybe all of it) the spin is divided into 9 larger “sectors” each accumulated over 10 spins.
By looking at the sector cadence within a file and the spin cadence you can tell how many sectors are included in a larger “sector” and how many spins are included in the accumulation.
If you want a spin averaged data product then you will need to add all of the data from each sector group within a spin and then you will have the spin averaged data.

Q: What are the energy channels? What is the y-axis plotted with Autoplot? What operations (slice, collapse, etc) should be applied to the data to get the fluxes and further calculate the densities?

A: This is a much harder question to answer but I will attempt it.
First I would like to encourage you to utilize the MIDL analysis package that is available at the following URL: http://sd-www.jhuapl.edu/rbspice/MIDL/
This analysis package already understands how to plot the RBSPICE data and I think would be very useful to you to better have access and understand our data.
The energy channels can be found at the following URL: http://rbspice.ftecs.com/Data.html --- scroll down to the bottom to get to links for the A/B calibration pages.
In regards to plotting of the y axis for autoplot, that depends upon what you are plotting and trying to accomplish.
The x axis is most likely time and for a spectrograph the y axis is energy and the z axis is intensity/rate/count (depending upon what data level you are using.
Obviously once you calculate the density of the data then the y axis is just the density and x the time.

Appendix B - Glossary