Neutral Gas and Ion Mass Spectrometer (NGIMS)
NGIMS Telemetry Data Format
For
CONTOUR NGIMS
Prepared by:
_________________________
Florence Tan
NGIMS Engineer
Approved by:
_________________________
Jack Richards
NGIMS
Instrument Manager
This document describes the telemetry data format of the Neutral Gas and
Ion Mass Spectrometer (NGIMS) on the CONTOUR spacecraft.
The NGIMS instrument is commanded via a 1553 bus on the CONTOUR spacecraft.
The 1553 bus schedule can be found on the CONTOUR website at: https://sd-forum.jhuapl.edu/CONTOUR/.
1 byte = 8 bits
1 word = 2 bytes = 16 bits
MSB = Most significant byte
LSB = Least significant byte
For all multi-bit
or multi-byte numbers, the first byte sent has the most numerical significance;
this is so-called "big-endian" format. This convention applies to
arguments in commands, data in telemetry, and messages over the 1553 bus.
The spacecraft Command & Data Handling (C&DH) system collects
telemetry from NGIMS over the 1553
bus. NGIMS produces 2 types of telemetry data:
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 instrument-specific. (details of
format here – to be inserted at a later date)
The
C&DH system collects up to 2.6 CCSDS packets from NGIMS every second. All
CONTOUR CCSDS packets are 244 bytes long including the CCSDS headers (see Reference 3).
The
NGIMS CCSDS primary header occupies six bytes and leaves 238 bytes for the data
payload. This format differs from the prescribed CONTOUR CCSDS format because
NGIMS did not to have the secondary header bit set. If the secondary header bit
is set, the next 4 bytes make up secondary header. Thus, NGIMS’ MET is not in
the expected 4 bytes following the CCSDS’ primary header. Table
1 describes the NGIMS packet format:
|
Name
|
Length
(bits) |
Value
|
Description
|
|
NGIMS Primary Header |
48
|
See Table 2 |
CCSDS primary header |
|
Data |
238
* 8 |
Data payload |
|
As
mentioned, NGIMS’ secondary header bit is not set, indicating the absence of
the secondary header in the packet. Instead, as can be seen later, NGIMS places
its MET within each of its subscan data.
|
Name |
Length (bits) |
Value |
Description |
|
Version |
3 |
000 |
Designates a source packet |
|
Type |
1 |
0 |
Designates a telemetry packet |
|
Secondary? |
1 |
0 |
Secondary header is not present |
|
Application Process ID |
11 |
100 1xxx
xxxx |
NGIMS, see Table 3 |
|
Grouping |
2 |
11 = None |
Grouping flags |
|
Sequence Count |
14 |
Unsigned integer |
Continuous sequence count for each
Application Process ID |
|
Length |
16 |
237 |
(Total Number of bytes – 1) in packet |
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 three packet types produced by NGIMS are as described:
|
Product
|
Application
Process ID (binary) |
When
Sent |
|
000 0000 |
Once every 0.495s |
|
|
000 0001 |
On demand |
|
|
000 0010 |
On receipt of each command |
|
The
NGIMS Subscan data is differentiated by the application process ID (APID =
0x0480) in the Primary Header and is used to transmit science subscan data.
Each packet has the following format:
|
Name
|
Length
(bits) |
Value
|
Description
|
|
48
|
CCSDS primary header |
||
|
16
|
See Table 5 |
Offset in 16-bit words |
|
|
202
* 8 |
See Table 6
|
Subscan Science Data (1 subscan = 160 bytes, more
than 1 subscan can fit here) |
|
|
34*8 |
See Table ? |
State of health data |
|
Each NGIMS CCSDS data packet consists of a 6-byte
header and 238-byte data payload. Of the 238 bytes of data payload, 202 bytes
are allocated for the transmittal of subscan science data. Each subscan
produces 160 bytes of science data. Thus, each NGIMS CCSDS data packet can
transmit 202/160 or 1.2625 subscans of science data.
Table 5. NGIMS Subscan
Offset Word Format
|
|||
|
Name |
Length (bits) |
Value |
Description |
|
Subscan Offset |
7 |
Unsigned integer |
Indicates the word offset to the first
subscan within the data section of the packet. A value of zero means the first subscan begins at the first
word of the Science Data section (the word immediately following the NGIMS
header). |
|
spare |
9 |
spare |
spare |
As
described in Section 4.2.2, instead of
coercing NGIMS subscan data to fit into the fixed size CONTOUR packets, NGIMS packs
160 bytes of fixed-sized Subscan Science data that “float” through its
allocated 202 bytes of subscan data as part of 238 bytes of fixed-size data
portion of the CCSDS packets (see Tables 1 and 4). The offset field in the Subscan Offset (see Table 5) points to the word offset of the NGIMS subscan
science packet within the packet.
Ground
software can use the Application Process ID field from NGIMS Primary Header and
the offset field in the NGIMS Subscan Offset word to extract a stream of
subscans. Initially, the ground software can synchronize using "offset” to
find the first subscan. The subsequent subscan can be found by adding the
length of the subscan (80 words) to the offset. The next subscan may begin in
the current packet or in the following packet. Each packet contains at least
one full subscan science and up to parts of 2 subscan science data.
The
subscan data can appear in this order:
·
partial subscan, full
subscan, partial subscan, or
·
partial subscan, full
subscan, or
·
full subscan, partial
subscan
If offset = 0, the next word is the
beginning of the subscan.
The format of a full Subscan Science Data that
“floats” within the 202 byte NGIMS subscan data space (see Table
4) is as follows:
|
Name
|
Length
(bits) |
Value
|
Description
|
|
Sync Word |
16 |
EB90 h |
Indicates the start of science subscan packet |
|
MET MSB |
16 |
Unsigned integer |
MSB MET in seconds |
|
MET LSB |
16 |
Unsigned integer |
LSB MET in seconds |
|
Frac MET |
16 |
Unsigned integer |
Fractional MET in 1/256 s |
|
Data |
152
* 8 |
|
Subscan data |
Add more information about subscan data and
fixed housekeeping.
The
NGIMS Memory Dump Packet is differentiated by the application process ID (APID
= 0x0481) in the NGIMS Primary Header and
is used to transmit memory contents of RAM, IORAM, EEPROM1, and EEPROM2 in the
NGIMS hardware. Memory dump packets consist of CONTOUR CCSDS headers, dump
source, a dump start address, dump length (in words TBC), 228 bytes of dump
data, and 4 spare bytes. Each packet
has the following format:
|
Name |
Length (bits) |
Value |
Description |
|
Header |
48 |
See Table 1 |
CCSDS primary |
|
|
16 |
See Table 2 |
NGIMS header |
|
|
16 |
Unsigned Integer |
Indicates the serial number of the dump command |
|
Dump Source |
16 |
See Table 8 |
Indicates source of dump data |
|
Start Address |
16 |
Unsigned Integer |
Indicates
start address of dump |
|
Length |
16 |
Unsigned Integer |
Indicates length (in number of words) of
dump |
|
Data |
222 * 8 |
|
Dump data |
|
MSB |
16 |
Unsigned Integer |
|
|
LSB |
16 |
Unsigned Integer |
|
|
Spare |
4 * 8 |
|
Spare bytes |
Table 8. NGIMS Memory Dump
Source Word Format
|
|||
|
Name |
Length (bits) |
Value |
Description |
|
Source |
2 |
Unsigned Integer |
0 = RAM, 2 = EERPROM,
3=IORAM (TBC) |
|
Chip |
1 |
|
0 = EEPROM0, 1= EEPROM1 |
|
spare |
9 |
spare |
spare |
An application process ID of 0x0482
in the NGIMS Primary Header indicates a
Command Acknowledge Packet. NGIMS echoes the op code, the first parameter, and
the serial number of each command it receives. Up to 8 commands are echoed per
Command Acknowledge Packet. NGIMS is limited to receiving a maximum of 8
commands per second and thereby, echoing up to 8 commands per packet. An OpCode
of zero indicates the end of the Command Echo block. Each packet has the
following format:
|
Name
|
Length
(bits) |
Value
|
Description
|
|
NGIMS Primary Header |
48
|
See Table 1 |
CCSDS Primary Header |
|
MET MSB |
16 |
Unsigned integer |
MSB MET in seconds |
|
MET LSB |
16 |
Unsigned integer |
LSB MET in seconds |
|
Telecommands Received |
16 |
Unsigned integer |
Total telecommands received |
|
Telecommands Rejected |
16 |
Unsigned integer |
Total telecommands rejected |
|
Total Commands |
16 |
Unsigned integer |
Total number of commands echoed in the packet |
|
Echo OpCode 1 |
16 |
See Table 10 |
Op code of command received |
|
Echo Data word 1 |
16 |
Unsigned integer |
First word parameter of command received |
|
Echo serial number 1 |
16 |
See Table 11 |
Serial number of command received |
|
Up to 7 more groups 3 echo info |
7
* 16 * 3 |
|
See above 3 rows |
|
End of packet |
16 |
0000 |
Indicate end of command echo block |
|
Spare |
206
* 8 |
|
Spare bytes |
Table 10. NGIMS Echo
Opcode Word Format
|
|||
|
Name |
Length (bits) |
Value |
Description |
|
vc |
1 |
|
(TBC) |
|
valid |
1 |
|
(TBC) |
|
spare |
6 |
spare |
spare |
|
opcode |
8 |
|
Op code
of command received |
Table 11. NGIMS Echo
Serial Number Word Format
|
|||
|
Name |
Length (bits) |
Value |
Description |
|
Destination |
2 |
|
TBC |
|
Serial Number |
14 |
|
Op code of
command received |
NGIMS produces two types of telemetry:
· CCSDS packets
· non-packetized data
The CCSDS packets consist of 3 types: subscan, memory dump and command acknowledge and differentiated by the application process ID within the CCSDS primary header, 0x480 (Table 4), 0x481 (Table 7), and 0x482 (Table 9), respectively.
|
Table 12. Acronyms |
|
|
Acronym |
Definition |
|
BC |
Bus Controller |
|
CCSDS |
Consultative Committee for Space Data
Systems |
|
C&DH |
Command & Data Handling |
|
CFI |
CONTOUR Forward Imager |
|
CONTOUR |
COmet Nucleus TOUR |
|
CRISP |
CONTOUR Remote Imager/Spectrometer |
|
DPU |
Data Processing Unit |
|
EEPROM |
Electrically Erasable Programmable ROM |
|
MET |
Mission Elapsed Time |
|
NGIMS |
Neutral Gas and Ion Mass Spectrometer |
|
RAM |
Random Access Memory |
|
ROM |
Read Only Memory |
|
RT |
Remote Terminal |
|
S/C |
Spacecraft |
|
TBC |
To Be Confirmed |
|
TBD |
To Be Determined |
|
XOR |
eXclusive OR |