Abstract-The SAMPEX Data Processing Unit provides overall control of the scientific payload while acquiring, combining, and compressing science data to produce the science telemetry for the mission. Section I of this paper describes data manipulation techniques employed to intelligently use the on-board recorder storage. Some key features of the Data Processor design are given in Section II.

Introduction

The Data Processing Unit (DPU) provides timing and control signals to the four sensors to manage data acquisition and mode switching while simultaneously combining sensor and DPU data to form telemetry packets which are transmitted to the Small Explorer Data System (SEDS) for recorder storage. DPU algorithms are designed to maximize the science output for the SAMPEX mission by controlling the data storage rate over the ~12 hour storage period. Fig 1. shows a system connection block diagram for the sensors, DPU and the SEDS.

The DPU is based on the Harris 80C85RH microprocessor and includes 24 Kbytes of PROM and 56 Kbytes RAM. Actel Field Programmable Gate Arrays (FPGAs) are utilized to gain a high degree of parallel hardware processing, redundancy, and fault tolerance without the penalty of greatly increased power or weight. Actel FPGAs are especially attractive for satellite instrumentation since each chip provides approximately 2000 logic gates in a quad flatpack package of 2.2 cm^2. The DPU box, including power preregulators for the HILT and LICA sensors, measures 7" (L) x 7" (W) x 9.7" (H) and weighs 7 lbs.

I. Data Manipulation

A. Recorder System Overview

The primary function of the DPU is to collect sensor data to create telemetry packets for transmission to the solid-state recorder located within the Small Explorer Data System (SEDS). The 22 Mbyte recorder is dumped only twice per day, therefore a key task of the DPU is to throttle packet outputs so that the recorder is not filled too soon following a ground pass, yet is almost full at the time of each acquisition. The DPU guarantees each sensor a minimum allocation of recorder memory for data storage in each orbit; unused memory allocation for the recently completed orbit is redistributed to future orbits so that highly active sensors are allocated greater data storage.

B. Pulse Height Analyzed (PHA) Event Data Handling

PHA events are output from the scientific sensors asynchronously at a rate dependent on the particle flux incident on detectors within the sensor. The DPU's sensor interfaces are capable of receiving up to 150 events from the combined payload, but outputting to the recorder at that rate would exhaust the recorder capacity within 2 hours. The DPU more slowly fills the recorder over the 12 hour "inter-pass" period by using a two-tiered quota system. The two types of quotas maintained by the DPU are one second quotas and orbit quotas. One second quotas limit the instantaneous burst rate of events from each sensor, thus providing a method of prioritizing event data items.

Orbit quotas limit the amount of recorder memory available to each sensor for event packet storage. When an event packet (four distinct types, one per sensor) is output to the telemetry stream, the appropriate orbit quota is decremented by the length (in bytes) of the packet transmitted. If the packet's orbit quota becomes zero as a result of the decrement operation, then further packets of that type are blocked from output to the recorder for the remainder of the current orbit. At the end of each orbit (~90 minutes), the DPU performs a memory reallocation algorithm which provides additional memory to each of the orbit constrained packet types.

C. Rate Scaler Data Handling

Low Resolution Rates

Low resolution rate data is accumulated in the DPU for all 4 sensors and output unconditionally every 6 seconds to the SEDS for storage.

High Resolution Rates & Triggering

The DPU supports high resolution rate (HRR) data processing for 6 HILT rates and 1 PET rate. For these items, data is read once every 100 milliseconds to produce high time resolution packets. To limit the amount of recorder memory expended for storage of uninteresting data, the DPU supports a ground-programmable "trigger level" which, when compared against data in the accumulation array (6 second coverage for HILT, 48 seconds for PET), determines if data should be recorded. High resolution rate data packets are subjected to orbit quotas similar to those given for PHA event packets, therefore limited space is made in the recorder for their output.

History Data Buffers

A large fraction of the low resolution rate data items are accumulated longer term to produce quick-look scalers. When combined with some subset of analog housekeeping data, these items make up an orbital history which, when requested at the time of initial transponder acquisition from the ground station, give a summary for data which existed in the orbit immediately preceding the ground pass. The DPU supports the orbital history with a circular buffer which is written with a new data point every 96 seconds for HILT and LICA, and every 192 seconds for MAST and PET.

Following boot-up of the DPU system or reception of a "Reset Quota" command, the DPU initializes the running orbit quotas with the ground-programmable baseline allocations. Upon output of a PHA event or high resolution rate data packet, the associated running quota is decremented by the packet length. As the orbit proceeds, the orbit quotas are decremented. Further packet outputs are blocked when the associated orbit quota reaches zero, at least until the next reallocation period is reached. For the first orbit, this assures that at least the minimum recorder memory is made available for each of the quota- controlled data packets.

At the end of the orbit, the DPU collects unused recorder memory quota for redistribution in the next orbit. As in the first orbit, each data type is given the baseline allocation, but each is also given additional quota based on the excess from the previous orbit as determined by ground-programmable redistribution percentages. This system redistributes unused memory from previous orbits so that highly active sensors can utilize unused memory from less active sensors, but only after those less active sensors have first forfeited the opportunity to use it.

II. System Description

A. Sensor Interface Electronics

Due to the high density of the Actel Gate array, each sensor interface is implemented in a single, dedicated sensor interface gate array. Each of these sensor gate arrays can be individually enabled or disabled, allowing the DPU to continue functioning in the event of a catastrophic failure in a gate array or sensor. Each sensor interface includes an instrument clock generator, command interface, data interface, and Direct Memory Access (DMA) circuitry. The DMA capability allows the sensor interface to transfer data directly from the sensor to processor memory with minimal processor intervention, freeing the processor for other tasks such as data compression.

B. Spacecraft Command Interface

Commands are transferred from the spacecraft to the DPU serially through a differential three signal interface consisting of a clock, gate, and data running at a rate of 2 kilobits per second (KB/S). Commands consist of 64 bits with the last 8 bits defined as the command checksum. Using this checksum, the DPU verifies the integrity of each received command and all included parameters prior to execution. A total of 59 commands are recognized; one of which allows for modifying DPU code and data, therefore making modification of the DPU program after launch possible.

C. Spacecraft Telemetry Interface

Telemetry data is transferred from the DPU to the spacecraft over a four signal interface at a rate of 100 KB/S. The signals are all differential and consist of a "Request to Send" from the DPU, a "Clear to Send" from the spacecraft, a clock and a data signal. The telemetry interface directly accesses the processor memory so that entire packets of data can be sent with a single processor operation.

The basic unit of data transferred from the DPU to the SEDS is a packet consisting of a primary header (6 bytes), a secondary header (10 bytes), and a variable length data block. The DPU hardware interface transmits fixed length packets, each of length 512 bytes to the SEDS, however packets are truncated to the length specified in the secondary header by the SEDS before storage. Each packet contains and application ID (APID) which specifies the type of data enclosed and a 16 bit checksum which certifies the integrity of the complete packet.

D. Spacecraft Interface Redundancy & Selection

The DPU's spacecraft interface (including command, telemetry, and time distribution interfaces) is implemented within the DPU using a single Actel FPGA. Spacecraft interface redundancy is achieved by collocating two copies of the Spacecraft Interface chip on the interface board. The best of the two spacecraft interfaces is chosen during the DPU's power on diagnostics where the SEDS provides an echo feature to help with the selection process.

E. Memory Mapper

The Memory Mapper is included in the DPU design to protect against system failure caused by RAM chip or cell failure. The RAM array consists of seven 8K x 8 bit RAM chips of which only six are needed to perform all DPU functions. As the DPU powers on, an exhaustive memory test is performed which tests not only the RAM cells, but also address and data input lines as well. As the memory verification process proceeds, the Memory Mapper maps good chips to lower memory locations and bad or suspect chips to higher locations. Data in the DPU is organized so that critical data, such as the flight program, are placed in lowest memory locations, therefore if several RAM chips do fail, less important data will be stored in the faulty locations. With this scheme, one RAM chip can fail with no impact on DPU operations; up to three RAMs can fail with only the loss of nonessential operations.

F. Task Scheduling Concept

Each sensor contains multiple hardware ports which support a different data type (e.g., digital status, counting rates, or PHA data), but organized so that only one type of data can be output at a time. The DPU software must coordinate read-outs from the sensors so that all data items are read as needed for the creation of low and high-resolution rates and digital status packets while simultaneously using any available interface dead time to readout asynchronously occurring PHA event data. In addition, the software system must schedule the creation of telemetry packets, the use of the spacecraft interfaces, and processing time for data compression or packet checksum calculation.

To organize time and resources available to the DPU, task scheduling algorithms were implemented to fully control the use of all DPU resources. The task scheduling scheme allows separate subroutines, each with a finite function (read counting rates, process spacecraft command, check HILT high voltage, reset watchdog timer, etc.), to be coded and tested independently. The task scheduling algorithms then allows operations, whether sensor interface related or processing related, to be combined to form the final software product. Incompatible operations can be separated in time, and processor and interface hardware may be load balanced for most efficient use of system resources.

H. System Reconfiguring

The DPU hardware system contains no non-volatile RAM, therefore changing the DPU's executable code or parameter set would usually require ground intervention. To overcome this situation, the DPU provides a special set of boot-up operations which, with support from the spacecraft, allow for modifying the default power-on DPU state even in the absence of ground contact. A set of relative time sequences (RTSs) are maintained in the spacecraft non-volatile RAM which contain DPU commands capable of modifying the DPU program, data structures, or default parameter states. As the DPU boots, while still in a partially dormant state, the DPU requests the RTSs, then processes the incoming modification commands. The complete program begins execution immediately following reception of the last modification command.

Acknowledgment

Successful testing of the DPU system relied heavily on the use of robust Ground Support Equipment (GSE) for which we thank Kirk Crawford and David Lau of the Aerospace Corporation. The GSE was originally designed for testing of the DPU system, but during launch and early orbit operations of the SAMPEX mission the GSE has provided scientific data displays as well. The quick-look capabilities of the GSE system, particularly those related to the early orbit operations, were crucial for early health monitoring of the scientific payload.