Cassini CAPS Raw Bundle
Cassini CAPS Raw Data Description
PDS3 DATA_SET_ID = CO-E/J/S/SW-CAPS-2-UNCALIBRATED-V1.0
PDS3 DATA_SET_NAME =
CASSINI ORBITER EARTH/JUP/SAT/SW CAPS UNCALIBRATED V1.0
START_TIME = 1999-01-04T00:00:00
STOP_TIME = 2012-06-02T06:11:45
PDS3 DATA_SET_RELEASE_DATE = 2013-02-13
PRODUCER_FULL_NAME = JUDITH D. FURMAN
CURATING_NODE_ID = PPI
MISSION_NAME =
CASSINI-HUYGENS MISSION TO SATURN AND TITAN
References:
CAPS standard data products and archive volume
software interface specification, Version 1.9, JPL SIS ID:
IO-AR-017, Southwest Research Institute, San Antonio, TX 78250,
2005.
Cassini Plasma Spectrometer Investigation,
Space Sci. Rev. 114, 1-112, 2004.
D. T. Young, J. J. Berthelier, M. Blanc, J. L. Burch, A. J. Coates,
R. Goldstein, M. Grande, T. W. Hill, R. E. Johnson, V. Kelha,
D. J. McComas, E. C. Sittler, K. R. Svenes, K. Szegö, P. Tanskanen,
K. Ahola, D. Anderson, S. Bakshi, R. A. Baragiola, B. L. Barraclough,
R. K. Black, S. Bolton, T. Booker, R. Bowman, P. Casey, F. J. Crary,
D. Delapp, G. Dirks, N. Eaker, H. Funsten, J. D. Furman, J. T. Gosling,
H. Hannula, C. Holmlund, H. Huomo, J. M. Illiano, P. Jensen,
M. A. Johnson, D. R. Linder, T. Luntama, S. Maurice, K. P. McCabe,
K. Mursula, B. T. Narheim, J. E. Nordholt, A. Preece, J. Rudzki,
A. Ruitberg, K. Smith, S. Szalai, M. F. Thomsen, K. Viherkanto,
J. Vilppola, T. Vollmer, T. E. Wahl, M. Wüest, T. Ylikorpi, C. Zinsmeyer
Wilson, Robert J., et al., PDS User's Guide for Cassini
Plasma Spectrometer (CAPS), Document can be found at the PDS Planetary
Plasma Interactions (PPI) Node, under the CAPS Data Archive website,
2012.
These data were originally archived in the following PDS3 data set:
CO-E/J/S/SW-CAPS-2-UNCALIBRATED-V1.1 (https://doi.org/10.17189/1519592)
This data consists of all of the uncalibrated data collected by the
Cassini Plasma Spectrometer (CAPS) on-board the Cassini spacecraft
during the entire Cassini mission.
These data were acquired in a mix of CAPS operating modes beginning
with the first instrument checkout in January 1999 and continuing
throughout the Cassini Tour and through the end of prime mission.
The data set covers the time period from 1999-004T03:07:47 UT until
end of prime mission (July 2008). In addition, it covers data from
the Equinox (July 2008 through July 2010) and Solstice (July 2010
through July 2017) extended missions. Sampling rates were variable
and depended upon the downlink capabilities and other activities
on-board.
For times when CAPS is not producing data due to being turned off or
due to communication issues, the data set will not contain data.
This effect can be sensor/data type specific.
Data Overview
=================
This data consists of all of the uncalibrated data collected by
the Cassini Plasma Spectrometer (CAPS) on-board the Cassini
spacecraft during the entire Cassini mission. CAPS produces the
following data products:
Electron Spectrometer data (ELS)
Ion Beam Spectrometer data (IBS)
Ion Mass Spectrometer ion data (ION)
Ion Mass Spectrometer singles data (SNG)
Ion Mass Spectrometer logicals data (LOG)
Ion Mass Spectrometer 'time of flight' (TOF)
-linear electric field (LEF)
-straight through data (ST)
Actuator data (ACT)
Ancillary information (ANC)
These data were acquired in a mix of CAPS operating modes beginning
with the first instrument checkout in January 1999 and continuing
throughout the Cassini Tour and through the end of prime mission.
The data set covers the time period from 1999-004T03:07:47 UT until
end of prime mission (July 2008). In addition, it covers data from
the Equinox (July 2008 through July 2010) and Solstice (July 2010
through July 2017) extended missions. Sampling rates were variable
and depended upon the downlink capabilities and other activities
on-board.
For times when CAPS is not producing data due to being turned off or
due to communication issues, the data set will not contain data.
This effect can be sensor/data type specific.
Parameters
==========
Data Sampling
-------------
Data acquisition strategies varied through the mission. During
the cruise phase, the instrument was only capable of 2 distinct
rates. In addition, the spacecraft telemetry modes were not fully
developed which lead to peculiar recording strategies as well. As
the mission progressed, the flight software for both the CAPS
instrument and the Cassini spacecraft matured. During the Jupiter
period, the spacecraft implemented data policing, where an
instrument was assigned a data allocation and the spacecraft would
not record any more data from an instrument who had reached their
negotiated limit. This strategy was useful during the planning
process, but careful control had to be exercised to not run over
the allocation. Data gaps in the CAPS data can come from a
variety of sources: instrument was off, specific sensors were off,
ground communication problems, CAPS over-allocation issues, the
instrument was in sleep mode for Probe activities, or there was a
problem with commanding on-board the spacecraft.
During the cruise phase, the average data rate for CAPS was low.
If at all possible, the instrument was set to cycle between our
lowest rate (in order to get contiguous data) and a higher rate
(for higher resolution data). The combined high & low rate were
designed to give us the average low rate data. This scheme did
not change as we entered Approach Science and Tour, but the
average data rate was increased. In addition to running in survey
mode, we also acquired data in higher resolution modes around
Magnetospheric boundaries, Titan flybys, icy satellite flybys,
ring & satellite campaigns, and distant torus observations. In
addition, any data volume allocation that was not allocated to
other instruments was distributed to those who could take
advantage of the increase in data volume (and hence data
resolution).
At the maximum CAPS telemetry rate of 16 kbits/s all data products
coming out of the science and calibration modes can be
accommodated without the need for compression. The exception is
the compressed extraction of ions by the SAM (spectrum analzer module)
algorithm, and a semi-logarithmic collapse of all data words. The
collapse replaces 16-bit data words stored in the DPU with 8-bit data
words to be returned to Earth. For small data numbers, the 8-bit
values are equal to the 16-bit values, but for higher values the
scale is logarithmic. A similar 32- to 16-bit compression is used
for TOF data. As a result of this compression, the uncertainty in the
higher data numbers is roughly +/- 0.015N rather than the statistical
+/- N^(1/2). No attempt was made to carry out more exotic on-board
compression routines such as moment calculations or image-like
compressions, with the exception of a run-length compression of the
sparse, IBS data.
The contents of the CAPS data products at 16 kbits/s are distributed
among the three sensors, the ACT and housekeeping channels as
indicated below. Data products are organized along A-cycle (32.0 s)
boundaries. Acquisition and formation of B-cycle data products is
more complex than the A-cycle process: The CPU2 extracts TOF data in
the form of 512 channels each of ST and LEF data. In the default
mode, adjacent energy steps are sampled to produce
2RES x 32E x 512TOF = 32,768 words. In the standard CAPS telemetry
mode of 16 kbits/s, each word of B-cycle data is summed over
8 A-cycles, whereas for some lower rate modes it is summed over
16 A-cycles (i.e., the B-cycle is 8 A-cycles long for the
16 kbits/s mode and 16 A-cycles long for these other modes).
In the very early CAPS data, there was even a mode where it is
summed over 32 A-cycles. Most CAPS data products are generated
at lower data rates by collapsing (summing) the 16 kbps data
over adjacent energy, elevation and/or azimuth bins. In addition,
snapshots (uncollapsed subsets of the 16 kbps data) may be
included. The subset of data included in the snapshot can be
determined on the spacecraft, so that the snapshot
contains the peak of the velocity distribution. Leaving out
certain products entirely produces the smallest possible datasets.
The modes used by the CAPS instrument were revised prior to the
Cassini Jupiter encounter to include 0.25, 0.5, and 1 kbps rates,
in addition to the original 2 and 16 kbps modes. These modes were
further revised before reaching Saturn, to add 4 and 8 kbps modes
and incorporate experience from analysis of the Jupiter data.
Other data products that can be included as options (at the
expense of sensor data) are memory readout of control tables for
diagnostic purposes. Sequential event data that are used to verify
IMS operations can also be included.
Telemetry products in 16 kbits/s mode
--------------------------------------
Data channels
-----------------------
Product EQ EL AZ MQ LOG TOF
---------------------------------------
ELS 63 8 16 . . .
IBS 255 3 16 . . .
IMS ION 63 8 8 7 . .
IMS TDC LOG 63 . 8 . 4 .
IMS TDC SNG 63 8 8 . . .
IMS TOF LEF 32 . . . . 512
IMS TOF ST 32 . . . . 512
ACTUATOR 32 position samples
HOUSEKEEPING 164 bytes of data
---------------------------------------
EQ=energy/charge, EL=elevation,
AZ=azimuth, MQ=mass/charge, LOG=logical,
TOF=time-of-flight, LEF=linear
electric field, and ST=straight-through
Data are collected as raw counts. For the ELS sensor, the 63
energy steps are swept through every 2 seconds. For the IBS
sensor, the 255 energy steps are swept through every 2 seconds.
For the IMS sensor, the 63 energy steps are swept through every 4
seconds. To learn more about the energy range covered by each of
the sensors and any other details regarding data acquisition,
please see.
Processing
==========
The uncalibrated counts are collected, collapsed, and compressed on
board the spacecraft. The data is then downlinked to the Jet
Propulsion Query Servers where it is queried from the server (in
standard data unit format, SFDU) and ingested into the CAPS oracle
database and stored as CCSDS packets. From this point, the data is
collected into blocks of CCSDS packets which comprise an A-cycle (32
seconds) of data. These data are then decompressed into their
separate sensor pieces and stored as raw, decompressed counts in
tables in the database. From this point, archive files are generated
with the raw, decompressed counts, into uncalibrated data set files.
For the ancillary files (ANC), the reconstructed c-kernel is used to
get the most accurate pointing information into the file for team
use. Daily, automated checking is performed to make sure we have the
most recent files that are available. Any other information
necessary is found in the CAPS database, which has been populated
from the raw CCSDS packets. The data found in the ANC files use the
latest ephemeris information that is available at the time of archive.
The ANC data product label files specify which kernels were used to
generate the ephemeris information contained within.
For the actuator data product (ACT), in December 2004 the position
monitor became unreliable. Based on our understanding of the
position at the time the monitor failed, the actuator file was
updated with an estimated value. This estimation continued until TBD
time, at which point the actuator was moved and began reporting
reliable readings again. While trying to move the actuator to +90
degrees on March 21, 2005, we again encountered a time period where
the position was adjusted to account for the monitor reading
unreliably. On May 26, 2005 at 10:00:00, the actuator position
monitor was modified in the flight software to be the estimated
position instead of the hardware position. This data is also
corrected before being placed into the archive file to account for
any drift in the estimated position.
Data
====
The data are stored in multiple data files and have been organized by
sensor type, and further subdivided by data type. Each file contains
maximum of 6 hours of data, with only 4 files being generated per day
per product. Format of the data files can be found in the CAPS
instrument archive specification. The timestamps, position data,
and other spacecraft information were processed using SPICE kernels.
The Cassini SPICE kernels are archived at NAIF.
Coordinate Systems
==================
The data are provided in the instrument frame. In the ancillary data
files, you can find the spacecraft orientation, spacecraft-sun
position and velocity data, and spacecraft-Saturn position and
velocity data. Note that the latest and greatest ephemeris file that
was available at the time of archive is used to generate this information.
Ancillary Data
==============
Most ancillary data needed can be found in the ANC data file provided
with the data. In addition, there are other files that are necessary
to process the data. These include sweep tables for each sensor and
table of instrument anomalies and resolutions. Sweep tables can be
found in the calibration directory.
General browse plots can be found in the browse directory.
User's Guide
============
The Cassini CAPS User's Guide was written and published at the PDS during
2012. The User's Guide is 'designed to instruct a novice to CAPS to load
in the binary data in order that they can make basic plots and understand
the field-of-view of the instrument at a given time'. This is more
complicated than one might imagine. It does not explain how to navigate
the PDS. Nor does it explain how to do high level processing of the data
(i.e. extracting plasma parameters such as density, temperature or plasma
velocity). For those see the references in chapter 20, however this
document provides the information needed so that one can begin to write
their own analysis codes.
The User's Guide document will focus on analysis of the SNG dataset,
however as ELS and ION are so similar those are also covered. Basic IBS
and TOF details will be given. LOG data are not covered at all.
The PDS contains two catalogs of Cassini CAPS data, COCAPS_1SAT and
COCAPS_1SW. The User's Guide is about the COCAPS_1SAT dataset, the data
just prior to arriving at Saturn (SAT) until end of mission. COCAPS_1SW
is the solar wind (SW) dataset for the cruise phase in getting Cassini
from Earth to Saturn and is not covered in the document.
Review
======
These data have completed review by the instrument team and are of the
highest quality that can be generated at this time. Science results
based on these data have been published in several journals (Science,
Nature, JGR, etc.). After submission to the PDS, these data were
approved through the peer review process.
Data Coverage and Quality
=========================
Gaps
----
There are many gaps in the CAPS data stream and there are many
different sources for these gaps. Sources of gaps are as follows:
a. telemetry outages
b. data policing violations (CAPS data volume higher than
allocated)
c. incorrect spacecraft data management commanding
d. telemetry commanding during Cruise
e. instrument anomalies
f. instrument modes which don't return all data products
g. planned instrument power-off and/or sleep periods
h. instrument off due to bus imbalance/short issues
When there is no data for a time period, one of the above sources
is the reason behind the gap. There is no indicator to which of
the sources is responsible for the gap in data coverage.
Poor Data
---------
When the instrument transmits the data, there is an associated
checksum that is checked during decompression. If the checksum is
incorrect, the data are flagged as having a 'bad checksum'. The
other way to get poor data is when we are missing part of the data
product and use fill data to complete the product. The data
product is then labeled as having both a 'bad checksum and fill'.
There is an indicator for 'no data', but the indicator does not
tell why the data is missing. The 'no data' indicator is only used
if there is data for any of the other sensors. This information can
be found in the ancillary data file. Each sensor and/or data type
has its own quality flag. Fill values for each sensor can be found
in Furman, Judith et al.
Sensor Gains
------------
Sensor gains were set for each sensor based upon calibration
information determined on the ground. While in-flight, sensor
calibrations were performed and adjustments were made to the gain
of a sensor, based upon interpretation of the data by the team and
the leader of the sensor. During the tour phase, calibrations were
performed roughly once every 50 days. The change in gain can't be
tracked with the current archive data, but is done with
housekeeping information.
Anomalies
---------
There are currently way too many anomalies to put in at the moment.
I'll start working on it. I plan to describe the time coverage of
the anomaly, the affect on the data, diagnosis of the problem, and
when (if at all) we were able to fix the problem.
Limitations
===========
The main limitation to using this bundle is that the data are not
calibrated. Please use the CALIBRATED bundle for calibrated
data. A secondary limitation is to make sure to use the ancillary
data files to avoid using any poor data. In addition, care should
be taken around calibration periods as the sweep table and gain
levels are changing. Data around anomaly periods also needs to be
carefully considered. Lastly, a user's guide has been written to
help users get started using CAPS data.
|