Format

The DPU sends telemetry data serially at 38400 baud with eight data bits, one stop bit, and no parity. Each package consists of a four byte header followed by zero or more data bytes. The header is a three byte synchronization pattern followed by a package identifier. Packages may be sent following the first synchronization pulse after the nadir pulse, but must conclude before the next nadir pulse. The package types used by HENA are summarized in the following tables.

Data packages are used to downlink science and housekeeping data. Each data product is placed in a package; the application id identifies the data type. The Compression bit would be set to command the CIDP to compress the data. Since the HENA DPU compresses its own data, this bit will never be set. The byte count gives the length of the data and checksum fields; the most significant byte of the length is sent first. Up to 63,980 bytes of data can be sent in one package. Following the data is a checksum, consisting of the byte-wise exclusive-or of the data.

Each package is converted to a HENA CCSDS packet by the CIDP. The packet will have an application process id consisting of 0101XXXXXXX where XXXXXXX is the application id from the package. The CCSDS packet secondary header will have the spacecraft time at the start of the next spin. The package checksum will be included in the packet data. If the checksum is bad, the package is downlinked as if the application id were 0x7f; the application id 0x7f is reserved by the CIDP for this use.

The CIDP request package requests action of the CIDP. The request id identifies the action to take. The byte count gives the length of the checksum field and is always one.

At most one request may be sent per spin. The CIDP will act on the request within two spins. The following requests are defined:

• Power Off Request (Id = 00010001)
• Power Cycle Request (Id = 00010010)
• Data Upload Request (Id = 00BB0101, where BB is the block id)

At least one package must be sent to the CIDP every spin to allay the CIDP watchdog's suspicions of HENA's demise. The No-data package is sent if HENA has no other data to send.

Science Products

Science data products are accumulators, PHA results, images from the HENA-M and HENA-S sensors, and various data structure dumps. Each product is accumulated and transmitted at a fixed interval or on demand as specified in the table below. Each product is sent in separate packages with a unique application id.

Each science data package has a common eight-byte header. This HENA data header contains the spacecraft time when the data was taken, and for integrated data, when the integration began. The header also has a bit indicating the instrument charge mode (0=neutral, 1=ion). The header also indicates this package's position in a multi-package data item.

Following the header is the science data. The format of each science data product is described below.

Accumulators

HENA accumulator packages consists of a package header (replaced by a CCSDS header in the CIDP), a HENA data header, and compressed accumulator values. Each 24-bit accumulator is log-compressed to ten bits.

Data log-compressed to ten bits consists of a five-bit exponent and a five-bit mantissa.

Data is decompressed using the following pseudo-C algorithm:

if(exponent==0)
	result = mantissa
else
	result = (mantissa | 0x20) << (exponent - 1)

HENA-M PHA Results

HENA-M PHA result packages consist of a package header (replaced by a CCSDS header in the CIDP), a HENA data header, and PHA results. Each PHA result occupies four bytes. Each package holds zero to 256 events. A package with zero events would be sent if HENA-M PHA data was enabled but no events were observed.

HENA-S PHA Results

HENA-S PHA result packages consist of a package header (replaced by a CCSDS header in the CIDP), a HENA data header, and PHA results. Each PHA result occupies four bytes. Each package holds zero to 256 events. A package with zero events would be sent if HENA-S PHA data was enabled but no events were observed.

HENA-M Raw + PHA Results

HENA-M raw + PHA result packages consist of a package header (replaced by a CCSDS header in the CIDP), a HENA data header, and event data. Each event occupies eighteen bytes: fourteen bytes for the seven raw data words and four bytes of PHA results. Each package holds zero to 56 events.

HENA-S Raw + PHA Results

HENA-S raw + PHA result packages consist of a package header (replaced by a CCSDS header in the CIDP), a HENA data header, and event data. Each event occupies sixteen bytes: twelve bytes for the six raw data words and four bytes of PHA results. Each package holds zero to 64 events.

HENA-M and HENA-S Images

Each HENA image is sent as a series of packages. A package consists of a package header (replaced by a CCSDS header in the CIDP), a HENA data header, a compression subheader, and compressed pixels. Each 16-bit pixel is log-compressed to eight bits; then the entire block of pixels is Rice-compressed. Compression type and compression information appear before the first pixel. Currently, the only compression type is Rice compression; type will be zero and information will be the Rice code (the number of uncompressed bits in each pixel). This is followed by the first pixel, log-compressed, but not Rice-compressed. Then, Rice-compressed pixels follow.

Each image is divided into fragments for the purpose of splitting the image across multiple packages. Each package is self-contained so that if one package is lost, the remaining packages can be used to reconstruct a partial image. HENA images have either high-spatial resolution (120x40), low-spatial resolution (60x20), or SSD resolution (80x24). High-spatial resolution images have eight fragments each containing 600 pixels. Low-spatial resolution images have four fragments each containing 300 pixels. SSD images have four fragments each containing 480 pixels. Image fragments are numbered starting at zero; the data header of a package will list the fragment contained in the package. Within each fragment, pixels are sent starting at the lower left pixel, moving horizontally over the first row, then starting at the left of the next row, etc.

Images are decompressed with the following pseudo-C algorithm:

if info == 8				/* if backup (i.e. no) comp */
	P0 = read(8 bits)		/* first pixel */
	for each remaining pixel
		Pi = (Pi-1 - Df) & 0xff
else
	P0 = read(8 bits)		/* first pixel */
	for each remaining pixel
		Pi = (Pi-1 - Dr) & 0xff
for each pixel				/* undo lossy comp */
	exponent = Pi >> 4; mantissa = Pi & 0x0f
	if(exponent==0)
		Pi' = mantissa
	else
		Pi' = (mantissa | 0x10) << (exponent - 1)

for(i=0; read(1 bit)==0; i++)	/* count zeroes */
	;
Dcode = (i << info) | read(info bits)
Dr = (Dcode & 0x01) ? ~(Dcode >> 1) : (Dcode >> 1)

and, where Df is computed as follows:

Dcode = read(info bits)
Df = (Dcode & 0x01) ? ~(Dcode >> 1) : (Dcode >> 1)

Memory Dump

Memory dump packages consist of a package header (replaced by a CCSDS header in the CIDP), a HENA data header, a memory dump subheader, and memory data. Up to 256 bytes can be sent in a single package; if a larger dump was requested, multiple packages will be sent with an incrementing sequence number in the data header. There is no guarantee of consistency within or between packages.

Memory Checksum

Memory checksum packages consist of a package header (replaced by a CCSDS header in the CIDP), a HENA data header, a memory checksum subheader, and memory checksum.

Parameters

A parameter package consists of a package header (replaced by a CCSDS header in the CIDP), a HENA data header, and data. The data consists of HENA parameter values. The package is only sent in response to a H_MEM_STR_READ command. Note: each parameter is 16 bits.

Calibration Sequences

A calibration sequence package consists of a package header (replaced by a CCSDS header in the CIDP), a HENA data header, and data. The data consists of three calibration sequences. The package is only sent in response to a H_MEM_STR_READ command.

Each sequence step has the following format, consisting of seven bytes, one byte for each calibrator value, time through coincidence. This is repeated for each of the fifteen sequence steps.

Monitor Limits

A monitor limits package consists of a package header (replaced by a CCSDS header in the CIDP), a HENA data header, and data. The data consists of pairs of monitor limits, a low limit and a high limit, for each monitor. The package is only sent in response to a H_MEM_STR_READ command.

SSD Parameters

The current SSD parameters are sent on request. Each package consists of a package header (replaced by a CCSDS header in the CIDP), a HENA data header, and data. The data consists of the SSD's current PHA, Actel, I/O, and FEA register values. The package is only sent in response to a H_MEM_STR_READ command.

Schedule

The current shutter and HV safing schedule is sent periodically. Each package consists of a package header (replaced by a CCSDS header in the CIDP), a HENA data header, and data. The data consists of the sector numbers at which the specified events will occur. Events that can never happen (e.g., because they are disabled) are reported as occurring in sector 120.

Macro Status

The status of each macro definition is sent on request. Each package consists of a package header (replaced by a CCSDS header in the CIDP), a HENA data header, and data. The data consists of the address of the first block of each macro; this will be zero for an undefined macro. The package is only sent in response to a H_MEM_STR_READ command.

Housekeeping Products

Housekeeping data products are listed in the following table. Each product is sent in a separate package with a unique application id.

Each housekeeping data package has an eight-byte header identical to the one used for science data (see above). Following the header is the data. The format of each housekeeping data product is described below.

Status

A status package is sent periodically. Each package consists of a package header (replaced by a CCSDS header in the CIDP), a HENA data header, and data. The data consists of analog status values, digital status, and the current instrument configuration. The package is sent automatically; the rate can be set by command (H_TLM_STAT_RATE).

The analog status data consists of 32 one-byte values. With the exception of the shutter current, a new analog value is read from the hardware every 200 milliseconds. The shutter current is read only while the shutter power is on. Each value is an 8-bit, unsigned number. Whenever the status package is sent, the most recent analog values are sent. All of the analogs except for the thermistor values are sent as read from the hardware; the thermistor values are modified to give them a positive slope (255 - value). The analogs are listed in the following table:

The digital status consists of digital values monitored by the DPU. The digital status is defined in the following table:

The hardware configuration data describes the commanded state of the instrument's hardware control registers. The format is defined in the following table:

The software configuration data describes the commanded state of the instrument's software. The format is defined in the following table:

The software information consists of values generated internally by the software. The software information is defined in the following table:

Command Echo

Each command received by the DPU is echoed in a package. Each echo package consists of a package header (replaced by a CCSDS header in the CIDP), a HENA data header, and command data. The command's opcode and first nine arguments are included, followed by a macro bit (set to 1 if the command was executed as part of a macro) and a code summarizing the command's result. If the command has fewer than nine arguments, the unused echo bytes are filled with zeroes. The result codes are defined in Appendix 4.

Alarm

Alarm packages report problems. Each package consists of a package header (replaced by a CCSDS header in the CIDP), a HENA data header, and alarm data. The alarm data consists of an 8-bit number identifying the alarm and an 8-bit value with additional information. The flag indicates transient or persistent alarms. See Appendix 2 for a list of the alarm ids.

Allocation

The HENA telemetry allocation is 41,666 bytes per spin. The command H_TLM_ALL_ALLOC can change this for ground testing or if the total IMAGE telemetry is reassigned. The production of data is partially controlled by ground command. Many HENA data products (e.g., accumulators) can be enabled or disabled by the H_SEN_CNTRL command. The rate at which status data is generated is controlled by H_TLM_STAT_RATE. Other data is generated automatically (e.g. command echo) or in response to a ground command (e.g. memory dump).

At the start of each spin, the HENA software divides the telemetry allocation among the enabled, synchronous producers as follows. The status and accumulator data have a fixed size and are allocated first. The remaining bandwidth is divided between images and PHA data. If the actual image data exceeds this bandwidth, low priority images will be discarded until the data fits in its given bandwidth. Any bandwidth remaining is divided between the HENA-M and HENA-S PHA data according to the percentage defined by the H_TLM_PHA_ALLOC command. This algorithm assumes that no asynchronous data will be generated.

If more data is generated than can be sent, the data is queued until there is an opportunity to send it. On subsequent spins, the telemetry production bandwidth that is parceled out is reduced until the backlog is cleared. HENA will never send more telemetry in a spin than has been allocated.

Return to HENA Software User's Guide. Report problems to John Hayes.