Laboratory for Atmospheric and Space Physics (LASP)
University of Colorado at Boulder
CASSINI
ULTRAVIOLET IMAGING SPECTROGRAPH
FLIGHT CODE USER’S GUIDE
Rev
1
2
3
Description of Change
Draft for review
Typos.
Updated for version 1.1 of flight code
Reformatted for webpage
Approved
Date
9/96
6/97
11/98
1 DOCUMENT PURPOSE .............................................................................................1
2 REFERENCES.............................................................................................................1
3 ABBREVIATIONS AND ACRONYMS.....................................................................2
4 PROGRAMMING UVIS: AN OVERVIEW .................................................................2
5 PROGRAMMING AT LARGE.....................................................................................5
5.1 Turning On/Off Detector High Voltage....................................................................5
5.2 Modifying EUV or FUV Channel Configuration.......................................................6
5.3 Modifying the HDAC Channel Configuration..........................................................6
5.4 Commanding the Ion Pump.....................................................................................7
5 5 Selecting a Housekeeping Format..........................................................................8
5 6 Preventing a DS from Turning on High Voltage......................................................8
5.7 Defining What to Dump and How to Dump It.........................................................9
5.8 Starting a Distributed Sequence...........................................................................10
5.9 Terminating a Distributed Sequence.....................................................................10
5.10 Terminating an Observation Description Command............................................10
5.11 Modifying UVIS Memory Contents......................................................................10
5.12 Executing an Observation...................................................................................12
6 USING DISTRIBUTED SEQUENCES ....................................................................14
6.1 Distributed Sequence Concept............................................................................14
6.2 Distributed Sequence Load Format......................................................................17
6.3 Distributed Sequence Preparation........................................................................18
6.4 Miscellaneous.......................................................................................................18
7 PERFORMANCE ISSUES .......................................................................................18
7.1 Packet Production Rate.........................................................................................19
7.2 Initialization of the FUV and EUV Channels..........................................................20
7.3 Integration Memory Read Out Timing...................................................................20
7.4 Execution of 84Mem_Zero....................................................................................21
8 COMMAND EXECUTION VERIFICATION ............................................................21
8.1 Command Acceptance..........................................................................................22
8.2 ALF Load Acceptance...........................................................................................22
8.3 DS Load Acceptance............................................................................................22
8.4 Command Execution Verification...........................................................................23
9 ERROR REPORTING: WHERE, WHY, AND HOW TO FIX ...............................24
9.1 Loss of Science Data............................................................................................24
9.2 Hardware and Software Problems........................................................................25
9.3 Commanding Failures............................................................................................27
10 NOTES ON DATA ACQUISITION ..........................................................................29
10.1 Science Data Acquisition......................................................................................29
10.2 Housekeeping Data Acquisition............................................................................29
1 DOCUMENT PURPOSE
This document is intended for people who program and/or monitor the UVIS
instrument. Its main goals are to:
•
Introduce some concepts used in the RAM code which should be
understood before programming the UVIS instrument to acquire
science data.
•
Give an overview on how to program the instrument using direct or
distributed commands.
•
Present information on how to verify the proper execution of
commands.
•
List the errors that can be reported by the RAM and the PROM code
and describe the corrective actions that can be taken to fix them.
This document presents the UVIS operation from the RAM code point of view.
From time to time it will refer also to the PROM code.
This document does not intend to detail every command or provide in-depth
information on the format of the housekeeping and science packets returned by
the instrument. The reader should be familiar with at least the parts of reference
(1) and reference (2) that specifically apply to the UVIS instrument.
This document assumes that the reader is familiar with the UVIS instrument
architecture.
Note that this document is based on version 1.1 of the RAM code.
2 REFERENCES
(1) CAS-3-281 Telemetry Formats and Measurements. JPL document
(2) CAS-3-291 Uplink Formats and Command Tables. JPL document
(3) CAS-3-271 Spacecraft Intercommunications. JPL document
(4) UVIS Instrument Software Detail Design Document. LASP document
(5) UVIS Science Packet Format. LASP document
Cassini UVIS Flight Code User’s Guide 11/98
1
(6) Cassini Command And Data Subsystem - Bus Interface Unit Design
Package. JPL document
(7) UVIS Instrument Microprocessor and Logic Description Document. LASP
document
(8) CAS-4-2084 UVIS Functional Requirement Document. JPL document
(9) UVIS Operational Procedures. LASP document
3 ABBREVIATIONS AND ACRONYMS
A/D
ALF
ASCII
BIU
bps
CDS
DS
DTSTAR
EUV
FIFO
FUV
HDAC
HSP
HVPS
MRO
ms
n/a
OASIS-CC
ODC
PROM
pps
RAM
RTI
SSR
UVIS
Analog to Digital
Accelerated Load Format
American Standard Code for Information Interchange
Bus Interface Unit
Bits per second
Command and Data Subsystem
Distributed Sequence
Dead Time Start
Extreme Ultra Violet
First In First Out
Far Ultra Violet
Hydrogen Deuterium Absorption Cell
High Speed Photometer
High Voltage Power Supply
Memory Read Out
Millisecond
Non applicable
Generic name for the support equipment used by UVIS
Observation Description Command
Programmable Read-Only Memory
Packets per second
Random Access Memory
Real Time Interrupt
Solid State Recorder
Ultra Violet Imaging Spectrograph
4 PROGRAMMING UVIS: AN OVERVIEW
Programming the UVIS instrument is done by (1) defining the sequences of
commands that will accomplish the program; and (2) sending these commands
to UVIS RAM code for execution. Command sequences can be stored on the
ground (for example, as part of an OASIS-CC command script) or in the
spacecraft CDS memory. Or they can be stored within the UVIS memory.
Cassini UVIS Flight Code User’s Guide 11/98
2
Direct Commands
When command sequences are stored on the ground or in the spacecraft
memory, the sequencing (i.e., the timing between each command in the
command sequence) is controlled by the ground computer or by the spacecraft
computer. This type of commanding is referred as direct commanding. Direct
commands are executed immediately by the flight code provided that no other
command is currently executing. Otherwise they are stored internally in a FIFO
buffer and executed as soon as possible.
Distributed Commands
When they are stored within the UVIS program memory, the command
sequences contain timing information that allows the RAM code to sequence
their execution. This type of commanding is referred to as distributed
commanding (because it is not under the control of the central spacecraft
processor). Command sequences stored in the UVIS memory are referred to as
Distributed Sequences (DS). The execution of a DS is started by a direct
command called 84TRIGGER.
Command Types
The RAM code executes a large set of commands (see [2]). Some commands
act only on one element of UVIS. Some more complex commands can act on
multiple elements of UVIS. In particular, scientific observations are defined via
Observation Description Commands (ODC). ODCs put UVIS under the correct
configuration and control the data acquisition process for a particular science
observation.
The following rules govern the interaction between commands:
•
Only one non-ODC command can be executed at one time.
•
Only one ODC can be executed at one time.
•
Non-ODC commands can be executed while UVIS is executing the
data acquisition portion of an ODC.
•
If UVIS is executing an ODC and receives a non-ODC command:
◊
If the command does not affect the instrument configuration (as far
as the channels being used are concerned), then data acquisition
does not stop while the non-ODC command is executed.
Cassini UVIS Flight Code User’s Guide 11/98
3
◊
•
If the command affects the configuration of the channels
providing data, then data acquisition stops while the command
is executed. Data acquisition then restarts under the new
instrument configuration.
If UVIS is running an ODC and receives another ODC:
◊
The data acquisition under the first ODC is terminated
◊
The new ODC is executed to re-configure UVIS
◊
And data acquisition is re-started under the new configuration.
Data Storage
Although the HSP and the HDAC channels produce data continuously, the EUV
and FUV channels burst up to 64K 16-bit words at the end of one integration
period. For this reason, most of the UVIS memory is used as a buffer where
“ready-to-be-transmitted” science packets are stored awaiting pickup by the
spacecraft CDS. Up to 720 science packets can be queued before UVIS starts
loosing data.
It is the user’s responsibility to make sure that the spacecraft telemetry mode
accommodates the rate and volume of the data produced by UVIS and is able
to downlink the data remaining in UVIS memory after an observation is
terminated. The UVIS RAM code does not account the spacecraft telemetry
mode: whenever the spacecraft requests a UVIS science packet it is passed to
the CDS if one is available.
Cassini UVIS Flight Code User’s Guide 11/98
4
packet
Transmit
Packet
packet
BIU memory
Queue
packet
Load
packet
Queue
packet
Load
packet
Queue
packet
Load
packet
Queue
packet
Load
packet
data
EUV
packet
FUV
Packet Queue
UVIS memory
HDAC
HSP
5 PROGRAMMING AT LARGE
5.1 TURNING ON/OFF DETECTOR HIGH VOLTAGE
NAME
84EUV_HV_LEVEL
84FUV_HV_LEVEL
84HDAC_HV_LEVEL
84HSP_HV_LEVEL
PURPOSE
TURN ON/OFF THE EUV CHANNEL HVPS AND
SELECT THE CHANNEL VOLTAGE LEVEL.
TURN ON/OFF THE FUV CHANNEL HVPS AND
SELECT THE CHANNEL VOLTAGE LEVEL.
TURN ON/OFF THE HDAC CHANNEL HVPS
TURN ON/OFF THE HSP CHANNEL HVPS
The HVPS on/off commands are 84EUV_HV_LEVEL, 84FUV_HV_LEVEL,
84HDAC_HV_LEVEL, and 84HSP_HV_LEVEL. These commands affect the
corresponding channel even if the channel is not integrating. They are RAM
code commands only.
Note: The EUV and the FUV HVPS should not be set to a level greater than 1.
The RAM code does not prevent the setting of the EUV and the FUV HVPS to a
level greater than 1.
Cassini UVIS Flight Code User’s Guide 11/98
5
5.2 MODIFYING EUV OR FUV CHANNEL CONFIGURATION
NAME
84EUV_SLIT_POS
84FUV_SLIT_POS
84OC_COV_POS
84TST_PULSE
PURPOSE
SELECT THE EUV CHANNEL SLIT POSITION
SELECT THE FUV CHANNEL SLIT POSITION
SELECT THE EUV CHANNEL OCCULTATION MIRROR
POSITION
TURN ON/OFF THE EUV AND FUV CHANNEL TEST
PULSES
The commands 84EUV_SLIT_POS, 84FUV_SLIT_POS and 84OC_COV_POS,
84TST_PULSE modify the configuration of the EUV and FUV channel. These
commands affect the corresponding channel even if the channel is not
integrating. They are RAM code commands only.
The EUV and the FUV slits can be moved clockwise or counter-clockwise. For
the RAM code “clockwise” has the following meaning (starting from the highresolution position):
NEXT POSITION
LOW RESOLUTION
OCCULTATION
LOW RESOLUTION
HIGH RESOLUTION
COMMANDED
POSITION VALUE
(EUV CHANNEL)
2
3
0
1
COMMANDED
POSITION VALUE
(FUV CHANNEL)
3
2
1
0
Note: At the first sleep-to-active transition, the RAM code moves both slits to the
high-resolution position and the occultation mirror to the closed position.
Note: The commands 84FUV_SLIT_POS and 84EUV_SLIT_POS contain a
duration field that is only taken into account when the commands are part of a
DS.
5.3 MODIFYING THE HDAC CHANNEL CONFIGURATION
NAME
84HDAC_D_FIL_SELECT
84HDAC_H_FIL_SELECT
84HDAC_D_FIL_LIM
84HDAC_H_FIL_LIM
84HDAC_TBL_LOAD
PURPOSE
SELECT THE D CELL FILAMENT
SELECT THE H CELL FILAMENT
SET THE MAXIMUN VOLTAGE THAT CAN BE
APPLIED TO THE D CELL FILAMENT
SET THE MAXIMUM VOLTAGE THAT CAN BE
APPLIED TO THE H CELL FILAMENT
LOAD THE H AND D CELL VOLTAGE TABLES
Cassini UVIS Flight Code User’s Guide 11/98
6
The commands 84HDAC_D_FIL_SELECT, 84HDAC_H_FIL_SELECT,
84HDAC_D_FIL_LIM, 84HDAC_H_FIL_LIM, and 84HDAC_TBL_LOAD modify
the configuration of the HDAC channel. They are RAM code commands only.
The commands 84HDAC_D_FIL_SELECT and 84HDAC_H_FIL_SELECT
affect the HDAC channel even if the channel is not integrating.
The command 84HDAC_TBL_LOAD loads the H and D cell filament voltage
tables. This command has no effect on the channel when the channel is not
integrating.
The commands 84HDAC_D_FIL_LIM, 84HDAC_H_FIL_LIM define the
maximum voltage that will be applied to the D and H cell filaments, respectively.
If either command is sent while the channel is not integrating, they will affect the
HDAC channel at the next integration. If either command is sent while the
channel is integrating, they affect the HDAC channel immediately. The main
purpose of these two commands is to prevent accidental usage of the filament
during bench testing.
Note: When the RAM code is started, both H and D cell filament voltage limits
are set to 7.
Note: At the first sleep-to-active transition, the RAM code resets the filament
selection to filament 1 for both the H and D cells.
5.4 COMMANDING THE ION PUMP
NAME
84ION_PUMP_ON
84ION_PUMP_OFF
PURPOSE
TURN ON THE FUV CHANNEL ION PUMP
TURN OFF THE FUV CHANNEL ION PUMP
The ion pump is turned on using the 84ION_PUMP_ON command. If the
duration field of the command is set to zero, the ion pump is turned on forever.
The ion pump is turned off by the 84ION_PUMP_OFF command.
Note: When a 84ION_PUMP_ON command is received while the ion pump is
already on, the duration field of the new command is used. It is not added to the
duration of the previous 84ION_PUMP_ON command.
Note: The RAM is set up to minimize pump “motor boating” -- when the detector
internal pressure is very low, the ion pump HVPS regulator constantly switches
the power supply on and off. The RAM code turns off the ion pump HVPS after a
number of consecutive pressure readings are found to be below a threshold.
Cassini UVIS Flight Code User’s Guide 11/98
7
Then the RAM code turns the HVPS back on after a number of seconds. When
the RAM code is started, the threshold is set to 0 and the off/on timer is set to 10
minutes. These values can be modified using the memory modification
commands (see Section 5.11 below). The addresses of the locations to modify
are:
PURPOSE
ION PUMP OFF
THRESHOLD VALUE
ION PUMP ON DELTA
TIME
NUMBER OF
CONSECUTIVE
READING
ADDRESS TO MODIFY
VALUE TYPE
(in hex)
6A4C
16-BIT INTEGER
CORRESPONDING TO
THE RAW A/D READING
VALUE BELOW WHICH
THE ION PUMP SHOULD
BE TURNED OFF
6A4D (most significant) 32-BIT INTEGER — THE
and 6A4E (least
NUMBER OF RTI BEFORE
significant)
NEXT TURN ON
6A4F
16-BIT INTEGER
5.5 SELECTING A HOUSEKEEPING FORMAT
NAME
84HK_SELECT
PURPOSE
SELECT ONE OF THE TWO HOUSEKEEPING
PACKET FORMATS.
The 84HK_SELECT command selects a housekeeping format. Two formats are
available: normal and extended MRO (MRO stands for Memory Read Out). The
normal format is the default format. It carries all the instrument health and state
information and also contains the dump of 16 consecutive memory addresses
(see section 5.7). The extended MRO format carries minimal health and state
information and contains the dump of 46 consecutive memory addresses (see
section 5.7).
5.6 PREVENTING A DS FROM TURNING ON HIGH VOLTAGE
NAME
84HV_SEQ_ENA
PURPOSE
ALLOW/PREVENT A DS TO TURN ON A
CHANNEL HVPS
The command 84HV_SEQ_ENA can be used to prevent (or allow) a DS from
turning on a detector HVPS. The main purpose of this command is to prevent
Cassini UVIS Flight Code User’s Guide 11/98
8
mistakes during instrument and software checkout while the instrument is on the
bench. This is a RAM code command only.
Note: When the RAM code is started, turning on high voltage power supply from
a DS is enabled for all four channels.
5.7 DEFINING WHAT TO DUMP AND HOW TO DUMP IT
NAME
84MEM_DUMP
84MEM_DUMP_FAST
PURPOSE
SET THE END POINTS OF A MEMORY DUMP
ALLOW MEMORY DUMPING VIA THE SCIENCE
CHANNEL
The commands 84MEM_DUMP and 84MEM_DUMP_FAST define how UVIS
memory is dumped. Dumping memory can be useful when tracking a problem
or when the contents of a memory region need to be verified (after a load for
example). The command 84MEM_DUMP_FAST is not processed by the PROM
code.
84MEM_DUMP sets the starting address of the memory dump. The ending
address is derived by the RAM code from the 84MEM_DUMP command. In
housekeeping packets, the memory dump slots (16 slots in the “normal format”,
and 46 slots in the “extended MRO” format) are always filled with the contents of
consecutive memory addresses. For example, assume a dump request with a
starting address of 0 and ending address of 8, the RAM code will continuously
dump address 0 to 15 (if in the “normal” format) or 0 to 45 (if in the “extended
MRO” format). The PROM code dumps data between the addresses defined by
the 84MEM_DUMP command and uses the memory dump slots as a circular
buffer.
When the RAM code receives a 84MEM_DUMP_FAST command, the contents
of the memory region defined by the last 84MEM_DUMP command are dumped
once, via the science stream using fast memory dump packets.
Note: The fast memory dump packets are treated by the RAM code as any other
science packets. They may be queued in the “ready-to-be-transmitted” queue
before they are passed to the CDS. This makes the dumping of the memory
where science packets are queued somewhat tricky (as fast memory dump
packets may be written over the memory to be dumped). The packets are
generated as fast as possible, regardless of the actual telemetry rate.
Note: When the RAM code is initialized, the starting dump address is set to a
memory region that contains the RAM code version number. The first 2 16-bit
words of the dump display this information in ASCII (for example, “1.0A”). The
first character indicates the main release number, the third character the sub-
Cassini UVIS Flight Code User’s Guide 11/98
9
release number. The fourth and last character indicates the release status (A for
an alpha test release, B for a beta test release, space of an official release).
5.8 STARTING ADISTRIBUTED SEQUENCE
NAME
84TRIGGER
PURPOSE
START THE EXECUTION OF DS
Starting a DS is accomplished by executing a 84TRIGGER command. This
command is rejected if the DS buffer defined in the command is invalid or if the
distributed sequence defined in the command does not exist. This is a RAM
code only command.
5.9 TERMINATING A DISTRIBUTED SEQUENCE
NAME
84SEQ_HALT
PURPOSE
TERMINATE THE EXECUTION OF A DS
To terminate the execution of a DS, send the 84SEQ_HALT command. If when
this command is received, an ODC is executing, data acquisition under the
ODC is terminated: integration is disabled on all the integrating channels, all
HVPS are turned off, FUV and EUV pulses are disabled, and all currently “being
filled” science packets are put into the “ready-to-be-transmitted” queue. The
execution of the current DS is also interrupted; the remaining commands of the
DS are not executed. This is a RAM code only command.
5.10 TERMINATING AN OBSERVATION DESCRIPTION COMMAND
NAME
84SEQ_HALT
PURPOSE
TERMINATE THE EXECUTION OF A ODC
To terminate the execution of an ODC started as a direct command, use the
84SEQ_HALT command. This has the same effect as for an ODC started from a
DS (see section 5.9). This is a RAM code only command.
5.11 MODIFYING UVIS MEMORY CONTENTS
NAME
84MEM_MOD_ENA
84MEM_ZERO
84MEM_SET
84LOAD_SEQ
PURPOSE
ENABLE 84MEM_ZERO AND 84MEM_SET
ZERO PART OF THE UVIS MEMORY
SET ONE MEMORY LOCATION TO A VALUE
WRITE THE DATA CONTAINED IN THE
COMMAND IN UVIS MEMORY.
Cassini UVIS Flight Code User’s Guide 11/98
10
The commands 84MEM_MOD_ENA, 84MEM_ZERO, 84MEM_SET, and
84LOAD_SEQ modify the contents of the UVIS memory. 84MEM_ZERO and
84LOAD_SEQ are RAM code only commands. Both 84MEM_ZERO and
84MEM_SET must be immediately preceded by the 84MEM_MOD_ENA
command.
In general, the 84LOAD_SEQ is used to load a DS in one of the two DS buffers.
But it can also be used to re-write a portion of the UVIS memory (see Section 6).
Note: Memory modification is enabled by the 84MEM_MOD_ENA command. It
is disabled by the next non-84MEM_MOD_ENA command regardless of the
origin of the command (direct command or distributed sequence command).
This can make memory modification via direct command tricky when a
distributed sequence is executing.
Note: The 84MEM_ZERO command cannot reset more than one memory page
(64K words) at a time. The command is rejected if the memory end points that it
defines are not in the same memory page. In addition because of performance
issue (see Section 9), it is recommended that no more than 4096 consecutive
addresses be zeroed per command.
Note: It may happen that rather than zeroing a contiguous set of memory, you
would like to write a non-zero value. This can be done by loading in address
6A63 (hex) the value to use before executing the 84MEM_ZERO command.
Don’t forget to re-write 0 at address 6A63 (hex), using the 84MEM_SET
command.
Note: 84MEM_ZERO, 84MEM_SET, and 84LOAD_SEQ should be used with
great care as RAM does not check the validity of the addresses to modify. For
example, one can modify RAM code memory with any of these last three
commands.
Cassini UVIS Flight Code User’s Guide 11/98
11
5.12 EXECUTING AN OBSERVATION
NAME
84HSPGEN_EXEC
84HDAC_EXEC
84UVSIMPLE_EXEC
84UVPHOTO_EXEC
84UVGEN_EXEC
84GENERIC_EXEC
PURPOSE
EXECUTE AN HSP-ONLY EXPERIMENT
EXECUTE AN HDAC-ONLY EXPERIMENT
EXECUTE A ONE WINDOW, FUV OR EUV
EXPERIMENT
EXECUTE A COMBINED EUV, FUV, HPS AND
HDAC (IN PHOTOMETRY MODE)
EXPERIMENT. ONLY ONE WINDOW CAN BE
DEFINED FOR THE EUV AND THE FUV
CHANNELS.
EXECUTE A GENERIC FUV-ONLY OR EUVONLY EXPERIMENT. UP TO 10 WINDOWS CAN
BE DEFINED.
EXECUTE A GENERIC EXPERIMENT USING
ANY COMBINATION OF THE FOUR
DETECTORS. EUV AND FUV SETUP CAN BE
DEFINED WITH UP TO 10 WINDOWS.
Experiments are defined via Observation Description Commands (ODC). These
are commands that (1) completely define the instrument setup and (2) control
the data acquisition process after the instrument has been set up. ODCs are
RAM code only commands.
The execution of an ODC has two distinct phases:
(1) An instrument setup phase in which each channel is configured
according to the ODC parameters. This phase can take from less than
0.125 seconds to up to 23.0 seconds, depending on the task to
accomplish.
(2) A data acquisition phase in which the RAM code answers the channel
interrupts, collects the channel data, and prepares the channel
packets for transmission.
Cassini UVIS Flight Code User’s Guide 11/98
12
Each channel configuration is defined via the following set of parameters:
HSP PARAMETERS
INTEGRATION TIME
COMPRESSION
HDAC PARAMETERS
DWELL DURATION
FILAMENT VOLTAGE
TABLE
FILAMENT SELECTION
COMPRESSION
FUV AND EUV
PARAMETERS
INTEGRATION TIME
WINDOW PARAMETERS
MECHANISM SELECTION
COMPRESSION
PURPOSE
DEFINE THE INTEGRATION TIME FROM 1 MS
TO 8 MS
DEFINE THE COMPRESSION ALGORITHM
PURPOSE
DEFINE HOW LONG THE RAM CODE SHOULD
STAY AT ONE FILAMENT VOLTAGE SETTING
BEFORE STEPPING TO THE NEXT VOLTAGE
SETTING. THIS IS EXPRESSED IN MULTIPLES
OF THE DETECTOR INTEGRATION TIME (0.125
MS)
FOR EACH CELL THE RAM CODE
CONTINUOUSLY STEPS THROUGH A 16ENTRY TABLE THAT DEFINES FILAMENT
VOLTAGES. THE STEPPING RATE IS DEFINED
BY THE DWELL DURATION PARAMETER.
DEFINE WHICH FILAMENT TO USE
DEFINE THE COMPRESSION ALGORITHM
PURPOSE
DEFINE THE INTEGRATION TIME FROM 0.125
MS TO 8191 SEC.
DEFINE THE NUMBER OF WINDOWS TO BE
USED AND EACH WINDOW’S CHARACTERISTICS
DEFINE WHICH SLIT TO USE AND WHICH
OCCULTATION MIRROR POSITION TO USE
DEFINE THE COMPRESSION ALGORITHM
In fact, each ODC requires more parameters than described above. These
parameters are needed by the RAM code to interpret the ODC correctly. They
are not relevant to UVIS scientific aspects. See CAS-3-291 for details on these
commands.
Cassini UVIS Flight Code User’s Guide 11/98
13
Four compression algorithms are currently defined in the RAM code:
COMPRESSION
ALGORITHM
NO COMPRESSION
8_BIT
SQRT-9
SQRT-8
PURPOSE
ALL 16 BITS ARE RETURNED
ONLY THE LOW 8 BITS ARE RETURNED
THE COMPRESSED VALUE IS RETURNED
USING 9 BITS AND IS COMPUTED USING
THE FOLLOWING ALGORITHM:
IF VALUE > 128
COMP. VALUE = SQRT(VALUE * 2) + 128
ELSE
COMP. VALUE = VALUE
END IF
SAME AS SQRT-9, BUT ONLY THE LOW 8 BITS
ARE RETURNED.
Note: Each EUV and FUV window is defined using four parameters: (1) the
upper left corner coordinates of the window, (2) the lower right corner
coordinates of the window, (3) the spatial binning to use, and (4) the spectral
binning to use. The window corners are defined in a 0-1023 (spectral
dimension) * 0-63 (spatial dimension) space. In the spectral dimension, the
wavelength increases with the position. Binning in the spectral dimension can
be from 0 (no binning) to 1023 (all spectral information is compressed into one
measurement). Binning in the spatial dimension can be from 0 (no binning) to
63 (all spatial information is compressed into one measurement).
Note: when an ODC is used as a direct command, its duration field is ignored.
This field is only taken into account when a ODC is part of a DS.
Note: the setup phase of an ODC is included in the ODC duration.
6 USING DISTRIBUTED SEQUENCES
6.1 DISTRIBUTED SEQUENCE CONCEPT
For UVIS, a Distributed Sequence (DS) is a memory-resident list of commands
that are executed sequentially and terminated by an 84SEQ_HALT command.
The execution of a DS starts at the first command of the DS and goes down the
list of commands until a 84SEQ_HALT command is encountered. The timing
information between each command execution is (for some, but not all the
commands) contained in the command itself (in a parameter called
DURATION), or it can be expressed using the 84DELAY command.
Cassini UVIS Flight Code User’s Guide 11/98
14
For example, assume the following list of commands:
84GENERIC_EXEC, DURATION => 1000...
84HDAC_EXEC, DURATION => 150...
84MEM_DUMP,...
84MEM_DUMP_FAST
84DELAY 200
64UVSIMPLE_EXEC, DURATION => 500
84SEQ_HALT
When this DS is executed, the following occurs:
t (sec)
WHAT
DATA ACQUISITION STATUS
0
84GENERIC_EXEC is executed.
Data acquisition started in the
setup defined by
84GENERIC_EXEC.
1000
84HDAC_EXEC is executed.
Data acquisition stopped and restarted under the setup defined by
84HDAC-EXEC.
1150
84MEM_DUMP and
84MEM_DUMP_FAST are
executed.
Data acquisition still continues
under the setup defined by
84HDAC_EXE.
1150
84DELAY
Data acquisition is stopped.
1350
84UVSIMPLE is executed.
Data acquisition is re-started under
the setup defined by 84UVSIMPLE
1850
DS execution is terminated.
Data acquisition is stopped. UVIS
goes into a “sleep” configuration.
Note that in the example above, the 84DELAY command stops the execution of
the 84HDAC_EXEC command. One way to provide the functionality of an
84DELAY command without interfering with the execution of an ODC is, for
example, to execute an 84FUV_SLIT_POS without moving the FUV slit.
A DS load is a group of Distributed Sequences that are uplinked to UVIS as
one unit using the 84LOAD_SEQ commands. The size of a DS load is limited
by the size of the buffers allocated in UVIS to store Distributed Sequences:
12286 16-bit words per buffer. Two buffers are used to store DS loads. They are
at address 1A001 (hex) and 1D001 (hex) The intent is to execute from one
Cassini UVIS Flight Code User’s Guide 11/98
15
buffer, thus allowing the other to be loaded at any time. Under this scheme,
UVIS will be executing from one buffer during one planning period. During the
next planning period, it will be executing from the other buffer.
In a DS load the Distributed Sequences are numbered from 0 to n, where n is
the last DS in the load. For example, this is a 3 Distributed Sequences load (DS
0, DS 1 and DS 2):
84GENERIC_EXEC....
84HDAC_EXEC....
84MEM_DUMP,...
84MEM_DUMP_FAST
84DELAY
64UVSIMPLE_EXEC....
84SEQ_HALT
84HSP_GEN...
84UVSIMPLE...
84SEQ_HALT
84UVGEN_EXEC
84SEQ_HALT
start of DS 0
end of DS 0
start of DS 1
end of DS 1
start of DS 2
end of DS 2
As explained in Section 5.8, execution of a DS is started using the 84TRIGGER
command.
Cassini UVIS Flight Code User’s Guide 11/98
16
6.2 DISTRIBUTED SEQUENCE LOAD FORMAT
PTR TO PTR TABLE
# OF DS
DS #0
DS #1
DS #2
DS #3
DS #N
PTR TO DS #0
PTR TO DS #1
PTR TO DS #2
PTR TO DS #N
CHECKSUN
A DS load is composed of four parts: (1) the distributed sequences themselves;
(2) a table of pointers to each of the distributed sequences; (3) a checksum
word used to regularly monitor the integrity of the DS load in UVIS memory and
(4) a pointer to the top of this table of pointers. This last item is the first word of
the distributed sequences load. All pointer values are expressed in the number
of 16-bit words from the first word (word 0)
Cassini UVIS Flight Code User’s Guide 11/98
17
.6.3 DISTRIBUTED SEQUENCE PREPARATION
Currently the easiest way to create a DS load is to:
•
Create a CSTOL procedure that represents the DS load.
•
Execute this CSTOL procedure, recording the binary output of the
OASIS-CC command port.
•
Run this binary output through two utility tasks. The first (seq2ds)
creates a file in the format of a DS load (see paragraph 6.2). The
second (ds2load) generates the 84LOAD_SEQ commands that will
uplink the DS load.
This procedure is detailed in (9) under the name of UVIS-OPS-0010.
Later on, when the UVIS ground software is fully developed, it is expected that
the tools used to generate DS loads and create the associated 84TRIGGER
command requests will be integrated in a seamless fashion in the UVIS
Planning and Scheduling software.
6.4 MISCELLANEOUS
In the UVIS DS concept, the commands within a DS are supposed to be
executed sequentially. However, it is easy to create a DS that repeats itself over
and over by forcing the DS to “trigger” itself. The repetition can only be
terminated via a 84SEQ_HALT sent as a direct command. The only restriction is
that the size of the seconds command of the DS is 2 words (for instance an
84DELAY command). For example, this DS will execute forever (assuming that
the DS resides in the first of the two DS buffers and is DS number 3):
84UVSIMPLE_EXEC,...
84DELAY,0
84HDAC_EXEC,...
84TRIGGER,Buffer => BUFFER_1,Sequence ID => 3
7 PERFORMANCE ISSUES
The following performance issues need to be taken into account when
programming the UVIS instrument: the packet production rate, the timing of the
setup of the FUV and EUV channels, and the rate at which the EUV and FUV
channels integration memories are read. Note that all the timing measurements
listed below are for the CPU clock running at 12 Mhz.
Cassini UVIS Flight Code User’s Guide 11/98
18
7.1 PACKET PRODUCTION RATE
The packet production rate of an experiment needs to be computed and
matched with the spacecraft packet collection rate. Two packet collection rates
exist for UVIS:
•
Normal rate : 37 packets every 64 seconds (i.e., 0.578 pps, equivalent
to 5032 bps).
•
Occultation rate : 236 packets every 64 seconds (i.e., 3.687 pps,
equivalent to 32096 bps).
The instrument packet production rate is the sum of each channel packet
production rate. This is indicated by the following table (where cf is the
compression factor, which is equal to 1.0 (when NO_COMPRESSION), 0.5
(when 8_BIT compression or SQRT_8 compression) or 0.5625 (when SQRT_9
compression). Int is the integration time, size is the number of pixels returned
per integration (for the EUV or the FUV channel) and win is the number of
windows defined (again for EUV or the FUV channel).
Channel
HDAC
HSP
FUV
EUV
TOTAL
Packet Production Rate Computation
Algorithm (in packets/sec)
0.01518 * cf
(0.00188 * cf)/int
16 * cf * size/((8480 -(win - 1) * 48) * int)
16 * cf * size/((8480 -(win - 1) * 48) * int)
Packet Production Rate
(in packets/sec)
+
+
+
=
For example, assume an experiment with the following parameters:
HDACcompression: SQRT_9
HPS compression: NO_COMPRESSION, integration: 2 ms
EUV compression: SQRT_9, integration: 40 seconds, 65536 pixels
(full image), 1 window
FUV compression: NO_COMPRESSION, integration: 60 seconds,
6384 pixels (quarter of an image), 1 window
Cassini UVIS Flight Code User’s Guide 11/98
19
The packet production rate for this experiment is:
Channel
HDAC
HSP
FUV
EUV
TOTAL
Packet Production Rate Computation
Algorithm (in packets/sec)
0.01518 * 0.5625
(0.00188 * 1) /0.002
(16 * 1 * 16384) / (8480 * 60)
(16 * 0.5625 * 65536) / (8480 * 40)
Packet Production Rate
(in packets/sec)
0.0085
+ 0.940
+ 0.515
+ 1.739
= 3.2025
As indicated above, the instrument can buffer up to 720 packets. Therefore, the
instrument can be programmed to produce packets at higher rates than the
telemetry collection for a short period of time.
7.2 INITIALIZATION OF THE FUV AND EUV CHANNELS
Setting up UVIS to acquire FUV and/or EUV data can take as much as 10
seconds per channel. This is because the following activities have to take place
for each channel:
•
The mechanisms are moved (0.250 ms per mechanism step).
•
The integration memories are zeroed (around 2.7 sec).
•
The indirection table is initialized (around 3.5 sec).
•
The window definitions are overlaid on the indirection table (up to
around 3.5 sec).
7.3 INTEGRATION MEMORY READ OUT TIMING
The FUV and EUV channels present a problem insofar as it is necessary to
insure that the processor has time to read the contents of an integration memory
while the UVIS hardware integrates data in the other memory. In other words,
the channel integration time must be greater than the time it takes the processor
to read the contents of an integration memory.
As a rule of thumb, when no other activities are going on, it takes around 0.127
ms to read and store a pixel value without compression, and 0.157 ms when the
selected compression is SQRT_9.
RAM code activities such as reading the FUV integration memory and reading
the EUV integration memory are timeshared. If both the FUV and the EUV
integration memories are being read, the RAM code reads 64 pixels from the
FUV memory, then 64 pixels from the EUV memory, and so forth. This has to be
Cassini UVIS Flight Code User’s Guide 11/98
20
taken into account when computing how long it takes to read an integration
memory.
Following is a list of the major activities and their individual duration (i.e., the
duration of their timeshared slot when running)
Activity
Read EUV integration memory (64 pixels - no
compression)
Read FUV integration memory (64 pixels - no
compression)
Move science packet to packet queue
Move science packet to BIU memory
Fast dump UVIS memory
Check UVIS memory (no error). This activity is
always running.
Move housekeeping packet to BIU memory
Copy command from BIU memory
Execute Command
Overhead
Time Slot Duration
7.84 ms
7.84 ms
2.69 ms
3.42 ms
2.68 ms
2.57 ms
1.02 ms
up to 4.0 ms
variable
0.170 ms
7.4 EXECUTION OF 84MEM_ZERO
The execution of the 84MEM_ZERO command is not timeshared with other
activities. Therefore it is recommended that no more than 4096 memory
locations be zeroed per command (that will take 10.5 ms).
8 COMMAND EXECUTION VERIFICATION
High-level verifications can be accomplished to verify that a command or an
ALF load or DS load has been accepted. They are listed below in paragraphs
8.1, 8.2 and 8.3.
In addition, the execution of some commands can be verified by their impact on
the instrument telemetry. This is described in paragraph 11.4.
Very often, a verification can be accomplished in more than one way.
Note: The instrument returns the opcode of the last processed command in
S.3250 (JPL 3-281 label: LAST CMD, OASIS-CC mnemonic: LAST_CMD
value).
Cassini UVIS Flight Code User’s Guide 11/98
21
8.1 COMMAND ACCEPTANCE
Verification 1: No commands are rejected (see paragraph 9.3).
Alternate verification 2: The number of accepted commands increases
correctly. The number of accepted commands is reported in S-3257 (JPL 3-281
name: ACC CMD CTR, OASIS-CC mnemonic: ACCEPTED CMDS). The PROM
code zeroes this measurement at the beginning of every housekeeping data
collection period.
8.2 ALF LOAD ACCEPTANCE
Verification 1: No ALF blocks are reported missing or rejected during the ALF
load uplink (see Section 9.3).
Alternate verification 2: The number of ALF blocks reported by the PROM code
is equal to the number of blocks transmitted. The number of ALF blocks
received is reported in S-3254 (JPL 3-281 name: ACC ALF/DS CTR, OASISCC mnemonic: ACCEPTED ALFDS) and in S-3259 (JPL 3-281 label: ACC
ALF/DS OVF, OASIS-CC mnemonic: ACCEPTED ALFDS_OVFLW). The PROM
code zeroes these measurements at the beginning of every housekeeping data
collection period.
8.3 DS LOAD ACCEPTANCE
Verification 1: No DS blocks are reported missing or rejected during the DS
load uplink (see Section 9.3).
Alternate verification 2: S-3251, bit 10 is set to 0 after the DS load has been
uplinked (see Section 9.3).
Alternate verification 3: The number of DS blocks reported by the RAM code is
equal to the number of blocks transmitted. The number of DS blocks received is
reported in S-3254 (JPL 3-281 name: ACC ALF/DS CTR, OASIS-CC
mnemonic: ACCEPTED ALFDS) and in S-3259 (JPL 3-281 label: ACC ALF/DS
OVF, and OASIS-CC mnemonic: ACCEPTED ALFDS_OVFLW).
Cassini UVIS Flight Code User’s Guide 11/98
22
8.4 COMMAND EXECUTION VERIFICATION
COMMAND NAME
84EUV_HV_LEVEL
84EUV_SLIT_POS
84FUV_HV_LEVEL
84FUV_SLIT_POS
84HDAC_D_FIL_LIM
84HDAC_D_FIL_SEL
84HDAC_H_FIL_LIM_
84HDAC_H_FIL_SEL
84HDAC_HV_LEVEL
84HDAC_TBL_LOAD
84HK_SELECT
84HSP_HV_LEVEL
84HV_SEQ_ENA
84ION_PUMP_OFF
84ION_PUMP_ON
84MEM_DUMP
84MEM_DUMP_FAST
84MEM_MOD_ENA
84MEM_SET
84MEM_ZERO
84OC_COV_POS
84TST_PULSE
WHERE AND WHAT TO LOOK FOR
JPL: S-3202
OASIS-CC: EUV HIGH_VOLTAGE
JPL: S-3204
OASIS-CC: EUV SLIT_POSITION
JPL: S-3210
OASIS-CC : FUV HIGH_VOLTAGE
JPL: S-3214
OASIS-CC: FUV SLIT_POSITION
Need to look at science data header
JPL: S-3237, bit 3
OASIS-CC: HDAC D_FILAMENT_CTL
Need to look at science data header
JPL: S-3236, bit 3
OASIS-CC: HDAC H_FILAMENT_CTL
JPL: S-3218
OASIS-CC: HDAC HIGH_VOLTAGE
Need to look at science data header
Change in housekeeping format
JPL: S-3226
OASIS-CC: HSP HIGH_VOLATGE
JPL: S-3251, bits 6, 7, 8 and 4
OASIS-CC: PGM_FLAG_1 HDAC_HV_DS
PGM_FLAG_1 HSP_HV_DS
PGM_FLAG_1 EUV_HV_DS
PGM_FLAG_1 FUV_HV_DS
JPL: S-3212
OASIS-CC: FUV IOP_HVPS
JPL: S-3211 and S-3212
OASIS-CC: FUV IOP_PRES
FUV IOP_HVPS
JPL: S-3266 anf S-3267
OASIS-CC: MRO ADDRESS
Memory dump packets in science stream
JPL: S-3251, bits 5
OASIS-CC: PGM_FLAG_1 MEMORY_MOD
(See Section 5.11)
Need to dump the affected memory
Need to dump the affected memories
JPL: S-3205
OASIS-CC: EUV OCC_POSITION
JPL: S-3251, bits 3 and 4
Cassini UVIS Flight Code User’s Guide 11/98
23
COMMAND NAME
OBSERVATION
DESCRIPTION
COMMANDS
WHERE AND WHAT TO LOOK FOR
OASIS-CC: PGM_FLAG_1 EUV_PULSE
PGM_FLAG_1 FUV_PULSE
JPL: Most of the above and S-3252, bits 10,
11, 12 and 13
OASIS-CC: Most of the above and
PGM_FLAG_2 HDAC_INTEGRATING
PGM_FLAG_2 HSP_INTEGRATING
PGM_FLAG_2 EUV_INTEGRATING
PGM_FLAG_2 FUV_INTEGRATING
9 ERROR REPORTING: WHERE, WHY, AND HOW TO FIX
The RAM code reports errors in Normal housekeeping telemetry via flags and/or
counters. Most error flags and all counters are reset after their values have been
transmitted; they represent what has happened during the last housekeeping
data collection period.
9.1 LOSS OF SCIENCE DATA
OASIS-CC MNEMONIC
PGM_FLAG_1 SC_PKT_LOSS
JPL 3-281 NAME
S-3251 PGM FLAG bit 12 (science packet
dropped)
This bit is set to 1 whenever the “ready-to-be-transmitted” science packet queue
is full. This condition indicates that UVIS is producing science packets at a rate
far greater than the spacecraft telemetry mode allows. Probable causes: (1)
wrong assumption as to which telemetry mode the spacecraft is supposed to be
in, or (2) wrong computation of the instrument telemetry rate.
OASIS-CC MNEMONIC
PGM_FLAG_1
CODACON_LOSS
JPL 3-281 NAME
S-3251 PGM FLAG 1 bit 1 (CODACON
data lost)
The EUV and FUV detectors each integrate data in two memory banks. While
one memory bank is used for the current integration, the other memory bank is
read by the RAM code. At the next integration period, the roles are reversed: the
first memory bank is read by the RAM code, while the detector integrates in the
second memory bank. If the integration time is too short, the RAM code does not
have time to read one memory bank before it is used during the next integration
period. This results in the “CODACON data lost” bit set. Probable cause:
integration time too short for the amount of data the RAM code has to read out of
the integration memories (see Section 7.3).
Cassini UVIS Flight Code User’s Guide 11/98
24
OASIS-CC MNEMONIC
DROPPED PACKETS
JPL 3-281 NAME
S-3252 DROP PKT CTR
This measurement counts (modulo 256) the number of science packets that
were lost during the last housekeeping data collection period (see the
description of the flag PGM_FLAG_1 SC_PKT_LOSS above for more
explanation).
9.2 HARDWARE AND SOFTWARE PROBLEMS
OASIS-CC MNEMONIC
PGM_FLAG_1 BIU_ERROR
JPL 3-281 NAME
S-3251 PGM FLAG 1 bit 2 (biu error has
occurred)
This bit is set whenever the RAM code notices that a transaction between CDS
and the instrument BIU has failed.
OASIS-CC MNEMONIC
PGM_FLAG_2
BIU_CH_B_FAILURE
PGM_FLAG_2
BIU_CH_A_FAILURE
JPL 3-281 NAME
S-3252 PGM FLAG 2 bit 4 (biu channel b
failure)
S-3252 PGM FLAG 2 bit 5 (biu channel a
failure)
These two bits correspond to two bits set in the BIU register 4 after execution of
the BIU BIT (see(6)). The BIU BIT is invoked by the RAM code approximately
once per hour.
OASIS-CC MNEMONIC
PGM_FLAG_1 MEM_FAULT
PGM_FLAG_2 BIU_MEM_FLT
JPL 3-281 NAME
S-3252 PGM FLAG 2 bit 7 (memory error)
S-3252 PGM FLAG 2 bit 6 (biu memory
error)
These bits are set when the RAM code finds an error while checking the
instrument memory or the BUI memory. The RAM code constantly checks
UVIS’s non-program memory. This is done in blocks of 64 words. The patterns
used in testing are first 5A5A (hex) and then A5A5 (hex). This test is nondestructive (except in case of error because memory page C (hex) is used to
store error information). All UVIS memory starting at memory page 2 is tested.
When an error is discovered, it is reported in the next housekeeping packet; and
the failing pattern, the value read- back, and the failing address are stored (in a
circular buffer) in page C (hex). When the EUV or the FUV channels are
integrating, memory pages 9 to F (hex) are not tested. A similar test is also done
on the BIU memory not used by the descriptor tables and the data and
command buffers (from address 5298 (hex) to address 5d47 (hex)).
Cassini UVIS Flight Code User’s Guide 11/98
25
The address of the last discovered memory in error is dumped in the Normal
housekeeping packet (the JPL names of the measurement are S-3263 for the
page number and S-3264 for the address within the page; the OASIS-CC
mnemonic is MEMORY FAULT).
OASIS-CC MNEMONIC
PROCESSOR FLT REGISTER
JPL 3-281 NAME
S-3253 1750 FLT REG
This measurement contains the O Ring (during the last housekeeping data
acquisition period) of the processor fault register contents read whenever a
Machine Error interrupt is raised. If the measurement is not 0, it may indicate a
processor hardware problem or program memory corruption.
OASIS-CC MNEMONIC
n/a
JPL 3-281 NAME
C-0268 UVIS BIU DISCRETE COMMAND
STATUS, bit 12 (processor watchdog
timer)
A value of 1 indicates that the processor watchdog timer was not reset in time by
the code. UVIS is put in a safe mode and stops producing housekeeping and
science packets. It needs to be restarted using a sequence such as:
84RT_RESET,RESET_HOLD
84RT_RESET,RESET_RELEASE
Load the ram code
84RAM_EXEC
OASIS-CC MNEMONIC
n/a
To reset processor.
To release processor
To execute from RAM
JPL 3-281 NAME
C-0267 UVIS BIU DISCRETE COMMAND
DATA, bit 15 (watchdog timer expiration
flag status)
A value of 1 indicates the instrument BIU watchdog timer was not reset in time
by CDS. UVIS is put in a safe mode and stops producing housekeeping and
science packets. After the BIU watchdog timer has been reset, it needs to be
restarted using a sequence such as:
84RT_RESET,RESET_HOLD
84RT_RESET,RESET_RELEASE
Load the ram code
84RAM_EXEC
To reset processor.
To release processor
To execute from RAM
Cassini UVIS Flight Code User’s Guide 11/98
26
OASIS-CC MNEMONIC
PGM_FLAG_1
MISSING_DSTART
PGM_FLAG_2 MISSING_RTI
JPL 3-281 NAME
S-3252 PGM FLAG 2 bit 14 (missing
DTStart)
S-3252 PGM FLAG 2 bit 15 (missing RTI)
These two bits are set whenever the RAM or the PROM code thinks that CDS
has not sent the RTI or the DTSTART signal within the required time period.
9.3 COMMANDING FAILURES
OASIS-CC MNEMONIC
PGM_FLAG_1
LAST_DS_STATE
JPL 3-281 NAME
S-3251 PGM FLAG 1 bit 10 (last DS load
invalid)
This bit indicates the status of the last DS load uplink. When the RAM code is
started, this bit is set to 1. It is set to 0 after a successful uplink of a DS load. If,
after a DS load transmission, this bit is set to (or stays set to) 1, there is an error.
Possible causes for the problem are:
•
One or more 84LOAD_SEQ commands were out of order or were missing.
•
One or more 84LOAD_SEQ commands have failed the checksum test.
•
Globally, the DS load has failed the checksum test.
The counts of missing 84LOAD_SEQ commands or of failed 84LOAD_SEQ
commands are reported elsewhere in the telemetry (see description of the
ALFDS flags below).
OASIS-CC MNEMONIC
REJECTED ALFDS
REJECTED ALFDS_OVFLW
JPL 3-281 NAME
S-3255 REJ ALF/DS CTR
S-3260 REJ ALF/DS OVF
These two counters report the number of rejected DS or ALF blocks during the
last housekeeping data collection period. The number of rejected DS or ALF
blocks during the last housekeeping data collection period is computed as:
REJECTED ALFDS + 256 * REJECTED_AFLDS_OVFLW
(See the description of the flag PGM_FLAG_1 LAST_DS_STATE above for
possible reasons for the load failure).
Cassini UVIS Flight Code User’s Guide 11/98
27
OASIS-CC MNEMONIC
MISSING ALFDS
MISSING ALFDS_OVFLW
JPL 3-281 NAME
S-3256 MSNG ALF/DS CTR
S-3261 MSNG ALF/DS OVF
These two counters report the number of missing DS or ALF blocks during the
last housekeeping data collection period. The number of missing DS or ALF
blocks during the last housekeeping data collection period is computed as:
MISSING ALFDS + 256 * MISSING_AFLDS_OVFLW
(See the description of the flag PGM_FLAG_1 LAST_DS_STATE above for the
possible reasons for the load failure).
OASIS-CC MNEMONIC
REJECTED CMDS
JPL 3-281 NAME
S-3258 REJ CMD CTR
This counter reports (modulo 256) the number of rejected commands during the
last housekeeping data collection period. This counter does not differentiate
between direct commands and commands that are executed from a DS. This
counter is incremented for many reasons:
•
Some commands are always rejected by the RAM code:
84RAM_EXEC, 84VENT_ENA, and 84VENT. These commands are
PROM-only commands. Similarly the RAM-only commands are
rejected by the PROM code.
•
84DELAY is only valid in a DS. It is rejected if it is a direct command.
•
84MEM_SET or 84MEM_ZERO is rejected if memory modification is
not enabled (see Section 5.11).
•
All commands that use power are rejected when the instrument is in
sleep mode. The exception to this rule is 84ION_PUMP_ON.
•
A command opcode was not recognized. This will register as one
rejected command. But in fact, the RAM code is forced to reject all the
pending commands that are stored behind the rejected command in
its command buffer.
•
For some commands, the RAM code checks the consistency of the
command parameters value. If it finds a problem, it rejects the
command.
Cassini UVIS Flight Code User’s Guide 11/98
28
10 NOTES ON DATA ACQUISITION
10.1 SCIENCE DATA ACQUISITION
Data from the HDAC and the HSP channels are processed in a similar way: at
each channel interrupt, the RAM code reads the 16-bit channel output and stuffs
the data in a science packet (each channel has its own science packet). When
the packet is full, it is placed at the end of the “ready-to-be-transmitted” packet
queue. For the HDAC channel and the HSP channel, the time in the packet
secondary header corresponds to the spacecraft time at which the first data in
the packet was collected.
The processing of the EUV and FUV channels is more complex. Both channels
are handled the same way. The hardware accumulates the data from one
channel into one of two buffers. At the end of one integration, the hardware
switches buffers. The RAM reads data from one buffer while the hardware
accumulates data in the other buffer. Only the data in the windows defined by
the executing ODC are returned to the ground. Data are stuffed, window after
window, spectral dimension first in a science packet. When the packet is full, it is
placed at the end of the Ready-to-Be-Transmitted packet queue. For the EUV
and FUV channels, the time in the packet secondary header corresponds to the
spacecraft time at the time of the channel integration interrupt.
Note: When an ODC is interrupted (either by the execution of an 84SEQ_HALT
command—which terminates the data acquisition, or by the execution of a
command that modifies the instrument configuration in relation to the data
acquisition), the current science packets are moved to the Ready-to-Be
Transmitted packet queue even if they are not full. The following data are
buffered in new packets.
Note: When an ODC that acquires FUV and EUV data is interrupted, the data
from the current (incomplete) integration are not collected by the RAM code. For
example, assume that UVIS is collecting FUV data with a 60-second integration
period. If the ODC is interrupted after 179 seconds, only data from integration 1
and 2 are returned.
10.2 HOUSEKEEPING DATA ACQUISITION
Approximately 8 seconds before the next CDS housekeeping packet pickup,
the RAM code starts filling the UVIS housekeeping packet in the following order:
•
First, the analog data from A/D channel 0 to A/D channel 31. The A/D
conversions are done 0.125 seconds apart;
•
Then the digital data are collected in one RTI.
Cassini UVIS Flight Code User’s Guide 11/98
29
The exceptions to this rule are the commanded voltage in measurements
S-3237 (JPL 3-281 label: HDAC DREG CTL, OASIS-CC mnemonic: HDAC
H_FILAMENT_CTL ) and S-3236 (JPL 3-281 label: HDAC HREG CTL, OASISCC mnemonic: HDAC D_FILAMENT_CTL ). They are collected at the end of the
A/D conversion of the analog measurements S-3220 (JPL 3-281 label: HDAC D
CURRENT, OASIS-CC mnemonic: HDAC D_CURRENT) and S-3223 (JPL 3281 label: HDAC H CURRENT, OASIS-CC mnemonic: HDAC H_CURRENT).
The time in the secondary header of the housekeeping packet is the spacecraft
time at the first A/D conversion (the first A/D data are read 0.125 seconds after).
Cassini UVIS Flight Code User’s Guide 11/98
30