CCSDS packets description

General Description

The packet format used within the PicSat mission is largely based on the CCSDS (Consultative Comitee for Space Data Systems) standard. However, the standard has been modified for the particular needs of a small CubeSat mission.

A CCSDS packet is made of three parts: a primary header, a secondary header, and a data section. In most cases (but not all), the information contained in the data section of the PicSat packets can be read bytewise. However, the fields of the primary and secondary headers are not bytes-aligned, and should be read bitwise.

All PicSat CCSDS packets have an absolute size limit (set by hardware) of 235 bytes.

Unpacking procdure

To extract data from one of the PicSat CCSDS Telemetry (TM) packets, it is suggested to follow at least these steps and verificatons:

• unpack the primary header: the primary header, of length 6 bytes, should be unpacked first. The data_length should be extracted and compared to the the size of the packet (minus 8 for the primary header) to check that the packet has been entirely received. The payload_flag, and packet_category values should be extracted as they are required to know how the data section should be read.
• unpack the secondary header: the secondary header (6 bytes) may be extracted to get the time of emission of the packet.
• auxiliary header: using Table 3 of this page together with the values of the payload_flag and packet_category from the primary header, the presence of an auxiliary header should be asserted. If present, all fields of the auxiliary should be extracted, as they provide important information about how the packets data should be interpreted.
• multiple or single datapoints: using again Table 3 of this page together with the values of the payload_flag and packet_category from the primary header, the user should determine if the packet contain a unique sequence of data, or a repeated sequence. In presence of a repeated sequence, the data_length (minus 6 for secondary header, minus the size of auxiliary header) may be used to determine how many datapoints can be extracted from the packet.
• data: the remaining bytes can finally be read using the correct format specification (see links in Table 3 of this page). If datapoints are being stored in a file, we suggest to repeat the auxiliary header data for each line. If stored in a database, there must be a way to unambiguously link each datapoint to the auxiliary header with which it came.

Primary Header

The primary header starts at byte 0 (first byte) of the packet, and ends at byte 7. It is 6 byte long. The following Table describes its content.

Process IDs

Secondary Header Telemetry

The secondary header of telemetries starts at byte 6 of the packet, and ends at byte 11. It is 6 byte long. The following Table describes its content.

Secondary Header Telecommand

The secondary header of telecommands starts at byte 6 of the packet, and ends at byte 21. It is 16 byte long. The following Table describes its content.

Packet Categories

In a telemetry packet, the section after the primary and secondary headers contains the optional auxiliary header, and the data themselves. These are highly mission specific. Each packet category (defined by the combination of the payload_flag and the packet_category from the primary CCSDS header) has its own auxiliary header and data format. In the following two tables, you will find links to all the packet format descriptions, when they are realeased. The "repeat" column indicate if the data format shall be read repeatedly until the end of packet (multiple data points in one packet, see unpacking procedure above).

If you click on the name of the category, you can also get an example CCSDS packet (no KISS, no AX.25), to test your software.

OBC packet categories (payload_flag = 0)

Payload packet categories (payload_flag = 1)