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.


SOC_INST_ICD_TABLE7_1.PNG 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.
SOC_INST_ICD_TABLE7_2.PNG 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.
SOC_INST_ICD_TABLE7_3.PNG 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.
SOC_INST_ICD_TABLE7_4.PNG 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. SOC_INST_ICD_FIGURE8_0.PNG 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 SOC_INST_ICD_FIGURE8_1.PNG 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.
SOC_INST_ICD_TABLE8_1.PNG 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. SOC_INST_ICD_FIGURE9_1.PNG 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.
SOC_INST_ICD_TABLE9_5.PNG 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.
SOC_INST_ICD_TABLE9_6.PNG Table 9-6
Table 9-6: Low Rate Instrument Telemetry Description
SOC_INST_ICD_TABLE9_7.PNG 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. SOC_INST_ICD_FIGURE9_8.PNG 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
SOC_INST_ICD_EQUATION9_1.PNG 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.
SOC_INST_ICD_TABLE9_9.PNG 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
SOC_INST_ICD_EQUATION9_2.PNG 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
SOC_INST_ICD_TABLE9_10.PNG 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).
SOC_INST_ICD_TABLE9_11.PNG 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. SOC_INST_ICD_FIGURE9_2.PNG Figure 9-2: LORRI Spectral Response vs Wavelength SOC_INST_ICD_FIGURE9_3.PNG 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. SOC_INST_ICD_FIGURE9_4.PNG Figure 9-4 Example of Special Processing of Calibrated Data 9.3.4 Dataflow Block Diagram SOC_INST_ICD_FIGURE9_5.PNG 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.
SOC_INST_ICD_TABLE9_12.PNG 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
SOC_INST_ICD_EQUATION9_3.PNG 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.
SOC_INST_ICD_TABLE9_13.PNG 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:
SOC_INST_ICD_TABLE9_14.PNG 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)
SOC_INST_ICD_TABLE9_15.PNG 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. SOC_INST_ICD_FIGURE10_1.PNG 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. SOC_INST_ICD_FIGURE10_2.PNG 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.
SOC_INST_ICD_TABLE10_2.PNG 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).
SOC_INST_ICD_TABLE10_3.PNG 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.
SOC_INST_ICD_TABLE10_4.PNG 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.
SOC_INST_ICD_TABLE10_1.PNG 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.
SOC_INST_ICD_EQUATION10_1.PNG 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
SOC_INST_ICD_EQUATION10_2.PNG 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.
SOC_INST_ICD_EQUATION10_3.PNG 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
SOC_INST_ICD_EQUATION10_4.PNG 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.
SOC_INST_ICD_EQUATION10_5.PNG 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.
SOC_INST_ICD_TABLE10_6A.PNG 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.
SOC_INST_ICD_TABLE10_6B.PNG 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.
SOC_INST_ICD_TABLE10_7.PNG 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.
SOC_INST_ICD_TABLE10_8.PNG 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.
SOC_INST_ICD_TABLE10_9.PNG 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.
SOC_INST_ICD_EQUATION10_7.PNG 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 SOC_INST_ICD_FIGURE11_1A.PNG Figure 11-1a Dataflow Block Diagram, Part A SOC_INST_ICD_FIGURE11_1B.PNG 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:
SOC_INST_ICD_TABLE11_1.PNG Table 11-1
Table 11-1: B boxes in normal mode In diagnostic mode, the boxes were:
SOC_INST_ICD_TABLE11_2.PNG Table 11-2
Table 11-2: B boxes in diagnostic mode C Rates:
SOC_INST_ICD_TABLE11_3.PNG Table 11-3
Table 11-3: C Rates Notes: -"Singles" means single events on the named detector. HK Rates: These are various housekeeping values:
SOC_INST_ICD_TABLE11_4.PNG 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:
SOC_INST_ICD_TABLE11_5.PNG 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:
SOC_INST_ICD_TABLE11_6.PNG 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.
SOC_INST_ICD_EQUATION11_8.PNG 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. SOC_INST_ICD_FIGURE11_2.PNG Figure 11-2: Location of PEPSSI on the New Horizons spacecraft. The lightly shaded area denotes PEPSSI Field-of-View (FOV) SOC_INST_ICD_FIGURE11_3.PNG Figure 11-3: Schematic drawings of the PEPSSI sensor SOC_INST_ICD_FIGURE11_4.PNG Figure 11-4: A cut-away view of the PEPSSI FOV. SOC_INST_ICD_FIGURE11_5.PNG Figure 11-5: Expanded view of the PEPSSI sensor. SOC_INST_ICD_FIGURE11_6.PNG Figure 11-6: Pepssi Layout labelling SOC_INST_ICD_FIGURE11_7.PNG Figure 11-7: PEPSSI Rate Boxes on the TOF vs Energy Plane. Normal Mode. SOC_INST_ICD_FIGURE11_8A.PNG Figure 11-8A: 2D PHA Histogram: No weighting. Note: artifact in high energy protons (Box B03). SOC_INST_ICD_FIGURE11_8B.PNG 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. SOC_INST_ICD_FIGURE12_1.PNG 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.
SOC_INST_ICD_TABLE12_1.PNG 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.
SOC_INST_ICD_TABLE12_2.PNG 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.
SOC_INST_ICD_TABLE12_3.PNG 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."
SOC_INST_ICD_TABLE12_4.PNG 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:
SOC_INST_ICD_TABLE12_5.PNG 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:
SOC_INST_ICD_TABLE12_6.PNG 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.
SOC_INST_ICD_TABLE12_7.PNG 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.
SOC_INST_ICD_TABLE12_8.PNG 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. SOC_INST_ICD_FIGURE13_1.PNG 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. SOC_INST_ICD_FIGURE13_7.PNG 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.
SOC_INST_ICD_EQUATION13_1.PNG 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.
SOC_INST_ICD_EQUATION13_2.PNG 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 SOC_INST_ICD_FIGURE13_8.PNG 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. SOC_INST_ICD_FIGURE14_1.PNG 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. SOC_INST_ICD_FIGURE14_2.PNG 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). SOC_INST_ICD_FIGURE14_3.PNG 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 ). SOC_INST_ICD_FIGURE14_4.PNG 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 SOC_INST_ICD_FIGURE14_5.PNG 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. SOC_INST_ICD_FIGURE14_6.PNG 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. SOC_INST_ICD_FIGURE14_7.PNG 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. SOC_INST_ICD_FIGURE14_8.PNG 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 SOC_INST_ICD_FIGURE14_9.PNG 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
SOC_INST_ICD_EQUATION14_1_6.PNG 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. SOC_INST_ICD_FIGURE14_10.PNG 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. SOC_INST_ICD_FIGURE14_11.PNG 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. SOC_INST_ICD_FIGURE14_12.PNG 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. SOC_INST_ICD_FIGURE14_13.PNG 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 SOC_INST_ICD_FIGURE14_14.PNG 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