New Horizons SOC to Instrument Pipeline ICD
August 2008
SwRI Project 05310
Document No. 05310-SOCINST-01
Contract NASW-02008
New Horizons SOC to Instrument Pipeline ICD
SwRI Project 05310
Document No. 05310-SOCINST-01
Contract NASW-02008
Prepared by: Joe Peterson 26 August 2008
Contributors:
ALICE specifics prepared by: Maarten Versteeg, Joel Parker, & Andrew Steffl
LEISA specifics prepared by: George McCabe & Allen Lunsford
LORRI specifics prepared by: Hal Weaver & Howard Taylor
MVIC specifics prepared by: Cathy Olkin
PEPSSI specifics prepared by: Stefano Livi
REX specifics prepared by: Ivan Linscott & Brian Carcich
SDC specifics prepared by: David James
SWAP specifics prepared by: Heather Elliott
General Approval Signatures:
Approved by: ____________________________________ Date: ____________
Hal Weaver, JHU/APL, Project Scientist
Approved by: Leslie Young via email 1 December 2005
SwRI, Deputy Project Scientist
Approved by: John Andrews via email 4 December 2005
SwRI, SOC Project Manager
Instrument-specific Signatures:
(Science Theme Teams members)
Approved by: ____________________________________ Date: ____________
Jeff Moore, NASA, GGI Science Theme Team Lead
(applies to MVIC, LORRI)
Approved by: /s/ Dale Cruikshank via email 6 March 2006
NASA, COMP Science Theme Team Lead
(applies to LEISA)
Approved by: Randy Gladstone via email 6 December 2005
SwRI, ATM Science Theme Team Lead
(applies to ALICE, REX)
Approved by: /s/ Fran Bagenal via email 23 January 2006
CU, P&P Science Theme Team Lead
(applies to SWAP, PEPSSI, SDC))
(Instrument PIs & Scientists)
Approved by: Alan Stern via email 5 December 2005
SwRI, ALICE Instrument PI
Approved by: Dave Slater via email 2 December 2005
SwRI, ALICE Instrument Scientist
Approved by: Alan Stern via email 5 December 2005
SwRI, ALICE Instrument PI
Approved by: Dennis Reuter via email 5 December 2005
NASA, LEISA Instrument Scientist
Approved by: ____________________________________ Date: ____________
Andy Cheng, JHU/APL, LORRI Instrument PI
Approved by: ____________________________________ Date: ____________
Hal Weaver, JHU/APL, LORRI Instrument Scientist
Approved by: Alan Stern via email 5 December 2005
SwRI, ALICE Instrument PI
Approved by: Dennis Reuter via email 5 December 2005
NASA, LEISA Instrument Scientist
Approved by: ____________________________________ Date: ____________
Ralph McNutt, JHU/APL, PEPSSI Instrument PI
Approved by: ____________________________________ Date: ____________
Stefano Livi, JHU/APL, PEPSSI Instrument Scientist
Approved by: /s/ Len Tyler via email 8 March 2006
Stanford, REX Instrument PI
Approved by: /s/ Ivan Linscott via email 8 March 2006
Stanford, REX Instrument Scientist
Approved by: ____________________________________ Date: ____________
Mihaly Horanyi, CU, SDC Instrument PI
Approved by: ____________________________________ Date: ____________
Mihaly Horanyi, CU, SDC Instrument Scientist
Approved by: Dave McComas via email 12 December 2005
SwRI, SWAP Instrument PI
Approved by: Heather Elliot via email 8 March 2006
SwRI, SWAP Instrument Scientist
Release to Document Control:
Approved by: ____________________________________ Date: ____________
L. D. McCullough, SwRI Project CM
TABLE OF CONTENTS
Page
1. SCOPE
2. SIGNATURES, AUTHORSHIP, AND RESPONSIBILITY
3. APPLICABLE DOCUMENTS
3.1 New Horizons Documents
4. INTRODUCTION
5. INTERFACE DESCRIPTION
6. REQUIREMENTS
6.1 Level 2 (output) Files
6.2 Pointing Information
6.3 The Code
6.4 Calibration Data
6.5 Documentation
6.6 Error Conditions and Integration Troubleshooting
6.7 PDS Archiving
6.8 Configuration Management
6.9 Pipeline Updates
6.10 Acceptance Review
6.11 Longevity
7. ALICE INSTRUMENT DESCRIPTION
7.1 PERSI-Alice Instrument Overview
7.2 "Raw" Data Specifics
7.2.1 Data Format
7.2.1.1 Histogram FITS file:
7.2.1.2 Pixel list FITS file:
7.2.2 Data Sources (High/Low Speed, CCSDS, ITF)
7.2.3 Definition of an "Observation"
7.2.4 S/C Housekeeping Needed in Level 1 Files (for Calibration)
7.3 "Calibrated" Data Specifics
7.3.1 Algorithm for Pipeline
7.3.1.1 Deadtime Correction
7.3.1.2 Dark Correction
7.3.1.3 Effective Area
7.3.1.4 Flat Field
7.3.2 Format of Calibrated Data
7.3.2.1 Histogram
7.3.2.2 Pixel List
7.3.3 Scientific Units
7.3.4 Additional FITS and PDS Keywords Added
7.3.5 Hardware/OS Development Platform
7.3.6 Language(s) Used
7.3.7 Third Party Libraries Required
7.3.8 Predicted Execution time
7.3.9 Contact/Support Person(s)
8. LEISA INSTRUMENT DESCRIPTION
8.1 Overview
8.2 Raw Data Specifics
8.2.1 Data Format
8.2.2 Data Sources (High/Low Speed, CCSDS, ITF)
8.2.3 Definition of an "Observation"
8.2.4 Housekeeping Needed in Level 1 Files (for Calibration)
8.2.5 Science Data and/or Housekeeping Requirements
8.3 Calibrated Data Specifics
8.3.1 Algorithm for Pipeline
8.3.2 Dataflow Block Diagram
8.3.3 Data Format
8.3.4 Extra FITS Extensions (planes) and Their Definitions
8.3.5 Scientific Units
8.3.6 Additional FITS and PDS Keywords Added
8.3.7 Hardware/OS Development Platform
8.3.8 Language(s) Used
8.3.9 Third Party Libraries Required
8.3.10 Calibration Files Needed (with Quantities)
8.3.11 Memory Required
8.3.12 Temporary File System Space Needed
8.3.13 Predicted Size of Output File(s)
8.3.14 Predicted Execution time
8.3.15 Contact/Support Person(s)
8.3.16 Maintenance Schedule (Code/Data Updates, Documentation)
9. LORRI INSTRUMENT DESCRIPTION
9.1 Overview
9.2 Raw image Specifics
9.2.1 Data Format
9.2.2 Data Sources (High/Low Speed, CCSDS, ITF)
9.2.3 Definition of an "Observation"
9.2.4 Housekeeping Needed in Raw Image Files (for Calibration)
9.2.5 Raw Science Data and/or Housekeeping Requirements
9.3 Calibrated Image Specifics
9.3.1 Algorithms for Pipeline Calibration Process
9.3.1.1 Bias Subtraction
9.3.1.2 Smear Removal
9.3.1.3 Flat-Fielding
9.3.1.4 Absolute Calibration (Conversion from corrected DN to physical units)
9.3.1.5 Pointing Information
9.3.1.6 Conversion of instrument housekeeping items to engineering units
9.3.2 Instrument Characterization
9.3.3 Special Processing
9.3.4 Dataflow Block Diagram
9.3.5 Data Format
9.3.6 Extra FITS Extensions (planes) and Their Definitions
9.3.7 Scientific Units
9.3.8 Additional FITS and PDS Keywords Added
9.3.8.1 Reading FITS file contents using IDL
9.3.9 Hardware/OS Development Platform
9.3.10 Language(s) Used
9.3.11 Third Party Libraries Required
9.3.12 Calibration Files Needed (with Quantities)
9.3.13 Memory Required
9.3.14 Temporary File System Space Needed
9.3.15 Predicted Size of Output File(s)
9.3.16 Predicted Execution time
9.3.17 Contact/Support Person(s)
9.3.18 Maintenance Schedule (Code/Data Updates, Documentation)
9.4 References
10. MVIC INSTRUMENT DESCRIPTION:
10.1 Overview
10.2 Level 1 Specifics
10.2.1 Data Format
10.2.2 Data Sources (High/Low Speed, CCSDS, ITF)
10.2.3 Definition of an "Observation"
10.2.4 Housekeeping Needed in Level 1 Files (for Calibration)
10.2.5 Raw Science Data and/or Housekeeping Requirements
10.3 Level 2 Specifics
10.3.1 Algorithm for Pipeline
10.3.1.1 Remove bias and flat-field pattern
10.3.1.2 Geometric Correction
10.3.1.3 Conversion to Physical Units
10.3.1.4 Error Propagation
10.3.1.5 Data Quality Flags
10.3.2 Dataflow Block Diagram (to do - add distortion correction to tree)
10.3.3 Data Format
10.3.4 Scientific Units
10.3.5 Additional FITS and PDS Keywords Added
10.3.6 Extra FITS Extensions() and Their Definitions
10.3.7 Hardware/OS Development Platform
10.3.8 Language(s) Used
10.3.9 Third Party Libraries Required
10.3.10 Calibration Files Needed (with Quantities)
10.3.11 Memory Required
10.3.12 Temporary File System Space Needed
10.3.13 Predicted Size of Output File(s)
10.3.14 Predicted Execution time
10.3.15 Contact/Support Person(s)
10.3.16 Maintenance Schedule (Code/Data Updates, Documentation)
11. PEPSSI INSTRUMENT DESCRIPTION
11.1 Overview
11.1.1 PEPSSI Investigation
11.1.2 PEPSSI Sensor Description
11.1.3 PEPSSI Electronics Description
11.2 Introduction to PEPSSI Data
11.3 Level 1 Specifics
11.3.1 Data Sources (High/Low Speed, CCSDS, ITF)
11.3.2 Definition of an "Observation"
11.3.3 Header with Keywords
11.3.4 Spacecraft Housekeeping Needed in Level 1 Files (for Calibration)
11.3.5 Raw Science Data and/or Housekeeping Requirements
11.4 Level 2 Specifics
11.4.1 Algorithm for Pipeline
11.4.1.1 IDL L1 to Pre-L2 step
11.4.1.2 MIDL L1 to Pre-L2 step
11.4.2 Dataflow Block Diagram
11.4.2.1 L1 to Pre-L2
11.4.2.2 Pre-L2 to L2 processing
11.4.3 L2 Data Format
11.4.3.1 PHA_HIGH_ION
11.4.3.2 PHA_ELECTRON
11.4.3.3 PHA_LOW_ION
11.4.3.4 PHA_DIAG
11.4.3.5 N1 and D_N1
11.4.3.5.1 Rate Box Definitions
11.4.3.6 N2 and D_N2
11.4.3.7 (D)_N(1/2)_STATUS
11.4.4 Bad Time Intervals (BTIs)
11.4.5 L3Data Format
11.4.5.1 Primary HDU: Rate Weighted 2-D Histogram
11.4.5.2 Quick Look Spectrograms
11.4.5.3 FLUX
11.4.5.3.1 FLUX Calibration Procedure
11.4.5.3.2 Derivation and Explanation of Calibration Table Values
11.4.5.4 PHA Data
11.4.6 Memory Required
11.4.7 Temporary File System Space Needed
11.4.8 Predicted Size of Output File(s)
11.4.9 Predicted Execution time
11.4.10 Contact/Support Person(s)
11.4.11 Maintenance Schedule (Code/Data Updates, Documentation)
12. REX INSTRUMENT DESCRIPTION
12.1 Overview
12.2 Raw Data Specifics
12.2.1 Raw Data Format
12.2.1.1 PDU Content
12.2.1.1.1 ROF ID byte
12.2.1.1.2 ROF Status byte
12.2.1.1.3 Integrated Radiometry values
12.2.1.1.4 Time Tag values
12.2.1.1.5 I & Q value pairs
12.2.1.2 PDU Data layout: Interleaving
12.2.1.2.1 Layout of ID & Status bytes
12.2.1.2.2 Layout of Radiometry
12.2.1.2.3 Layout of Time Tags
12.2.1.2.4 Layout of I & Q values
12.2.1.3 Layout of ROF
12.2.2 Data Sources (High/Low Speed, CCSDS, ITF)
12.2.3 Definition of an "Observation"
12.2.4 Housekeeping in Raw FIT files' extensions
12.2.5 Raw Science Data and/or Housekeeping Requirements
12.3 Calibration Specifics
12.3.1 Calibration Algorithms
12.3.1.1 Calibrating the REX filter output: In-phase &
Quadrature-phase values
12.3.1.1.1 Combine the unsigned bytes into a two's complement
16-bit signed integer filter value
12.3.1.1.2 Scale the filter value by the calibrated reference voltage
12.3.1.2 Calibrating the REX Radiometry
12.3.1.3 Calibrating the REX Time Tags
12.3.2 Calibrated FITS file data format
12.3.2.1 Extension Data Unit (EDU) 1: I & Q values
12.3.2.2 EDU 2: Radiometry & Time Tags
12.3.2.3 Additional FITS Extensions (planes) and Their Definitions
12.3.2.4 Scientific Units
12.3.2.5 Additional FITS and PDS Keywords
12.3.2.5.1 Radiometry calibration provenance added to PHDU
12.3.2.5.2 FITS keywords added to EHDU 1
12.3.2.5.3 Scaling parameters
12.3.3 Hardware/OS Development Platform
12.3.4 Language(s) Used
12.3.5 Third Party Libraries Required
12.3.6 Calibration Files Needed (with Quantities)
12.3.7 Memory Required
12.3.8 Temporary File System Space Needed
12.3.9 Predicted Size of Output File(s)
12.3.10 Predicted Execution time
12.3.11 Contact/Support Person(s)
12.3.12 Maintenance Schedule (Code/Data Updates, Documentation)
13. SDC INSTRUMENT DESCRIPTION
13.1 Overview
13.2 Raw Data Specifics
13.2.1 Data Format
13.2.2 Data Sources (High/Low Speed, CCSDS, ITF)
13.2.3 Definition of an "Observation"
13.2.4 Housekeeping Needed in Level 1 Files (for Calibration)
13.2.5 Raw Science Data and/or Housekeeping Requirements
13.2.6 Notes about Raw Data
13.3 Calibration
13.3.1 Pre-Flight Calibration Procedure- Charge
--Charge Calibration File--
13.3.2 Calibration - Mass
13.3.2.1 Pre-Flight
13.3.2.2 Mass Production
13.4 Calibrated Data Specifics
13.4.1 Algorithm for Pipeline
13.4.2 Dataflow Block Diagram
13.4.3 Data Format
13.4.4 Extra FITS Extensions (planes) and Their Definitions
13.4.5 Scientific Units
13.4.6 Additional FITS and PDS Keywords Added
13.4.7 Hardware/OS Development Platform
13.4.8 Language(s) Used
13.4.9 Third Party Libraries Required
13.4.10 Calibration Files Needed (with Quantities)
13.4.11 Memory Required
13.4.12 Temporary File System Space Needed
13.4.13 Predicted Size of Output File(s)
13.4.14 Predicted Execution time
13.4.15 Contact/Support Person(s)
13.4.16 Maintenance Schedule (Code/Data Updates, Documentation)
14. SWAP Instrument description
14.1 Overview
14.2 Electronics and Flight Software
14.3 SWAP Data Types
14.4 Raw File (Level 2) Specifics
14.4.1 Data Format
14.4.2 Definition of an Observation
14.4.3 Housekeeping Needed in Level 2(Raw) Files (for Calibration)
14.4.4 Raw Science Data and/or Housekeeping Requirements
14.5 Calibrated (Level 3) File Specifics
14.5.1 Data Format
14.5.2 Further Algorithm details for Pipeline
14.5.3 Real-time science data processing
14.5.4 Errors
14.5.5 Quality Flags
14.5.6 Thruster Firings
14.5.7 SPICE Orbit and Attitude Calculations
14.5.8 Summary and Histogram Files
14.5.9 Calibration
14.5.10 Background Subtraction
14.6 Operations
14.7 Observation Examples
14.8 Updates to Level 3 (calibrated data)
SWAP Science Goals
14.8.1 Dataflow Block Diagram
14.8.2 Extra FITS Extensions and Their Definitions
14.8.3 Scientific Units
14.8.4 Additional FITS and PDS Keywords Added
14.8.5 Hardware/OS Development Platform
14.8.6 Language(s) Used
14.8.7 Third Party Libraries Required
14.8.8 Memory Required
14.8.9 Temporary File System Space Needed
14.8.10 Predicted Size of Output File(s)
14.8.11 Predicted Execution time
14.8.12 Contact/Support Person(s)
14.8.13 Maintenance Schedule (Code/Data Updates, Documentation)
14.9 Packet Description
REVISION NOTICE
Draft 1: October 2005
Draft 2: February/March 2006
Initial Issue: February 2007. Updated Sections 10 (MVIC), 11
(PEPSSI), 13 (SDC) and 14 (SWAP).
PDS V2.0 delivery: August 2008. Updated Sections 10 (MVIC),
13 (SDC), 14 (SWAP).
1. SCOPE
This document specifies the interfaces between the New Horizons
Science Operations Center (SOC) and the instrument pipeline, which
process data from Level 1 to Level 2. The purpose is to define the
various aspects of the interfaces in sufficient detail to establish a
clear understanding between the SOC and the instrument team to allow
for a parallel pipeline development.
2. SIGNATURES, AUTHORSHIP, AND RESPONSIBILITY
This document is unusual in that many parties took part in its
writing. Specifically, sections 1 through 6 were written by the
document author, whereas the bulk of the instrument-specific sections
(7 through 14) were written by representatives of the instrument
described. Because of this, a few words will be said regarding
signatures.
Each instrument team will have a person or persons responsible for
their section. If changes are made to that section, only the
person(s) responsible need to sign the new revision. If, however,
changes are made to sections 1 through 6, all parties need to sign.
The title(s) of the person(s) responsible for each instrument section
are given in the signature section above.
3. APPLICABLE DOCUMENTS
3.1 New Horizons Documents
- New Horizons SOC Data Pipeline Guide (SwRI Doc. No. 05310-SOCPL-G-01)
- New Horizons SOC Level 1 Data Formats (SwRI Doc. No. 05310-SOCL1DATA-01)
- New Horizons SOC Pipeline User Manual (SwRI DOc. No. 05310-SOCPLUM-01)
- New Horizons Data Management and Archiving Plan
(SwRI Doc. No. 05310-DMAP-01)
- New Horizons Longevity Plan (APL Doc. No. 7399-9009)
- Definition of the Flexible Image Transport System (FITS)
(ftp://legacy.gsfc.nasa.gov/fits_info/fits_office/fits_standard.pdf)
4. INTRODUCTION
The New Horizons SOC is part of the ground system that processes data
returned from the New Horizons planetary spacecraft. Data downlinked
from the spacecraft in raw packetized form is retrieved by the SOC
from the Mission Operations Center (MOC) along with navigation and
related ancillary data. The SOC generates the higher level (more
refined) data products used by the instrument teams and science
teams. In addition, the SOC performs archiving of data (but not data
products, such as maps) to the Planetary Data System (PDS). The
science data processing component of the SOC is called the SOC
pipeline. The Level 2 pipeline (called the "instrument pipeline" and
also known as the "calibration pipeline") software is a segment of the
SOC Pipeline. The instrument pipeline for each instrument is written
by the appropriate instrument team. It is run on the SOC processing
station to transform Level 1 decommutated data into Level 2 calibrated
science data. The instrument pipeline creates PDS standard, Level 2
provisional products in Flexible Image Transport System (FITS) format,
which is described in the document referenced herein (Definition of
the Flexible Image Transport System).
The SOC pipeline is divided into two main parts: the Level 1 pipeline
segment and the Level 2 (instrument) pipeline segment. Pipeline
processing is carried out sequentially. Results of the Level 1
pipeline are provided as inputs to the instrument Level 2 pipeline
segment. More information about the formats of Level 1 data can be
found in the "New Horizons SOC Level 1 Data Formats" document (SwRI
Doc. No. 05310-SOCL1DATA-01). The instrument pipeline generates Level
2 results that the SOC forwards to the PDS archiving process.
The SOC obtains science data from the Mission Operations Center (MOC)
through automated network transfers. Low-speed housekeeping and
high-speed science data from the spacecraft are provided in packetized
Supplemented Telemetry Packet (STP) form. Navigation data, ephemerides
and spacecraft pointing information, is provided in SPICE format from
the MOC and is used in Level 1 processing. Upon getting packets
(housekeeping and science data) from the MOC, the data is decommutated
in the SOC and written to an SQL database. Housekeeping from the
database and science data are associated by MET time and other
methods, such as by using meta data inserted in the high-speed
telemetry. Data for an observation are combined to create the Level 1
uncalibrated data file. A PDS detached header file (a separate file
containing the PDS header with a pointer to the data file itself) is
also created for each file. The header of the Level 1 file contains
most of the necessary information about the particular observation
needed by the instrument pipeline (an exception is detailed pointing,
which will be calculated during calibration). The instrument pipeline
segment creates the Level 2 calibrated data file from the contents of
the Level 1 file and calibration data provided by the instrument
team. Level 1 and Level 2 science data files are stored in FITS
format. Lastly, the SOC archives pipeline data products to the PDS.
SOC pipeline processing is automated under the control of the Master
Data Manager (MDM), which is a collection of scripts that control the
flow of the pipeline. While manual execution of the program is
permitted, normal operation of the SOC pipeline is not directed by
manual requests or user inputs. Pipeline segments are called by the
MDM when data from the MOC or from a previous pipeline step is
available.
The hardware platform used for the SOC as implemented for launch and
early mission is an Intel Pentium 4 processor running at 3.2GHz with
4GB RAM and a 146GB SCSI hard disk. In the case of the primary SOC
(TSOC), located in Boulder, Colorado, two of these machines are used
(one for pipeline processing and the other for data storage). At the
secondary (backup) SOC (CSOC), only one machine is used for both
purposes. The operating system used in all cases is Linux. Migration
to newer machines compatable with SOC requirements is a possibility
during the long flight missions.
5. 5. INTERFACE DESCRIPTION
The SOC pipeline code will call the Level 2 pipeline code by executing
a separate process. The name of the executable or script shall be:
[instrument]_level2_pipeline
(where "[instrument]" is the full instrument name (i.e. alice, leisa,
lorri, mvic, pepssi, rex, sdc, or swap) in lower case).
The parameters (all are character strings) passed to the Level 2 code
will follow the executable name and will be in the following order
(note that "full path," when stated below, means a file specification
containing the filename and all directories in the file's path):
- in_file - Location of input (Level 1) file (in_file)
The SOC will provide the full path of the Level 1 input file to the
Level 2 pipeline code.
- in_pds_header - Location of input (Level 1) detached PDS header
The SOC will provide the full path of the Level 1 PDS header to the
Level 2 pipeline code.
- calibration_dir - Location of calibration data and temporary file storage
Data provided by the instrument team that is needed for calibration
shall be supplied by the instrument team. The SOC will provide the
root directory containing these files (and potentially,
subdirectories) to the Level 2 pipeline code so it references the
correct location. The structure of the directories under this
directory is up to the instrument team.
- temp_dir - Location for temporary storage used by code
This is a place where the instrument pipeline code may write files for
temporary use. The contents of this directory will be erased upon
completion of the instrument pipeline.
- out_status - Location of status file
The Level 2 pipeline, upon completion, may write a short machine
readable status file used to communicate the results of the processing
to the main SOC pipeline. The location (full path) of this file will
be supplied by the SOC.
- out_file - Location of output (Level 2) file
This is the file (full path) to which the output will be written. The
SOC will provide this to the Level 2 pipeline code.
- out_pds_header - Location of output (Level 2) detached PDS header
This is the file (full path) to which the Level 2 PDS header will be
written. The SOC will provide this to the Level 2 pipeline code.
6. REQUIREMENTS
This section describes the various requirements that the instrument
team shall follow with regard to the Level 2 pipelines.
6.1 Level 2 (output) Files
The Level 2 data files shall be FITS files, and there shall be exactly
one Level 2 file produced for each Level 1 file (in any given run of
the instrument pipeline). The headers will be mostly the same, except
for optional additional keywords inserted in the Level 2 files (this
could include, for example, refined pointing). In other words,
typically, the Level 2 header keywords will be a superset of the Level
1 header keywords.
The filename of the Level 2 file will be supplied by the SOC, and it
will be similar to the Level 1 filename. PDS requires a "27.3" ASCII
character limit on the filenames, and the format of the names shall be
as follows:
- Level 1: [instrument]_[MET]_[ApID]_eng_[version].fit
- Level 2: [instrument]_[MET]_[ApID]_sci_[version].fit
(where "[instrument]" is the first three letters of the instrument
- name (i.e. ali, lei, lor, mvi, pep, rex, sdc, or swa) in lower case,
- "[MET]" is the 10-digit MET time, either from the instrument itself
- (low-speed data) or from the instrument interface card (high-speed
- data), "[ApID]" is the hexadecimal value of the ApID for this
- observation, and "[version]" is the version stamped on this file
- based in existing previous versions produced).
The instrument/mode strings above will be derived from the ApID of the
data, and these filenames will be supplied to the instrument pipeline
(see the interface description above).
Whereas the Level 1 files will be in the same "units" as the data
coming from the spacecraft/instrument (i.e. same binary representation
- this is partly to avoid any round-off or conversion loss), the Level
2 files shall express values in physical units useful for scientific
interpretation.
Whereas the Level 1 files only contain the header and data itself, the
Level 2 files shall contain (when appropriate) two additional "panes"
(FITS extensions):
- Error (specifies error bars on the numbers - defined by the instrument team)
- Quality (Indicates the quality of the data - defined by the instrument team)
If it is desired to re-run the Level 2 pipeline (because of new Level
2 code or calibration data), a new version of the output file will be
named as specified above when calling the Level 2 pipeline.
6.2 Pointing Information
The pointing information included in the Level 1 files will be mostly
non-instrument specific (except for bore-sight vector where
applicable). It also may not cover the time granularity needed for
calibration in the Level 2 pipelines (see the "New Horizons SOC Level
1 Data Formats" document (SwRI Doc. No. 05310-SOCL1DATA-01) for
specifics). Therefore it is expected that the Level 2 pipelines may
have to make use of SPICE. It is therefore the responsibility of the
Level 2 pipelines to provide this functionality. SPICE kernels will
be available on the SOC.
6.3 The Code
The SOC defines the interface the code uses to access the required
data. This includes the directory structure on the disk where the
Level 1 data file can be found as well as the path (specific to each
instrument) where instrument-team-supplied calibration files and other
data will be stored and accessed. Also, the filename of the output
file is supplied.
The code shall be written in a language that meets the SOC's longevity
requirements (see section 6.11). More information on this can be found
in the "New Horizons SOC Pipeline Guide" (SwRI
Doc. No. 05310-SOCPL-G-01). The languages allowed are as follows:
- C
- C++
- Fortran
- IDL
- Python
- Java
- Perl
The code written by the instrument team shall not implement very time
consuming iterative numerical processing to the extent that it
has an impact on the daily processing done by the SOC. In
other words, if the time to compute Level 2 data is so extreme
that it jeopardizes the completion of each daily run of the
pipeline (so ample idle time is not available between runs),
the situation will need to be re-evaluated. It is expected
that a daily run of the entire pipeline be complete within a
few hours of its start. This gives most of the day for users
to access new data before the next run is initiated. The
maximum time allowed for execution of an instrument's Level 2
pipeline shall be 5 minutes (for each input file processed).
The predicted actual maximum time is negotiated and specified
in the instrument-specific sections.
Any needed 3rd party libraries also shall meet the longevity
requirements. Specifically, source code should be available and must
be provided with the code unless already available to the SOC.
6.4 Calibration Data
The code will most likely need calibration data in addition to the
Level 1 data files themselves. This data can be anything required. The
SOC will provide a directory where these files will be placed on the
SOC pipeline system, and the instrument pipeline code will be able to
access them there.
The combination of the Level 1 file (and detached PDS label) and the
data provided must be sufficient to produce each Level 2 file. If
housekeeping information (instrument or spacecraft) is needed, these
must be already in the header (or tables) of the Level 1 file. If
continuously varying values (e.g. temperature over many seconds, etc.)
are needed, a FITS table will be written into the Level 1 file with
this information.
6.5 Documentation
All code and data files shall be accompanied by thorough
documentation. The code itself should have clear and appropriate
comments throughout. Error conditions shall be documented in the code
as well (see section 6.6 for more on this topic).
Documentation and code shall be written assuming that it will be read
by someone years from now who is unfamiliar with the
system. Understanding of the documentation should not rely on special
scientific knowledge or specific domain knowledge.
6.6 Error Conditions and Integration Troubleshooting
If there are any reasons the code might abort processing, these shall
be defined, and the resulting action should be specified. Also, if
such an abort happens, the reason should be noted in the status file
written ("out_status" file described above).
A contact person shall be specified who will be responsible for
helping the SOC operators when unexpected errors occur. This person
should be able to help with debugging and should also be available to
respond and help in two days or less for consultation during the
pipeline integration process.
6.7 PDS Archiving
The Level 2 (output) files, as well as Level 1 files, will be archived
to PDS. Therefore the format of the files shall meet PDS
requirements. This includes size requirements set forth in the New
Horizons Data Management and Archiving Plan (#05310-DMAP-01).
PDS detached labels for the Level 2 files shall be generated by either
the instrument pipeline code or by the SOC using a translation table
(from FITS to PDS keywords). Which method is appropriate will be
determined on an instrument by instrument basis. If generated by the
SOC, "in_pds_header" and "out_pds_header" can be ignored in the
instrument pipeline code.
6.8 Configuration Management
All code, documentation, and calibration files will be put under
configuration management at the SOC. Also, the necessary keywords
shall be inserted into the Level 2 headers by the Level 2 pipeline
code to specify the version of the code and data used to produce the
Level 2 files. This ensures that data is traceable back to the
correct code version.
In addition, the Level 2 pipeline code shall insert, using header
keywords, the calibration files used and the versions thereof (if
applicable).
6.9 Pipeline Updates
Updates to the instrument pipeline (including code, documentation, and
calibration data) are to be delivered to SOC personnel for
integration; all such updates will require appropriate documentation
and will fall under SOC CM. The code will be checked in to the SOC
configuration management after regression tests are run. Any special
instructions or changes should be communicated to the SOC personnel,
and a file containing release notes (called "RELEASE_NOTES") should
accompany the update. The SOC personnel will notify the instrument
team when the new update is in place and active.
6.10 Acceptance Review
The instrument pipeline (including code, documentation, and
calibration data) shall be subject to an acceptance review.
6.11 Longevity
The code and all third party libraries and data files used shall meet
the longevity requirements as specified in the New Horizons Longevity
Plan (#7399-9009). Also, development, documentation, and testing of
the pipeline shall adhere to these requirements.
7. ALICE INSTRUMENT DESCRIPTION
7.1 PERSI-Alice Instrument Overview
PERSI-Alice is a UV spectrograph that is sensitive to Ultraviolet (UV)
light in the range of 520-1870 Angstroms. The instrument consists of a
telescope section with an off-axis parabolic mirror, and a
spectrograph section that includes a diffraction grating and a
microchannel plate (MCP) detector. The MCP detector is an
electro-optical device sensitive to extreme and far ultraviolet
light. It consists of a photo cathode-coated MCP surface that
converts UV photons to electrons, an MCP Z-stack configuration of
three MCPs to amplify the signal, and a two-dimensional double
delay-line (DDL) anode readout array. The first (x) dimension
provides the spectral location of the detected photon and the second
(y) dimension provides one-dimensional spatial information. The DDL
detector system outputs to the command-and-data-handling (C&DH)
electronics the pixel location for each detected photon event. The
pixel location (X,Y) is given as a pair of coordinates, spectral (X
axis) and spatial (Y axis). The events are processed by the C&DH
electronics. The C&DH is also the controller of Alice; it receives
commands from the spacecraft, acquires data from the MCP detector
system, and returns telemetry to the spacecraft. Science data
telemetry generation is performed by the detector hardware but the
C&DH also controls this function. Alice has two acquisition modes
(see below) in which the spectral/spatial data from the detector are
processed by the C&DH subsystem.
All following descriptions assume a nominal operating instrument. The
instrument hardware also provides a basic, hardware-controlled,
default pixel list acquisition mode, which is activated when the
instrument control hardware detects multiple successive software
failures. This mode is called the 'State Machine Mode' (SMM); for a
description of this mode, the reader is referred to the instrument
C&DH hardware description. Once this mode is activated any software
control of the acquisition operation is disabled, until the
instrument C&DH is reset either by a power cycle reset or by a
hardware S/C reset.
Data recorded on New Horizons are sent to the ground via the Deep
Space Network. From there the data are sent to the Mission
Operations Center (MOC) at the Applied Physics Laboratory (APL). The
Science Operations Center (SOC) at the Southwest Research Institute
(SwRI) in Boulder retrieves new data from the MOC daily. The data
from the MOC are in a packetized form. Software pipelines at the SOC
convert the data from these raw packets into FITS (Flexible Image
Transport System) format files with scientifically useful and
calibrated data. The initial processing sorts the packets into FITS
files (as images and data tables) with useful header keywords. These
keywords include the mode of the observation, exposure and timing
information, and basic pointing information of the instrument
boresight. The initial processing also adds relevant housekeeping
telemetry (temperatures, voltages, etc.) in a binary table as an
extension to the FITS file. The calibration pipeline then performs
basic scientific calibration on these data.
7.2 "Raw" Data Specifics
The term "raw" as used here refers to CODMAC Level 2 data
7.2.1 Data Format
PERSI-Alice High Speed data frame formats:
Science data frames consist of "raw" science data of 32768 16-bit
words in size, consisting of 1 word (16 bits) of frame ID header
information and a 32767-word data block. Science data frames are
generated by the acquisition hardware and sent to the spacecraft via
the dedicated LVDS interface. Data are transferred at a rate of 1
Mbit/sec, resulting in a frame transfer time of 557 milliseconds. The
spacecraft tags the received data with a receive time (referred to as
'collect time') and stores the data in the Solid State Recorder (SSR).
Note that these science frames are not identical to the CCSDS
telemetry packets that are used to transfer the science data to the
ground. The generation of telemetry (TM) packets from the frames
stored in the SSR is handled by the spacecraft and multiple CCSDS TM
packets are used to transfer a single science frame.
To identify the Science frames, a single 16-bit word header is
inserted into each frame. This header is generated by the acquisition
hardware and includes the information listed in Table 7-1. The
complete header word of the most recently generated science frame is
included in the housekeeping TM packet to allow for correlation
between the two data streams (low and high speed) after the data are
received by the ground system.
Table 7-1
Table 7-1
The contents of the remainder of the data frames (the 32767-word data
block) depend on the acquisition mode:
- Pixel List: Each word in the data block from a pixel list
exposure describes a photon event or a time hack. Photon events are
indicated by bit 15 having a value of zero and time hacks are
indicated by bit 15 having a value of one. For a photon event, the
remaining 15 data bits encode the location of the detected event
consisting of a 10-bit encoded spectral location (X) and a 5-bit
encoded spatial location (Y). The time hack is used to provide
temporal information about the photon events. The acquisition
hardware will generate and insert time hacks in the frame on a
periodic basis; the frequency of the time hacks is configurable (by
command) for each acquisition in a range of 4 - 512 ms. For a time
hack, the remaining 15 bits contain an incrementing counter that
counts the number of 4 ms periods. This value allows for verification
and correction of timing in case of lost frames or packets.
- Histogram: Each word in the data block from a histogram
exposure is a 16-bit "counter" giving the number of photon
events detected at each specific X,Y location on the
detector. The format of the detector is 1024x32 pixels,
which are the spectral and spatial dimensions respectively,
i.e., there are 1024 spectral elements along the X-axis and
32 spatial elements along the Y-axis, giving a total of 32768
values (however, the first word always contains the header
word). The counters are stored row-wise, corresponding to
the spectral dimension indexing most quickly. These counters
saturate at a maximum value of 65535 to indicate a completely
filled counting bin, meaning that the counters do not wrap
around. In addition some special data words (header
cross-identification and pulse height distribution) are
overlying the lower left-hand corner of the actual array in a
block of 4 (spatial) x 32 (spectral) words. This usage
doesn't affect the science data contents because detector
events do not occur in this region. In this over-written
block, the first row contains the header cross-identification
word, the second and third rows contain the 64 words of pulse
height information, and the fourth row is filled with zeros.
A "pulse height" is the amplitude of a photon event, and this
pulse height distribution (PHD) shows the number of events in
a 64-bin distribution with 6-bit resolution; the value in
each PHD bin gives the number of events that occurred with
the particular amplitude associated with that bin. These PHD
counters also saturate at a value of 65535. So a single
photon event is counted both in the spectral/spatial array
and in the pulse height list. The PHD is used as a
diagnostic for the health and behavior of the detector.
For test purposes the instrument can fill the memory with known
deterministic patterns so the interfaces to the spacecraft and ground
can be verified. The instrument software allows for the generation of
5 different test patterns.
7.2.1.1 Histogram FITS file:
The primary data unit in the FITS file is a 2-D raw histogram frame
(also referred to as an "image") consisting of 1024x32 16-bit integer
numbers. Note that the Alice instrument data are unsigned 16-bit
integers (giving values of 0 to 65535). The first data extension in
the FITS file contains the 64-element pulse height distribution (PHD)
that was acquired together with the histogram. When the Level 1
pipeline saves the PHD to this extension, it then zeros out that part
of the histogram array. The second data extension contains a 141
column by t row binary table, where t is the time of the exposure in
seconds, of housekeeping values recorded during the observation (the
housekeeping report rate is 1 Hz).
FITS File Storage Location Description
Primary Data Unit (PDU) Raw Histogram image (uncorrected counts)
Extension #1 Pulse Height Distribution (PHD)
Extension #2 Binary Housekeeping Table
7.2.1.2 Pixel list FITS file:
Upon receiving a pixel list frame, the Level 1 processing creates a
ground-calculated "reconstructed histogram" from the received pixel
list data and places it in the primary data unit of the FITS file;
this enables an easy quick-look inspection of the pixel list data
(e.g., using most FITS viewers that by default typically display the
data in the primary data unit). The pixel list data itself can be hard
to interpret, so this reconstructed histogram image is desirable to
enable the scientist to determine, e.g., data quality, whether the
target was in the field of view, etc... The first data extension
contains the raw pixel list data set, which includes the full stream
of photon events and time hacks. The second extension contains the
count rate derived from the pixels list data. Each count rate bin
shows the number of events that occurred between successive time
hacks. The resolution of this count rate data set is determined by the
hack rate used for the pixel list acquisition. The length of this
vector is variable depending on the source flux and the hack rate. The
third data extension contains a 141 column by t row binary table,
where t is the time of the exposure in seconds, of housekeeping values
recorded during the observation.
FITS File Storage Location Description
Primary Data Unit (PDU) Reconstructed Histogram image (uncalibrated counts)
Extension #1 7.2.1.3 raw pixel list
Extension #2 7.2.1.4 Count rate vector from pixel
list data (sampled at time hack rate)
Extension #3 Binary Housekeeping Table
7.2.2 Data Sources (High/Low Speed, CCSDS, ITF)
7.2.2 Data Sources (High/Low Speed, CCSDS, ITF)
PERSI-Alice data are transferred via CCSDS packets that are packetized
7.2.by the spacecraft from the Solid State Recorder.
The spacecraft will packetize the PERSI-Alice High Speed Telemetry
data into CCSDS packages before sending the data to the ground.
Different APIDs are used to distinguish the histogram and pixel list
data packets (see Table 7-2). For the PERSI-Alice science frames the
spacecraft will either use the "RAW" packetized format or the
loss-less compressed format to transfer the data. In either case the
result will be data encoded in CCSDS telemetry packets. The package
APIDs listed in Table 7-2 are used to distinguish the different Alice
CCSDS packets.
The packet time as listed in the CCSDS packet represents the time at
which the packetization operation was performed. The second time
field contains the frame collection time as sent from a spacecraft
perspective, meaning this represents the time at which the spacecraft
received the frame from the instrument. As the instrument immediately
sends the frame at the completion of the acquisition this corresponds
to the time at which the acquisition was completed.
Table 7-2
Table 7-2: PERSI-Alice science APIDs
Packetized "RAW" telemetry:
The nominal data transfer method for the Alice pixel list science data
is packetized "raw" data. Each CCSDS science packet can transfer a
segment of up to 480 data bytes. In order to transfer a full
PERSI-Alice frame of 32768 words (16-bits), 137 science packets are
needed; the first 136 packets will all be full size segments of 480
bytes, the last packet will transfer the remaining 256 bytes. The
grouping flags of the packets indicate the start and end segment
within a complete frame transfer.
Note the '#' marks in the following tables refer to the third digit of
the APID, the valid digits for these numbers are indicated in Table 7-2.
Table 7-3
Table 7-3: PERSI-Alice CCSDS Packetized (RAW) science packet
Lossless Compressed telemetry:
The nominal data transfer method for the Alice histogram science data
is lossless compressed data. When applied to pixel list data, the
'FAST' algorithm results in negligible compression rates, and
occasionally in a 1% expansion, therefore lossless compression will
generally not be used with pixel list data. The spacecraft uses the so
called 'FAST' algorithm to compress the image data. The 'FAST'
algorithm uses one-dimensional correlation between successive data
elements to remove redundancy. Data is encoded in blocks of 16
successive science values, the first value of such a block is send in
full 16 bits, the remainder of the block is encoded using successive
differences, using an adaptive coding mechanism.
Table 7-4
Table 7-4: PERSI-Alice CCSDS Compressed (Loss-Less) science packet
7.2.3 Definition of an "Observation"
An observation will be a single histogram image or one frame of a
pixel list series. Each observation will be written to a separate FITS
file. A pixel list resulting from a single exposure command may
therefore produce many such frames, each of which will be saved as a
separate FITS file.
7.2.4 S/C Housekeeping Needed in Level 1 Files (for Calibration)
Spacecraft housekeeping that may be needed in the Alice pipeline
include any temperature sensors on the spacecraft around the Alice
instrument and the spacecraft-measured instrument bus voltage and
power consumption on the different busses.
Spacecraft measured temperatures related to Alice (ApId 0x00D and 0x08D):
T_A.CDH_TEMP_ALICE_BRACK_BASE_00D
T_A.CDH_TEMP_ALICE_1_00D
T_A.CDH_TEMP_ALICE_2_00D
PDU parameters related to Alice (ApId 0x009, 0x00a, 0x089 and 0x08a):
ALICE_LVPS_A_VOLT_009
ALICE_LVPS_A_CURR_009
ALICE_LVPS_B_VOLT_009
ALICE_LVPS_B_CURR_009
ALICE_ACT_A_VOLT_00A
ALICE_ACT_A_CURR_00A
ALICE_ACT_B_VOLT_009
ALICE_ACT_B_CURR_009
Note that these temperatures currently are not used in the pipeline
processing, but may be used in the future as the code and calibrations
are revised.
7.3 "Calibrated" Data Specifics
"Calibrated" data as used here refers to CODMAC level 3 data.
7.3.1 Algorithm for Pipeline
Overview: The Alice calibration pipeline that is run at the SOC
applies various calibrations to raw Alice data to convert the data
from units of counts to flux units (photons/s/cm2). Four types of
operations can be performed. They are, in order of application to the
data: deadtime correction, dark correction, effective area correction,
and flat field correction. These are described in more detail below.
7.3.1.1 Deadtime Correction
The Alice detector electronics require a finite time to process a
photoelectron pulse. As a result, if photoelectron pulses arrive too
close together in time, the latter pulse(s) will not be recorded,
resulting in an effective decrease in the sensitivity of the
instrument that is a function of the count rate. The deadtime
correction time constant is 18 microseconds. At input rates below 50
kHz, the detector electronics is non-paralyzable (fixed deadtime per
event that is not re-triggerable). To calculate the detector output
count rate, the following formula is used: C_out = C_in / (1 + C_in
tau), where Cout is the output (i.e., detected) count rate and C_in is
the input count rate. At a count rate of 1 kHz, the deadtime correction
factor (tau) is approximately 1.02, while at 20 kHz, the deadtime
correction factor is approximately 1.56.
7.3.1.2 Dark Correction
The Alice detector electronics register photon events even when the
aperture door is closed and the detector is not illuminated. The
spatial distribution of dark counts is approximately uniform across
the detector. However, there is some low-level 2-D structure to the
dark counts. Alice observations made with the aperture door closed are
summed together to create a "superdark". This superdark image is then
scaled to the exposure time of an Alice science observation and
subtracted from the data.
During in-flight commissioning, these dark counts were measured at a
rate of approximately 94 Hz across the entire detector. The primary
source of dark counts is the spacecraft RTG. Dark exposures are made
throughout the mission to monitor the background event rate and
detector performance.
7.3.1.3 Effective Area
The sensitivity of Alice to UV photons varies as a function of
wavelength. It is convenient to think of the Alice sensitivity in
terms of the effective area of the instrument. For a point source
located at infinity, effective area is defined as the area of the
surface that intercepts incident photons at the same rate as is
detected by the Alice instrument. Dividing the observed count rate by
the effective area yields the incident flux of photons. In general,
effective area depends on the geometric size of the instrument
aperture, reflectivities of the optical surfaces, sensitivity and
quantum efficiency of the detector, etc.
The Alice effective area curve (v003) is based on pre-flight estimates
and calibration stars observed by both Alice and the IUE
satellite. Above 1350 Angstroms, the effective area is derived from
matching the stellar flux observed by Alice with that observed by
IUE. Below 1350 Angstroms, the pre-flight effective area estimate has
been scaled by a factor of 0.6 so that the long wavelength end of the
pre-flight effective area estimate approximately matches the
calibration derived from the stellar observations.
7.3.1.4 Flat Field
When uniformly illuminated by a monochromatic source, the counts
detected by the Alice instrument vary from pixel to pixel with a
standard deviation of approximately 15%. This spatial variation in
instrument sensitivity is the instrument flat field response.
As of September 2007, no suitable observations have been made from
which to derive an in-flight flat field calibration. Thus the flat
field correction is currently disabled in the Alice pipeline code.
Current plans are that during annual checkouts, a stellar scan along
the slit could be used to generate a pseudo-flat field that could be
used in the Alice pipeline.
7.3.2 Format of Calibrated Data
7.3.2.1 Histogram
The primary data unit in the FITS file is a 2-D calibrated histogram
frame consisting of 1024x32 array of 32-bit floating-point
numbers. The units of the histogram image are photons/s/cm2. The
first data extension in the FITS file is a 1024x32 array of 32-bit
floating numbers containing the uncertainty in the histogram
image. The second data extension is a 1024x32 element array
containing the wavelength for each pixel in the histogram
image. The third data extension is the 64-element PHD, identical
to that in the raw data. The fourth data extension is an array
containing the number of photon events per second, sampled at a
rate of 1 Hz. The fifth data extension is the 141 column by t row
housekeeping row as in the raw data.
FITS File Storage Location Description
Primary Data Unit (PDU) Calibrated Histogram image (photons/sec/cm2)
Extension #1 Uncertainties in histogram data values
Extension #2 Wavelength Image (Angstroms)
Extension #3 Pulse Height Distribution (PHD)
Extension #4 Count rate vector from HK (sampled at 1 Hz)
Extension #5 Binary Housekeeping Table
7.3.2.2 Pixel List
The primary data unit in the FITS file is a 2-D calibrated
reconstructed histogram image consisting of a 1024x32 array of 32-bit
floating-point numbers. The units of the histogram image are
photons/s/cm2. The first data extension in the FITS file is a 1024x32
array of 32-bit floating numbers containing the uncertainty in the
reconstructed histogram image. The second data extension is a 1024x32
element array containing the wavelength for each pixel in the
reconstructed histogram image. The third data extension contains a
binary table of 5 columns and rows for each photon event. The five
columns are the X (spectral) position of each photon event, the Y
(spatial) position of the photon event, the wavelength of the photon
event, the cumulative number of elapsed time intervals (starting from
0 at the beginning of the file), and the ephemeris time (et),
i.e. seconds past J2000, at the time of detection. The fourth data
extension is the count rate derived from the pixels list data, showing
the number of events that occurred between successive time hacks. The
resolution of this count rate data set is determined by the hack rate
used for the pixel list acquisition. The length of this vector is
variable depending on the source flux and the hack rate. The fifth
data extension contains the binary housekeeping table.
FITS File Storage Location Description
Primary Data Unit (PDU) Reconstructed Calibrated Histogram image
(photons/sec/cm2)
Extension #1 Uncertainties in reconstructed
histogram data values
Extension #2 Wavelength Image (Angstroms)
Extension #3 Binary Pixel List Table
(X, Y, wavelength, time hack #, MET)
Extension #4 Count rate vector from pixel list data
(sampled at time hack rate)
Extension #5 Binary Housekeeping Table
7.3.3 7.3.3 Scientific Units
For Histogram, units are counts (histogram), angstroms (wavelength
array), and counts (PHD array).
For Pixel List, units are counts (generated histogram), angstroms
(wavelength array), counts, pixel location, and angstroms, and seconds
(pixel list array), counts per second (count rate array).
7.3.4 Additional FITS and PDS Keywords Added
Below is an example of the Mike pipeline keyword block added to the
FITS header:
COMMENT
=============================================
COMMENT
MIKE_BEG= 'Feb 15 16:12:57 2005' / START MIKE KEYWORD BLOCK
MIKE_VER= '2.0 [2005 Feb 15]' /Version of Mike pipeline code
K_MODE = 'ACQMODE ' / Keyword containing the mode name
K_ETIME = 'EXPTIME ' / Keyword for the effective exposure time
FILE_IN = 'test/ali_0000006498_0x4b3_eng_1.fit' / Input file for processing
FILE_OUT= 'test/test_his.fit' / Output file after processing
DIR_CAL = 'cal/ ' / Directory of calibration data
DIR_DONE= ' ' / Directory to put raw data after processing
BADFILE = ' ' / FITS file of bad pixel mask array
BADFLAG = -1 / Bad pixel mask flag
BADVALUE= -666 / Bad pixel value
DEADFILE= 'deadtime/ra_dead_002.txt' / Deadtime correction file
DEADFLAG= 1 /
DEADTYPE= 'FUN ' / Correct using FUNction or lookup table (LUT)?
DEADCORR= 'TOTAL ' / Correct by TOTAL or each PIXEL count rate?
BIASFILE= ' ' / Bias image filename
BIASFLAG= -1 / Bias correction flag
DARKFILE= 'dark/ra_dark_001.fit' / Dark image filename
DARKFLAG= -1 / Dark correction flag
FLATFILE= 'flat/ra_flat_001.fit' / Flag field image filename
FLATFLAG= -1 / Flat field correction flag
FLATNORM= 'AVERAGE ' / How to normalize flat field
WCALFLAG= 0 / Wavelength calibration flag
WCALPRO = 'alice_wavecal' / IDL program to perform wavelength calibration
WCALPARS= 'T_DELECC' / keywords for parameters to use for wave cal
AEFFFLAG= 1 /
AEFFPRO = 'alice_aeff' / IDL program to get effective area
AEFFPARS= 'T_DELECC' / keywords for parameters to get effective area
LOG_FILE= 'test/log.out' / Filename to save log file (default = append to
LOG_MAIL= ' ' / address (if any) to e-mail log file
MIKE_ERR= 1 /
MIKE_END= 'Tue Feb 15 16:12:57 2005' / END MIKE KEYWORD BLOCK
COMMENT
=============================================
COMMENT
7.3.5 Hardware/OS Development Platform
Dell Linux, Redhat 7.2; Apple G5 Power PC and PowerBook G4, OS X v10.4
7.3.6 Language(s) Used
IDL
7.3.7 Third Party Libraries Required
IDL Astro (http://idlastro.gsfc.nasa.gov/)
7.3.8 Predicted Execution time
A few seconds per file.
7.3.9 Contact/Support Person(s)
Andrew Steffl, Joel Parker, and Maarten Versteeg
8. LEISA INSTRUMENT DESCRIPTION
8.1 Overview
LEISA is an infrared imaging spectrometer. The detector is a 256x256
pixel array. Spectral separation is done with a wedged optical etalon
filter placed in close proximity to the detector array. The filter is
made of two pieces, a high spectral resolution
(lambda/delta(lambda)=580) segment and
a low spectral resolution (lambda/delta(lambda)=280) segment, bonded
together. The
detector-filter assembly is located at the plane of focus of the Ralph
telescope where a 2-D image is recorded simultaneously with the
infrared spectrum of the scene. The layout for the filter assembly is
shown in Figure 8-0: Layout for LVF Filter Assembly. The wavelength
range of the sensor is 1.225-2.5 nm for the low resolution segment and
2.1-2.25 microns for the high resolution segment. The wavelength of
transmission of the filter varies along one axis and is constant in
the other. Lines of constant wavelength are aligned with the row
direction of the detector array. The number of pixel-limited spectral
channels is the number of rows of the detector, excluding a number of
rows (4) obscured by opaque adhesive at the bond joint between the two
filter segments.
Figure 8-0: Layout for LVF Filter Assembly
The LEISA detector array is a Rockwell PICNIC device. It is read out
by the Ralph electronics in Correlated Double Sample (CDS) mode. The
signal is converted to a 12-bit value using the middle 12 bits of a 16
bit analog to digital (A/D) converter. There are two data transfer
modes, one in which both signal and reset level data are returned
(un-subtracted mode), and the other in which the reset level is
subtracted from the signal level and only the difference is returned
(subtracted mode).
The image cube is recorded as a series of N image frames, with N
determined by the length of the scan multiplied by the frame
rate. Detector frame rate is adjustable between 0.25 and 8 Hz in 1 ms
steps. Each frame covers the complete range of wavelengths. LEISA is
normally operated in a scanning mode, with the target moving through
the image plane, row by row. Slicing the image cube along one row
gives a scanned image of the target in one wavelength. Co-registering
each wavelength image (removing motion and optical distortion) yields
an IR spectrum of the target.
Data recorded on New Horizons is sent to the ground via the Deep Space
Network. From there the data is sent to the Mission Operations Center
(MOC) at the Applied Physics Laboratory (APL). The Science Operations
Center (SOC) retrieves new data from the MOC daily. The SOC software
pipelines convert the data from the MOC archives into FITS (Flexible
Image Transport) files with scientifically useful and calibrated
data. The SOC first sorts the packets into image cubes of raw (12-bit)
sensor counts with useful header keywords. These keywords include the
recording mode of the observation, timing information and basic
pointing information of the instrument boresight. The raw processing
also gathers housekeeping (H/K) telemetry from the Ralph instrument
into a table. Once the raw processing is complete, the SOC produced a
calibrated data set for each observation.
8.2 Raw Data Specifics
8.2.1 Data Format
Raw Dataset:
The SOC stores the LEISA data cubes in Band Interleaved by Line (BIL)
order, i.e. image frames are stored sequentially. To re-order LEISA
images as received from the spacecraft, the SOC does the following to
each frame of data:
1. de-interlace by quadrant
2. reverse the Y direction
3. rotate 180 degrees
The resulting frames from LEISA have the (0,0,0) element of the 3-D
array corresponds to the location of wavelength 2.5 microns on the LEISA
filter at the minimum X axis location in the image in the first
frame.
The SOC raw data product is a FITS format data file and PDS detached
label file. Ancillary data for an observation is placed in the primary
header of the FITS data file. The 256X256XN data cube is stored in
the primary data unit as an array of integers. The first FITS
extension is a binary table of Ralph housekeeping data.
Outline of the raw FITS file:
- Primary HDU - Raw 12 bit image counts
- Primary Header (FITS + pointing + observation keywords)
- 256 X 256 X N integer point array
- Extension 1 - Binary table of Ralph housekeeping
- Ext. Header (keywords + binary table definition)
- Ext. Binary Table (115 X S binary table of Ralph housekeeping data)
*[N is the number of data image frames in the observation, S is the
number of seconds in the observation]
**[In the case of un-subtracted readout mode, frames alternate between
read and reset signal levels]
Image Data
The primary data unit contains the raw spectral image data. Values
recorded by the instrument with 12 bit precision are stored as 16 bit
integers.
Housekeeping Data
Housekeeping data generated by the Ralph instrument is stored in
Extension 1 as a binary table. The first field in each row of the
table is mission elapsed tine (MET). Table entries are sorted by
increasing MET. The time interval between each table entry is fixed,
one second per entry, unless there is missing data. Pipeline
Processing
The limits of an observation are established by the SOC using
information in each telemetry packet of an observation sequence.
8.2.2 Data Sources (High/Low Speed, CCSDS, ITF)
Ralph housekeeping data is transmitted in the form of CCSDS packets.
One housekeeping packet is produced by the Ralph instrument each time
a spacecraft PPS (pulse per second) signal is received. State
information is gathered, time tagged, and written to the low speed bus
in CCSDS packet form. The CCSDS packets are transmitted during the
next DSN pass.
LEISA image data is transmitted in the form of CCSDS packets produced
by the spacecraft compression/packetization routines from the data
written to the high-speed bus. The LEISA detector has 4 output
channels, one for each array quadrant. The first 4 elements of the
data stream are the first pixels from each quadrant. The second 4
elements are the second pixels from each quadrant, and so on. One
'line' of data in this order is 4x 128 pixels long, and is not the
same as a line in the final image. During the observation, image data
is written to the spacecraft high speed bus. These data are not
automatically transmitted. A compression/packetization routine is
scheduled some time later that converts the Ralph sensor counts to a
packetized form.
The data can be packetized without compression, with lossless
compression, or with lossy JPEG compression. The packetization
routine can also process a sub-frame area of interest, or a more
complicated sliding subframe that tracks the image target as the
scanning observation proceeds. In un-subtracted readout mode, the
spacecraft interface supports only uncompressed downlink. Regardless
of windowing or compression, the SOC raw data processing reassembles
the data into a full 256X256XN data cube.
8.2.3 Definition of an "Observation"
Science Operation
The size of the LEISA detector is 256 x 256 pixels. One read out of
all 65,536 detector pixels is called an image or frame. The data
content of a LEISA "frame" is consistent with the S/C definition of
the term. The processing definition of "image" is consistent with the
optical definition except that the order of pixel elements is
different in the electronic data stream.
An observation is a sequence of frames. The number of frames per
observation is variable. Pixel values are recorded with 12 bit
precision. One image contains 65536 pixels x 1.5 bytes/pixel = 98304
bytes of data, however, data is stored as 16 bit values in the SOC
data files.
For normal science observations the Ralph electronics use the value of
the frame rate to minimize smearing by compensating for the spacecraft
motion and scan rate relative to the target. Reset levels are stored
temporarily by the electronics and subtracted from read levels
(subtracted mode). The difference in read and reset levels is
transferred to the spacecraft. Alternately, the instrument can be
forced to use a fixed frame rate value.
Un-subtracted Read-out:
There is a voltage offset for each LEISA quadrant to assure the sensor
signal will be in the correct range of the A/D. The offset values are
set from a table when Ralph is powered on. Un-subtracted mode can be
used to evaluate the offset values. In un-subtracted readout mode,
reset levels are not subtracted from read levels. Both read and reset
are transferred. The number of values in one data frame of the
un-subtracted mode (131,072) is 2x twice that of subtracted mode. Read
and reset values are interleaved by data line and the number and order
of the pixel elements in a line are the same as for subtracted mode
readout. The reset of a pixel occurs after the integrated signal is
read, so read levels correlate with reset levels recorded in the
preceding frame. The spacecraft interface supports only uncompressed
packetization of the full LEISA array for un-subtracted readout mode.
8.2.4 Housekeeping Needed in Level 1 Files (for Calibration)
Most of the H/K values are used for engineering troubleshooting and
not needed for data processing. Housekeeping data that are important
to further processing (see the following table) are stored in header
keywords.
Keyword Description
SIDE Instrument hardware side
DETECTOR Always LEISA for LEISA data
FILTER Always WEDGE for LEISA data
LEI_OFFx Value used to set voltage offsets for the four LEISA quadrants. x=1-4
LEI_RATE Time between LEISA readouts (ms)
8.2.5 Science Data and/or Housekeeping Requirements
Other important information is determined by the SOC while processing
the raw observation data. These values are also stored as keywords in
the FITS header.
Keyword Description
MET510 The MET of the Ralph housekeeping packet that marks the start
of an observation, used to determine the observation start time and
frame rate
TRUE510 Is the 0x510 real or assumed from a gap?
SCANTYPE Always LEISA for LEISA data
LEI_MODE RAW for un-subtracted readout mode
SUBTRACTED for subtracted readout mode
STARTMET Actual start time of first integration, in MET (s)
EXPTIME LEISA exposure time (s). Same as RALPHEXP.
There is zero dead time between frames so the
frame rate is exactly 1/EXPTIME
SPICE and SPICE Kernels:
The SOC maintains an archive of SPICE kernels that describe the
position and attitude of the spacecraft as any time in the mission.
The kernels are used to calculate many values describe the instrument
pointing during each observation, stored as header keywords with the
prefix SPC. The names of the SPICE kernels used to process the
observation are stored as header keywords with the prefix SPCK.
8.3 Calibrated Data Specifics
8.3.1 Algorithm for Pipeline
There are six processing steps applied to the raw LEISA data to produce the calibrated output:
1. Validate raw image file
2. Preprocess un-subtracted mode data
3. Process A/D rollover pixels
4. Convert raw counts to calibrated values
5. Compute pointing data
6. Construct FITS file
Validate raw image file
The input file is validated to assure the data is ready for further
8.processing. Checks are for valid mission, instrument, mode, and
8.image array size. The values of important keywords are validated
8.and collected in this step.
Preprocess un-subtracted mode data
If the data readout was in un-subtracted mode, the reset values are
subtracted from the read values in this step and the rest of the
processing is the same, regardless of readout mode.
Process A/D rollover pixels
There are two instances where the subtracted raw data value will be
off by exactly 4096 counts. The first is when the subtraction of the
reset count results in a negative number . This happens because of
array noise and read noise and results in small negative numbers being
returned as large positive number.s. The second instance is when the
subtraction of the reset count results in a number greater than 4095
(12 bits). This happens because the most significant bit of the A/D
is not read. A count higher than 4095 is normally considered outside
of dynamic range of LEISA, but can be corrected on a case by case
bases.
If a file identifying rollover pixels for the observation exists (see
next paragraph), the identified pixels are corrected for rollover. If
no file exists, any subtracted count greater than 3850 is considered
to have rolled over, and 4096 is subtracted from the raw count value.
This is a good first-cut since the observations will not be designed
to return signal counts this high.
During initial image analysis by the Ralph team, each observation is
analyzed in detail. A file identifying rollover pixels is generated
which identifies the pixels that are deemed to need rollover
correction. The case where the read count is higher than 4095 can be
detected by analyzing surrounding pixels and by watching the target
scan through the array. These are also included in the rollover file.
Once this file is installed on the SOC, processing of the calibrated
data for the observation will automatically use the rollover file
instead of the default processing.
Convert raw counts to calibrated values
There are 8 values that make up the conversion between raw signal
count and calibrated signal value.
1. Electronics induced readout signal
2. CCD flat field
3. Calibration offset
4. Calibration gain
5. Integration time
6. Filter width
7. Pixel solid angle
8. Gain correction
The electronics induced readout signal is a base signal that does not
depend on integration time. It has been derived from studies of the
dark frames of flight data and is subtracted from the raw signal
count.
The CCD flat field is derived from laboratory data and refined with in
flight observation data. The flat field changes slightly as the
mission progresses so a different flat field can be defined for an
individual observation or a range of observations. The actual flat
field used in the processing is included in the output FITS file.
The calibration offsets and calibration gains are derived from
laboratory data and refined with in flight observation data. These
values can change as the mission progresses. Different calibration
values can be defined for an individual observation or a range of
observations. The actual calibration values used in the processing
are included in the output FITS file.
The integration time is divided into the calculated calibrated counts.
The filter width of each pixel is divided into the calculated calibrated counts.
The pixel solid angle is divided into the calculated calibrated counts.
The gain correction is divided into the calculated calibrated counts.
All of these values are derived from laboratory data and refined with
in flight calibration observation data. They are updated, as needed
an applied to the observation data automatically when re-processed
Compute pointing data
The pointing for each pixel of each frame is computed using the timing
information from the observation, reconstructed ephemeris and attitude
files, and knowledge of the optical distortion of the instrument. One
array is generated giving the cartesian pointing vector of each pixel
in the LEISA array. This is a function only of the optical distortion
of the system. A second array is generated giving the rotation
quaternion of the instrument boresight into the J2000 reference frame
for the middle of each exposure. By rotating the pointing vector of a
pixel by the quaternion for the image frame, the J2000 pointing vector
of each pixel can be derived
Construct FITS files
A FITS file is constructed to store all the calibrated image data and related processing data.
8.3.2 Dataflow Block Diagram
Figure 8-1: Dataflow Block Diagram
8.3.3 Data Format
Calibrated Dataset
The calibrated LEISA data are stored in Band Interleaved by Line (BIL)
order, exactly as the raw data is stored. The resulting frames from
LEISA have the (0,0,0) element of the 3-D array corresponds to the
location of wavelength 2.5 microns on the LEISA filter at the minimum X
axis location in the image in the first frame.
The calibrated data product is a FITS format data file and PDS
detached label file. Ancillary data for an observation is placed in
the primary header of the FITS data file. The 256X256XN data cube is
stored in the primary data unit as an array of floating point numbers.
The FITS extensions are outlined below.
Outline of the calibrated FITS file:
- Primary HDU - Calibrated image data
- Primary Header (FITS + pointing + observation keywords)
- 256 X 256 X N floating point array
- Extension 1 - Center wavelength and filter width for each pixel
- 256 X 256 X 2 floating point array
- Extension 2 - Cartesian pointing vector for each pixel
- 256 X 256 X 3 floating point array
- Extension 3 - Flat field correction for each pixel
- 256 X 256 X 1 floating point array
- Extension 4 - Radiometric gain and offset for each pixel
- 256 X 256 X 2 floating point array
- Extension 5 - Error estimates for each pixel
- 256 X 256 X 1 floating point array
- Extension 6 - Data quality flags for each pixel
- 256 X 256 X 1 Integer array
- Extension 7 - Ephemeris time and quaternion for each frame
- 5 X N floating point array
- Extension 8 - Binary table of Ralph housekeeping
- Ext. Header (keywords + binary table definition)
- Ext. Binary Table (115 X S binary table of Ralph housekeeping data)
*[N is the number of data image frames in the observation, S is the
number of seconds in the observation]
For a description of the contents of the FITS extension, see the above
section describing the SOC calibration processing.
Calibrated Image Data
The Image Data Unit of the Level 2 file contains data expressed in
physical units useful for scientific interpretation. The instrument
pipeline converts the data values of raw instrument counts to
radiance units, W/cm2/sr.
Data quality flags
The data quality flag is set if there is a known problem with the
given pixel.
Quality Flag Value Description
0 Good pixel
1 Defect in one of the calibration files
2 Flat field out of bounds
4 Known CCD defect
32 Bad pixel not in any of above categories
8.3.4 Extra FITS Extensions (planes) and Their Definitions
See above
8.3.5 Scientific Units
Radiometric units: W/cm2/sr
8.3.6 Additional FITS and PDS Keywords Added
See above
8.3.7 Hardware/OS Development Platform
The software for processing the raw and calibrated data files has been developed on the SOC computers, running GNU/Linux/i686 Version 2.6.17-1.2142_FC4.
8.3.8 Language(s) Used
The software for processing the raw data files is written in Python.
The software for processing the calibrated data files is written in C, with a Perl script wrapper.
8.3.9 Third Party Libraries Required
Python SPYCE interface library
Python MySQLdb interface library
Independent JPEG Group's JPEG software
CSPICE processing library
CFITSIO processing library
8.3.10 Calibration Files Needed (with Quantities)
The instrument software package will include additional datasets needed for calibrating the data. All The calibration software requires additional datasets needed for calibrating the data, as describe in the above sections. The instrument pipeline maintains version control on calibration datasets, as with calibration procedures. Some calibration files are associated with specific observations, some are associated with a range of observations.
The estimated number of calibration files needed for the mission is 300, totaling 3 GBs.
8.3.11 Memory Required
500MB
8.3.12 Temporary File System Space Needed
500MB
8.3.13 Predicted Size of Output File(s)
Up to 500MB
8.3.14 Predicted Execution time
Processing time for raw data files is approximately 3 seconds per image frame.
Processing time for calibrated data files is approximately .1 seconds per frame
8.3.15 Contact/Support Person(s)
Allen Lunsford
Dennis Reuter 301-286-2042
Donald Jennings 301-286-7701
Laddawan Miko 301-286-2166
8.3.16 Maintenance Schedule (Code/Data Updates, Documentation)
The LPS is installed by extracting files from an archive. The
sub-directory structure for the software package is created during
extraction. Symbolic links to external directories may be substituted
for default directory references. The shell for execution of the LPS
is tcsh/csh. Changes will be made to shell initialization files; new
elements are appended. Instructions for configuring the shell
environment are given. A guide to installation and setup is included
with the LPS package.
An initial period of testing and refinements is expected. Pieces of
the software are tested separately during development. LPS modules are
re-tested upon installation to the SOC. Sample datasets are provided
to verify the function of software. Integrated testing of the
instrument pipeline under the control of the SOC MDM is performed in
accordance with the SOC. The instrument software engineer is available
exclusively to the SOC to support the integration of pipeline
software.
Changes to calibration datasets are made as needed. A facility is
provided by the SOC so that software changes are reversible. A LEISA
team member will be available to assist SOC operators in responding to
unexpected errors in the instrument pipeline. Persons supporting the
LEISA Instrument Pipeline software are listed above.
The LEISA instrument pipeline is developed at GSFC. The first fully
functional version (v0) of the software is tested on the GSFC computer
system. In advance of completion of LPS v0, a skeleton software
package will be made available to the SOC. The skeleton software is a
callable code set which installs and functions as the instrument
pipeline but does not perform calibration and book keeping on
instrument data. Completion of software Version 0 encompasses the
creation of instrument calibration files. Documentation including
instructions for installation and setup will be delivered to the SOC
with Version 1 of the LPS. Updates of software after Version 1 are
performed on an as needed basis.
Table 8-1
Table 8-1
9. LORRI INSTRUMENT DESCRIPTION
9.1 Overview
The LOng Range Reconnaissance Imager (LORRI) is a narrow angle
(FOV=0.29degrees), high resolution (IFOV=5 microrad), Ritchey-Chretien
telescope
with a 20.8 cm diameter primary mirror, a focal length of 263 cm, and
a three lens field-flattening assembly. A 1024 x 1024 pixel (optically
active region), back-thinned, backside-illuminated CCD detector (model
CCD 47-20 from E2V) is located at the telescope focal plane and is
operated in standard frame-transfer mode. LORRI does not have any
color filters; it provides panchromatic imaging over a wide bandpass
extending approximately from 350 nm to 850 nm. The LORRI telescope has
a monolithic silicon carbide structure, built by SSG Precision
Optronics, Inc., is designed to maintain focus over the entire
operating temperature range (-125 C to +40 C) without a focus
adjustment mechanism. A detailed description of the design and
fabrication of LORRI can be found in the paper by Conard, et al.,
"Design and fabrication of the New Horizons Long-Range Reconnaissance
Imager" in SPIE proceedings 5906-49, 2005. A detailed discussion of
the performance of LORRI, as measured during calibration testing
before launch, can be found in the paper by Morgan et al.,
"Calibration of the New Horizons Long-Range Reconnaissance Image" in
SPIE proceedings 5606-49, 2005.
LORRI is a supplemental instrument on New Horizons and is not needed
to meet the baseline scientific objectives of the
mission. Nevertheless, LORRI adds significant capabilities to New
Horizons, including the highest available spatial resolution (50
m/pixel at the Pluto closest approach distance of 10,000 km) and
redundancy for the primary optical imager, MVIC on Ralph.
The exposure time for LORRI is adjustable in 1 msec increments from 0
ms to 29,967 msec. However, exposure times will normally be limited to
< 150 msec to prevent image smear associated with spacecraft motion
during observations. Initially, the shortest useful exposure time was
expected to be ~40 msec owing to frame transfer smear associated with
the transfer of charge from the active CCD region to the storage
region, during which time the active region remains exposed to the
image scene because LORRI has no shutter, but an improved frame
transfer smear removal algorithm was developed that now permits
exposure times as little as 1 msec. The LORRI exposure time can be
commanded to a specific value, or LORRI can be operated in
"auto-exposure" mode, in which the LORRI flight software sets the
exposure time automatically based on the signal level in a previous
image. In auto-exposure mode, the algorithm used to set the exposure
time depends on several adjustable parameters that are stored in an
onboard table. The optimal values for these table parameters vary with
the type of scene being observed, which means that new table loads may
be required prior to some observations. Although the LORRI
auto-exposure mode worked well during ground testing, no decision has
yet been made on whether it will be used in-flight during encounter
observations.
LORRI can also be operated in "rebin" mode, in which case the signal
in a 4 x 4 pixel region is summed on-chip to produce an active region
that is effectively 256 x 256 pixels covering the entire 0.29 degrees
FOV. The main purpose of this mode is to provide high sensitivity
acquisition of a Kuiper Belt object (KBO), which requires an exposure
time of ~10 sec. Although LORRI rebin mode may never be used for
science observations, the LORRI pipeline is still required to
calibrate rebinned images.
Figure 9-1: Cutaway Views of LORRI
9.2 Raw image Specifics
9.2.1 Data Format
The raw image data is organized in a FITS file. The primary header
9.and data unit (HDU) is used to store the reconstructed image from
9.telemetry. Additional data are stored in the extensions of the
9.file. The two tables below contain a description of the layout for
9.the extensions for raw data.
As described previously, LORRI operates in two binning modes: 1x1 and
4x4. For the 1x1 binning mode, the raw image dimensions are 1028x1024
where columns 0 through 1023 are the optically active region of the
CCD and the remaining columns (1024-1027) are from optically inactive
region (dark columns) of the CCD and represent a temperature-specific
measurement of the bias value. For the 4x4 binning mode, the raw
image dimensions ar 257 x 256 where columns 0 through 255 are
optically active and column 256 for the dark column.
Table 9-5
Table 9-5: Raw FITS file extension layout
9.2.2 Data Sources (High/Low Speed, CCSDS, ITF)
The LORRI high-rate data is delivered to the Instrument Interface card
over a low-voltage differential signal (LVDS) interface and is then
transferred to the SSR through the spacecraft high-speed PCI bus by
the C&DH software. The image data is stored directly on the SSR and
packets are generated by command to the C&DH software as is described
in the table below. The APID from which the image originated is part
of the filename, so this mapping may provide some assistance in
decoding the filenames retrieved from the SOC.
Table 9-6
Table 9-6: Low Rate Instrument Telemetry Description
Table 9-7
Table 9-7: LORRI high-speed telemetry description
9.2.3 Definition of an "Observation"
Each LORRI image is an "observation."
9.2.4 Housekeeping Needed in Raw Image Files (for Calibration)
No special requirements other than pointing
9.2.5 Raw Science Data and/or Housekeeping Requirements
No special requirements
9.3 Calibrated Image Specifics
9.3.1 Algorithms for Pipeline Calibration Process
The calibration of LORRI images potentially involves all of the
following steps:
1) Bias subtraction
2) Signal linearization
3) Charge transfer inefficiency (CTI) correction
4) Dark subtraction
5) Smear removal
6) Flat-fielding
7) Absolute calibration
Ground testing has demonstrated that the linearization, CTI, and dark
subtraction steps will not be needed, so they are not described
below. Nevertheless, the LORRI pipeline architecture will be
maintained to allow these additional steps to be incorporated quickly,
if in-flight data suggest they are needed.
The LORRI pipeline software consists of a series of IDL routines that
implement the above processing steps. In general, the IDL routines
have the following naming convention: lorri_function.pro, where
"function" refers to the specific task performed by that routine. (The
"pro" extension will be omitted below when discussing specific
routines.) Each routine typically has several command line arguments
and keywords that specify the input and output files and, possibly,
parameters for tailoring the routine for particular circumstances. The
routines that perform the bias subtraction, the smear removal, and the
flat-fielding are described below. No special routines are provided to
perform the absolute calibration. Instead, the absolute calibration is
performed using keywords provided in the FITS header, as described
further in Section 9.3.1.4.
9.3.1.1 Bias Subtraction
If an image has an associated "dark" image (i.e., an image taken with
the same exposure time but without any illumination), then the
debiased image is simply the difference of those two images. This was
usually the case during on-ground testing when images taken of a scene
were immediately followed by images taken with the scene blocked
(i.e., an obstruction was placed in the optical path to block the
illumination). However, in-flight images may often be taken without
accompanying darks either because of limitations on downlink
bandwidth, or because a decision is made to take more target images at
the expense of concurrent darks. In either case, the same pipeline
routine will be used to debias the image (lorri_debias), but the
algorithm employed is different in each case and different reference
files are required.
If in-flight data indicate that bias images are stable over time, many
bias images will be combined (after filtering out clearly discrepant
pixels) to produce a "super-bias" image. Then the median value of the
inactive region of the image (i.e., the median of a 1024 row by 4
column region) is subtracted from the super-bias image to produce a
"delta-bias" image. The IDL procedure that produces the delta-bias
image is called lorri_delta_bias, but this routine is not part of the
standard LORRI calibration pipeline; rather, it is an ancillary
routine used to produce a calibration reference file.
The delta-bias image will exhibit the pixel-to-pixel variation in the
bias and will oscillate about zero. The bias subtraction for any new
image is then a two-step process:
1) The median signal level in the inactive region of the image is
subtracted from each pixel's value to remove the overall
bias level, and
2) The delta-bias image is subtracted from the image created in
the previous step to remove the pixel-to-pixel variation and
produce the final, debiased image.
Ground calibration testing showed that the overall bias level in step
(1) above depends on the signal level in the last few columns of the
active region of the CCD. The effect is produced by amplifier
undershoot, which means that the bias level recorded by the pixels in
the inactive region is smaller than the actual bias level. The
magnitude of the effect depends on the signal level in the active
region and on the column number in the inactive region and can be as
large as ~12 DN. Thus, prior to computing the median signal in the
inactive region (step 1 above), the intensities of all the pixels must
be corrected for amplifier undershoot. This correction step is
incorporated into the lorri_debias procedure.
If the in-flight bias images vary significantly in time, separate bias
images (i.e., 0 ms exposures) must be taken for each science image
obtained. In this case, the bias subtraction proceeds exactly as
performed during ground calibration testing, with the bias removal
achieved by simple subtraction of the bias image from the science
image. There are several drawbacks to this approach: (1) more images
must be taken, which affects the data volume that must be stored on
the on-board solid-state recorder, (2) more data must be downlinked,
which may not be possible because of limited downlink bandwidth and/or
the cost associated with the extra Deep Space Network (DSN) support
required, (3) the signal-to-noise ratio (SNR) may be degraded because
the bias subtraction no longer involves a high SNR reference file, and
(4) fewer science images can be obtained because they have been
displaced in the observing timeline by extra bias images.
9.3.1.2 Smear Removal
LORRI does not have a shutter, so the target being observed
illuminates the active region of the CCD whenever LORRI is pointed at
the scene. In particular, the CCD continues to record the scene as the
charge is transferred from the active portion to the storage area, and
this results in a smearing of the observed scene. Fortunately, this
smear can be removed to high accuracy using the correction algorithm
described below.
When bright objects are observed, the readout smear makes the raw
image difficult to use for analysis purposes. In the image of Jupiter
below, the raw image is on the left and the calibrated image with
readout smear (aka frame transfer smear) removed is on the right.
Figure 9-8: Demonstration of Smear Removal
The need for the readout smear removal arises from the operation of
the frame transfer CCD used in LORRI, where first the image zone is
flushed, then an exposure is taken, and finally the image is
transferred into the storage zone. Hence a pixel of the raw image is
exposed to the scene radiance from the corresponding geometrical
element of the scene, but it is also exposed to the radiances of all
the scene elements in the same image column during the image
transfers. Thus the raw image is the superposition of the scene
radiance and the signal acquired during frame transfers, which is
called readout smear.
The readout smear is removed as follows.
Equation 9-1
Equation 9-1
The value for T_favg is dependent on the desired exposure time and has
been determined empirically using in-flight data. The following table
provides the appropriate values at different exposure times.
Table 9-9
Table 9-9 Value for T_favg from T_exp
It should be noted that when the raw data is saturated, the resulting
readout smear correction will be inaccurate. The algorithm relies on
an accurate accumulation of charge in all rows of each column and if
the raw data is clipped for lack of dynamic range to capture that
integrated signal, the effect of readout smear cannot be completely
and properly removed.
This correction algorithm has been implemented in the IDL routine
lorri_desmear.
9.3.1.3 Flat-Fielding
Flat-fielding refers to the process of removing the pixel-to-pixel
sensitivity variations in the image. An exposure obtained by
illuminating the LORRI aperture uniformly with light is called a
"flat-field" image. During ground calibration testing, flat-fields
were obtained by using an "integrating sphere to provide uniform
illumination. The light source was a xenon arc lamp with a spectrum
similar to that of the sun. The absolute intensity of the input
illumination was measured using a calibrated photodiode. For the
panchromatic case, which is the one most relevant for flat-fielding
LORRI images, the light from the xenon lamp was unfiltered. Flat-field
images were also obtained by passing the light through bandpass
filters centered at five different wavelengths spanning the range over
which LORRI is sensitive, prior to injection into the reference
sphere, in order to estimate the sensitivity of the flat-fields to the
spectral distribution of the source. The spatial patterns in the
flat-field images change fairly dramatically with wavelength. However,
the variation in panchromatic flat-fields caused by differences in the
spectral distribution of the illumination source should be much less
significant. Indeed, panchromatic flat-field images produced using a
tungsten lamp were virtually indistinguishable from those produced by
the xenon lamp. Flat-fields were obtained at four different telescope
temperatures (at standard laboratory room temperature, and at the
lowest, nominal, and highest temperatures predicted for in-flight
conditions), but no significant temperature variations in the
flat-field images were detected.
The flat-field reference file used in the LORRI pipeline was produced
by averaging 100 flat-field images taken at room temperature using the
xenon arc lamp as the light source, debiasing and desmearing the
average image as described earlier, and normalizing the intensities in
the active region to a median value of 1. If "S" (units are DN) is an
image of a target that has already been desmeared and debiased, and if
"FF" is the reference flat-field image, then the flat-fielded (i.e.,
photometrically-corrected) target image ("C"; units are DN) is given
by: C = S/FF
The flat-fielding correction is implemented in the LORRI pipeline by
the routine lorri_flatten.
If in-flight measurements indicate that the LORRI flat-field
characteristics are different than those measured during ground
calibration tests, new reference flat-field images must be
obtained. Although LORRI has two internal reference lamps (sometimes
referred to as "cal lamps"), the illumination pattern is highly
non-uniform and, thus, not very suitable as a secondary flat-field
standard. Various test measurements will be performed during the early
portion of the mission to determine if scattered sunlight can serve as
a suitable secondary flat-field standard. If there is a Jupiter
encounter, smeared images of Jupiter might also prove to be useful as
a secondary flat-field standard. In any case, there will be an attempt
to monitor the flat-field characteristics of LORRI over time, and the
reference flat-field image used by the LORRI pipeline will be updated
as necessary to maintain an accuracy better than 1% in the correction
of the pixel-to-pixel sensitivity variation, except possibly near the
center of the field where image ghosts may compromise the quality of
the reference flat-field (see further discussion below).
During ground calibration tests, intensity artifacts caused by optical
ghosts were observed near the center (roughly covering a 200 x 200
pixel region) of the flat-field images. Ray tracing of the optical
system indicates that the intensity of the ghost image should be less
than ~1% of the intensity produced by the direct illumination, but
measurements indicated that ghost intensities have an amplitude of
~5-7% of the direct intensity for panchromatic illumination. The ghost
intensity is scene-dependent with most (~80%) of the ghost signal
arising from regions outside the nominal field-of-view of LORRI. There
is a suspicion that at least some of the ghost signal is an artifact
of the test conditions, and the reference flat-fields currently used
by the pipeline do not include the ghost signal produced by the
out-of-field light. Any flat-field data taken in-flight will be
carefully scrutinized to search for any effects attributable to
optical ghosts. Depending on those results, further modifications to
the reference flat-fields may be required. There is also the
possibility that different flat-field reference images may be required
depending on the scene being imaged (i.e., a ghost subtraction step
may be required prior to application of the flat-field correction
under some circumstances).
9.3.1.4 Absolute Calibration (Conversion from corrected DN to
physical units)
The calibration software pipeline does not perform the conversion from
DN to physical units because that conversion requires knowledge of
the spectral distribution(i.e. color) of the target. Instead, various
LORRI FITS header keywords ("photometry" keywords) are provided that
allow users to convert from DN to physical units depending on the
spectral type and spatial distribution (diffuse vs. point source) of
the target.
Photometry keywords are provided for targets having spectral
distributions similar to Pluto, Charon, Pholus, Jupiter, and the
Sun. The units adopted for the radiance (aka "intensity") of diffuse
targets are ergs/cm2/s/sr/Angstrom. The units adopted for the irradiance (aka
"flux") of point (i.e., unresolved) targets are ergs/cm2/s/Angstrom. Tables
providing the values for the photometry keywords at the time of launch
are given below. The latest (i.e., current) values of the photometry
keywords are provided in the header of the calibrated image FITS file
for the image being analyzed.
The absolute calibration is achieved by specifying a keyword (RPLUTO)
in the header of the calibrated image file that allows the user to
convert a count rate ("C/TEXP" in DN/s/pixel, where "C" is the
flat-fielded signal in a pixel and "TEXP" is the exposure time) for a
resolved source into a radiance value ("I" in ergs/cm2/s/sr/Angstrom) at
LORRI's pivot wavelength (specified by the FITS keyword PIVOT; see
below), assuming that the spectrum of the target is identical to the
globally-averaged spectrum of Pluto. The relevant formula is:
I = C/TEXP/RPLUTO
Similarly, the keyword RSOLAR allows the conversion of the count rate
for a resolved source into a radiance value at the pivot wavelength
assuming that the target has a solar-like spectral distribution:
I = C/TEXP/ RSOLAR
Finally, the keyword RPHOLUS allows the conversion of the count rate
for a resolved source into a radiance value at the pivot wavelength
assuming that the target has a spectral distribution identical to that
of the centaur object 5145 Pholus, which may be a good analog for the
reddest regions on Pluto:
I = C/TEXP/RPHOLUS
The current best estimates for these sensitivity keywords, based on
ground calibration tests, are provided in the table below. In-flight
calibration observations of photometric standard stars will be used to
verify these values and to monitor them over time.
Keyword Value [(DN/s/pixel)/(ergs/cm^2/s/sr/Angstrom)]
RSOLAR 2.664 x 10^5
RPLUTO 2.575 x 10^5
RCHARON 2.630 x 10^5
RJUPITER 2.347 x 10^5
RPHOLUS 3.243 x 10^3
If users need conversions for other spectral distributions, they must
derive those themselves using the LORRI spectral response function
provided in the paper describing LORRI's in-flight calibration
results.
The pivot wavelength (PIVOT) is given by Equation 9-2, where "P" is
Equation 9-2
the LORRI system quantum efficiency (i.e., fraction of photons
detected) at wavelength " lambda". The current best estimate for the
LORRI pivot wavelength is 6076 Angstroms.
For unresolved sources (e.g., stars), the absolutely calibrated flux
(also called "irradiance") at the pivot wavelength can be determined
using keywords that are defined analogously to the photometry keywords
discussed above for resolved sources. In the case of a source having a
spectral distribution identical to that of a globally-averaged Pluto
spectrum, the observed count rate integrated over the LORRI PSF
("CINT/TEXP" in DN/s, where CINT is the total number of flat-field
corrected counts integrated over the image and "TEXP" is the exposure
time) can be related to the flux ("F" in ergs/cm2/s/Angstrom) by:
F = CINT/TEXP/PPLUTO
Similarly, the flux at the pivot wavelength for a target having the
same spectral distribution as the sun is given by:
F = CINT/TEXP/PSOLAR
And the flux at the pivot wavelength for a target having the same
spectral distribution as 5145 Pholus is given by:
F = CINT/TEXP/PPHOLUS
The current best estimates for these sensitivity keywords, based on
ground calibration tests, are provided in the table below. In-flight
calibration observations of photometric standard stars will be used to
verify these values and to monitor them over time.
Keyword Value [(DN/s)/(ergs/cm2/s/Angstrom)]
PSOLAR 1.066 x 10^16
PPLUTO 1.030 x 10^16
PCHARON 1.052 x 10^16
PJUPITER 9.386 x 10^16
PPHOLUS 1.297 x 10^16
Synthetic photometry techniques can be used to convert the fluxes
derived in the manner described above to fluxes at other wavelengths,
and then into standard UBVRI magnitudes in the Landolt (1992)
photometric system, which is essentially identical to the Johnson UBV
system combined with the Kron-Cousins RI system. The results described
in the LORRI calibration paper can be used to derive fluxes for
targets whose spectral distributions do not match the three cases
discussed above.
We provide below some examples showing how to convert from engineering
units to physical units, for both diffuse and point targets.
Consider a diffuse target whose spectrum is similar to that of
Pluto. You should then use the RPLUTO photometry keyword in the header
of the calibrated image file to convert a count rate ("C/TEXP" in
DN/s/pixel, where "C" is the flat-fielded signal in a pixel and "TEXP"
is the exposure time) into a radiance value ("I" in ergs/cm2/s/sr/Angstrom)
at LORRI's "pivot" wavelength (specified by the FITS keyword PIVOT for
the formal definition of the pivot wavelength):
I = C/TEXP/RPLUTO
Similarly, the photometry keywords RSOLAR, RCHARON, RJUPITER, and
RPHOLUS should be used to convert count rates into radiance values at
the pivot wavelength assuming that the target has, respectively,
solar-like, Charon-like, Jupiter-like, or Pholus-like spectral
distributions.
For LORRI, the pivot wavelength is 6076.2 Angstroms, and we don't expect this
to change, at least not significantly. Since the solar flux (F_solar)
at a heliocentric distance of 1 AU at the pivot wavelength is 176
erg/cm2/s/Angstrom, the value for the radiance can be converted to I/F (where
pi*F = F_solar) using:
I/F = pi * I * r^2 / F_solar
where "r" is the target's heliocentric distance in AU.
For unresolved targets (e.g., stars), the absolutely calibrated flux
(also called the "irradiance") at the pivot wavelength can be
determined using keywords that are defined analogously to the
photometry keywords discussed above for resolved targets. In the case
of a target having a spectral distribution identical to that of a
globally-averaged Pluto spectrum, the observed count rate integrated
over the LORRI PSF ("CINT/TEXP" in DN/s, where CINT is the total
number of flat-field corrected counts integrated over the image and
"TEXP" is the exposure time) can be related to the flux ("F" in
ergs/cm2/s/Angstroms; not to be confused with "F" in I/F) by:
F = CINT/TEXP/PPLUTO
When observing point targets, it is more common to convert the
absolute flux to a magnitude in a standard photometric system. The
following equation can be used to transform a measured value of the
irradiance (aka "flux") of an unresolved target to a magnitude in the
standard V band:
V = -2.5 log S + PHOTZPT + CC + BC
where "V" is the visual magnitude in the Johnson photometric system,
PHOTZPT is the "stellar photometry keyword", which is the "zero point"
of the LORRI instrumental magnitude system, "S" is the integrated net
signal rate from the target in DN/s, "CC" is the color correction
(i.e., correction for the spectral distribution of the target), and
"BC" is the aperture correction (in case the flux is not integrated
over the entire stellar image; a careful analysis of the flux versus
aperture size for a bright star in the field can then be used to
determine the value of BC for the aperture selected for the
photometry).
In-flight photometry of stars in the open galactic cluster M7 yield
the following:
PHOTZPT = 18.94
Table 9-10
Table 9-10: Color correction coefficient for various targets
The following reference flux information is provided for convenience
and was gathered from several sources. The UBV are in the Johnson
system, RI are in the Landolt-Kron-Cousins system, and JHK_sK are in
the UKIRT system.
The fluxes for Vega are from the model STScI absolutely-calibrated
spectrum. At near-IR wavelengths, the model underestimates the actual
Vega flux by about 5-6% owing to the excess flux from the Vega dust
disk. Note also that Vega has U=B=V=0.03 (i.e., not 0).
Table 9-11
Table 9-11 Fluxes for Vega
9.3.1.5 Pointing Information
Pointing information for the LORRI boresight (center of the LORRI
field-of-view, which is pixel [511,511]) is included in the FITS
header in both the raw and the calibrated image files. An example of
this information follows:
SPCBLRA = 233.4199004768138 / [degrees] Boresight RA, EME J2000
SPCBLDEC= -17.96897170490819 / [degrees] Boresight DEC, EME J2000
SPCEMEN = 283.935414259362 / [degrees] EME J2k North Clk Angle, CW
from UP
9.3.1.6 Conversion of instrument housekeeping items to engineering units
The LORRI-specific housekeeping items reported in the raw FITS file
are in units of counts or DN. To make these values more useful for
data analysis, they have been converted to engineering units (volts,
amps, degrees Celsius) and reported at the tail end of the header of
the primary HDU of the calibrated FITS file. Because the contents of
the raw header are duplicated in the calibrated file, a different set
of tag names are used for the values that have been converted to
engineering units. The new tags are reported after the comment that
reads "LORRI Level 2 Calibrated telemetry items".
9.3.2 Instrument Characterization
There are several characteristics of the instrument that are related
to the radiometric calibration of LORRI that will be useful when
analyzing the calibrated image data. They are the quantum efficiency
and spectral responsivity, each as a function of wavelength. There
are tables for each of these in the calibration directory for the PDS
archive, but a graph for each is reproduced in the figures below.
Figure 9-2: LORRI Spectral Response vs Wavelength
Figure 9-3: LORRI Quantum Efficiency vs Wavelength
After the data have been calibrated, additional processing steps are
likely to be required. Obvious examples of this are ghost removal and
stray light processing. At present, there have been no algorithms
developed for public release because they are highly scene dependent.
Individual images must be analyzed to understand the structure of the
effects to determine an appropriate method for its removal. In the
example below, a cutout from a calibrated image is presented to
illustrate the effect of stray light from Jupiter's disk, which is
just out of the field of view. The circular structure is an example
of the ghost pattern. The image on the right demonstrates the
processed version of that image. The gradient from the stray light has
been removed, as well as the majority of the effects of the ghost.
Figure 9-4 Example of Special Processing of Calibrated Data
9.3.4 Dataflow Block Diagram
Figure 9-5
9.3.5 Data Format
The calibrated image data is organized in a FITS file. The primary
header and data unit (HDU) is used to store the calibrated image that
results from the calibration pipeline. The first extension is the
error estimate image, followed by the second extension containing the
data quality image. The table below contains a description of the
layout for the extensions for calibrated data.
For 1x1 binning mode, the calibrated image dimensions are 1024x1024,
and for 4x4 mode, the dimensions are 256x256 pixels. In both
situations, these pixels correspond to the optically active pixels
from the raw image mentioned previously.
Table 9-12
Table 9-12 Calibrated FITS file extension layout
LORRI calibrated FITS files have 3 extensions. The debiased, desmeared
LORRI image is written into the primary HDU as a 2-dimensional, 32-bit
real image. The unit for each data value is photometrically-corrected
DN. The estimated errors in these corrected DN values are stored as a
2-dimensional, 16-bit real image in the first extension. A data
quality image is stored in the second extension as a 2-dimensional,
16-bit integer image.
The error in the photometrically-corrected signal is estimated from
Equation 9-3, where "sigma" is the 1-sigma error in the corrected signal
Equation 9-3
for a particular pixel (DN), "Pmeas" is the observed signal in that
pixel (DN, after bias subtraction but before smear removal), "g" is
the electronics gain (22 e/DN), "RN" is the electronics noise (1.3
DN), "f" is the estimated error in the reference flat-field image
(0.005), and "FF" is the value of the reference flat-field image at
the relevant pixel. The above formula neglects any noise contributed
by the bias and smear removal steps, but those errors are generally
expected to be small compared to the other sources of error.
The data quality image is used to flag pixels that have known
artifacts and may need special consideration when performing
scientific analysis. The pixel value in the quality flag image
represents the sum of all quality flags present for that pixel. This
pixel value can also be described as the result of the bitwise 'OR' of
each quality flag value. The list of data quality values and their
descriptions are listed in Table 9-13.
Table 9-13
Table 9-13 Quality flag value descriptions
9.3.7 Scientific Units
Following the convention adopted by the New Horizons Principal
Investigator, the unit used for calibrated data product are
"photometrically-corrected DN". The procedure given above must be
completed to obtain absolutely calibrated data products. The units
adopted for the radiance ( aka "intensity") of diffuse targets are
ergs/cm2/s/sr/Angstroms. The units adopted for irradiance (aka "flux") of
point (i.e. unresolved) targets are ergs/cm2/s/Angstroms. Wavelengths are
quoted in angstrom units.
9.3.8 Additional FITS and PDS Keywords Added
Listed below are the keywords and sample values for those keywords
that have been added to the FITS header and are stored with the
primary HDU of the output calibrated image FITS file.
COMMENT *********************************************************
COMMENT *** LORRI Level 2 software name and version info ***
COMMENT *********************************************************
L2_SWNAM= 'lorri_level2_pipeline' /Level 2 calibration software
L2_SWVER= 'untagged' /software version tag
COMMENT *********************************************************
COMMENT *** LORRI Level 2 software logic flow control flags ***
COMMENT *********************************************************
IMGSUBTR= 'OMIT ' / image subtraction step
BIASCORR= 'PERFORM ' / bias subtraction step
SLINCORR= 'OMIT ' / signal linearization step
CTICORR = 'OMIT ' / charge transfer inefficiency step
DARKCORR= 'OMIT ' / dark subtraction step
SMEARCOR= 'PERFORM ' / smear removal step
FLATCORR= 'PERFORM ' / flat-fielding step
GEOMCORR= 'OMIT ' / geometric correction step
ABSCCORR= 'PERFORM ' / absolute calibration step
COMPERR = 'PERFORM ' / compute error estimate
COMPQUAL= 'PERFORM ' / compute quality flags
COMMENT *********************************************************
COMMENT *** LORRI Level 2 Reference Filename ***
COMMENT *********************************************************
REFDEBIA= 'sap_006_combined_100img_1x1.fit' / debias image filename
REFFLAT = 'cflat_grnd_SFA_20050309_v2.fit' / flat field image filename
REFDEAD = 'dead_ground_1x1_synthetic.fit' / dead pixel image filename
REFHOT = 'hot_ground_1x1_synthetic.fit' / hot pixel image filename
REFSUBIM= ' ' / subtraction image filename
COMMENT *********************************************************
COMMENT *** LORRI Level 2 Absolute Calibration Parameters ***
COMMENT *********************************************************
PIVOT = 6076.20019531 / LORRI pivot wavelength. units=angstroms
RSOLAR = 266400.000000 / Conv to radiance for solar source
RPLUTO = 257500.000000 / Conv to radiance for pluto source
RPHOLUS = 324300.000000 / Conv to radiance for 5145 pholus source
RCHARON = 263000.000000 / Conv to radiance for charon source
RJUPITER= 234700.000000 / Conv to radiance for jupiter source
PPLUTO = 1.03000005170E+16 / Conv to irradiance for pluto source
PSOLAR = 1.06600003807E+16 / Conv to irradiance for solar source
PPHOLUS = 1.29700002225E+16 / Conv to irradiance for 5145 pholus source
PCHARON = 1.05199994793E+16 / Conv to irradiance for charon source
PJUPITER= 9.38600033786E+15 / Conv to irradiance for jupiter source
PHOTZPT = 18.9400000000 / Zero point for visual magnitude, V
COMMENT *********************************************************
COMMENT *** LORRI Level 2 Calibrated telemetry items ***
COMMENT *********************************************************
EPU_P5VO= 5.04305504857 / EPU +5 voltage. units=Volts
EPU_P5CU= 0.143143000000 / EPU +5 current. units=Amps
FPU_P15V= 15.0005851594 / FPU +15 voltage. units=Volts
FPU_P15C= 0.0493827000000 / FPU +15 current. units=Amps
FPU_P6_V= 6.05666080780 / FPU +6 voltage. units=Volts
FPU_P6_C= 0.152152000000 / FPU +6 current. units=Amps
FPU_HTRC= 0.00000000000 / FPU heater current. units=Amps
EPU_25PV= 2.50943456804 / EPU +2.5 voltage. units=Volts
RINGTEMP= -66.8836898878 / Intermediate ring temp. units=celsius
MFOOTTMP= -61.8964797242 / Mounting foot-top temp. units=celsius
M2MNTTMP= -66.8836898878 / M2 mirror mount temp. units=celsius
RADTEMP = -88.9564863168 / Radiator temp. units=celsius
BAFATEMP= -62.9653774259 / Baffle-aft temp. units=celsius
BAFFTEMP= -70.8007466057 / Baffle-forward temp. units=celsius
M1SUPTMP= -67.2398321861 / M1 mirror support temp. units=celsius
M1MIRTMP= -66.5275372052 / M1 mirror temp. units=celsius
CCDTEMP = -79.5485000000 / CCD temperature. units=celsius
M1VFTEMP= -66.0128183000 / M1 V/F temperature. units=celsius
M2VFTEMP= -66.3287025000 / M2 V/F temperature. units=celsius
FPUBTEMP= 29.5499120000 / FPU board V/F temp. units=celsius
STEMPCVR= 'ENABLE ' / Temperature conversion enable
SCLMP2PE= 'OFF ' / Cal lamp 2 power enable
SCLMP1PE= 'OFF ' / Cal lamp 2 power enable
SSOURCE = 'CCD ' / Image source
SFORMAT = '1X1 ' / Image format
SEXPMODE= 'MANUAL ' / Exposure mode
PDUNAME = 'Level 2 LORRI image' /
9.3.8.1 Reading FITS file contents using IDL
The main method for accessing the various extensions and headers from
the FITS file within IDL rely on a third-party library known as the
Goddard Astron library. From within IDL, one can load the primary HDU
from a fits file using the following command:
IDL> calimg=readfits('lor_0035015237_0x630_sci_1.fit', hdr )
IDL> help, calimg
CALIMG FLOAT = Array[1024, 1024]
The return value of this function ("calimg") is a two dimensional
array containing the image data from the primary HDU and its type
depends on the data that is read from the file. In the case of raw
data, it will be a 16-bit integer array and for calibrated data, it
will be a 32-bit floating-point array. The first argument in the call
to readfits() is the name of the FITS file to be read. The second
argument is an ASCII string variable that will contain the FITS header
for the primary HDU upon completion of the function.
The same function may be used in order to read any of the extensions
listed in the files. For example, to read the data quality image from
the calibrated FITS file, one would use a statement such as:
IDL> quality=readfits('lor_0035015237_0x630_sci_1.fit', hdr2,
exten_no=2)
IDL> help, quality
QUALITY UINT = Array[1024, 1024]
In this example, the ASCII string variable "hdr2" contains the FITS
header associated only with the second extension and has no portion of
the header from the primary HDU.
9.3.9 Hardware/OS Development Platform
The pipeline software was developed in a variety of environments with
the commonality of unix-style operating systems. There are no
dependencies on the endian properties of the environment.
9.3.10 Language(s) Used
IDL
9.3.11 Third Party Libraries Required
There are two third party IDL libraries that are needed by the
calibration pipeline software:
1) Goddard Astron library, which contains routines needed to read
and write FITS files, the format used by the raw data files.
Because this library is provided by the SOC for use by many
instruments, we will not be delivering this library, but
will rely on the version provided to us.
2) IDLUSR, a collection of useful IDL routines made available for
public release at APL. Information about this library can
be found at http://fermi.jhuapl.edu/s1r/idl/idl.html
9.3.12 Calibration Files Needed (with Quantities)
There are currently five categories of reference files needed to
perform the calibration process. The reference image categories are
the delta-bias, flat-field, dead pixel, hot pixel and desmear
e-matrix. Because the LORRI instrument can produce images in either
1024 x 1024 mode or 256 x 256 mode, there are two varieties of each of
these images. The filenames associated with these images will be
obvious by inspection, although no formal file naming convention has
been adopted.
There are two ASCII description files in the calibration directory
that don't qualify as calibration files but are related to the
operation of the pipeline. The first is a configuration file that
details all of the configuration parameters for the pipeline
("default_config.txt"). The other file is a description of the
housekeeping items that are stored in the first 34 pixels (51 bytes)
of the raw image data ("binary_lorri_image_hdr.txt"). These values
can be used to validate the FITS header tags that were produced by
associating the high-speed image data with the low-speed telemetry
values. The values in the first 34 pixels are guaranteed to be
correctly associated with a particular image (provided the were not
compressed in a lossy fashion) because the LORRI ASE put them in place
prior the transfer of the image data to the SSR. As such, they
represent a valuable check of the telemetry processing performed on
the ground after receipt.
The following is a table of the types of files in the calibration
directory:
Table 9-14
Table 9-14
9.3.13 Memory Required
~ 100 MiB
9.3.14 Temporary File System Space Needed
None
9.3.15 Predicted Size of Output File(s)
Table 9-15
Table 9-15
9.3.16 Predicted Execution time
Less than 30 seconds per image.
9.3.17 Contact/Support Person(s)
Raw data support: Howard Taylor, John Hayes, and Hal Weaver
Calibrated data support: Howard Taylor and Hal Weaver
9.3.18 Maintenance Schedule (Code/Data Updates, Documentation)
As in-flight calibration data are collected and analyzed, certain
aspects of the calibration pipeline will require updates, either in
the form of updated reference files, or updated code for bug fixes or
future improvements.
9.4 References
A. F. Cheng, H. A. Weaver, S. J. Conard, M. F. Morgan, O. Barnouin-Jha, J. D. Boldt, K.
A. Cooper, E. H. Darlington, M. P. Grey, J. R. Hayes, K. E. Kosakowski, T. Magee1 E.
Rossano, D. Sampath, C. Schlemm, H. W. Taylor, "LONG-RANGE
RECONNAISSANCE IMAGER ON NEW HORIZONS", in Space Science Review, in
press(2007)
S. Conard, F. Azad, J. Boldt, A. Cheng, K. Cooper, E. Darlington,
M. Grey, J. Hayes, P. Hogue,
K. Kosakowski, T. Magee, M. Morgan, E. Rossano, D. Sampath,
C. Schlemm, and H. Weaver, "Design
and fabrication of the New Horizons Long-Range Reconnaissance Imager,"
in Astrobiology and Planetary
Missions, G. R. Gladstone, ed., Proc. SPIE 5906, 2005.
F. Morgan, S.J. Conard, H.A. Weaver, O. Barnouin-Jha, A.F. Cheng,
H.W. Taylor, K.A. Cooper, R.H. Barkhouser, R. Boucarut,
E.H. Darlington, M.P. Grey, I. Kuznetsov, T.J. Madison, M.A. Quijada,
D.J. Sahnow, and J.M. Stock, "Calibration of the New Horizons
Long-Range Reconnaissance Imager," in Astrobiology and Planetary
Missions, G. R. Gladstone, ed., Proc SPIE 5906, 2005.
10. MVIC INSTRUMENT DESCRIPTION:
10.1 Overview
The Ralph instrument consists of two sets of focal planes: MVIC a
visible, near-IR imager and LEISA, a short-wave IR spectral imager.
This document only relates to the MVIC (Multispectral Visible
Imaging Camera) part of the Ralph instrument. The LEISA pipeline
is described in a different document (New Horizons SOC to
Instrument Pipeline ICD LEISA Edition). There are 7 separate CCD
arrays in the MVIC focal plane. The MVIC telemetry is communicated
via a low-speed interface and the imaging data uses a high-speed
interface.
Figure 10-1 shows a model of Ralph in the spacecraft coordinate
system. The MVIC detector package is the light blue box on the +Y
face of the instrument.
Data recorded on New Horizons is sent to the ground via the Deep Space
Network. From there the data is sent to the Mission Operations Center
(MOC) at the Applied Physics Laboratory (APL). The Science Operations
Center (SOC) retrieves new data from the MOC daily. The data is in a
raw form (packetized). The Level 1 and 2 software pipelines convert
the data from these raw packets into FITS (Flexible Image Transport)
files with scientifically useful and calibrated data. The Level 1
processing sorts the packets into images (in the case of MVIC) with
useful header keywords. These keywords include the mode or filter of
the observation, timing information and basic pointing information of
the instrument boresight. The Level 1 processing also adds relevant
housekeeping telemetry (temperatures, voltages, etc.) in a binary
table as an extension to the FITS file. The Level 2 processing
performs the basic scientific calibration.
Before we get into a description of the MVIC calibration, we will
describe the image formats for each of the CCD arrays that comprise
MVIC. There are 8 detectors in the Ralph instrument. Seven of those
are part of MVIC (the yellow and blue ones). The boresight information
in the figure is from ground-testing and will change in the future.
Figure 10-2
The "Pan Frame" array (yellow) has 5024x128 pixels. The first and
last 12 pixels in each row are not optically active. When observing
with the pan frame array, multiple images are recorded in each
observation. Correspondingly, we store these images together in one
FITS file. The first three letters of these files are "mpf" standing
for MVIC pan frame. The images are stored as an image cube
(3-dimensions). The first dimension is the column number, the second
dimension is the row number and the third dimension is the image
number within that observation.
The remaining 6 arrays are operated in a time-delay integration mode
(TDI). These arrays have 5024x32 pixels. The first and last 12 pixels
in each row are not optically active. To take an observation with the
TDI arrays, we scan the spacecraft and (typically) clock the charge
through each of the 32 rows at a rate that matches the spacecraft's
scan rate. Using this method we can build up arbitrarily long images
in the row direction. For the "Pan 1" and "Pan 2" (panchromatic --
unfilterred) detectors, the resulting FITS files are standard
2-dimensional images The first three letters of these files are either
"mp1" or "mp2" corresponding to MVIC pan 1 or MVIC pan 2. The color
arrays (NIR, CH4, Red and Blue) are operated together and they use a
time-delay integration to build up images. The data for each filter
is stored in separate FITS files.
In the table below the variable "Ni" stands for the number of images
in a pan frame observation. When we command a pan frame observation,
we always take multiple images. The "Nr" in the table is the number
or rows in an observations. This is determined by the length of time
that we are recording data and the rate that we clock the rows in TDI
mode.
Table 10-2
Table 10-2 Observation Modes and their filename prefixes and
data dimensions (top)
Table 10-2 Pan Frame Image Data Format (bottom)
The Level 2 FITS file has a primary data unit which contains the
bias-subtracted, flattened image (or image cube in the case of pan
frame) plus 4 extensions. Extension 1 is the bias-subtracted,
flattened, distortion-removed image (or image cube). Extension 2 is an
array with the per pixel error of the bias-subtracted, flattened,
distortion-removed image (or image cube). Extension 3 is an array with
a data quality flag for each pixel of the bias-subtracted, flattened,
distortion-removed image (or image cube).
Table 10-3
Table 10-3 TDI Image Data Format
10.2 Level 1 Specifics
10.2.1 Data Format
The Level 1 MVIC files will be FITS files. Details of the dimensions
10.of the FITS images and header keywords are given in the following
10.sections.
10.2.2 Data Sources (High/Low Speed, CCSDS, ITF)
MVIC telemetry data are recorded using the low-speed interface and
images are recorded with the high-speed interface. There are four
Ralph-MVIC data formats:
A. MVIC Panchromatic TDI (Time-Delay Integration) Format
B. MVIC Panchromatic TDI Binning Format
C. MVIC Color TDI Format
D. MVIC Frame Format
Note the distinction between "format" and "mode" is a hold over from
the spacecraft to Ralph ICD where the LEISA component of Ralph has
multiple modes for one format. The MVIC Panchromatic TDI format has
two modes (either "Pan 1" or "Pan 2" indicating which detector was
used). The MVIC Panchromatic TDI binning format is obsolete and is
not being supported at this time. The remaining two formats each have
only one mode.
The columns in Table 10-4 list the MVIC ApIDs and their corresponding
data types. For each data type there are two ApIDs, one for each C&DH
(Command and Data Handling) system on the spacecraft.
Table 10-4
Table 10-4: ApID and Data Type for MVIC Data
*Note that the Panchromatic TDI Binned data is 3x1 binning in the
cross-track direction with 2 out of 3 along-track lines discarded.
Note there is not a different ApID for PAN1 and PAN2 observations.
This information is stored in the low-speed housekeeping data (keyword
MODE). This information is inserted into the FITS header of the Level
1 FITS file. A value of 3 means that the observation was taken with
the "Pan 1" array and a value of 4 indicates the "Pan 2" array was
used. For more information, see the Ralph Users Manual.
The Pan Frame detector has 5024x128 pixels. The first and last 12
pixels in each row are not optically active. When observing with the
pan frame array, multiple images are recorded in each
observation. Correspondingly, we store these images together in one
FITS file. The first three letters of these files are "mpf" standing
for MVIC pan frame. The images are stored as an image cube
(3-dimensions). The first dimension is the column number, the second
dimension is the row number and the third dimension is the image
number within that observation.
The remaining 6 arrays are operated in a time-delay integration mode
(TDI). These arrays have 5024x32 pixels. The first and last 12 pixels
in each row are not optically active. To take an observation with the
TDI arrays, we scan the spacecraft and (typically) clock the charge
through each of the 32 rows at a rate that matches the spacecraft's
scan rate. Using this method we can build up arbitrarily long images
in the row direction. For the "Pan 1" and "Pan 2" (panchromatic --
unfilterred) detectors, the resulting FITS files are standard
2-dimensional images The first three letters of these files are either
"mp1" or "mp2" corresponding to MVIC pan 1 or MVIC pan 2. The color
arrays (NIR, CH4, Red and Blue) are operated together and they use a
time-delay integration to build up images. The data for each filter is
stored in separate FITS files.
10.2.3 Definition of an "Observation"
For this ICD and as is consistent with the "New Horizons Spacecraft to
PERSI/RALPH Interface Control Document", an "observation" is a
coherent sequence of data-taking operations, with data reported over
the high-speed telemetry interface conducted automatically after being
initiated by telecommands from the C&DH system. The observation may
end automatically, or may run until a telecommand ends it.
All observations consist of one or more "frames." A "frame" is the
amount of high-speed image data between returns of the +frame signal
to the high state. All frames consist of a sequence of "words". A
word is a pixel and is 12 bits in length.
10.2.4 Housekeeping Needed in Level 1 Files (for Calibration)
There are some housekeeping values that we need to track for the
health of MVIC and to assess the data quality. We need to monitor
these keywords during Ralph observations. The Ralph telemetry will be
sent each second during an MVIC observation and these keywords will be
stored as a binary table in EXTENSION 1 of the Level 1 FITS file.
They will be used to set the data quality flag if the value exceeds
its yellow limit. The red and yellow limits in Table 10-1 are
pre-launch limits and will be updated as needed.
Table 10-1
Table 10-1: Housekeeping Limits (pre-launch)
There are no additional raw science data requirements beyond those
already specified.
Ralph housekeeping data are stored in a binary table extension.
Ralph specific keywords in the Level 1 file are given in the following Table.
Keyword Description
MET510 the MET of the Ralph 0x510 packet that marks the start of an
observation
TRUE510 Is the 0x510 real or assumed from a gap?
RALPHEXP RALPH exposure time (s)
MODE Instrument mode
SIDE Instrument HW side
FILTER CCD filter color, Only in MVIC Color FITS files
PANCCD Pan CCD used (1 or 2), Only in MVIC Panchromatic TDI FITS files
For the MVIC pan frame data, the standard keywords describing the
pointing and mid-exposure time are repeated for each image in the
image cube.
10.3 Level 2 Specifics
10.3.1 Algorithm for Pipeline
There are five processing steps applied to the Level 1 MVIC data to
10.produce the Level 2 output:
7. Remove bias and flat-field pattern
8. Correct for a geometric distortion
9. Convert from DN to physical units
10. Calculate error for each pixel and construct the error array in a new extension
11. Construct data quality extension.
Note there will not be any correction for scattered light (at least
initially) in the Level 2 products. A complete assessment of the
scattered light field will be made in flight, and corrections will be
implemented if necessary. Also, there is no correction for cosmic
rays in the Level 2 product.
We do not apply the Level 2 calibrations to the non-optically active
pixels of the detector to maintain our high-speed header data which is
encoded in some of these pixels.
10.3.1.1 Remove bias and flat-field pattern
First, the removal of the bias level and flat-field pattern for the
framing array will be discussed, and then we will address
modifications for the TDI modes.
For the "Pan Frame" data, we use the shielded pixels on both sides of
the array to compute the row-by-row bias. For column numbers 12 to
2511 (the active area on the left half of the chip), the bias is the
median of pixels in columns 2 to 11 (inclusive and
zero-based). Similarly, the bias for pixels from column numbers 2512
to 5011 (the active area on the right half of the chip) comes from the
shielded pixels in columns 5012 to 5021 (inclusive and zero-based). We
do not include the pixels closest to the edge of the array as they
contain the high-speed header information.
For the TDI mode, only pixels on one side of the image would be usable
as bias level. The others are used for charge injection and do not
represent the bias level. However, if we only use pixels from one
side of the array we do not get a good model of the bias level.
Instead we assume a fixed value of 24 DN for the bias level for all
TDI arrays.
The correction for the bias level and flat-field pattern are described
here. Let B be the bias level, R is the raw image, and F is the
normalized flat-field image:
We calculate the corrected image, R_f in Equation 10-1.
Equation 10-1
The name of the flat field file used will be stored in the header
keyword FLAT. The naming convention for the flats will be unique.
Each file name will contain the name of the array as well as the date
(i.e. "flat_mvic_pan1_20050612.fits" or
"dark_mvic_colorBlue_20050612.fits").
For our purposes, the dark current is expected to be negligible.
For the TDI exposures, the flat field image is one-dimensional since
each pixel in a given column is clocked through all 32 rows before
being read out. This one-dimensional flat field has the dimensions of
a single row in the TDI image. Instead of dividing the TDI image by a
two-dimensional normalized flat, we will be dividing each row by the
normalized (1-dimensional) flat. There will be 6 different flat-field
one-dimensional arrays: 4 color and 2 panchromatic. There will only
be one 2-D flat field image (for the framing array).
The function that constructs the flattened, bias-subtracted image
(Eq. 2) is called mvic_flatten. The function will determine what
imaging mode was used (pan1, pan frame, etc), use the appropriate
median flat field image, and produce an image with the bias
subtracted, and flat field pattern removed. This image (or image cube,
in the case of the pan frame detector) is stored in the primary data
unit (PDU) of the Level 2 FITS file.
10.3.1.2 Geometric Correction
Once again we will start with a discussion of the correction as
applied to the framing array and then expand to describe the procedure
for the TDI arrays. There are two sources of geometric distortion.
The first is instrumental. This is the distortion due to optical
effects in the instrument. The second source of distortion is motion
distortion. This second source only affects TDI observations and is
caused by the cross-track drift of the boresight within the deadband
during the scan.
For the following discussion, we define the following variables:
N = number of images included in the analysis
i = 0, ..., N = index running over the number of images
p, q, ..., n = number of correlated star pairs identified for each image
j = index running over all correlated stars in image i. e.g., if i =
0, j runs from 0 to p
C_ji = column number of jth star in image i
R_ji = row number of jth star in image i
xi_ji^c = xi -coordinate of the catalog star correlated with the jth
star in image i
eta_ji^c = eta-coordinate of the catalog star correlated with the jth
star in image i
m_c, m_r = plate scales in column and row directions
theta_i = FOV rotation of ith image, and is the angle measured in a
counter-clockwise
sense from the row-direction of the image to the positive eta-axis.
n_c, n_r = number of columns and rows in the instrument CCD
For image i, the transformation from column and row coordinates (C_ji,
R_ji) to the tangent-plane coordinates (xi_ ji, eta_ji) is made using
Equation 10-2, where C_ji' = C_ji - n_c/2 and R_ji' = R_ji - n_r/2, and ai
Equation 10-2
and bi are constants. The center of the FOV maps onto xi = a_i and eta =
b_i. Delta(C_ji) and delta(R_ji) are perturbations about C_ji and R_ji
that account for
instrument distortion. If they are zero, and exact values of all other
parameters in Equation (1) are known, then the xi_ji and eta_ji are equal
to the catalog values xi_jic and eta_ji^c. delta(C_ji) and Delta(R_ji)
are each modeled
as a series of orthogonal polynomials: we use Legendre Polynomials,
and we introduce the following normalization to scale C_ji' and R_ji'
to the -1 to 1 range required Equation 10-3.
Equation 10-3
We adopt a fifth order Legendre polynomial model for the distortion model.
This is the general kth-order bivariate polynomials. For our case k=5.
Equation 10-4, where the vpq and wpq are unitless constants included
Equation 10-4
as free parameters in the least squares algorithm. Note that no
zero-order terms are present (p > 1) since they are already
represented by the offsets ai and bi in Equations (2). The number of
terms in each polynomial is Equation 10-5.
Equation 10-5
The vpq and wpq do not depend on i and j and there are a total of 2N_P
of them, regardless of the number of stars and images.
Also included in the list of free parameters for the least squares fit
are the two plate scales (m_c and m_r), the N rotations (theta_i), and the 2N
column and row offsets (a_i and b_i). The total number of free
parameters is therefore M = 2 + 3N + 2N_P.
The columns in Table 10-6 define the fitted parameters to 10 images
that were used to define the distortion model.
Table 10-6a
Table 10-6a Values of free parameters in a fifth-order least squares
analysis of Equations (1). Comparison of values in image headers is
given in parentheses where available. Results continue in Table 10-6b.
Table 10-6b
Table 10-6b Continuation of free parameter results from Table 10-6a.
The standard deviation of the residuals is less than 0.1 pixel. The
maximum distortion at the edge of the field (near column numbers 12
and 5000 is about 2.5 pixels.
The navigation team would not like the image pixels remapped. For
this reason, we will retain the image with the bias subtracted and
flat field removed but without the geometric distortion correction and
store this image in the primary data unit. This flattened,
distortion-corrected image will be the first extension in the level
two product.
For the TDI images, we need to also correct the flattened image for motion
distortion in the cross-track and along-track directions. The C-Kernel
provides the spacecraft pointing information. The spacecraft scan can be
oriented in any direction in space. From the C-Kernel, we get the
pointing at the beginning and end of the scan and construct a line between
those two points. This is our nominal scan path. Deviations from the
linear path are the motion distortion. At the mid-exposure time for each
pixel, we query the C-Kernel for the spacecraft pointing and compare that
to our nominal scan path. We determine the cross-track and along-track
errors from the nominal scan path and bilinearly interpolate the pixels in
that row to correct for the motion distortion at the mid-exposure time of
the row. We only correct for both the cross-track and along-track motion
distortions.
10.3.1.3 Conversion to Physical Units
We are using the same standard method as used by the LORRI instrument
for conversion to physical units.
In order to determine the conversion to physical units, we need to
know the spectral type of the target.. We have determined the
conversion factor for 4 different spectral types: Pluto, Charon,
Jupiter, Solar and Pholus. The absolute calibration is given by a
keyword (i. e., RPLUTO) in the header of the Level 2 file that allows
the user to convert a count rate ("C/TEXP" in DN/s/pixel, where "C" is
the flat-fielded signal in a pixel and "TEXP" is the exposure time)
for a resolved source into a radiance value ("I" in ergs/cm^2/s/sr/Angstroms)
at MVIC's pivot wavelength (specified by the FITS keyword PIVOT; see
below), assuming that the spectrum of the target is identical to the
globally-averaged spectrum of Pluto. The relevant formula is:
I = C/TEXP/RPLUTO
The keyword RPHOLUS allows the conversion of the count rate for a
resolved source into a radiance value at the pivot wavelength assuming
that the target has a spectral distribution identical to that of the
centaur object 5145 Pholus, which may be a good analog for the reddest
regions on Pluto:
I = C/TEXP/RPHOLUS
Similarly, the keywords RSOLAR, RJUPITER and RCHARON provide the
conversion factors for resolved targets with Solar-, Jupiter- or
Charon-like spectra. Table 10-7 gives the values of the
multiplicative factor (RSOLAR, RJUPITER...) for resolved objects.
Table 10-7
Table 10-7 The values of the conversion factor for resolved objects.
The pivot wavelength (PIVOT) is given by Equation 6, where "P" is the
MVIC system quantum efficiency (i.e., fraction of photons detected) at
wavelength "lambda". The pivot wavelength is passband specific and is
stored in the FITS file header.
Table 10-8
Table 10-8 The pivot wavelength in microns.
For unresolved sources (e.g., stars), the calibrated flux (also called
"irradiance") at the pivot wavelength can be determined using keywords
that are defined analogously to the photometry keywords discussed
above for resolved sources. In the case of a source having a spectral
distribution identical to that of a globally-averaged Pluto spectrum,
the observed count rate integrated over the MVIC PSF ("CINT/TEXP" in
DN/s, where CINT is the total number of flat-field corrected counts
integrated over the image and "TEXP" is the exposure time) can be
related to the flux ("F" in ergs/cm^2/s/Angstroms) by:
F = CINT/TEXP/PPLUTO
Similarly, the flux at the pivot wavelength for a target having the
same spectral distribution as Charon (PCHARON), the sun (PSOLAR), and
Pholus (PPHOLUS) are given in the FITS header.
Table 10-9
Table 10-9 The values of the conversion factor for unresolved objects
10.3.1.4 Error Propagation
The standard deviation of each pixel will be calculated and the
resulting 2-D array of errors will be put into extension 2 of the FITS
file. The gain, g, and the DN value of each pixel of the
distortion-removed flattened image (extension 1 in the FITS file) will
be used to determine the photon noise. The photon noise and the read
noise, RN, will be used to calculate the standard deviation per pixel
in DN. The error equation, Equation 10-7.
Equation 10-7
The gain (58.6 electrons per DN) and read noise (30 electrons) values
used to calculate the standard deviation will be entered in the file
header with the keywords GAIN and READNOI. We will also include the
error propagation due to uncertainty in the flat field pattern. Other
sources of error such as the uncertainty in the bias level are not
included. (XXcheck the error equation not that I will be doing it for
the distortion corrected image which already has the flat field
pattern removed).
10.3.1.5 Data Quality Flags
The data quality flags will be set to a non-zero value if there is a
problem with the data and zero if the data is fine. Below is a
preliminary list of the factors that will cause the data quality flag
to be set to its appropriate value.
Quality Flag Value Description
0 Good pixel
1 Housekeeping keyword out of yellow limits, see Table 10-1.
2 Defect in one of the reference calibration files
4 Permanent CCD defect (e.g., dead pixel)
8 DN level in non-linear regime of detector
16 Zero-value pixel
32 Bad pixel not in any of above categories
-1 Missing data
If a housekeeping keyword exceeds it's yellow limit at any time during
the exposure the data quality flag for all the pixels in the image are
set to 1.
10.3.2 Dataflow Block Diagram (to do - add distortion correction to tree)
Here is a diagram that shows how the data flows through the different
IDL procedures and functions that comprise the Level 2 pipeline.
; mvicL2_pipeline
; |
; --mvic_level2_pipeline
; |
; --mvic_flatten
; | |
; | --pantdi_flatten
; | | |
; | | --pantdi_readflat
; | | |
; | | --tdi_flatten_core
; | |
; | --mcl_flatten
; | | |
; | | --mcl_readflat
; | | |
; | | --tdi_flatten_core
; | |
; | --panfra_flatten
; |
; --mvic_geo
; |
; --mvic_dq
; | |
; | --pantdi_dq
; | |
; | --check_pixels
; | |
; | --pantdi_hk_check
; | | |
; | | --setUpAndScaleHK
; | | |
; | | --scaleRawRalphTelemetry
; | | |
; | | --conversionCoefsForMVIChk.pro
; | --panfra_dq
; | |
; | --panfra_check_pixels
; |
; |
; --mvic_err
; |
; --pantdi_err
; | |
; | --pantdi_readflat
; |
; --mcl_err
; | |
; | --mcl_readflat
; |
; --panfra_err
10.3.3 Data Format
All of the MVIC Level 2 FITS files have a primary data unit and four
extensions. In the primary data unit, the bias-subtracted, flattened
data is stored. The first extension has the bias-subtracted,
flattened, distortion-removed data. The second extension has the
error array for the bias-subtracted, flattened, distortion-removed
data. The third extension has the data quality array for the
bias-subtracted, flattened, distortion-removed data. The fourth
extension is the binary table containing the instrument housekeeping.
The image data for the TDI observations is stored in a a
two-dimensional array. The number of columns in the array is always
5024. The number of rows in the array depends on the duration of the
observation and the scan rate.
The image data for the pan frame observations is stored in a
three-dimensional array (an image cube). The number of columns is
always 5024, the number of rows is always 128.
10.3.4 Scientific Units
We will be using cgs units for the Level 2 output. The flux per pixel
will have the units of ergs/s/cm2/Angstrom.
10.3.5 Additional FITS and PDS Keywords Added
Additional FITS keywords added to the Level 2 product include:
SOCL2VER= '1.0 ' /Version of Level 2 software
PIXSIZE = 13.0000 /Pixel size in microns
PIXFOV = 19.8000 /Single pixel field of view in microradians
READNOI = 30.0000 /Readnoise in Electrons
GAIN = 58.6000 /Gain in Electrons/DN
CALDIR = 'cal/ ' /Directory for calibration files
PPHOLUS = /(DN/s)/(erg/cm^2/s), Pholus spectrum
PPLUTO = /(DN/s)/(erg/cm^2/s), Pluto spectrum
PSOLAR = /(DN/s)/(erg/cm^2/s), Solar spectrum
RPHOLUS = /(DN/s/pix)/(erg/cm^2/s/sr), Pholus spectrum
RPLUTO = /(DN/s/pix)/(erg/cm^2/s/sr), Pluto spectrum
RSOLAR = /(DN/s/pix)/(erg/cm^2/s/sr), Solar spectrum
PIVOT = /cm, pivot wavelength
The values of the radiometric keywords are source dependent as
discussed above.
10.3.6 Extra FITS Extensions() and Their Definitions
There are four extra FITS extensions. The first three have been
described in detail previously (the distortion-removed image file, the
error array and the data quality flag array). The fourth extension is
the binary table with the housekeeping data. This data is simply
passed along from the Level 1 file without modification.
10.3.7 Hardware/OS Development Platform
The Level 2 software will be developed on a PowerBook G4 running Mac
OS X version 10.3.4. Future
Migration will be backwards compatible.
10.3.8 Language(s) Used
The MVIC Level 2 software will be written using IDL.
10.3.9 Third Party Libraries Required
The code will require the "IDL Astronomy User's Library". It is
available from http://idlastro.gsfc.nasa.gov/homepage.html.
10.3.10 Calibration Files Needed (with Quantities)
The following calibration files will be used.
- Flat field images for each array
- Bad pixel files for each array
- File with the acceptable levels of the housekeeping keywords that we are monitoring
There will probably be multiple generations of each over time during
the mission. These files will be archived with the observations ]
10.3.11 Memory Required
TBD
10.3.12 Temporary File System Space Needed
None.
10.3.13 Predicted Size of Output File(s)
The output files will be approximately twice as large as the input
files since we are adding the multiple extensions, but not propogating
the housekeeping.
10.3.14 Predicted Execution time
TBD
10.3.15 Contact/Support Person(s)
Cathy Olkin
Dennis Reuter
Leslie Young
10.3.16 Maintenance Schedule (Code/Data Updates, Documentation)
The code will be updated on the schedule mandated by the mission. The
current plan is to do code maintenance after the Instrument
Calibration (on the ground), after Integration and Test (on the
ground), after Commissioning, and after the Jupiter Encounter.
Calibration files will be updated throughout the mission as necessary.
Necessary criteria include new calibration information (such as new
flat-field observations or a new geometric distortion correction) such
as might be available after an annual checkout.
11. PEPSSI INSTRUMENT DESCRIPTION
11.1 Overview
11.1.1 PEPSSI Investigation
PEPSSI (Pluto Energetic Particles Spectrometer Science Investigation)
is a hockey-puck-size, time-of-flight (TOF) spectrometer that
measures ions and electrons over a broad range of energies and
pitch angles. Particle composition and energy spectra be measured
for H to Fe from ~15 keV/nucleon to 1 MeV/nucleon and for electrons
from 15 keV to 700 keV. The PEPSSI instrument traces its heritage
back to the MESSENGER Energetic Particle Sensor (EPS)
instrument. EPS/PEPSSI was developed with the support of a NASA
Planetary Instrument Definition and Development (PIDDP) grant aimed
at designing a low-mass, low-power sensor that can measure
energetic pickup ions produced near planets and comets (Andrews et
al., 1998; McNutt et al., 1996). The overall PEPSSI instrument
weighs 1.5 kg and uses maximum power of 1.4 W. Figure 2 shows the
placement of PEPSSI on the spacecraft and the PEPSSI fields-of-view
(FOV).
The science goals of the PEPSSI instrument are:
1. Determine the escape rate of Pluto's atmosphere
2. Measure the interaction of the solar wind with Pluto's ionosphere
3. Determine the source and nature of energetic particles found
near Pluto
11.1.2 PEPSSI Sensor Description
PEPSSI is a compact particle telescope with a time-of-flight (TOF)
section and a solid-state detector (SSD) array (see Figure 3). A
mechanical collimator defines the acceptance angles for the incoming
ions and electrons. A cutaway view of the assembly is shown in Figure
4. The TOF section is axially symmetric; entrance and exit apertures
are 6 mm wide with an azimuthal opening angle of 160degrees. The entry and
exit apertures are covered by thin (~7 microg/cm2) polyimide/aluminum and
(~10 microg/cm^2) palladium/carbon foil mounted on high-transmittance
stainless-steel grids, respectively. The foil thickness and
composition is a compromise to minimize the energy threshold,
secondary electron production, and scattering of particles in the foil
while blocking UV from the direct Sun and Lyman-alpha background. PEPSSI
measures the ion TOF using secondary electrons generated as the ion
passes through the entrance and exit foils in the spectrometer. Total
energy is measured by the SSD array. Each of the six SSDs has two
pixels, three of the SSDs are dedicated for ion measurement. The
other three have one pixel covered with ~1 microns Al absorber, to block
low energy ions and permit measurements of electrons. The fan-like
collimator together with the internal geometry defines the acceptance
angles. The FOV is 160degrees by 12degrees with six angular sectors
of 25degrees each;
the total geometric factor is ~0.15 cm^2sr. As an ion passes through
the sensor, it is first accelerated by the potential of ~3 kV on the
front foil prior to hitting it. The ion generates secondary electrons
at the foils, which are then electrostatically steered to well-defined
separate regions on a single micro channel plate (MCP), providing
"start" and "stop" signals for the TOF measurements (from 1 ns to 320
ns). The segmented MCP anode, with one start segment for each of the
six angular entrance segments, allows determination of the direction
of travel even for lower-energy ions that do not give an SSD signal
above threshold.
The combination of measured energy and TOF provides unique particle
identification by mass and particle energy in the range: for protons
from 15 keV to 1 MeV; for heavy (CNO) ions from 80 keV to 1 MeV.
Lower-energy (>3 keV) ion fluxes are measured by TOF and pulse-height
analysis (PHA) of the signal they produce in the MCP, providing
particle identification and velocity spectra at these energies as
well. Molecular ions, expected from Pluto's atmosphere, will break up
in the foil prior to their full detection, but will be detected as
high-mass events. Internal event classification electronics determine
the mass and produce an eight-point energy spectrum for each of four
species for six arrival directions. Energetic electrons are measured
simultaneously in the dedicated electron pixels in the range from 20
to 700 keV. Only protons with energies > 300 keV (expected to be very
rare at Pluto) can penetrate the absorbers on these pixels, and even
those would be eliminated by on-board MCP coincidence requirements and
ground comparisons with the simultaneously measured ion flux.
11.1.3 PEPSSI Electronics Description
Extensive uses of miniaturization and custom electronic in the design
allow PEPSSI to weigh less than 1.5 kg and consume less than 1.4 W.
PEPSSI is made up of six modular 4"x4" slices. They consist of:
1) Energy board;
2) High Voltage Power Supply (HVPS);
3) TOF board;
4) Digital processing board;
5) Common event processor board; and
5) Low Voltage Power Supply (LVPS) board.
See Figure 11-5 below which shows the exploded view of PEPSSI with
each board labeled. A brief description of the functionality of
each board is highlighted below.
Energy board:
The energy board is the interface between the SSDs and the signal
conditioning electronics. It houses the sensor, MCP anodes, charge
amplifiers, pulse shapers, etc. In addition, it also outputs the
pulse signal from the 6 start anodes and 1 stop anode.
HVPS board:
The HVPS board contains the high voltage (HV) drive circuitry, HV
transformer, and its control circuitry. It provides HV up to -2900 V
for the sensor electrostatic lens and MCP bias. In addition, the HVPS
also needs to provide bias voltage over the range of 0 to -200 V with
<10 mV ripple.
Digital processing board:
The digital processing board provides valid event logic functions,
which include channel enables, programmable coincidence window, event
packet generation and rate counters for event statistics. It provides
the logic to distinguish between electrons, ions and directionality.
Common event processor board:
This board contains PEPSSI's main processor (RTX2010RH), the Filed
Programmable Gate Array (RT54SX72S), and various memory modules (SRAM,
EEPROM, PROM).
LVPS board:
This board converts primary spacecraft power into multiple low voltage
outputs used by PEPSSI. It provides highly efficient power conversion
into two digitals (+5, +2.5V) and four analogs (+5, -5, +15, and -15)
outputs.
11.2 Introduction to PEPSSI Data
The PEPSSI instrument can operate in two modes: Normal and
Diagnostic. On the spacecraft, each event generates a PHA record.
This record is classified by event type: Electron, High-Energy Ion (or
"Hi-Ion" or "Triple"), or low-energy ion (or "Low-Ion," "Double," or
"TOF-only"). In diagnostic mode, events are not classified;
alternatively, all events are "diagnostic events". Events of a given
type are further classified into "Rate Boxes" by their energy and/or
time of flight (TOF). Thus each event has a type, a rate box, and a
detector in which it occurred. Instead of detector number, we will
often use arrival direction (or sector) since there is a one to one
relation between them (see figure 6). A six character string is used
to specify each possible classification (or Rate) of an event. The
construction of this string is (type)(rate box)S(arrival sector). The
arrival sector numbering is shown in figure 6. The "type" string is:
B - Hi-Ions (possesses Energy and TOF)
R - Electrons (energy only, no TOF)
L - Low-Ions (TOF-only, no-energy).
For High Energy Ions, the "Rate Boxes" are determined by areas in the
TOF vs Energy plain (see figure 7). These correspond to different
particle species and different energies.
For Electrons, the "Rate Boxes" are determined by energy ranges.
For Low Energy Ions, the "Rate Boxes" are determined by TOF ranges and
by which heavy ion discriminators fired. The definition of Low-Ion
"Rate Boxes" has been changed for the post-Jupiter phases of the
mission. Note that because of the way the PEPSSI electronics work,
frequently the arrival sector is unknown or uncertain for the Low-Ion
measurements.
Some examples:
B02S04 - High-Energy Rate Box #2, arriving from the sector 4
direction. Protons with deposited energy in channels 95-169 , in
analog-to-digital units(ADUs).
L06S03 - Low-Ions Rate # 6 arriving from the sector 3 direction. Ions
with TOF indices from 45-79 ADUs and for which the heavy ion
discriminator H0 fired but H1 didn't.
R00S05 - The 0th electron rate, arriving from the sector 5 direction.
Electrons with Energy channels in the range 720-1023 ADUs .
There are two counters for each Rate that are incremented whenever a
corresponding event occurs. The N2 counter is accumulated for a
certain time interval (usually 15, 30, or 60 seconds), then recorded
and zeroed. The N1 counter is accumulated for some multiple of the N2
interval (usually 10 minutes), then recorded and zeroed. A certain
number of PHA events are kept according to a complex priority scheme
and telemetered along with the Rate data. (Note: if the multi-hit,
i.e. anti-coincidence, flag is set for an event, the event is not
counted. This is programmable, but the "don't count multi-hit events"
rule was true outside of Bad Time Intervals for the whole Jupiter
phase).
Various housekeeping and status data and certain global hardware and
software counters are also present in the data at Levels 1 and 2.
PEPSSI Level 1 and PEPSSI Pre-Level 2 data are internal formats that
are not used outside the SOC.
PEPSSI Level 2 data represents, with 3 exceptions, the raw data taken
from the spacecraft telemetry. It has merely been reformatted for
ease of use. No data has been added, removed or altered with the
following 3 exceptions:
a. Instrument Status information has been calibrated to physical
units where applicable (see discussion in section 1.2.1.7 below).
b. For clarification, a "DT" column has been added to the Rate
tables to indicate the integration time over which the count data was
accumulated. This information is not available in the spacecraft
telemetry and must be calculated from the available timestamps. This
"DT" value may be inaccurate during Bad Time Intervals (BTIs), see
below.
c. For ease of use, we have added a column giving the deduced
"Rate Box" of High-Ion PHA and Electron PHA events to the Level 2 PHA
data. While this can, in principle, be calculated from the raw Level
2 quantities and the instrument configuration files available in the
calibration file section of the PDS archive, the procedure is complex
enough that we have found it convenient to perform this calculation in
advance and include the information in the Level 2 files.
PEPSSI Level 3 data presents the data in a format that should be
convenient for scientific analysis. All of the calibration parameters
needed to convert Level 2 data to Level 3 data are present in the
headers of the Level 3 data files. The formula's used to calculate
the calibrated quantities are also present in the Level 3 headers.
Rate data is presented in physical flux units with uncertainties as
well as counts per second.
PHA data is presented with calibrated TOF and deposited energy.
Further calibrated incident energies are given for assumed ion
species. Only PHA data telemetered with the N2 rates is present in
Level 3 as discussed below. There are also some "quick look" PHA
images and Rate spectrograms in the Level 3 data to allow for a simple
overview of one day's observations.
No "multi-hit" events are present in Level 3 PHA data. No diagnostic
mode data is present in the Level 3 data. BTI data is present in the
Level 3 data but should be ignored. Level 3 data for the "Launch"
phase is present for quick-look purposes, but, apart from the
deposited energy calibration (which is well known), the calibrations
are performed with dummy values, as will be evident from examination
of the header information.
Note: End users of PEPSSI data (i.e. those outside the instrument team
and the SOC) will probably not find much useful information in the
Level 1 and Pre-Level 2 documentation which follows and are when
reading this document are encouraged to skip directly to section
11.4.3, Level 2 Data.
11.3 Level 1 Specifics
The SOC Level 1 data product is a FITS format data file and all data
is contained in FITS extension Header Data Units (HDUs). Each HDU
contains a PEPSSI science data telemetry block which is described in
depth in the PEPSSI Flight Software Specification. Level 1 files are
not present in the PDS archive. They are:
File Type HDU Type
N1 Primary HDU: High Priority Telemetry Block
Extension 1: PHA Telemetry Block
Extension 2: Status Telemetry Block
N2 Primary HDU: Medium Priority Telemetry Block
Extension 1: PHA Telemetry Block
Extension 2: Status Telemetry Block
N3 Primary HDU: Low Priority PHA Telemetry Block
11.3.1 Data Sources (High/Low Speed, CCSDS, ITF)
PEPSSI is low-speed only. Data will be from CCSDS packets.
11.3.2 Definition of an "Observation"
PEPSSI doesn't make specific "Observations".
11.3.3 Header with Keywords
11.3.4 Spacecraft Housekeeping Needed in Level 1 Files (for Calibration)
Spacecraft attitude is necessary to calculate PEPSSI pointing in the
ecliptic coordinate system, and with respect to Jupiter, Pluto, and
Charon. An accuracy of 1 degree is adequate.
11.3.5 Raw Science Data and/or Housekeeping Requirements
No special requirements
11.4 Level 2 Specifics
11.4.1 Algorithm for Pipeline
11.4.1.1 IDL L1 to Pre-L2 step
The PEPSSI pipeline conversion from Level 1 (L1) to Level 2 (L2) data
has two steps. The first uses an IDL program to rearrange the Raw L1
data into single-rowed vector-valued FITS tables. These "Pre-L2"
files are temporary and not in the final PDS archive. Multiple Pre-L2
files will be combined in the next processing step into final L2
files; see section 11.3.1.2 below.
The base routine PEPSSI_LEVEL2_PIPELINE reads from the input file the
following variables:
Filein
dir_cal
temp_dir
status_file
fileout
and generates in the output files one of more of the corresponding HDUs
N1
N1_STATUS
N2
N2_STATUS
D_N1
D_N2
PHA_ELECTRON
PHA_LOW_ION
PHA_HIGH_ION
PHA_DIAG
STATUS
Decoding of the level 1 data stream follows two steps: first blocks
are read into the 7 structures:
N1 = { $
met:lonarr(blockcnt), $
high_ions:lonarr(6,19,blockcnt), $
electrons:lonarr(3,3,blockcnt), $
low_ions:lonarr(7,16,blockcnt), $
rates:lonarr(32,blockcnt), $
housekeeping:fltarr(33,blockcnt) }
N2 = { $
met:lonarr(blockcnt), $
high_ions:lonarr(6,19,blockcnt), $
electrons:lonarr(3,3,blockcnt), $
low_ions:lonarr(7,8,blockcnt), $
rates:lonarr(24,blockcnt) }
PHA_ELECTRON={ $
met:lonarr(ele_cnt) , $
energy:fltarr(ele_cnt) , $
multi:intarr(ele_cnt) , $
chann:intarr(ele_cnt) }
PHA_LOW_ION={ $
met:lonarr(low_cnt) , $
tof:fltarr(low_cnt) , $
heavy1:intarr(low_cnt) , $
heavy0:intarr(low_cnt) , $
startseg:intarr(low_cnt) }
PHA_HIGH_ION={ $
met:lonarr(hig_cnt) , $
energy:fltarr(hig_cnt) , $
tof:fltarr(hig_cnt) , $
multi:intarr(hig_cnt) , $
heavy1:intarr(hig_cnt) , $
heavy2:intarr(hig_cnt) , $
chann:intarr(hig_cnt) , $
startseg:intarr(hig_cnt) }
PHA_DIAG={ $
met:lonarr(dia_cnt) , $
energy:fltarr(dia_cnt) , $
tof:fltarr(dia_cnt) , $
start:intarr(dia_cnt) , $
stop:intarr(dia_cnt) , $
fired:intarr(dia_cnt) , $
multi:intarr(dia_cnt) , $
heavy1:intarr(dia_cnt) , $
heavy0:intarr(dia_cnt) , $
chann:intarr(dia_cnt) , $
startseg:intarr(dia_cnt) }
STATUS = { $
MET:lonarr(nsta), $
STATINT:lonarr(nsta), $
MACBLCKS:lonarr(nsta), $
TLMVOL:lonarr(nsta), $
WTCHADDR:lonarr(nsta), $
WTCHMEM:bytarr(nsta), $
WTCHDATA:lonarr(nsta), $
PEPSWVER:bytarr(nsta), $
ALARMID:bytarr(nsta), $
ALARMTYP:bytarr(nsta), $
ALARMCNT:bytarr(nsta), $
CMDEXEC:bytarr(nsta), $
CMDREJCT:bytarr(nsta), $
MACEXEC:bytarr(nsta), $
MACREJCT:bytarr(nsta), $
MACROID:bytarr(nsta), $
MACROLRN:bytarr(nsta), $
MONRESP:bytarr(nsta), $
WRITEENB:bytarr(nsta), $
HVPSCURR:fltarr(nsta), $
HVPSVOLT:fltarr(nsta), $
BIASCURR:fltarr(nsta), $
BIASVOLT:fltarr(nsta), $
PEPSTAT:lonarr(nsta), $
DVOLTP5:fltarr(nsta), $
AVOLTN5:fltarr(nsta), $
VOLTP2:fltarr(nsta), $
VOLTN5:fltarr(nsta), $
VOLTP15:fltarr(nsta), $
VOLTN15:fltarr(nsta), $
DCURRP5:fltarr(nsta), $
ACURRP5:fltarr(nsta), $
CURRP2:fltarr(nsta), $
CURRN5:fltarr(nsta), $
CURRP15:fltarr(nsta), $
CURRN15:fltarr(nsta), $
PRIMCURR:fltarr(nsta), $
LVPSTEMP:fltarr(nsta), $
ENGYTEMP:fltarr(nsta), $
HVPSTEMP:fltarr(nsta), $
ADDR12C:lonarr(nsta), $
RSLT12C:lonarr(nsta) $
}
where blockcnt is the number of blocks present in the level 1 file
(i.e. the number of sample periods), ele_cnt is the number of
electron pha events, and similarly for low_cnt, hi_cnt, and
dia_cnt. nsta is the number of sample periods for the status
quantities. See the full L2 file description for the meaning of
the status quantities.
Example: n1.low_ions(3,4,6) corresponds to the number of
time_of_flight only events (low_ions) coming from anode 3, 4th
velocity bin, collected during the 6th time interval.
11.4.1.2 MIDL L1 to Pre-L2 step
A Java program derived from the MIDL analysis program is used to
convert the Pre-L2 files into L2 files. The L2 files contain exactly
one day of data, except on days when new Rate Box definitions are
loaded to the spacecraft in which case there will be a "before" file
and an "after file"(these load-days are very rare). The DataConverter
program essentially "flattens out" the Pre-L2 structure. In the L2
files, each row is a separate sampling period or PHA event (i.e. the
blockcnt, hi_cnt, lo_cnt, etc. axis is now the row structure of the
FITS binary table). Each "Rate Box" or hardware count is a separate
column in the N1 or N2 FITS table. So, for example, each row of the N1
rates extension represents a separate sampling period (usually 600
seconds) and each column is a different rate, listed in alphabetical
order by rate name, so the columns would be:
ET, MET, B00S00, B00S01, ..., B18S05, C00D00, C01D01, ..., C23, C24, HK00,
HK01, ...,HK34, J00, J01, ..., J06, L00S01, L00S02, ..., L15S05,
L15SUnknown, R00S00, ..., R02S05
The meaning of the individual Rate Labels will be discussed below, or
see the comments in the corresponding FITS header. As another example,
the PHA_ELECTRON extension is another simple 2D table of values; each
row represents a separate PHA event, the columns are:
ET, MET, APID, Cross_Talk_Indicator, Electron_Channel, Raw_Energy
11.4.2 Dataflow Block Diagram
Figure 11-1a Dataflow Block Diagram, Part A
Figure 11-1b Dataflow Block Diagram, Part B
11.4.2.2 Pre-L2 to L2 processing
There is no data-flow diagram for Pre-L2 to L2 processing.
11.4.3 L2 Data Format
The contents of the in the L2 files are detailed in the following
sections. The ordering of the extensions is not guaranteed, programs
accessing the data should search for the desired extension by name (in
the EXTNAME keyword). There will always be only one extension of each
type (EXTNAME) and not all types will be present. An extension will
only be present if there is data of that type taken during the time
period covered by that file. Each file will contain exactly one
observing day worth of data (i.e. one UTC day from hour 0 -
23:59:59.999...). The Primary HDU contains no data, only informational
header keywords identifying mission info, observational start time,
and information about the file creation (date, software version,
etc.).
The available extensions are:
D_N1, D_N1_STATUS, D_N2, D_N2_STATUS, N1, N1_STATUS, N2, N2_STATUS,
PHA_DIAG, PHA_ELECTRON, PHA_LOW_ION, PHA_HIGH_ION
The different extensions are described below. For detailed
information such as the data-type of different columns see the FITS
header in the data file.
Extension names beginning with "D_" (and the PHA_DIAG extension)
represent data taken in diagnostic mode. Diagnostic data is taken for
purposes of calibration and understanding the instrument at a very low
level. Diagnostic data is complex and often taken under unusual
conditions. It is unlikely that the general user will be able to use
diagnostic data in any meaningful way. In diagnostic mode, a PHA
event is generated whenever any of the instrument detectors sees an
event. All events are counted except for those with the multi-hit
flag set (by default, the multi-hit setting can be changed). This
means that there are no "Low-Ion" events because, by definition, these
events are required to have no SSD fire, which is mutually exclusive
with the diagnostic mode requirement that every diagnostic event is
initiated with an SSD fire. Many of the columns will contain "fill
values" for certain types of events. The "Fill" values for invalid
Energy and TOF PHA data are: Energy - 1023 and TOF - 2047. In the
PHA_DIAG extension, what would normally be an electron event, for
instance, will have a Time of Flight value of 2047.
11.4.3.1 PHA_HIGH_ION
When an ion enters the PEPSSI detector, if it has enough energy, we
measure an Energy and a Time of Flight (TOF). Since we don't have
enough bandwidth to telemeter all of our events, we use a round robin
priority scheme to decide which PHA events to discard and which to
telemeter. All of the events are counted in the N1 and N2 Rate
data. The Rate data can be used to remove the priority group effects
(to a large extent) from the PHA data by weighting events by their
respective rates. See the L3 documentation below for more on
rate-weighting.
The PHA_HIGH_ION extension contains one row for each high energy ion
event that was not discarded by the priority scheme. The columns are:
ET Ephemeris Time (J2000)
MET Mission Elapsed Time
APID Which APID was this event telemetered in:
N1 - 0x691, N2 - 0x692, N3 - 0x693
Cross_Talk_Indicator Did more than one detector fire?
H0 Did Heavy Ion Descriminator 0 fire?
H1 Did Heavy Ion Descriminator 1 fire?
Ion_Channel Detector Channel (0-8)
Raw_Energy Energy deposited (ADU)
Raw_TOF Time of Flight (ADU)
Start_Anode Bits 0-5 are set if that start anode fired.
Notes on PHA High Ion data:
-IMPORTANT NOTE: The timing of a PHA event is not known to 1
second precision. The "time tag" of a PHA event only
represents the end time of the accumulation interval of the
Rate packet with which it was telemetered. So, in normal
operation, "N1 PHA" event arrival times are known only to the
nearest 10 minutes, N2 events to the nearest minute, and N3
events to within 2 hours. See discussion of Level 3 PHA data
for more details.
- Mission Elapsed Time starts about 19-JAN-2006-18:09:05.184.
See figure 6 for a diagram of the detector numbering. 9 of the 12
detectors are dedicated to Ions (the other 3 are dedicated to
electrons) and are configured accordingly.
- The H0 and H1 ion discriminators were found to be of limited usefulness.
Events with the Cross_Talk_Indicator value set are discarded from
the rate counters and are not usually used in analysis.
- Energy and TOF are given in raw "Analog to Digital Units" (ADU).
The Start Anode column consists of a single byte. The individual
bits 0-5 indicate whether the corresponding Start Anode (0-5)
registered an event. See figure 6 for start anode layout. Note
that, unfortunately, the numbering of the anodes is reversed from
the numbering of the incoming angle sectors.
- The electronics of the Start Anodes are such that, while a given
event may have a known TOF, the exact Start Anode information may be
uncertain or completely unknown. Thus, a valid event may show more
than one Start Anode, or none.
11.4.3.2 PHA_ELECTRON
The PHA_ELECTRON data is very similar to the PHA_HIGH_ION data except
that the TOF-related values aren't present since electrons aren't
detected by that part of the instrument (i.e. they only have solid
state detector (SSD)-related values:
ET Ephemeris Time (J2000)
MET Mission Elapsed Time
APID Which APID was this event telemetered in
Cross_Talk_Indicator Did more than one detector fire?
Electron_Channel Detector Channel (0-2)
Raw_Energy Energy deposited solid state detector (ADU)
Notes:
- Only Sectors 0, 2, and 5 have electron detectors (0,1, and 2,
respectively) associated with them.
See PHA_HIGH_ION notes for other relevant info.
11.4.3.3 PHA_LOW_ION
The PHA_LOW_ION events are from low energy ions that register in the
TOF part of the detector but do not trigger the SSDs. Hence "Low
Ions" have TOF data (and associated quantities like Start Anode) but
no Energy data:
ET Ephemeris Time (J2000)
MET Mission Elapsed Time
APID Which APID was this event telemetered in
H0 Did Heavy Ion Descriminator 0 fire?
H1 Did Heavy Ion Descriminator 1 fire?
Raw_TOF Time of Flight (ADU)
Start_Anode Bits 0-5 are set if that start anode fired.
See PHA_HIGH_ION notes for other relevant info.
11.4.3.4 PHA_DIAG
In diagnostic mode, the following columns are present:
ET Ephemeris Time (J2000)
MET Mission Elapsed Time
APID Which APID was this event telemetered in?
Cross_Talk_Indicator Did more than one detector fire?
Fired 0 - electron event 1 - ion event
H0 Did Heavy Ion Descriminator 0 fire?
H1 Did Heavy Ion Descriminator 1 fire?
Ion_Channel Detector Channel (0-8) or (0-2 if electron)
Raw_Energy Energy deposited solid state detector (ADU)
Raw_TOF Time of Flight (ADU)
Start Did a start anode fire?
Start_Anode Bits 0-5 are set if that start anode fired.
Stop Did the stop anode fire?
Notes on Diagnostic PHA Data:
- The "Fired" flag indicates whether the event is an Ion or an
Electron event. This determines which Rate counter gets incremented
as well.
- Raw Energy frequently has the 1023 fill value in diagnostic mode.
- Raw TOF frequently has the 2047 fill value in diagnostic mode.
11.4.3.5 N1 and D_N1
The N1 and N2 (and D_N1 and D_N2) extensions contain several types of
"Rate" data. The Rate data is accumulated in histograms which are
then dumped at set intervals. For N1 data, usually the histograms are
accumulated for 600 seconds. For N2 data, the accumulation time is
usually 60 seconds except for the first hour of the day when it is 15
seconds. This can be changed, but during normal observing it is
almost always true. The DT column will indicate the accumulation time
for a given row or Rate data. The DT column may not be accurate
during BTIs.:
B Rates: The number of high energy ion events in the various
Hi-Ion "Rate Boxes".
C Rates: The contents of various hardware counters
HK Rates: Various housekeeping quantities such as power levels and
descriminator thresholds
J Rates: Software counters that represent overall quantities like
total number of Electron Events.
L Rates: The number of low energy (TOF-only) ion events in the
various Lo-Ion Boxes.
R Rates: The number of electron events in the various electron
"Rate Boxes".
The N1 and D_N1 data are identical in format; the D_N1 data is taken
when the instrument is in diagnostic mode. The definitions of some of
the Rate Boxes are different in diagnostic mode and normal mode
(i.e. the Rate Box number is the same, but its definition is different
depending on the mode). The events being counted are triggered with
different rules, as well, see the discussion of PHA_DIAG data for more
detail.
We describe some of the rates in more detail below. A detailed
description of each rate is also available in the FITS header as a
comment to the keyword defining a Rate column. Example:
TTYPE12 = 'B01S03 ' / B01S03: Protons (60-94) Energy ADUs Sector: 3
means that column 12 contains rate B01S03 which is nominally Protons
with energy between 60 and 94 ADUs incident from Sector 3.
B Rates: The TOF vs Energy plane is divided into 19 "Rate Boxes" as
shown in figure 6. Each high energy ion is classified into a Rate Box
and further its incident sector is used to classify it, resulting in a
Rate, or histogram cell designation of the form B_nnS_nn. The B boxes
in normal mode for the Jupiter encounter were:
Table 11-1
Table 11-1: B boxes in normal mode
In diagnostic mode, the boxes were:
Table 11-2
Table 11-2: B boxes in diagnostic mode
C Rates:
Table 11-3
Table 11-3: C Rates
Notes:
-"Singles" means single events on the named detector.
HK Rates:
These are various housekeeping values:
Table 11-4
Table 11-4: Housekeeping values
Notes:
- HK33 and HK34 are only retained because they're present in the
telemetry. They're just spare values.
J Rates:
These are software counter totals:
J00 Electron Events
J01 Hi-E Ion Events
J02 Low-E Ion Events
J03 Electron Discards
J04 Hi-E Ion Discards
J05 Diagnostic Events
J06 Diagnostic Discards
L Rates:
Table 11-5
Table 11-5: L Rates
Notes:
- Since the heavy ion discriminators appear to be of limited
usefulness, the L Rate Boxes were reprogrammed after the Jupiter
observing phase and are substantially different for the next observing
phase of the mission.
- Light events - neither heavy ion discriminator fired.
- Medium events - H0 fired, H1 didn't
- Heavy events - both discriminators fired.
R Rates:
R rates represent electron events.
Rate Box Lower Energy (ADU) Upper Energy(ADU)
R00 0,720 57,1023
R01 57 202
R02 203 719
Notes:
- R00 nominally includes both low and high energies, but this is only
a complication early in the Jupiter phase (days 6 - 22 of 2007), after
which the electron detector threshold was raised so that only the high
energies received valid events. This is why the L3 spectrograms put
the electron pixels in the order: R01, R02, R00.
- There are only 3 (out of 12) detectors dedicated to electrons (see
figure 6). We number sectors the same way we do in the other rates,
so electron rates only come from sectors: S00, S02, and S05.
11.4.3.5.1 Rate Box Definitions
For Electrons and Low-Ions, the rate box definitions are simple ranges
in Energy and TOF in ADUs which can be read found in the Level 2
headers. For Hi-Ions, the Rate Boxes are regions in the TOF-Energy
plane (see figure 7). The precise specification of the rate boxes is
complex and this is why we include rate box classifications in the
Level 2 PHA data. However, for completeness, we include here the
description of the Rate Box definition files. The binary files can be
found in the instrument_config/ directory tree of the PEPSSI PDS data
set.
For each event packet that is not discarded, the 10-bit Energy ADU
value is used as an index into a 1024-element array in which each
element contains the 16-bit offset relative to the starting address of
a "Rate Box" definition table. The offset is used in determining the
beginning address of the corresponding row within the table. Each row
contains a number of "break-points", and has the following format:
Table 11-6
Table 11-6: Row format
N specifies the number of breakpoints contained in the row. The row
whose address is contained in the energy pointer table entry
identified by the event's Energy value is scanned to locate the first
breakpoint whose TOFlow and TOFhigh values bracket the 11-bit TOF
value from the event packet. The bin number contained in the 8-bit bin
number field of the corresponding breakpoint identifies which one of
19 bins should be incremented in the histogram to which this event
maps. A bin number of 0 corresponds to a background box. If the TOF
value for the event does not fall within any of the breakpoints, then
the event is treated as a background event and mapped to bin 0.
11.4.3.6 N2 and D_N2
N2 (and D_N2) are identical to their N1 counterparts except that they
are typically sampled much more frequently (every 15 or 60 seconds)
and only some of the L and C rates are present:
- Only L01,02,03,04,08,09,13,14 are present
- Only C00,02,03,05,06,07,08,09,10,13,14,15,16,17,22,23,24 are present
11.4.3.7 (D)_N(1/2)_STATUS
All the STATUS extensions contain the same quantities for their
respective coverage periods.
STAT00 STATINT Status interval (seconds)
STAT01 MACBLCKS Number of macro blocks fre
STAT02 TLMVOL Telemetry volume produced
STAT03 WTCHADDR Memory watch address
STAT04 WTCHMEM Watched memory (pg. no)
STAT05 WTCHDATA Watched memory
STAT06 PEPSWVER Software version number
STAT07 ALARMID Latest Alarm Id
STAT08 ALARMTYP Latest alarm type
STAT09 ALARMCNT Count of alarms
STAT10 CMDEXEC Commands executed
STAT11 CMDREJCT Commands rejected
STAT12 MACEXEC Macro commands executed
STAT13 MACREJCT Macro commands rejected
STAT14 MACROID Id of most recent macro executed
STAT15 MACROLRN Macro learn mode
STAT16 MONRESP Monitor response
STAT17 WRITEENB Memory write enable
STAT18 HVPSCURR HVPS current
STAT19 HVPSVOLT HVPS voltage
STAT20 BIASCURR Bias current
STAT21 BIASVOLT Bias voltage
STAT22 PEPSTAT PEPSSI status word
STAT23 DVOLTP5 +5V digital voltage
STAT24 AVOLTN5 +5V analog voltage
STAT25 VOLTP2 +2.5V voltage
STAT26 VOLTN5 -5V voltage
STAT27 VOLTP15 +15V voltage
STAT28 VOLTN15 -15V voltage
STAT29 DCURRP5 +5V digital current
STAT30 ACURRP5 +5V analog current
STAT31 CURRP2 +2.5 volt current
STAT32 CURRN5 -5V current
STAT33 CURRP15 +15V current
STAT34 CURRN15 -15V current
STAT35 PRIMCURR Primary current
STAT36 LVPSTEMP LVPS temperature
STAT37 ENGYTEMP Energy temperature
STAT38 HVPSTEMP HVPS temperature
STAT39 ADDR12C I2C read command address
STAT40 RSLT12C I2C read command result
11.4.4 Bad Time Intervals (BTIs)
Various instrument conditions can make the PEPSSI data difficult or
impossible to use for scientific purposes. Powering down, ramping the
high voltage power up or down, running in diagnostic mode, etc. will
all make the PEPSSI data unusable for standard analysis. The
"PEPSSI_BTI.txt" file contains a tab-separated list of "Bad Time
Intervals" which should not be used for science analysis. It should
be noted that the entire "Launch" phase of PEPSSI data is classified
as a BTI.
While not actually a BTI, the period between 2007 day 144 and day 178
should be treated with caution as well. The PEPSSI Rate Box tables
were changed on day 144 and calibration and analysis of this period is
still preliminary.
11.4.5 L3Data Format
The L3 Files contain calibrated scientific data in an easily
accessible form. There are three basic types of data in the L3 files:
Quick-Look, flux-calibrated Rate Data, and calibrated PHA data. As
with the L2 files, each file contains one UTC day's worth of data. No
Diagnostic mode data is present in the L3 files. No "multi-hit" data
is present in L3 files. Only N2-telemetered PHA data is present in L3
files.
The Level 3 files are meant to be, as much as possible,
self-documenting. All calibration constants, calibration formulas,
and physical units should be present in the FITS header in an easily
readable format. It should be possible, albeit with a lot of work, to
reproduce the Level 3 files independently from the Level 2 files using
the information in the Level 3 headers.
11.4.5.1 Primary HDU: Rate Weighted 2-D Histogram
The image in the primary array of the L3 file is a rate-weighted 2-D
histogram of the PHA data for that day binned in calibrated deposited
energy. It represents a "best available" overview of the day's most
detailed high energy ion data.
The priority scheme distorts ion abundances, so we correct for that by
using a "rate-weight" rather than a single count. For each period of
600 seconds, we divide the counts reported in the N2 rate box by the
number of PHA events observed in that rate box. This is the weight
those events are then assigned in constructing the histogram (see
figure 8 for comparison of weighted and unweighted histograms). The
two axes: energy deposited in the SSD and time of flight, are simple
linear calibrations of the measured values. The calibration
parameters are reported in the primary FITS header.
11.4.5.2 Quick Look Spectrograms
The extensions: SPEC_Protons, SPEC_Helium, SPEC_Heavies,
SPEC_Electrons, and SPEC_LowIon, contain quick-look spectrograms of
their respective species. These spectrograms present counts/second N2
data, averaged over 60 second intervals and summed over all incidence
directions (i.e. "Sectors"). 60 seconds is, except for the first hour
of the day, the default accumulation interval of N2 data (Before 2007
day 42, the default N2 accumulation interval was 30 seconds). The
x-axis of the spectrograms is hour of day. On the y-axis each pixel
represents a different rate (e.g. B00, L01, R02, etc.). Nominal
deposited energies of the rate boxes (or, in the case of Low-Ions,
nominal time of flight bins) are given in the FITS header.
11.4.5.3 FLUX
This HDU contains calibrated fluxes, uncertainties, and raw counts/sec
rates for all of the High Energy Ion and Electron N2 Rate data. There
is also an accumulation time column (DT) and three timing columns.
IMPORTANT NOTE: The UTC YEAR and DAY_OF_YEAR columns are only
included for convenience in plotting. DO NOT USE THEM for precise
timing as there could be leap-second ambiguities in them. Use the
ephemeris time (ET) column if precision is important.
For some Rate Boxes, the exact particle species is undeterminable.
They contain both Oxygen and Sulfur. Separate calibrations are
supplied for Oxygen and for Sulfur. The Rate Box name is modified by
appending an "O" or an "S" respectively in the FITS table column name.
All of the quantities used in the calibration of the flux measurement,
including their uncertainties are included in keywords in the FITS
header. A description of the calibration procedure follows.
IMPORTANT NOTE: Calibration work on the PEPSSI instrument is ongoing.
Uncertainties in some quantities (particularly efficiency) are still
very large.
11.4.5.3.1 FLUX Calibration Procedure
We calculate the differential intensity j (1/cm2sr-s-keV) in terms
of the counts C, time coverage T (s), geometric factor G (cm2sr),
upper and lower energy bounds Ehi and Elo (keV), and detection
efficiency eta, Equation 11-8.
Equation 11-8
A "pseudo-code" version of the actual calculation code used is given
in COMMENT keywords in the FITS header.
Note on the correlation of the errors in E_lo and E_hi:
To zeroth order, we can treat the errors on E_lo and E_hi as
uncorrelated. One pragmatic reason is that it is a conservative
assumption; if we are wrong then we are overstating the errors (at
most by a factor of Root(2). Also, there are times when the uncertainty
in E_lo or E_hi will be quite uncorrelated. For example the E_lo could
depend on our understanding of the SSD threshold, while the E_hi could
depend on our estimate of how fast the spectrum will be falling, both
very different things. The most problematic case (from an error
propagation point of view) would be where we believe we know the
passband width delta(E) very well but we are not sure of the absolute
energies. We think most of these potential cases are taken care of in
the channel-to-Edeposit calibration (which establishes the scale)
whereas most of the potential cases of uncorrelated errors in E_lo and
E_hi occur in the E_deposit-to-E_incident calibration.
11.4.5.3.2 Derivation and Explanation of Calibration Table Values
In this initial delivery of the PEPSSI data from the Launch and
Jupiter phases of the New Horizons mission we have supplied values to
convert the instrument specific data (e.g., count rates) into physical
instrument-independent units (e.g., differential intensity), as well
as computing the physical quantities themselves. It must be stressed
that these are preliminary values that should not be used without
significant effort from the user to understand the limitations (see
section 11.4.5.3.1 for a description of the method used to calculate
differential intensity, also called flux).
The calibration quantities are energy pass-band (delta(E) = E_hi - E_lo, lower
and upper limit of the energies of the particles measured),
measurement efficiency (eta, the fraction of valid incident particles
that are actually measured), the geometry factor (G, the measurement
of the physical detector size and solid angle subtended by the field
of view). These values are all given and applied with uncertainties
in the Level 3 files.
The energies are incident energies. Incident energy is the energy the
particle has just before entering the instrument aperture absent the
effect of the ~3 kV accelerating potential, which would induce a
charge dependent energization. These energies were determined using a
Monte Carlo technique that includes the energy loss as the particles
trace through the entire system: start foil, free time-of-flight area,
stop foil, dead layer, and energy defect. Losses through the foils are
simulated and traced, as well as trajectory aberrations due to angular
scattering. The energy defect for every particle and energy is also
estimated by the SRIM code and checked with real data, where
available. Some ground calibration of protons was also included. The
uncertainties were not quantitatively determined from this modeling
and measurements but are rather estimated from the known differences
between various techniques. The geometry factors are derived from the
same technique with similarly non-quantitative errors. These
calibration values, although the uncertainties have not been estimated
quantitatively, we consider appropriate to use for scientific study.
The largest uncertainty in the calculated PEPSSI fluxes in the Level 3
data is due to the efficiency determination. PEPSSI, like most
particle instruments (excluding sensors that rely only on solid state
detectors and measure relative high ~> 1 MeV/nuc particles), is far
from 100% efficient. This is due in large part to the "foil
efficiency," which is the fraction of incident ions that result in
secondary electrons that are detected by the micro channel plate
(MCP). This efficiency is dependent on the voltage established across
the MCP. So there are at least two primary physical processes
involved (a) the probability that there are any secondary electrons
emitted from the foil and (b) the probability that any resulting
electrons are steered towards the MCP and multiplied to a sufficient
current conducted to the anodes and that this signal triggers the
start or stop disciminators.
We can determine this through a combination of ground measurements,
through analysis of the in-flight calibration alpha-particle source,
modeling, and through intercalibration with known measurements.
Before we can confidently report absolute fluxes, we must do all of
these things. Currently we have only employed the final method, which
has the obvious drawback of not providing an independent determination
of the absolute flux. Therefore the fluxes provided in the Level 3
data should not be used as is to conduct science that is relying on
absolute fluxes for scientific interpretation unless the user
determines the fluxes independently and with full knowledge of the
care that must be taken.
In addition to these issues, a further consideration must be taken
into consideration. The PEPSSI instrument was specifically engineered
to make low rate measurements. This means that whenever there was a
trade off between engineering effort, electronic components, power
usage, mass, and volume, and ability to make high rate measurements,
the later was given relatively low priority. For example, the CPU was
selected for it's low power consumption, which means that there is an
upper limit to the total number of events that can be processed.
Therefore the user has to be aware that saturation of the rates can
take place and that the saturation does not have to be uniform across
different rates. It is possible during high rate periods for a large
number of triple coincidence ions, for example, to impeded the
processing of electrons.
It is for this reason that it is very difficult to provide a single
set of calibration values for this phase of the mission. We have
provided what we have now and intend to continue to improve our
knowledge and deliver the improved calibration information with
subsequent updates to the PDS archive
11.4.5.4 PHA Data
The three PHA extensions: PHA_ELECTRON, PHA_LOW_ION, and PHA_HIGH_ION
contain the PHA event data. As in the L2 data, each row represents a
single PHA event. Events with the multi-hit (cross talk) flag set
have been excluded. Quantities of limited usefulness (such as Heavy
Ion Discriminator triggers) have been excluded. Because of the
difficulty of removing priority scheme biases from non-N2 PHA data,
only N2 (APID == 0x692) PHA data is present in the L3 files.
Calibrated Deposited Energy and/or Time of Flight values are given.
The linear calibration constants and formulas are in the FITS headers.
A Speed column is calculated from the Time of Flight assuming a 6.0cm
flight path.
The Rate Box classification for each event is given in the Rate_Box column.
The PHA_HIGH_ION extension contains additional columns:
The H_Incident_Energy, He_Incident_Energy, O_Incident_Energy, and
S_Incident_Energy columns contain the calculated Incident energy
assuming that the event is of that (H, He, O, or S) species.
The Rate_Normalized_Weight column has removed Priority Group artifacts
from the PHA data by the procedure described in the Primary HDU
section above. This column is usually used in making histograms of
the High Energy Ion PHA data.
11.4.6 Memory Required
1 GB memory and a 3 GHz Pentium is sufficient for processing.
11.4.7 Temporary File System Space Needed
The Pre-Level 2 files require up to 50MB per day's worth of data.
11.4.8 Predicted Size of Output File(s)
Level 2 files are in the range 1MB - 30MB. Level 3 files are
typically 5-6 times larger than the corresponding Level 2 file, but
only range up to a maximum of around 50MB.
11.4.9 Predicted Execution time
Less than a minute per file, typically. The L1 to Pre-L2 conversion
takes a few seconds per file. The entire Jupiter phase takes 40
minutes to convert from Pre-L2 to L2 and L3 files on a Red Hat Linux
machine with 4 4GHz Xeon processors. It's not known how much
parallelization was actually responsible for the speed.
11.4.10 Contact/Support Person(s)
Stefano Livi, Matthew Hill, Martha Kusterer, Larry Brown and Reid
Gurnee
11.4.11 Maintenance Schedule (Code/Data Updates, Documentation)
As calibration data is collected during flight, the level 2 pipeline
code will require updates either to calibration files or to code for
bug fixes or enhancements.
Figure 11-2: Location of PEPSSI on the New Horizons spacecraft. The
lightly shaded area denotes PEPSSI Field-of-View (FOV)
Figure 11-3: Schematic drawings of the PEPSSI sensor
Figure 11-4: A cut-away view of the PEPSSI FOV.
Figure 11-5: Expanded view of the PEPSSI sensor.
Figure 11-6: Pepssi Layout labelling
Figure 11-7: PEPSSI Rate Boxes on the TOF vs Energy Plane. Normal Mode.
Figure 11-8A: 2D PHA Histogram: No weighting. Note: artifact in high
energy protons (Box B03).
Figure 11-8B: 2D PHA Histogram with Rate-Weighting applied.
12. REX INSTRUMENT DESCRIPTION
12.1 Overview
The REX instrument is unique among the suite of instruments comprising
the New Horizons payload in that it is physically and functionally
incorporated within the spacecraft telecommunications subsystem.
REX consists of both a 'Flight Element' carried onboard the New
Horizons spacecraft, and a 'Ground Element' made up of existing
NASA Deep Space Network (DSN) transmitting and operations
facilities.
The primary purpose of the REX system is to investigate open questions
regarding the atmospheric and ionospheric structure, surface
conditions, and planetary radii of both Pluto and Charon. Secondarily,
New Horizons will attempt to observe any Kuiper Belt Objects (KBOs) it
encounters on its journey towards interstellar space . These
investigations fulfill many of the science objectives addressed in
NASA's Announcement of Opportunity (AO) document AO-OSS-01, which
defined the mission objectives for the Hew Horizons mission to Pluto.
REX is designed to fulfill the AO objectives by performing the
following distinct experiments:
1. A radio occultation experiment designed to detect and measure the
atmospheres and ionospheres of Pluto and Charon. The experiment
will be used to deduce, from phase changes in the uplink signal,
atmospheric temperature and pressure profiles down to the surface
of Pluto (and Charon, should it be found to have a tenable
atmosphere), and electron and ion densities of Pluto's (and
possibly Charon's) ionosphere.
2. A radiometry experiment, designed to measure the hemispherically
averaged surface emission brightness at a wavelength of 4.2 cm
(7.182 GHz, the nominal operating frequency of the New Horizons
radio). The dark-side emissions will be measured during the
occultation interlude. The day-side emissions will be measured as
is operationally feasible.
3. Accurate tracking of Doppler shifts in the transmission frequency
of the New Horizons transceiver will be used to deduce
gravitationally induced changes in velocity along the spacecraft's
flight path, thus measuring the gravitational fields of Pluto and
possibly Charon. The physics underlying these experimental
techniques and the details of the measurements themselves are
outlined in the New Horizons REX Users Manual.
The heart of the REX instrument is an Actel Field Programmable Gate
Array (FPGA) that takes samples of the downconverted & digitized
intermediate frequency (IF) receiver output and generates wideband
radiometer and narrowband sampled signal data products. The REX
hardware also includes an analog-to-digital converter (ADC) and other
direct interface components, and by extension all of the RF
telecommunications system hardware along the uplink (receive) path
from the High Gain Antenna (HGA) to the input to the ADC.
Stanford is responsible for the FPGA design and system analysis. APL
is responsible for the design of the telecommunications system and
incorporating the REX FPGA system therein.
The interfaces to the REX FPGA (see Fig. 12-1) include a 30 MHz clock
signal from the Ultra-Stable Oscillator, (USO), the secondary power
connections, the command and telemetry data interfaces to the Uplink
Card, the high-speed data interface to the Instrument Interface Card,
a 1 PPS signal for data framing, and the interface to the ADC, where
the wideband IF signal from the Uplink Card is sampled.
Figure 12-1: Electrical Interfaces to the REX FPGA
The input to the REX FPGA is normally the uplink signal from the DSN
after being filtered by a 4.5 MHz banpass filter (not shown) and
digitized by the ADC at a sample rate of 10 Msamples/s. The Input
Select function, commandable via uplink, allows the FPGA to process
any of seven predetermined digital signals for testing the FPGA
functionality (see the ROF Status Byte section below).
12.2 Raw Data Specifics
After receiving the command to start taking data, the REX FPGA, on the
1PPS strobe from the spacecraft clock, generates a continuous stream
of data containing In-Phase & Quadrature-Phase value pairs as well as
integrated radiometer values. This stream of data is divided into
fixed-length units called REX Output Frames (ROF) at a rate of one ROF
per 1.024 seconds. The ROFs are stored on the spacecraft solid state
recorder (SSR), and eventually played back via the High-Speed
Telemetry interface to the DSN and arrive at the SOC as raw telemetry
packets.
REX continues to produce ROFs until turned off. Each ROF contains
Time Tags that may be used to verify that a sequence of ROFs is a
contiguous set.
12.2.1 Raw Data Format
The SOC Raw pipeline decommutates each ROF from telemetry and places
it into the Primary Data Unit (PDU) of an individual FITS file. Each
PDU is stored as a one-dimensional image of 5088 bytes: the first
5082 bytes are the ROF; the last 6 bytes in the PDU are spare.
The SOC Raw pipeline also looks in the telemetry for packets
corresponding to the time of the ROF, and places them in EDU.
Specifically, data from spacecraft housekeeping ApIDs 0x004, 0x016,
0x084 and 0x096 as well as from Thruster packets are placed in EDUs 1
through 5, respectively, of the Raw FITS files.
12.2.1.1 PDU Content
Each ROF contains the items listed in Table 12-1 in an interleaved
format.
Table 12-1
Table 12-1: REX Output Frame Contents
12.2.1.1.1 ROF ID byte
The ID byte is the first byte in the ROF and should always have the
same value; see Table 12-2.
Table 12-2
Table 12-2: REX Output Frame ID byte value
12.2.1.1.2 ROF Status byte
The ROF Status byte is the fourth byte in the ROF. In bit positions
6, 5 & 4 it contains the three bits that make up the Input Select
setting for the ROF; all other bits are normally zero. When Input
Select is set to any of its non-zero values, the ADC output is
replaced as the FPGA input with a predetermined 10Msample/s signal as
described in Table 12-3. In that case, the ouptut of the REX FPGA
should be deterministic and known, and may be compared bit-for-bit
against the expected ouput as a limited check on the health of the
FPGA as well at that of the Input Select system.
Table 12-3
Table 12-3: REX Input Select & Status Byte values
12.2.1.1.3 Integrated Radiometry values
The details of how incoming power is used as radiometry are given in Tyler et al., 2007.
The FPGA integrates the incoming power from its input signal by squaring and summing the ~10Msamples/s that compose its input. Ten accumulating radiometry values are stored in each ROF, and the FPGA resets the value to zero at the start of each ROF. Each radiometry value comprises 40 bits, or 5 bytes, as an unsigned integer, and the bytes are in MSByte-first order, interleaved with I&Q values.
The time interval between radiometry values is one-tenth of a ROF or 102.4ms. In each ROF, REX stores a integrated radiometry value at the start time of that ROF (and not 102.4ms after its start), so the tenth, or last, radiometry value of associated with a ROF (i.e. the one that represents a full 1.024s of integration time) is actually stored as the first radiometry value in the following ROF.
12.2.1.1.4 Time Tag values
REX places ten incrementing time tags in each ROF. The first time tag of the first ROF after a start command is zero, and the following time tags increment by one. Unlike the integrated radiometry values, the time tag is not reset at the start of each ROF. Each time tag values comprises 24 bits, or 3 bytes, as an unsigned integer, and the bytes are in MSByte-first order, interleaved with I&Q values. Each increment of the time tag represents 102.4ms, so the rollover time is just under a fortnight and a half.
The time tags can be used both to identify any breaks in a sequence of ROFs, and to determine the time between any two ROFs in a sequence.
12.2.1.1.5 I & Q value pairs
Each ROF contains 1250 pairs of In-Phase (I) & Quadrature-Phase (Q)
values. Each I value and each Q value comprises 16 bits or two bytes
as a twos-complement signed value.
The process of down conversion from 10 Ms/s is accomplished by
heterodyning to zero frequency the uplink carrier signal centered
initially at the 2.5MHz Intermediate Frequency (IF) center frequency,
followed by use of time-invarient baseband filters to reduce the
bandwidth. The details are too extensive to include here, but are
explained in detail in Tyler et al. (2007).
12.2.1.2 PDU Data layout: Interleaving
In each ROF, the bytes of the ID, Status, Radiometry and Time Tag
values are interleaved with the I&Q value pairs, but none of the
values start or end on other than a byte boundary. There are two ways
to describe such an arrangement: describe the layout of the ROF as
built out of a sequence of bytes extracted from the de-interleaved
data values (ID, Status, Radiometry, Time Tag, I&Q); describe the
layout of the data values as a sequence bytes from the ROF. Both
methods will be used here, the latter first as it lends itself more
easily to writing computer code to extract the data values from the
ROF. Indeed, an IDL(tm) routine to extract ROF data value exists with
less than two dozen lines.
The I&Q value pairs use up over 98% of the space in each ROF; this
suggests that describing the data layout of the other data values will
take less time and leave the I&Q values as "everything else."
Table 12-4
Table 12-4: Summary of ROF data value positions and offsets
This section uses the notation in Table 12-5 to describe and or locate
the various quantities in the ROF:
Table 12-5
Table 12-5: Notation used in this section
12.2.1.2.1 Layout of ID & Status bytes
The ID and Status bytes are the first and fourth bytes in the ROF, respectively, and can simply be obtained from the ROF as such as there are no following bytes or values:
ID byte = ROF[1]
Status byte =ROF[4]
12.2.1.2.2 Layout of Radiometry
The first byte of the first radiometry value is the seventh byte of the ROF, and the following four bytes of that first radiometry value are each offset by three bytes from the previous byte. The order is MSByte-first. So, the first radiometry value of a ROF may be calculated from the following formula:
R[1] = ( ( (ROF[7] * 256 + ROF[10]) * 256 + ROF[13]) * 256 + ROF[16]) * 256 + ROF[19]
The following radiometry values' bytes in the same ROF are each offset 508 bytes from the previous radiometry value's bytes. So, more generally:
R[i]=(((ROF[7+Oi]*256 + ROF[10+Oi])*256 + ROF[13+Oi])*256 + ROF[16+Oi])*256 + ROF[19+Oi]
12.2.1.2.3 Layout of Time Tags
The first byte of the first time tag value is the 22nd byte of the
ROF, and the following two bytes of that first radiometry value are
each offset by three bytes from the previous byte. The order is
MSByte-first. So, the first time tage value of a ROF may be
calculated from the following formula:
T[1] = (ROF[22] * 256 + ROF[25]) * 256 + ROF[28]
The following time tag values' bytes in the same ROF are each offset
508 bytes from the previous radiometry value's bytes. So, more
generally:
T[i] = ( ROF[22+Oi] * 256 + ROF[25+Oi] ) * 256 + ROF[28+Oi]
12.2.1.2.4 Layout of I & Q values
The bytes that are used to store the I & Q values alternate in
sequence (I[1], Q[1], I[2], Q[2], I[3], Q[3], ..., I[1250], Q[1250])
as 16-bit MSByte-first two's complement signed integers, that cover
all of the bytes not used by the other values (ID, Status, Radiometry,
Time Tags) above.
Specifically, Table 12-6 describes how ROF bytes are used to calculate
I[K] and Q[K] for K=1 to 1250:
Table 12-6
Table 12-6: I & Q values from ROF
Where Function IQ(MSByte,LSByte) is defined as (with MSByte & LSByte
interpreted as unsigned 8-bit - i.e. 1-byte - integers)
IQ(MSByte,LSByte) = 256 * MSByte + LSByte
if MSByte is between 0 and 127 inclusive. Otherwise, it is defined as
IQ(MSByte,LSByte) = 256 * MSByte + LSByte - 65536
12.2.1.3 Layout of ROF
The tables below have one cell per ROF byte, and indicate which data
values (ID, Status, Radiometry, &c) each byte contributes to. The
order of bytes in these table is left-to-right and down i.e.
ROF[1] ROF[2] ROF[3]
ROF[7] ROF[8]
ROF[9] ROF[10]
... ...
The first six ROF bytes contain the ID & Status bytes and the first I&Q pair:
ID I[1][MSB] I[1][LSB]
Status Q[1][MSB] Q[1][LSB]
The next 508-byte "chunk" (ROF byte order is left-to-right then down)
contains one Radiometry value, one Time Tag, and 125 I&Q pairs:
R[1][39:32] I[2][MSB] I[2][LSB]
R[1][31:24] Q[2][MSB] Q[2][LSB]
R[1][23:16] I[3][MSB] I[3][LSB]
R[1][15:8] Q[3][MSB] Q[3][LSB]
R[1][7:0] I[4][MSB] I[4][LSB]
T[1][23:16] Q[4][MSB] Q[4][LSB]
T[1][15:8] I[5][MSB] I[5][LSB]
T[1][7:0] Q[5][MSB] Q[5][LSB]
I[6][MSB] I[6][LSB]
Q[6][MSB] Q[6][LSB]
I[7][MSB] I[7][LSB]
Q[7][MSB] Q[7][LSB]
I[8][MSB] I[8][LSB]
Q[8][MSB] Q[8][LSB]
... ...
I[126][MSB] I[126][LSB]
Q[126][MSB] Q[126][LSB]
The rest of the ROF comprises 9 more chunks of 508 bytes per chunk,
essentially identical to the one above, incrementing the R[] & T[]
indices by one per chunk, and incrementing the I[] & Q[] indices by
125 per chunk. Each chunk except the last contains 125 I&Q pairs;
N.B. the tenth chunk ends after its 504th byte and after its 124 I&Q
pair which is the 1250th, and last, I&Q pair of the ROF.
12.2.2 Data Sources (High/Low Speed, CCSDS, ITF)
REX data are in the high-speed stream and come to the SOC in CCSDS packets.
12.2.3 Definition of an "Observation"
One REX Output Frame (ROF), as defined above, is an observation.
12.2.4 Housekeeping in Raw FIT files' extensions
The Raw pipeline puts information from several types of housekeeping
(HK) packets into Extension Data Units (EDUs) 1 through 5 (see Table
12-7). The pipeline attempts to find the closest HK packet to the
observation time. If no packet is available, the EDU is not present
and the corresponding Extension Header Unit (EHDU) will indicate a
zero-sized EDU.
Table 12-7
Table 12-7: REX RAW FITS extension Numbers, Names, Calibration
relevance, & Descriptions
Extension with values used in the calibration have "Yes"
in the "Cal" column.
Note 1: The SSR Sector Header information is only present in REX data
with ApID 0x7b1 in the FITS filename.
The presence of ApID 0x004 housekeeping indicates Side A is active,
and the presence of ApID 0x084 housekeeping indicates Side B is
active. If neither 0x004 nor 0x084 housekeeping is present, then the
data will not be calibrated.
12.2.5 Raw Science Data and/or Housekeeping Requirements
Radio receiver housekeeping (ApIDs 0x004 and/or 0x084 noted above).
12.3 Calibration Specifics
12.3.1 Calibration Algorithms
The conversion of RAW REX data to Calibrated data is concerned with
two data streams from REX:
(1) the REX filter output, comprising 16-bit samples at 1250 samples
(complex) per ROF, i.e., 1250 In-phase samples per ROF and 1250
Quadrature-phase samples per ROF, and
(2) the Radiometer output, comprising 40-bit samples at a rate of 10
samples per ROF, and
(3) the Time Tag
12.3.1.1 Calibrating the REX filter output: In-phase &
Quadrature-phase values
The conversion of the I/Q samples from the raw DN to calibrated
physical units (milliVolts) involves applying a gain independent
scaling, since the FIR process producing the samples has no adjustable
parameters.
The algorithm takes each two ROF bytes that represent a single filter
output value and does the following:
12.3.1.1.1 Combine the unsigned bytes into a two's complement
16-bit signed integer filter value
FilterValue = ( I[MSB] * 256 ) + I[LSB]
IF FilterValue > 32767 THEN FilterValue = FilterValue - 65536
The example above is for In-Phase filter values; the procedure for
Quadrature-phase values is identical.
12.3.1.1.2 Scale the filter value by the calibrated reference voltage
VIorQ = (1000 / (2^15)) * FilterValue
N.B. As noted below, this scaling factor is only stored in the FITS
EHDU for these data, and the 16-bit data values are what are stored in
the EDU calibrated FITS file.
12.3.1.2 Calibrating the REX Radiometry
The formula for converting the Raw REX radiometer data to power, in
units of dBm, is as follows:
Prad = -172 + 10 * log10(sample) - Ro - (AGC - AGCoffset) * dBstep
Where
sample = Combined unsigned integer value of five radiometry bytes
from ROF
AGC = AGC Voltage from whichever REX Side, A or B, is active
- REX side A active => CDH_PLL_AGCV_1 from ApID 0x004
- REX side B active => CDH_PLL_AGCV_2 from ApID 0x084
- The calbration pipeline uses whichever ApID is in the
Raw FITS file extensions
AGCoffset = REX Side-dependent constant AGC Voltage offset: 2512 if
Side A; 2504 if Side B.
Ro = Constant: 96.870
dBstep = Constant: 0.475
Since the Radiometry is integrating, or accumulating, instantaneous
power values and saving ten accumulations per ROF, only the tenth
value, integrated over the full ROF of about 1s, can be thought of as
being in units of dBm or dB relative to 1mW. All of the previous
values should be divided by the time since the accumulation was reset.
Also, it was noted above that the tenth accumulated value for each ROF
is actually stored as the first Radiometry value in the next ROF.
Perhaps units of dBj would be more accurate.
The formula for dBm above can be rearranged to convert the Raw value
to mW as follows:
Prad_mW = sample * 10-(172 + Ro + (AGC - AGCoffset) * dBstep) / 10
OR
Prad_mW = sample * K
where
K = 10-(172 + Ro + (AGC - AGCoffset) * dBstep) / 10
and all other symbols are the same as above.
N.B. As noted below, the scaling factor K is only stored in the FITS
header for these data, and the 40-bit data values for sample, in
double precision IEEE form, are what are physically stored in the
calibrated FITS file.
12.3.1.3 Calibrating the REX Time Tags
The time tags are 24-bit integers that increment ten times per ROF
frame of 1.024s and represent the time since the first contiguous ROF
frame in a sequence (or, in the unlikely case of REX taking data for
more than about a fortnight and a half, from the last Time Tag
rollover), so the formula to convert from the 24-bit Time Tag value
TTraw to seconds is
Ts = TTraw * 0.1024
N.B. As noted below, the scaling factor 0.1024 is only stored in the
FITS header for these data, and the 24-bit data values for TTraw, in
double precision form, are what are stored in the calibrated FITS
file.
12.3.2 Calibrated FITS file data format
The calibrated data from each ROF are stored in a single FITS file.
The PDU is empty, and all data are stored in FIT extensions. This
section gives the details of the extensions.
12.3.2.1 Extension Data Unit (EDU) 1: I & Q values
The first extension of the Calibrated FITS file is a FITS BINTABLE, or
binary table, containing the calibrated I&Q value pairs in mV. The
table has two columns (I & Q) and 1250 rows.
N.B. Because the conversion from the raw integer form to the
calibration unit of mV is a linear factor, the values physically
stored in the Calibrated FITS file are the 16-bit integer results of
the first step of the calibration described above. The scaling factor
applied in the calibration is actually only stored in the FITS
BINTABLE header TSCALn keywords. From there, most FITS readers will
apply the factor when reading the data, but any user writing their own
FITS reading software should be aware of the presence and application
of this scaling factor.
12.3.2.2 EDU 2: Radiometry & Time Tags
The second extension of the Calibrated FITS file is also a FITS
BINTABLE, containing the ROF's Radiometry values in dBm, the Time Tags
in seconds, and the Radiometry values in mW. The table has thre
columns (Radiometry in dBm; Time Tags in seconds, and Radiometry in
mW).
N.B. Because the conversion from the raw integer form to the
calibration unit of seconds and mW in the second and third columns
(but not dBm) is a linear factor, the values physically stored in the
Calibrated FITS file are the integral values from combining the Raw
bytes, stored as double precision IEEE floating point numbers. The
scaling factors applied in the calibration is actually only stored in
the FITS BINTABLE header TSCALn keywords. From there, most FITS
readers will apply the factor when reading the data, but any user
writing their own FITS reading software should be aware of the
presence and application of this scaling factor.
12.3.2.3 Additional FITS Extensions (planes) and Their Definitions
After EDUs 1 & 2, any extensions (housekeeping, thrusters, SSR info),
from the Raw FITS file for each ROF are carried over to the
corresponding Calibrated FITS file. Table 12-8 describes those
extensions.
Table 12-8
Table 12-8: REX RAW FITS extension Numbers, Names, Calibration
relevance, & Descriptions
12.3.2.4 Scientific Units
The units of the calibrated values, after applying the scaling factors
if present, are as follows:
Filter output: Voltage (mv)
Radiometry: Power (dBm and mW)
Time Tag: Time (s)
12.3.2.5 Additional FITS and PDS Keywords
12.3.2.5.1 Radiometry calibration provenance added to PHDU
A summary of the Radiometry calibration is added to the Primary Header
Data Unit (PHDU), using the prefix RAD for the keywords. The
information in this summary includes
- the formula
- the AGC voltage
- which REX side was assumed to be active (A or B)
- the value of all constants used in the formula (AGCoffset, Ro, dBstep).
12.3.2.5.2 FITS keywords added to EHDU 1
The average power, the ID byte, the Status byte and a decoded version
of the Status byte (indicating the input select setting) are added to
EHDU 1.
12.3.2.5.3 Scaling parameters
As noted above, the linear calibrations are achieved by physically
placing the Raw integer values into the FITS binary tables and
providing scaling factors (FITS keyword TSCALn) in the corresponding
EHDUs. These scaling parameters are also present in the PDS labels
for the PDS archive (PDS keyword SCALING_FACTOR).
12.3.3 Hardware/OS Development Platform
PC/Linux
12.3.4 Language(s) Used
IDL
12.3.5 Third Party Libraries Required
cfitsio (if C used) or ASTRO (if IDL used)
12.3.6 Calibration Files Needed (with Quantities)
None; all calibration factors are in the source code and listed above.
12.3.7 Memory Required
< 128MB
12.3.8 Temporary File System Space Needed
None.
12.3.9 Predicted Size of Output File(s)
< 70 Kbyte
12.3.10 Predicted Execution time
Less than a second per ROF
12.3.11 Contact/Support Person(s)
Ivan Linscott
12.3.12 Maintenance Schedule (Code/Data Updates, Documentation)
None planned; something may come out of the PDS review.
13. SDC INSTRUMENT DESCRIPTION
13.1 Overview
The mission of the Venetia Burney Student Dust Counter (VSDC) is to
analyze the size and distribution of dust particles along the New
Horizon's trajectory to the Kuiper Belt. The SDC instrument
consists of the front end analog electronics, the digital interface
electronics, the detector panel, and the intraharness.
Each particle impact on one of the 12 active SDC detectors will be a
candidate for a science event. This impact causes a depolarization
signal in the Polyvinylidene Flouride (PVDF) detector film dependent
on the size and speed of the particle. This signal gets converted to
a digital number via the electronics. If the amplitude is above the
value at which the threshold is currently set, then the signal is
stored in memory as a science event along with other relevant
housekeeping data.
These depolarization signals are measured in charge (Q) produced (Note
that SDC reports charge in number of electrons. Even though this is
not strictly charge, the number of electrons will from here on be re-
ferred to as the charge). The charge from an impacting particle
depends on the particles mass and velocity. Because the unit of the
raw data is data number (DN), a calibration curve from data number
to charge (DN=>Q) is needed. This curve is a function of box
temperature and detector channel. For SDC, this curve was produced
pre-flight and is checked during the mission with internal calibration
procedures. The DN=>Q calibration curves are shown in Figure 13-7.
The calibrated files are derived from the raw files through these curves.
13.2 Raw Data Specifics
The raw data are unprocessed telemetry. At the SOC and PDS, all
levels of data are recorded in FITS format. The SDC team uses IDL for
our data processing and hence would like to be able to load these FITS
files into IDL as structures/arrays, etc. To do this we typically use
an IDL fits reader which can be found in the Goddard IDL library.
Specifically we use mrdfits.pro. If this is used, please note that a
"/unsigned" flag must be given as the data are all unsigned integers.
The raw data FITS file consists of housekeeping and science data.
Some of these data are not used in the calibration process to produce
the calibrated data. It stated in the PDS label files which telemetry
points are and are not used by the calibration process.
In addition to the IDL functions for FITS files, generic programs such
as fv can also be found. If opened in this program, the raw data
tables are displayed as in figure below.
Figure 13-1: Raw data tables as viewed by Fv.
13.2.1 Data Format
The data in the FITS file are stored as a binary table extension.
There are five tables in the raw file. These tables and their
columns are :
DATA -
1) Copy Number - Not used in calibration
2) Channel ID - Detector number (0-13) [Channel 10 has a
electrical issue and is not used for science. Channels 6 and 13 are
reference detectors. These detectors cannot detect real dust as they
are covered. For all higher level data products the channel IDs are
incremented by one and become 1-14.]
3) Zero Fill - Not used in calibration
4) Threshold - First note that this DN scale is reversed. This
means 65535 is a small event while 0 is a very large event. This
reverse scale is also true for the Magnitude described below. The
threshold value is the maximum (highest DN but smallest signal)
magnitude (see next item) for accepted hits. Hits above (smaller
amplitude) the threshold are rejected at the instrument level. These
thresholds are adjustable and vary from channel to channel. [Note
that it is SOMETIMES possible for a slightly smaller amplitude hit to
come in just above this value due to the way the software works].
5) Magnitude - The size of the hit in DN [Note that this scale is
also reversed. This means that 65535 is a small event while
0 is a very large event.]
6) Time Stamp - The time the hit was recorded in Mission Elapsed
Time (MET)
HOUSEKEEPING_SDC -
1) MET - Mission Elapsed Time
2) PanTemp A-D - Temperature recorded on the panel of SDC
3) BoxTemp 1-4 - Temperatures recorded on the electronics box of SDC
HOUSEKEEPING_0X004 - Values used in Calibration from this table:
1) CDH_PNL_A-D_TEMP - Temperature recorded on the panel of SDC
(Note these are the same as above)
2) CDH_ANA_A-B_TEMP - Temperature recorded on analog side of the
electronics box of SDC
3) CDH_ANA_DCDC_TEMP - Temperature recorded on DCDC
4) CDH_ANA_DCDC_TEMP - Temperature recorded on the FPGA
HOUSEKEEPING_0X00D - Values used in Calibration from this table:
d. MET - Mission Elapsed Time for the columns in this table
e. CDH_TEMP_SDC_ELEC - Electronics box temperature as recorded by
the spacecraft
f. CDH_TEMP_SDC_DET - Detector temperature as recorded by the spacecraft
HOUSEKEEPING_0X00A
1) MET - Mission Elapsed Time for the columns in this table
2) SDC_LVPS_VOLT - Voltage of SDC recorded by the spacecraft
3) SDC_LVPS_CURR - Current of SDC recorded by the spacecraft
THRUSTERS - Values used in this Table
- GC1_DATA_VALID_MET - MET of Thruster Fire
- GC1_RCS_FIRE_MINOR_1-24 - Tells whether one of the thrusters fired
13.2.2 Data Sources (High/Low Speed, CCSDS, ITF)
SDC data are low-speed CCSDS packets only.
13.2.3 Definition of an "Observation"
One observation is one collection of events in one CCSDS packet.
13.2.4 Housekeeping Needed in Level 1 Files (for Calibration)
See Section 13.2.1
13.2.5 Raw Science Data and/or Housekeeping Requirements
From launch to the end of the first month, HK packet METs should be
within 1 minute of a dust observation
From the end of the first month until Jupiter, HK packet METs should
be within 1 hour
From Jupiter until the end of the mission HK packet METs should be
within 1 day
For the redundant points, such as temperatures, only one of these
needs to satisfy this requirement.
13.2.6 Notes about Raw Data
1) The scale in DN is "backwards" on a 0-65535 scale. In other
words, a very large hit represent a number near 0. A small hit
registers as a number close to 65535
2) The threshold can be tuned and represents the minimum DN of a
detectable hit. HOWEVER, it is possible due to the way the
electronics work, that you might get a hit with a slightly
higher DN (smaller hit) than the threshold. Usually this is
no more than a few tens of DN higher than the threshold.
3) SDC has on-board flight rules for autonomously turning a
channel off. The user will then need to know when the
channel was on/off. This information is in a separate file
named sdc_on_off_times.dat.
4) The maximum number of recorded hits in one second on a given
channel for SDC is in general 3. The way the timing works
it is possible to get up to 5 hits/second. However, if more
than one hit is recorded in one second (instrument wide)
this is considered a coincident event and will be flagged.
The science processing interprets such an event as s/c noise
and removes it.
13.3 Calibration
The data calibration is a three-step process. The telemetry is stored
as raw DN. Each DN value representing the size of a hit is converted
into charge (see below). Mass is then derived from this charge via
the ground calibration results obtained at a dust accelerating
facility.
13.3.1 Pre-Flight Calibration Procedure- Charge
In a temperature controlled environment, the electronics from the end
of the PVDF to the DN in the raw data were calibrated, at each of 4
calibration box temperatures and for each of the 14 channels. This
was done by injecting 19 (actually 21; see below) fixed-amplitude
charge pulses 100 times into a channel and recording the DN value each
time. From those recorded values, the average DN (DNavg) and its
standard deviation (SIG) at each charge pulse amplitude, box
temperature and channel were calculated. Then, for each box
temperature and channel, a 9th order polynomial fit of Q(DNavg) was
derived. Finally, these 3 sets of values (the polynomial
coefficients, DNavg, and SIG) were stored in a matrix. This matrix
contains all information required to calculate the charge equivalent
to a DN as a function of box temperature and channel (detector), as
well as the uncertainty in that calculated charge value.
For detailed information about this calibration procedure see Horanyi,
et. al., "The Student Dust Counter on the New Horizons Mission", Space
Sci. Rev., in pub., 2007..
--Charge Calibration File--
The calibration file contains the calibration values described above
as a matrix of floating point values with dimension (4 X 14 X 3 X 19)
representing values for the 4 box temperatures (Tbox), the 14
channels, and the 3 types of calibration values (coefficients, DN_avg &
SIG). The the zero-based indices have the following meanings:
First Index - 4 Box Temperatures:
0) 49.9deg
1) 40deg
2) 34.25deg
3) -7.1deg
Second Index - 14 Channels
0) First channel
1) Second channel
...
13) Last (fourteenth) channel
Third Index - 3 types of data.
- By setting this index you select which array of values are retrieved
via the last index:
0 - Coeffs - Polynomial fit coefficients (in practice only the
first 10 are used)
1 - DNavg - Average DN recorded during Calibration at this Tbox & Channel
2 - SIG - Standard deviation of the corresponding average DN value
(index = 1)
Fourth Index - Dependent on Third index; see also Note 1 below
- For the coefficients of the polynomial (third index = 0)
log10(Q(DN)) = C0 + C1*DN + C2*DN2 + C3*DN3 + ... + C9*DN9
- 0) Zeroth order coefficient, C0
- 1) First-order coefficient, C1
- N) Nth-order coefficient, Cn
- For DN_avg & SIG data types (third index = 1 & 2)
- the index of each charge pulse tests arranged in order of
increasing charge (decreasing DN)
Note 1: We injected charge pulses at 21 different values, but some of
these were too small to record, and no channel had more than 19
recordable values at any box temperature. Also, there are only 10
coefficients in the 9th-order polynomial. So, although the matrix can
hold up to 19 coefficients, average DNs or standard deviations per box
temperature and channel, only the derived/recorded values are stored
in the matrix, and the any unused matrix values are set to zero. This
does not affect the polynomial evaluation, but when using the DNavg
and SIG values one should ignore zero values.
Thus from this matrix you can get 3 things: Fit coefficients, Average
DNs, and standard deviations.
So, for example, to get the fit coefficients for a box temperature of
-7.1 degrees on the first channel you want (-7.1, first channel,
Coeff, *) => CALARRAY[3, 0, 0, *] (IDL notation). See Figure 13-7 for
a plot of Charge vs DN represented by the Fit Coefficients.
For detailed information about this calibration procedure see Horanyi,
et. al., "The Student Dust Counter on the New Horizons Mission", Space
Sci. Rev., in pub., 2007.
Figure 13-7: Calibration curves for SDC. All 14 channels are shown
for reference.
13.3.2 Calibration - Mass
13.3.2.1 Pre-Flight
The mass can be derived from the charge. It was discovered by
J.A. Simpson and A.J. Tuzzolino that a particle impacting a 28 microns
PVDF film (such as those on SDC) will produce a charge given by
Equation 13-1.
Equation 13-1
In this equation N is the charge in number of electrons, m is the mass
in grams, and v is the particle velocity in km/s. On SDC we make one
measurement. We can measure the charge produced. Thus to find either
mass or velocity we must assume the other. Fortunately the velocity
of SDC with respect to the Keplerian orbital velocity of the dust
particles is very high. Thus, by assuming that the velocity of the
dust is the opposite direction to the velocity of the s/c, the mass
can be determined.
To verify the results of this equation for our detectors they were
taken to the Max Planck Institute in Heidelberg, Germany. With the
dust accelerator there, particles of known velocity and mass were
accelerated into the detectors and the charge curve produced. From
these experiments we were able to verify the curve above with a
slightly different constant of 5.63 x 10^17.
13.3.2.2 Mass Production
Rearranging the equation above gives Equation 13-2.
Equation 13-2
Thus one can simply use the number of electrons produced and the
velocity of the spacecraft calculated through SPICE to determine the
mass of the impacting particle.
Note that each event is converted to mass regardless of whether or not
it is believed to be noise.
13.4 Calibrated Data Specifics
13.4.1 Algorithm for Pipeline
Pre-flight calibration of the electronics box was performed to find
the relationship between charge in and DN out. This was done at 4
electronics box temperatures for all 14 channels. Fits were
established from this data and the coefficients were stored in a
matrix (see Figure 13-7 and section 13.3.1 above).
The code for Level 2 data uses the channel number and electronics box
temperature to find the correct coefficients in the matrix. These
coefficients are then used in a polynomial function, with the raw DN
as the independent value, to calculate the corresponding charge, and
then converted to mass using the equation the Mass Production equation
above. For in-flight box temperatures other than the calibration
temperatures represented by the first index of the calibration matrix,
the in-flight charge is interpolated (or extrapolated) from the
calculated charges using the two nearest calibration temperatures.
Finally, in like manner using the standard deviations calibration
matrix (SIG), for the nearest DN calibration measurements (DNavg) and
nearest two calibration temperatures, as an analog for the 1-sigma
combined uncertainty of the calibration charge pulse measurement and
of the calibration and in-flight DN measurement, the +/- 1-sigma
masses (M_sigplus & M_sigminus) are calculated.
13.4.2 Dataflow Block Diagram
Figure 13-8: Dataflow Block Diagram
13.4.3 Data Format
The calibrated FITS file consists of science data expressed in units
of number of electrons and quality flags for the PVDF detectors. The
quality flags signal whether or not any of the housekeeping values
were out of the standard operating range when the hit occurred. The
quality flags also tell whether or not the data was extrapolated or
interpolated from our pre-flight calibration curve.
Note that for scientific convenience in calibrated data, the channels
are labeled 1-14 instead of 0-13.
13.4.4 Extra FITS Extensions (planes) and Their Definitions
The two tables in the calibrated FITS file are
1) CALIBRATED_DATA -
a. UTC Time
b. MET - Time in Mission Elapsed Time (MET)
c. Channel - [1-14]
d. Charge [Number of Electrons]
e. Mass [grams]
f. Mass_Thrsh - The threshold in mass [grams]
g. M_sigplus - Mass Plus sigma [grams]
h. M_sigminus - Mass Minus sigma [grams]
i. Quality_flag - Because we are susceptible to thruster firings
(i.e. a thruster fire can cause false hits) a flag has been created to
flag events we believe were caused by a thruster..
i. "OK" - No thruster firings occurred near this event
ii. "TF" - A thruster firing occurred within 1 second of this
event and thus we believe the event was possibly caused by a thruster
firing
13.4.5 Scientific Units
Charge - Number of electrons produced from impact.
Mass - Grams of impacting particle.
13.4.6 Additional FITS and PDS Keywords Added
13.4.7 Hardware/OS Development Platform
Intel, Linux or Windows
13.4.8 Language(s) Used
IDL
13.4.9 Third Party Libraries Required
JPL Astro Library downloaded from NASA at Goddard.
13.4.10 Calibration Files Needed (with Quantities)
IDL .sav file consisting of a table for fit coefficients. ( TBD, <1MB
)
13.4.11 Memory Required
TBD
13.4.12 Temporary File System Space Needed
TBD
13.4.13 Predicted Size of Output File(s)
Less than 1KB
13.4.14 Predicted Execution time
A few seconds
13.4.15 Contact/Support Person(s)
Level 1: Andrew Poppe, David James
Level 2: Mihaly Horanyi, David James
13.4.16 Maintenance Schedule (Code/Data Updates, Documentation)
We do have on-board calibration capabilities for the instrument and a
place to insert these changes built into the code. Currently this
simply multiplies by 1, but it the capability to adjust the values by
some specified function remains.
14. SWAP Instrument description
14.1 Overview
Solar Wind Around Pluto (SWAP) instrument is designed to measure the
properties of solar wind ions for the New Horizons mission to Pluto. The
bulk (thermal) solar wind ion distribution is typically Maxwellian. For most
of the long journey to Pluto we expect to encounter bulk solar wind cold ion
distributions that are nearly Maxwellian since the density and temperature
of the solar wind decrease with increasing distance from the Sun,. One
notable exception is when we encounter Jupiter's magnetosheath. Ion
distributions are known to be hot in sheath regions. Since there have been
no prior in situ measurements near Pluto, we do not know if it has a well
developed sheath region.
Figure 14-1: Diagram of SWAP electro-optics. Two ion trajectories are
drawn: one having energy greater than the RPA voltage and one less. [Figure
8 from McComas et al., 2007]
The SWAP instrument is an electrostatic instrument. The SWAP electro-optics
control the energy passband of ions entering the instrument. The
electro-optics has three parts: the Retarding Potential Analyzer (RPA), the
Electrostatic Analyzer (ESA), and the deflector (DFL). Figure 14-1 shows a
cross section of the instrument. The RPA consists of four grids with the
inner two having a positive voltage, which repels ions with energies less
than the corresponding potential energy (qV) (top right and left of Figure
14-1). The Electrostatic Analyzer has two parts, which are concentrically
spaced, an inner dome and an outer spherical shell (at ground). Only ions
with a limited range of energies pass through the ESA to reach the detector.
The SWAP instrument is mounted on the -Zsc side of the spacecraft and
the normal to the center of the aperture is aligned with +Ysc (Figure
14-2). Figure 14-3 shows the instrument being mounted to the spacecraft.
The deflector is used to adjust the field of view. That is if the solar
wind, which is highly collimated (spanning only a few degrees), enters at
the bottom of the RPA, the voltage on the deflector could be set so that
only ions that are not part of the solar wind beam enter the instrument.
This would allow pickup ions, which occur over a wide range of angles, to be
studied. In the inner heliosphere the pickup ions have substantially lower
fluxes than the solar wind. The SWAP deflector can be used to bring the
solar wind into the field of view if the solar wind beam is slightly above
the top of the nominal field of view. Operating the deflector affects the
energy of the ions that can enter the ESA. The RPA voltage is adjusted to
compensate such that the same energy ions enter the ESA as did prior to the
deflector voltage change. The deflector voltage can be automatically varied
based on the commanded angle. The voltage settings for the ESA, RPA,
deflector, and the amount the RPA should be adjusted to compensate for the
deflector setting are all specified using lookup tables, which allow many
instrument operation changes to be made by uploading new tables without
having to make any software changes. Additional information on the
electro-optical design is given in the introduction of section 3 and in
section 3.1 in the McComas et al. [2007] instrument paper. The CEM detector
design is also described in section 3.1.
Figure 14-2: Diagram of New Horizons spacecraft SWAP instrument on the
left. On the right diagram of the SWAP instrument with the spacecraft axes
labeled.
The SWAP instrument has two kinds of voltage scans (also called sweeps):
coarse and fine. The voltage settings are predefined with onboard voltage
tables. In coarse scans large voltage steps are taken with the ESA and RPA
holding the ratio of the two voltages fixed. In the fine scans we also hold
the RPA and ESA at constant ratio, but take smaller steps. Our voltage
tables allow us to vary the ratio between the RPA and ESA voltages, but
typically this ratio is held constant as much as possible. For high ESA
voltages we cannot set the RPA to a high enough voltage to keep the RPA and
ESA voltage ratio fixed because the highest RPA voltage is 2000 V and the
highest ESA voltage is 4000 V. A given step number refers to a pair of RPA
and ESA voltages. In the inner heliosphere we set the RPA to ESA voltage
ratio high in order to narrow the passband slightly by removing ions at the
low energies. All fine scans are approximately centered about the step
number where the peak counts are observed in the coarse scan. To determine
plasma properties from the detected count rates as a function of step
number, the following calibration information is necessary: the ESA and RPA
response functions, angular response function, the instrument solid angle,
the detector gain, and the effective area.
Onboard there is one ESA table with 1024 steps and 4 RPA tables with 1024
steps each. For a given sweep we use the ESA table and one of the RPA
tables. The different RPA tables can be used for coarse and fine scans, but
currently for Jupiter operations we are using the same RPA table for both
the coarse and fine scans. In a scan/sweep the same step number is used in
the software to reference rows in the ESA table and the chosen RPA table.
The coarse scans use every 16th step in the 1024 step table where a step
refers to a RPA and ESA voltage pairing. A fine scan consists of 64 steps
with the coarse step at which the peak counts were detected in the middle of
the fine scan (16*64=1024).
Figure 14-3: Picture of SWAP being mounted to the spacecraft.
14.2 Electronics and Flight Software
The instrument electronics are described in section 3.4 of the McComas et
al. [2007] instrument paper. In subsequent sections of this document some
information related to the flight software is provided, but further details
are provided in sections 3.6 of the instrument paper.
14.3 SWAP Data Types
There are six types of SWAP science and engineering data: real-time science
(0x584), summary (0x585), histogram (0x586), housekeeping, messages, and
memory dump. Housekeeping, messages, and memory dump provide engineering
data and the other three modes contain science data. Real-time data provide
the most detailed science measurements since they contain the full count
rate distribution as a function of energy (speed). For science summary and
science histogram modes, the full distribution is not recorded. Instead,
parameters are derived from the count rate distribution stored by SWAP.
These derived parameters require less memory than storing the whole
distribution. The science summary and science histogram modes are primarily
used during the cruise phase of the mission.
The real-time science data contain the full count rate energy distribution
for the primary, secondary and coincidence rates. The full distribution is
desired because in bow shock and sheath regions plasma distributions may not
be Maxwellian. The shape of the distribution will provide valuable
information about what physical processes are occurring. In real-time mode
the instrument can take measurements at a rate of 1 Hz, which is crucial for
studying plasma boundaries and shocks.
Summary data consist of parameters related to the average speed,
temperature, and density. The summary data are designed to study the bulk
solar wind. The peak of the count distribution is related to the density,
the bin location of the peak is related to the speed, and the distribution
width is related to the temperature and speed combined. Along with the
average values, the variance, maximum and minimum values of the peak counts,
width of the peak, and energy of the peak are also recorded.
The histogram data are designed to study pickup ions. The pickup ion
distribution has a characteristic shape once it is normalized by the average
solar wind energy (or speed). The histogram data conserve storage space by
adding up all the counts detected in given bins. The accumulation time for
the histogram is variable. The bins for the histograms are not energy bins,
but are bins relative the average solar wind energy (Esw). The steps for the
fine scan are roughly centered on the coarse scan step where the peak counts
were observed allowing the energy of the solar wind to be more precisely
determined in the fine scan. The energy found in the fine scan is then used
to place the counts determined in the coarse ESA scan into a new large 1-D
histogram array. The coarse scan count rate data array is placed into the
larger histogram array such that the bin with the maximum counts in the fine
scan is placed into histogram bin 1024. There are 1024 possible voltages in
a given onboard voltage table. To understand the histogram data further
information about the scans is necessary. Onboard there is one ESA table
with 1024 steps and 4 RPA tables with 1024 steps each. For a given sweep we
use the ESA table and one of the RPA tables. The different RPA tables can be
used for coarse and fine scans, but currently for Jupiter operations we are
using the same RPA table for both the coarse and fine scans. In a scan/sweep
the same step number is used in the software to reference rows in the ESA
table and the chosen RPA table. The coarse scans use every 16th step in the
1024 step table where a step refers to a RPA and ESA voltage pairing. A fine
scan consists of 64 steps with the coarse step at which the peak counts were
detected in the middle of the fine scan (16*64=1024). There are 2048 bins
because the peak count rate in a fine scan could occur at any step in the
fine scan, and the step in the coarse scan containing the peak counts is
always place in bin 1024.
When another set of coarse-fine scans is performed, the new array of counts
is processed in a similar fashion. The new data are placed into bins such
that the new peak counts aligned with bin 1024, and then added to the
running total number of counts. The amount of data put into each histogram
bin is tracked in a separate array. The histogram packets then consist of
two 1-D vectors: one for counts in the bins and one for the number of
samples placed into each bin (Example shown in Figure 14-4 ).
Figure 14-4: Example of how histogram data are created on-board the
spacecraft
The histogram data consist of a series of 64 packets to facilitate data
transmission. There are two types of histogram packets. For each histogram
type 1 packet, there should be 63 histogram type 2 packets. One type 1 and
63 type 2 histogram packets are combined when placed into the Level 2 (raw)
files. The histogram type 1 packets contain information about the data
collection such as the start and end time of the data collection interval
and the plan and sweep numbers. Type 1 contains a small portion of the
histogram data, but most of the histogram data is contained in the Type 2
packets, which hold a larger amount of data since they do not contain
information about the data collection.
14.4 Raw File (Level 2) Specifics
14.4.1 Data Format
Figure 14-5: Example of real-time calibrated (level 3) data files on the
SOC webpage.
There are separate files for summary, histogram, and real-time data, and
corresponding housekeeping data are placed in each file. Note that not all
kinds of packets will be generated every day. For example, during
commissioning there may only be housekeeping and memory dump packets, and
during cruise there will be housekeeping, summary, and histogram packets.
All the packet types have a CHKSUM parameter. This parameter is calculated
onboard and is also calculated on the ground to check the data. In Figure
14-5 we show what the calibrated files look like on the SOC web site. For
the real-time data there are black and white images of the coincidence
spectrogram array where the y-axis is energy bin number and the x-axis is
time bin number.
Real-time science packets can occur at a rate as high as 1 Hz where each
packet contains a set of counts, voltages, etc. A set of two observations
are stored in one packet. One observation occurs in the 1st half second and
a 2nd observation occurs in the 2nd half second. The 1st and 2nd half second
measurements correspond to two different steps in a given sweep. Each step
consists of an RPA and ESA voltage pairing, and 64 such pairs complete
either a coarse-coarse scan or a coarse-fine scan. In a coarse-coarse scan
two 64 step (32 packets) coarse scans are done back to back. In a
coarse-fine scan a 64 step (32 packets) coarse scan and then a 64 step (32
packets) fine is performed. Both a complete coarse-coarse, and a coarse-fine
scan have 64 packets. There is a parameter called SWAP_RT.sec64_ST, which is
included in every real-time science packet and has the value 1 at the start
of a pair of scans (a set of 64 packets) and is zero otherwise. We use this
parameter to insure that a 64 second cycle (pair of scans) is not split
across a day.
The SWAP raw (level 2) data are arranged in a binary table such that the
columns are instrument parameters and measurements, and rows are measurement
times. The FITS format has a binary table that allows for columns and rows.
Below in Figure 14-6 is a picture of what the Level 2 raw real-time files
look like using FITS Viewer (FV). As mentioned earlier the housekeeping data
are also in an table extension. The histogram counts and number of samples
are stored as image extensions. The zeroth extension contains only the
primary header, the first extension holds the real-time data, the second
extension holds the housekeeping data, and the third extension holds the
thruster data.
Figure 14-6: Real-time level 2 (raw) file displayed using FV.
SWAP data are in CCSDS packets packetized by the spacecraft from the
low-speed bus. Note that on the New Horizons mission, every instrument also
outputs a non-packetized portion of telemetry to the S/C. This portion is
also called the instrument state and this data is incorporated into the
general spacecraft housekeeping data and not into the SWAP packets. All the
bits in the SWAP packets were defined for the MOC at APL in EXCEL
spreadsheets in the form required by the mission. The New Horizons SOC used
the same bit level format description (APL EXCEL spreadsheets) for all the
parameters in our packets to decode our raw (level 2) data.
14.4.2 Definition of an Observation
A complete histogram observation consists of one histogram type 1 packet and
63 histogram type 2 packets. A complete set of real-time science
measurements consists of a full 64-second cycle. This is described in detail
in section 14.4.1. One summary packet constitutes a complete measurement.
Housekeeping data are required for all science measurements since the
housekeeping data are key to interpreting the data and determining error
flags.
14.4.3 Housekeeping Needed in Level 2(Raw) Files (for Calibration)
Unlike some of the other instruments all housekeeping data for SWAP are
included into the level 2 (raw) files as an extension.
14.4.4 Raw Science Data and/or Housekeeping Requirements
In addition to the complete housekeeping packets, raw summary, real-time,
histogram, and thruster fire packets are included into our raw (level 2)
files. The thruster data format for the raw files was reformatted to reduce
space (Joe Peterson). In the calibrated (level 3) data the thruster data
has been arranged by thruster name and time. The numbers in the table
indicate the duration of the thruster firings.
Figure 14-7: General Schematic for SWAP Pipeline. In green are inputs to
the pipeline. Data files are in purple. The primary extension holds the main
header (orange). In blue are the data tables, and in yellow are the image
extensions.There are 3 spectrogram extensions and 3 error spectrogram
extensions for our three count rate signals: PCEM, SCEM, and coincidence.
14.5 Calibrated (Level 3) File Specifics
14.5.1 Data Format
The SWAP calibrated (level 3) pipeline requires the following input
information, SWAP level 2 (raw) files which include all the housekeeping
data, SWAP calibration information and engineering factors, orbit and
attitude information, and spacecraft information such as thruster firings.
In Figure 14-7 we show a general schematic for our level 3 (calibrated)
real-time data files. The main input to the calibration pipeline are the
SPICE kernels, and raw level 2 files which include the real-time data,
thruster firings, a few minor calculations performed using SPICE in the
header and the housekeeping data..
The SWAP level 3 (calibrated) analysis software has four parts corresponding
to the different data (packet) types. There are simple algorithms for
converting the raw data to engineering units. For example in the raw data
the RPA voltage is stored as a step number for the Digital to Analog
Converter (DAC), and not the actual voltage. We first make all such
engineering conversions. Most information in our calibrated (level 3) files
is stored in table format (blue blocks in diagram). The tables contain all
the data (science and housekeeping) converted to engineering units, and
counts are converted to count rate (Hz). There are extensions for
housekeeping data, thruster firing data, and quality flags. In the real-time
data there are additional image extensions for spectrograms derived from
high voltage science real-time measurements. There are three count rate 2-D
arrays for the SCEM, PCEM, and coincidence signals stored as images, and
three corresponding count rate error image extensions. These errors will be
based on counting statistics. In addition to the 2-D arrays, axis
information is also necessary for the spectrograms. The axis information for
the spectrograms are contained in two tables one with the energy per charge
(E/q) and one with the time tags fore each sweep. In Figure 14-8 we show a
picture of what the real-time files look like when opened using the FITS
viewer FV.
Figure 14-8: Picture of what the real-time calibrated (level 3) files look
like using Fv. The numvers listed under index are the extension numbers. All
tables are Binary type and all images are image type.
14.5.2 Further Algorithm details for Pipeline
In this section we describe the algorithm for SWAP level 3 (calibrated)
processing. As mentioned above The first step in our processing is to
convert all raw values over to engineering units. These conversion factors
are also stored in the command and telemetry spreadsheets used in the APL
GSEOS system. The details of the housekeeping processing are not discussed
further since processing of the housekeeping data consists of simple
conversion factors. Analysis of ground calibration data provides critical
information used to process the SWAP data, and is consequently a crucial
input to our software. A description of the type of calibration information
used in the pipeline is given in the calibration document.
14.5.3 Real-time science data processing
Figure 14-9: Examples of a coincidence (right) and error coincidence (left)
spectrogram arrays.
The identifier in the SOC filenames for real-time data is the APID 0x584.
Our real-time high voltage science (HVSCI) analysis begins by determining
the count rates in Hz as a function of energy for each measurement. A
spectrogram is created by sorting the data into sweeps in order to build a
2-D array where the y-axis is energy per charge and the x-axis is time. A
spectrogram spans the time range in HVSCI mode in a given daily level 2
(raw) file. Spectrograms are created for each of the 3 count signals (PCEM,
SCEM, and coincidence). Corresponding count rate error spectrograms are
created based on counting statistics for each of the three signals as
described in the next paragraph. The x-axis time information is provided in
the TIME_LABEL_SPECT extension along with a column indicating if a
background has been removed. The background is mentioned in section 14.5.10
and described in detail in the calibration document. Also in the
TIME_LABEL_SPECT extension is a column indicating the plan and sweep used
since the energy bins are different for different plans and sweeps. The
y-axis energy labels for a given sweep and plan number are provided in the
ENERGY_LABEL_SPECT extension. These count rate spectrograms provide a way to
examine our data at high time resolution over the full energy range of the
instrument. These kinds of spectrograms have proven useful for analyzing
high time resolution plasma in situ measurements. Having a high time
resolution product is critical for identifying plasma boundaries and shocks.
In Figure 14-9 we show examples of what coincidence and an error coincidence
spectrogram arrays look like when opened in FV.
14.5.4 Errors
In the level 3 (calibrated) data files an error value for every measurement
is given in the extension labeled ERROR_BARS. We also provide spectrogram
arrays for each signal type for the errors in the extensions labeled
X_ERROR_BARS_SPECT_HZ where X is PCEM, SCEM, or COIN. The errors provided
are errors for the rates. The errors and include an error for the sample
time, and data compression when compression occurs. The raw rate (count
counts per sample (C)) are convert to Hz using the 0.390 sec
sample/accumulation time (t) (Equation 1). The error squared is given in
Equations 2 and 3, and the fractional error squared is shown Equation 4.
Taking the square root the resulting fractional error is given by equation
5. The final error given in the data files is shown in Equation 6. If the
count rates are not compressed (Cuncomp) then C = Cuncomp and deltaC =
(Cuncomp)^(1/2). However, if the counts are compressed (Ccomp) then C =
16Ccomp + 7.5 and deltaC=(16Ccomp + 7.5)^(1/2). In the ERROR table there
is a column indicating if a background has been removed. The background is
mentioned section 14.5.10 and described in detail in the calibration
document.
C
Rc = - (Equation 1)
t
2 2
2 /dRc\ 2 /dRc\ 2
(deltaRc) = ( --- ) (deltat) + ( --- ) (deltaC) (Equation 2)
\dt / \dt /
N.B. d prefix implies partial derivative
in Equation 2
2 2
2 C 2 /1\ 2
(deltaRc) = -- (deltat) + ( - ) (deltaC) (Equation 3)
4 \t/
t
2 2 2
(deltaRc) (deltat) (deltaC)
---------- = -------- + -------- (Equation 4)
2 2 2
Rc t C
____________________
/ 2 2
deltaRc /(deltat) (deltaC)
------- = _ / -------- + -------- (Equation 5)
Rc \ / 2 2
\/ t C
____________________
/ 2 2|
/(deltat) (deltaC)
deltaRc = _ / -------- + -------- * Rc (Equation 6)
\ / 2 2
\/ t C
Image of those same equations:
Equations 14-1 to 14-6
Equations 14-1 to 14-6
14.5.5 Quality Flags
Flags assessing the quality of the data are based on operational
housekeeping alarms, but in the future additional ones may need to be added
which are based on on orbit and attitude, and additional calculations. All
current flags are stored in a table extension.
14.5.6 Thruster Firings
As mentioned earlier the calibrated (level 3) code reorganizes the thruster
data into a table where each column refers to a given thruster name and each
row is the start time of the thruster firing. The numbers under each
thruster column indicate the duration of the thruster firings. Each thruster
column has a title that looks like GC1_A2_FIRING where GC1 indicates it
originated in a G&C packet, and FIRE indicates thruster firing. The
thruster names are A1, A2, B1, B2, B3, C1, C2, C3, C4, D1, D2, D3, D4, F1,
and F2. The value for each thruster firing corresponds to the duration of
the thruster firing (0=0msec,1=5msec,2=20msec,3=40msec). In the raw data
each row is a major frame, and the columns are minor frames where each minor
frame is 40msecs. Thus, there are 25 columns with numbers between 0 and 24.
In the level 3 (calibrated) data we calculate the start time of the firings
for a given minor frame which means we have already taken the major frame
start time and added in the time to the start of the minor frame where the
firing occurred (
Start_time = major_frame_start_time + 0.040 * [minor_frame_number +1]
). The implication of this is that one row in the raw file may result in
several rows in the calibrated file if there are multiple thruster firings.
14.5.7 SPICE Orbit and Attitude Calculations
Our orbit and attitude calculations are contained in the
SPICE_ORBIT_ATTITUDE_CALC extension. We calculate times for each SWAP
measurement in the REAL_TIME extension. The MET for the packet is listed
along with the UTC, and ET for the start and stop time of each measurement.
There are two start times and two stop times one since each packet stores
two measurements one in the first half second (labeled with a 0) and one in
the second half second (labeled with a 1). In the tail the spacecraft is
spinning so we have included the angle in the Xsc-Zsc plane between the Zsc
axis and Jupiter's spin axis (north). This angle is 0 deg (90 deg) when Zsc
(Xsc) is aligned with the North end of Jupiter's spin axis. These angles are
named ANGLE_JSP_XZ in the files and calculations were done for the start,
middle, and stop for each observation, since the spacecraft rotates quickly
(5RPM). All other parameters are calculated at the middle of each
observation. We also calculated the angle between the Ysc and the Sun,
Jupiter, and Earth. The label for the angle between Ysc and the Sun for the
1st measurement is called Y_SUN_ANG0_MIDDLE. The distances from the
spacecraft to Earth, Jupiter and the Sun are calculated (i.e.,
SUN_SC_0_MIDDLE). We calculate the angle to the Sun is in the X-Y plane
(phi), and the latitude angle from the X-Y plane (theta). Positive phi
values are toward the +Xsc axis and negative phi angles are towards the -Xsc
axis. Negative theta values are towards the top of the instrument since the
-Zsc axis is at the top of the instrument. Note this is the opposite
convention used in the calibration chamber. However, the phi angle is
analogous to the roll angle in calibration (see calibration Document). We
also calculate the position and velocity of the spacecraft in IAU Jupiter
Cartesian coordinates. The naming convention is such that the X component of
position in IAU Jupiter for the 1st half second measurement is labeled as
SC_IAU_JUP_X_0. Likewise the X component of the velocity is
SC_IAU_JUP_VX_0. In addition to IAU Jupiter coordinates we calculate the
spacecraft position in J2000 Jupiter coordinates the X component for the 1st
measurement is labeled as SC_J2000_JUP_X_0. Column name descriptions are
given in the header for the SPICE extension as well as the names of the
SPICE kernel files used to perform the calculations.
Figure 14-10: Examples of a summary (top) and histogram (bottom) files
viewed in FV
14.5.8 Summary and Histogram Files
Both the summary (Figure 14-10 top) and histogram (Figure 14-10 bottom)
files also have the primary header, and housekeeping, quality, thruster and
spice orbit attitude extensions the same as in the real-time files. In
extension 1 are is the summary data table converted to engineering units.
The histogram data are stored as images in the 0th and 1st extensions. The
0th extension contains the number of times data was added to each bin, and
the 1st extension contains the histogram count rates.
14.5.9 Calibration
Analysis of ground calibration data provides critical information used to
process the SWAP data, and is consequently a crucial input to our software;
therefore, details describing the use of calibration information in the
pipeline is described in section the calibration Document. The SWAP lab
calibration consists of an effective area; an angular response function for
the ESA (function of alpha and phi); an energy response curve for the RPA
that depends on the RPA and deflector voltages; a function representing how
the RPA changes the energy of ions prior to enter the ESA; an energy
response function for the ESA; the functions for how the width and center of
the ESA passband varies with alpha; and a function for how the conversion
factor for converting ESA voltage to energy depends on phi. Our pipeline
incorporates ESA and RPA response curves by precalculating the energy
passband for each RPA and ESA voltage pair stored in the onboard tables.
This information is used as a lookup table in the pipeline code so that each
RPA and ESA voltage step can be assigned a energy per charge value. The code
determines which set of tables to use by examining the time range since we
have had different sets of RPA and ESA tables loaded at different times in
the mission. To determine which of the 4 RPA tables to use the code compares
the sweep and plan number in the data to the sweep and plan number in the
precalculated tables. The results of the pipeline energy determination are
stored in the energy axis label extension and can be used directly to label
the y-axis of the spectrogram.
Figure 14-11: Timelines for SWAP plan numbers, data rates, and spacecraft
maneuvers (top panel). Plan 0 is blue plan 5 is red. Two minutes of data set
of measurements every two hours is in orange where one set consists of a two
coarse-fine sweeps. Purple is one set of measurements every 5 minutes. Green
is 3-axis stable and black is spin mode where the spinning is about Ysc.
The 2nd panel is the spacecraft-Jupiter distance in Rj. In the 3rd panel is
the spacecraft-Sun distance in AU, and in the bottom panel is the Ysc-Sun
angle in degrees.
14.5.10 Background Subtraction
There is a background in our data when the RPA is on. The background
reduces as the distance from the Sun increases and will most likely not be a
problem for the Pluto encounter. We can operate using only the ESA and have
done so for the Jupiter encounter (plan 5). For the solar wind measurements
inbound we needed to use the RPA (plan 0) to shield the instrument from high
solar wind fluxes. Background subtraction information is processed in
similar way as to the energy bin information. A given background is
subtraction is only valid for a given time range; therefore, a list of
background files and validity times are read in and then the background is
subtracted. The background files are stored in the calibration directory and
the names of the files used are stored in the list file. The instrument
detector gain will evolve with time and this information will be
incorporated in fashion similar to the background subtraction. Gain
calibrations occur during annual checkouts. The background subtraction is
described in more detail in the calibration Document
14.6 Operations
Plan 3 was used to take the first complete sweeps of the solar wind during
SWAP-009-6 in commissioning. The voltage tables were updated before the
beginning of the Jupiter phase to improve the voltage sweeps for the Jupiter
phase. There are only two plans used in the Jupiter phase plan 0 and plan 5.
Plan 0 is designed for the solar wind and plan 5 is designed for the
magnetosphere. The voltage settings in plan 0 protect the instrument from
high solar wind proton fluxes. Early on the data rate was such that two
coarse-fine scans were taken approximately every two hours. The spacing was
only approximately every two hours the operations were commanded and the
commands were adjusted by so as not to interfere with other instruments. At
2/21/2007 17:27:31 we kept the plan number set at 0 and then changed the
data rate such that we took 1 coarse and 1 fine scan every 5 minutes. Then
at 02/25/2007 19:22:43 we switched to plan 5, which consists two coarse
scans in 64 seconds every 5 minutes. In plan 5 the RPA is off and only the
ESA voltage is swept. With the RPA off, the instrument is so sensitive that
the high proton fluxes in the solar wind near Jupiter would cause the
instrument to automatically shut down. Since the instrument is more
sensitive in plan 5, we took some measurements in plan 0 in the
magnetosphere to insure that some measurements would be obtained even if the
spacecraft entered the solar wind. We show timelines for operations
in Figure 14-11 along with the distance to Jupiter and the Sun. And in the
bottom panel we show the angle between Ysc and the Sun. In spin mode the
spacecraft spins about Ysc. The spacecraft entered the magnetosphere on day
056(02/25) in 2007 and the first time it exited in the tail was
approximately on day 132(05/12) of 2007. There were many tail crossing and
there appears to be a boundary layer inside the sheath; therefore,
definitive boundary crossing times are difficult to determine. When SWAP
turned off on day168 (06/17) of 2007 for hibernation, New Horizons was once
again in the magnetosphere
14.7 Observation Examples
In this section we show two examples of SWAP data taken during the Jupiter
encounter. Figure 14-12 shows most of the solar wind measurements on
approach to Jupiter. The format is that of a color-coded spectrogram of the
background-subtracted coincidence count rates in Hz of solar wind ions as a
function energy per charge (E/q) as measured by the Solar Wind Around Pluto
(SWAP) instrument on New Horizons at ~4.9 AU from the Sun (~0.4 AU upstream
from Jupiter). We used plan 0 for these measurements since this plan helps
protect the instrument from high fluxes. In plan 0 the RPA is on at energies
below 2000 eV/q. The RPA creates a background and this background has been
removed (see calibration document). The lower trace shows the solar wind
protons, while the upper trace shows the alpha particles (He++), with
enhanced sensitivity (~100x larger) above 2 keV/q. Solar wind speed is a
function E/q, with 1 keV protons corresponding to typical, ~440 km/s solar
wind and larger (smaller) E/q representing faster (slower) wind speeds.
Interplanetary shocks passed over the New Horizons spacecraft at ~1800 on
Day-of-Year (DOY) 11 and at ~1300 on DOY 14 causing the abrupt jumps in
solar wind speed; the speed immediately following the latter shock was in
excess of 600 km/s. The slowly decreasing speed after the second shock
(falling E/q of the proton and alpha beams) is a rarefaction region, which
forms as faster solar wind outruns the slower solar wind behind it. In all,
these SWAP observations show a clear solar wind stream structure.
Below we show magnetospheric observations taken using plan 5 since plan 5 is
more sensitive and the flux rates are lower in the magnetosphere than in the
solar wind (Figure 14-13). The only time the plan 5 data has any background
is when there is penetrating radiation, and we do not remove any background
due to penetrating radiation. The penetrating radiation occurs close to
Jupiter and usually is greatest in the secondary and primary signals. When
it occurs, the count rates are usually elevated at all energy steps;
therefore, in spectrograms the penetrating radiation usually shows up as
vertical stripes. The penetrating radiation is significantly reduced in the
coincidence signal. The plan 5 data consists of one measurement set every
5th SWAP minute, and one set consists of 2 coarse scans performed in 64
seconds.
Figure 14-12: Coincidence count rate spectrogram of solar wind measurements
on approach to Jupiter. The y-axis is in the energy per charge. The x-axis
is day of year. The color indicates the count rate in Hz, and grey indicates
no data. An instrumental background has been removed. This background only
occurred below 2000 eV/q. In the top trace are He++ ions and in the bottom
trace are H+ ions. Purple diamonds indicate shocks. All data below the
orange line at 2000eV have a lower sensitivity than the measurements above
2000 eV/q. The same flux measured below 2000eV/q is a about a factor of 100
lower than if that same flux was measured above 2000eV/q.
14.8 Updates to Level 3 (calibrated data)
We added the center energy for given RPA and ESA voltages to the REAL_TIME
data extension. The column names are ENERGY_0 and ENERGY_1 in eV and
correspond to the 1st and 2nd measurement in a given packet (row). We
corrected the background subtraction. We corrected a rounding error in the
time used to calculate the spin angles in the SPICE extension and fixed a
small offset in the times for the spectrogram in the TIME_LABEL_SPECT
extension. We include directories of 1 day and 10 day coincidence
spectrograms plots for the entire Jupiter phase.
Figure 14-13: Coincidence spectrogram of the rates in counts/sample, the
total rates in a coarse scan, the Sun theta and phi angles in spacecraft
coordinates (Section 14.5.7), and the Jupiter to Spacecraft distance in Rj.
SWAP Science Goals
==================
These level 3 (calibrated) data products described above will allow us to
meet two key science goals as outlined in section 6.3.1.1 of the SWAP
Specification document (Document No. 05310-03-SWAPSPEC-01). Below we quote
this section.
The Mission Science Requirements document specifies that SWAP should make
the following measurements.
- Measure solar wind standoff to ~ 3000 km.
- Determine nature of solar wind interaction at Pluto. Distinguish
between magnetic, cometary, & ionospheric interactions.
14.8.1 Dataflow Block Diagram
Figure 14-14 SWAP Level 2 Pipeline Diagram
14.8.2 Extra FITS Extensions and Their Definitions
We have binary tables for both real-time, and summary data. Likewise, we
have binary table extensions for housekeeping data, flags, errors, and
thruster packet spacecraft data. We have image extensions for both count
rate spectrograms and error spectrograms image. For histogram data we have
two image extensions: one for counts and one for accumulations (number of
samples).
14.8.3 Scientific Units
The level 3 calibrated code will have rate spectrogram in Hz, and all the
engineering data converted to engineering units.
14.8.4 Additional FITS and PDS Keywords Added
TBA
14.8.5 Hardware/OS Development Platform
Intel, Linux
14.8.6 Language(s) Used
C/C++
14.8.7 Third Party Libraries Required
Cfitsio and CSPICE.
14.8.8 Memory Required
TBA
14.8.9 Temporary File System Space Needed
None
14.8.10 Predicted Size of Output File(s)
TBA
14.8.11 Predicted Execution time
On the order of seconds
14.8.12 Contact/Support Person(s)
PI: Dave McComas
Lead Engineer and Project Manager: Scott Weidner
Onboard Software and Commanding: John Hanley
Pipeline and Science Operations: Heather Elliott
Sequencing: Helen Hart
14.8.13 Maintenance Schedule (Code/Data Updates, Documentation)
TBD
14.9 Packet Description
This section gives the parameters found in SWAP science packets. The names
are as given in the APL spreadsheets used to view the data in real-time and
playback modes. The level 1 names are shortened versions of these names.
REAL_TIME
=========
SWAP_RT.CC_PID_VER Primary Header - Version Number
SWAP_RT.CC_PID_TYPE Primary Header - Packet Type
SWAP_RT.CC_PID_SEC_FLAG Primary Header - Secondary Header Flag
SWAP_RT.CC_PID_APID Primary Header - Application ID; type of data ie
real-time, housekeeping, etc
SWAP_RT.CC_PSC_GRP_FLAG Primary Header - Grouping Flag; set to a
constant value, not used
SWAP_RT.CC_PSC_SSC Primary Header - Sequence Count
SWAP_RT.CC_PKT_DATA_LN Primary Header - Packet Length; this is used to
SWAP_RT.CC_MET_TIME Secondary Header - Time
SWAP_RT.SEC64_ST A bit indicating the beginning
of a 64-second cycle
SWAP_RT.PLAN_ID Plan ID
SWAP_RT.SWEEP_ID Sweep ID
SWAP_RT.ANGLE Commanded angle for deflection compensation
SWAP_RT.RPA_LVL0 RPA level during first half-second
SWAP_RT.DFL_LVL0 DFL level during first half-second
SWAP_RT.ESA_LVL0 ESA level during first half-second
SWAP_RT.RPA_LVL1 RPA level during first half-second
SWAP_RT.DFL_LVL1 DFL level during first half-second
SWAP_RT.ESA_LVL1 ESA level during first half-second
SWAP_RT.MODE Enumerated type representing each of the modes
SWAP_RT.PCEM_RNG_ST0 PCEM counts are compressed or raw during first
half-second; this is a flag that determines
if the data in SWAP_RT.PCEM_CNT0 is compressed
or not. If this flag is set to zero the data
are not compressed. If the flag is set to 1
then the data in SWAP_RT.PCEM_CNT0 is 1/16 of
the actual count rate.
SWAP_RT.SCEM_RNG_ST0 SCEM counts are compressed or raw
during first half-second
SWAP_RT.COIN_RNG_ST0 Coincidence counts are compressed or raw
during first half-second
SWAP_RT.PCEM_RNG_ST1 PCEM counts are compressed or
raw during second half-second
SWAP_RT.SCEM_RNG_ST1 SCEM counts are compressed or
raw during second half-second
SWAP_RT.COIN_RNG_ST1 Coincidence counts are compressed or
raw during second half-second
SWAP_RT.PCEM_CNT0 PCEM count value during first half-second
SWAP_RT.SCEM_CNT0 SCEM count value during first half-second
SWAP_RT.COIN_CNT0 Coincidence count value during first half-second
SWAP_RT.PCEM_CNT1 PCEM count value during second half-second
SWAP_RT.SCEM_CNT1 SCEM count value during second half-second
SWAP_RT.COIN_CNT1 Coincidence count value during second half-second
SWAP_RT.CHKSUM XOR checksum; this value is based on all the
other real-time quantities listed above.
It is used to determine if a bit was flipped
in one of the real-time quantities. If check
sum is not what is predicted based on the other
real-time quantities then the data need to be
thrown away.
SUMMARY
=======
SWAP_SM.CC_PID_VER Primary Header - Version Number
SWAP_SM.CC_PID_TYPE Primary Header - Packet Type
SWAP_SM.CC_PID_SEC_FLAG Primary Header - Secondary Header Flag
SWAP_SM.CC_PID_APID Primary Header - Application ID
SWAP_SM.CC_PSC_GRP_FLAG Primary Header - Grouping Flag
SWAP_SM.CC_PSC_SSC Primary Header - Sequence Count
SWAP_SM.CC_PKT_DATA_LN Primary Header - Packet Length
SWAP_SM.CC_MET_TIME Secondary Header - Time
SWAP_SM.BEG_TIME Time stamp at the beginning of this summary period
SWAP_SM.END_TIME The time stamp at the end of this summary period
SWAP_SM.N64_CNT Number of 64-second sample sets used
SWAP_SM.NDFL DFL
SWAP_SM.ANGLE_SUM Angle
SWAP_SM.DENSITY_SUM An estimate of the pseudo density
SWAP_SM.VELOCITY_SUM An estimate of the pseudo speed using energy
SWAP_SM.TEMP_SUM Estimate of the pseudo temperature
SWAP_SM.ANGLE_SSQ_HI The variance of the angles
SWAP_SM.ANGLE_SSQ_LO The variance of the angles
SWAP_SM.DENSITY_SSQ_HI The variance of the pseudo n-values
SWAP_SM.DENSITY_SSQ_LO The variance of the pseudo n-values
SWAP_SM.VELOCITY_SSQ_HI The variance of the pseudo V-values
SWAP_SM.VELOCITY_SSQ_LO The variance of the pseudo V-values
SWAP_SM.TEMP_SSQ_HI The variance of the pseudo T-values
SWAP_SM.TEMP_SSQ_LO The variance of the pseudo T-values
SWAP_SM.ANGLE_MIN Minimum Angle
SWAP_SM.DENSITY_MIN Minimum pseudo density
SWAP_SM.VELOCITY_MIN Minimum pseudo speed
SWAP_SM.TEMP_MIN Minimum pseudo Temperature
SWAP_SM.ANGLE_MAX Maximum Angle
SWAP_SM.DENSITY_MAX Maximum pseudo density
SWAP_SM.VELOCITY_MAX Maximum pseudo speed
SWAP_SM.TEMP_MAX Maximum pseudo temperature
SWAP_SM.CHKSUM XOR checksum
HISTOGRAM Type 1
================
SWAP_H0.CC_PKT_DATA_LN Primary Header - Packet Length
SWAP_H0.CC_MET_TIME Secondary Header - Time
SWAP_H0.BEG_TIME Time stamp at the beginning of
this histogram period
SWAP_H0.END_TIME The time stamp at the end of this histogram period
SWAP_H0.SMPLS_CNT Number of 64-second samples used
SWAP_H0.PLAN_ID The Plan ID used for the
current science sweeping mode
SWAP_H0.TABLE_ID Table ID within the Plan ID that is being used
SWAP_H0.SEQNUM_CNT Sequence number starting at 0 for header
SWAP_H0.DATA Histogram data
SWAP_H0.CHKSUM XOR checksum
HISTOGRAM Type 2
================
SWAP_H1.CC_PID_VER Primary Header - Version Number
SWAP_H1.CC_PID_TYPE Primary Header - Packet Type
SWAP_H1.CC_PID_SEC_FLAG Primary Header - Secondary Header Flag
SWAP_H1.CC_PID_APID Primary Header - Application ID
SWAP_H1.CC_PSC_GRP_FLAG Primary Header - Grouping Flag
SWAP_H1.CC_PSC_SSC Primary Header - Sequence Count
SWAP_H1.CC_PKT_DATA_LN Primary Header - Packet Length
SWAP_H1.CC_MET_TIME Secondary Header - Time
SWAP_H1.SEQNUM_CNT Sequence number
SWAP_H1.DATA Histogram data
SWAP_H1.CHKSUM XOR checksum starting with
beginning of CCSDS header
HOUSEKEEPING
============
SWAP_HK.CC_PID_VER Primary Header - Version Number
SWAP_HK.CC_PID_TYPE Primary Header - Packet Type
SWAP_HK.CC_PID_SEC_FLAG Primary Header - Secondary Header Flag
SWAP_HK.CC_PID_APID Primary Header - Application ID
SWAP_HK.CC_PSC_GRP_FLAG Primary Header - Grouping Flag
SWAP_HK.CC_PSC_SSC Primary Header - Sequence Count
SWAP_HK.CC_PKT_DATA_LN Primary Header - Packet Length
SWAP_HK.CC_MET_TIME Secondary Header - Time
SWAP_HK.CMD_EXE_CNT Cumulative mod-256 count of
successfully executed commands
SWAP_HK.CMD_REJ_CNT Cumulative mod-256 count of rejected commands
SWAP_HK.LUT_CHOICE Which LUT is in use
SWAP_HK.PCEM_SAFE PCEM was safed due to CEM interrupts
SWAP_HK.SCEM_SAFE SCEM was safed due to CEM interrupts
SWAP_HK.WDT_ST SWAP has rebooted due to a watchdog expiration.
SWAP_HK.RCV_SAFE_ST SWAP has received safe command from S/C
SWAP_HK.SAFE_ST SWAP has safed itself.
SWAP_HK.PCEM_RATE_ST Count rate threshold for PCEM
counter has been exceeded
SWAP_HK.SCEM_RATE_ST Count rate threshold for the SCEM
counter has been exceeded
SWAP_HK.PCEM_CURR_ST Current threshold for the PCEM has been exceeded
SWAP_HK.SCEM_CURR_ST Current threshold for the SCEM has been exceeded
SWAP_HK.PCEM_VOLT_ST Voltage tolerance for the PCEM has been exceeded.
SWAP_HK.SCEM_VOLT_ST Voltage tolerance for the SCEM has been exceeded.
SWAP_HK.LVPS_VOLT_ST Voltage tolerance for +5 V or -5V supply
has been exceeded.
SWAP_HK.LVPS_CURR_ST Current tolerance for +5 V or -5V supply
has been exceeded.
SWAP_HK.OVR_TEMP_ST Upper temperature limit exceeded.
SWAP_HK.UND_TEMP_ST Lower temperature limit exceeded.
SWAP_HK.MODE Enumerated type representing each of the modes
SWAP_HK.MEMDP_ST MEMDUMP State
SWAP_HK.SENSOR_TEMP Temperature of sensor detector. AD mux = 0x10
SWAP_HK.HVSUPP_TEMP Temperature of HVPS. AD mux = 0x11
SWAP_HK.CNTRLR_TEMP Temperature of controller. AD mux = 0x12
SWAP_HK.PCEM_VOLT Voltage monitor of PCEM high-voltage
power supply. AD mux = 0x02
SWAP_HK.SCEM_VOLT Voltage monitor of SCEM high-voltage
power supply. AD mux = 0x03
SWAP_HK.PCEM_CURR Strip current monitor of PCEM high-voltage
power supply. AD mux = 0x04
SWAP_HK.SCEM_CURR Strip current monitor of SCEM high-voltage
power supply. AD mux = 0x05
SWAP_HK.P5_VOLT Voltage monitor of +5V power supply.
AD mux = 0x0c
SWAP_HK.N5_VOLT Voltage monitor of -5V power supply.
AD mux = 0x0d
SWAP_HK.P5_CURR Current monitor of +5V power supply.
AD mux = 0x0e
SWAP_HK.N5_CURR Current monitor of -5V power supply.
AD mux = 0x0f
SWAP_HK.SWAP_REV Revision number for the SWAP software
SWAP_HK.LAST_OPCODE Opcode of last executed command
SWAP_HK.PHD_LLD_LVL DAC Level of PHD LLD
SWAP_HK.MEMLD_ST MEMLOAD state
SWAP_HK.OPT1_ST State of primary optics
SWAP_HK.OPT2_ST State of backup optics
SWAP_HK.PCEM_ST State of Primary Channel Electron
Multiplier disable/enable
SWAP_HK.SCEM_ST State of Secondary Channel Electron disable/enable
SWAP_HK.SPARE1 SPARE
SWAP_HK.PCEM_CNT_ST The PCEM count rate was tripped
but handled by SWAPFW
SWAP_HK.SCEM_CNT_ST The SCEM count rate was tripped
but handled by SWAPFW
SWAP_HK.PCEM_CURRTHR Current level when PCEM safety algos are tripped
SWAP_HK.SCEM_CURRTHR Current level when SCEM safety algos are tripped
SWAP_HK.PCEM_LVL PCEM DAC level
SWAP_HK.SCEM_LVL SCEM DAC level
SWAP_HK.AGND_VOLT Voltage monitor of Analog ground. A/D mux = 0x00
SWAP_HK.CEM_CURR Current level when SCEM safety
interrupt is tripped
SWAP_HK.ESA1_VOLT Voltage monitor of ESA high-voltage
power supply. AD mux = 0x06
SWAP_HK.ESA2_VOLT Voltage monitor of ESA high-voltage
power supply. AD mux = 0x07
SWAP_HK.DFL1_VOLT Voltage monitor of DFL high-voltage
power supply. AD mux = 0x08
SWAP_HK.DFL2_VOLT Voltage monitor of DFL high-voltage
power supply. AD mux = 0x09
SWAP_HK.RPA1_VOLT Voltage monitor of RPA high-voltage
power supply. AD mux = 0x0a
SWAP_HK.RPA2_VOLT Voltage monitor of RPA high-voltage
power supply. AD mux = 0x0b
SWAP_HK.P2_5_VOLT Voltage monitor of +2.5V reference. AD mux = 0x13
SWAP_HK.PHD_LLD_VOLT Voltage monitor of PHD_LLD. Ad mux = 0x14
SWAP_HK.PCEM_RATELIM The count value at which the
primary CEM safety limit is set.
SWAP_HK.SCEM_RATELIM The count value at which the
secondary CEM safety limit is set.
SWAP_HK.STIM_ENA State of whether the stimultor
pulsers are enabled or disabled.
SWAP_HK.PPS_SEL_ST State of which side of the IEM
interface is being used.
SWAP_HK.PPS_DET_ST 1 PPS detected state
SWAP_HK.CEM_INT_LIM Current limit at which the CEM
triggers an interrupt.
SWAP_HK.CMD_ECHO_ST Whether command echo is enabled or disabled
SWAP_HK.HV_PGSAFE_ST State of safe / arm plug
SWAP_HK.HV_PGENA_ST State of high-voltage disable/enable plug
SWAP_HK.HV_ARM_ST State of high-voltage software disable/enable
SWAP_HK.CEM_INT_DIP Counts to dip the CEM supplies
SWAP_HK.PLAN_ID The Plan ID used for the current
science sweeping mode if any.
SWAP_HK.SWEEP_ID Current Sweep table ID
SWAP_HK.ANGLE The commanded angle for deflection compensation
SWAP_HK.PCEM_VLT1_ST PCEM voltage is out of tolerance
for only one 0.5 second sample
SWAP_HK.PCEM_CUR1_ST PCEM current is out of tolerance
for only one 0.5 second sample
SWAP_HK.SCEM_VLT1_ST SCEM voltage is out of tolerance
for only one 0.5 second sample
SWAP_HK.SCEM_CUR1_ST SCEM current is out of tolerance
for only one 0.5 second sample
SWAP_HK.PCEM_INT_ST The CEM current interrupt was tripped,
but handled by SWAPFW
SWAP_HK.SCEM_INT_ST The CEM current interrupt was tripped,
but handled by SWAPFW
SWAP_HK.EEP2_RDY EEPROM 2 is ready to be written
SWAP_HK.EEP1_RDY EEPROM 1 is ready to be written
SWAP_HK.FPGA_TYPE Type number of the FPGA
SWAP_HK.FPGA_REV Revision number of the FPGA
SWAP_HK.SM_TLM How often the science summary packet is output.
SWAP_HK.HX_TLM How often the histogram
telemetry packet is output.
SWAP_HK.RT_TLM How often all of the 64-second
real-time packets are output
SWAP_HK.HK_TLM How often the housekeeping packet is output.
SWAP_HK.FPGA_PUP_ST A status of the power on check
of the FPGA initialization check
SWAP_HK.EEPL2_CKS_ST Status of the power on check
of the EEP_L2 checksum
SWAP_HK.EEPL1_CKS_ST Status of the power on check
of EEP_L1 checksum
SWAP_HK.RAM_D_ST Status of the power on check
of the RAM_D memory test
SWAP_HK.EEPC2_CKS_ST Status of the power on check
of the EEP_C2 checksum
SWAP_HK.EEPC1_CKS_ST Status of the power on check
of the EEP_C1 checksum
SWAP_HK.RAM_C_ST Status of the power on check
of the RAM_C memory test
SWAP_HK.PROM_CKS_ST Status of the power on check
of the PROM checksum
SWAP_HK.CHKSUM XOR checksum