Data Set Overview : This data set 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) and 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 will cover any data received during an extended mission. 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 throughout 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. n 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 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, and TOF:time-of-flight 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 225 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 [YOUNGETAL2004]. 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. 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. For information about the calibrated files, please see the CALIBRATED_DATA_SET.CAT. 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 a 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 [FURMANETAL2005]. The format can also be found in the .FMT files in the FM/UNCALIBRATED directory. The timestamps, position data, and other spacecraft information were processed using SPICE kernels. The Cassini SPICE kernels are archived at https://naif.jpl.nasa.gov/naif/data_archived.html. 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. 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 a table of instrument anomalies and resolutions. References : [FURMANETAL2005] 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. [YOUNGETAL2004] Cassini Plasma Spectrometer Investigation, Space Sci. Rev. 114, 1-112, 2004.

Review : These data have been reviewed 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 will be 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. telemety outages b. data policing violations (CAPS data volume higher than allocated) c. incorrect spacecraft data mangement 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 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 transmitts 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 labelled as having both a 'bad checksum and fill'. There is an inidicator 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 ancillay data file. Each sensor and/or data type has its own quality flag. Fill values for each sensor can be found in [FURMANETAL2005] or in the corresponding .FMT file. 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 to 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 data set is that the data are not calibrated. Please use the CALIBRATED data set 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.