Telemetry Interface

The spacecraft Command & Data Handling (C&DH) system collects telemetry from the imagers over the 1553 bus as non-packetized housekeeping and as CCSDS packets.

Non-packetized Housekeeping

The C&DH system picks up a 16-byte non-packetized housekeeping record every second. The contents can be incorporated into C&DH autonomy processing. The C&DH system also assembles the data into a housekeeping packet. The format of the non- packetized housekeeping record is imager-specific.

Packets

The C&DH system collects up to one packet from each imager every second. All CONTOUR packets are 244 bytes long including the CCSDS headers (see Reference 2). The CCSDS primary header is six bytes long and the CCSDS secondary header is 4 bytes long, leaving 234 bytes for the data payload.

The application process id in the primary header identifies the type of packet. On CONTOUR, the eleven-bit id is divided into a four-bit source and a seven-bit data id. This gives each source up to 128 possible packet types that can be produced. The packet types produced by both imagers are described below.

Memory Dump

Memory dump packets consist of CONTOUR CCSDS headers, a dump start address, dump length, and 228 bytes of dump data. The 32-bit address field accommodates the possible range of addresses for both 16-bit and 32-bit processors.

Subpackets

Instead of coercing imager data to fit into the fixed size CONTOUR packets, the imagers use variable-sized subpackets that "float" through fixed-size packets. A specific packet apid indicates that the packet contains subpackets. Each subpacket is loaded into one or more packets. Each packet data field starts with a byte containing an offset to the first subpacket in the packet; if no subpacket begins in the packet, an invalid offset of 0xff is used. The remaining bytes in the packet data field are from subpackets. Subpacket packets are sent at a higher priority than dump packets.

Each subpacket has a header containing an id, length, grouping flags, and time-tag. The subpacket id identifies the type of subpacket. The grouping flags allow multiple subpackets to be treated as a unit in ground processing. The time tag in the subpacket corresponds to when the subpacket data was sampled. The length is the number of bytes in the data portion of the subpacket.

Ground software can use the "first offset" field from the packet and the length field in the subpacket headers to extract a stream of subpackets. Initially, the ground software can synchronize by waiting for a subpacket packet that has a "first offset" that is not equal to 0xff. It can use this offset to find the first subpacket. The subsequent subpacket can be found by adding the length of the subpacket to the offset. The next subpacket may begin in the current packet, in the following packet, or many packets later.

The subpacket types produced by both imagers are described below.

Status

The DPU generates a status subpacket periodically. The rate is controlled by a command (see CXX_STAT_INT). The actual format of the subpacket is imager specific.

Command Echo

Each command received by the DPU is echoed in a subpacket. Each echo subpacket consists of a subpacket header and command data. The command's opcode and first nine argument bytes 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 argument bytes, the unused echo bytes are filled with zeroes. The result codes are defined in Appendix 1.

Alarm

Alarm subpackets report problems. Each subpacket consists of a subpacket header and alarm data. The alarm data consists of a byte identifying the alarm's cause and two value bytes with additional information. For monitoring alarms, the first byte is the out-of-limit value and the second byte is the associated limit. The type indicates transient or persistent alarms. See Appendix 1 for a list of the alarm ids.

Memory Checksum

Memory checksum subpackets consist of a subpacket header and checksum data. The checksum is the 16-bit two's complement sum of the indicated memory region.

Monitor Limits

The DPU generates a monitor limits subpacket on demand (see CXX_MEM_STR_READ). The actual format of the subpacket is imager specific.

Flush

A flush subpacket consists of a subpacket header and enough pad data to fill the end of a packet. Flush subpackets are used to flush out a packet that is partially filled with subpackets.

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