The Packet Sequence Count uses 14 bits, wraps at 16383, and runs independently per APID. This causes many telemetry processing errors during a team's first ground station test. Ground software often compares the count with one global counter instead of a per-APID counter. Each new APID then appears to produce a jump, leading the team to suspect dropped frames. The frames are intact.
This guide covers key validation checks for CCSDS Space Packet Protocol (CCSDS 133.0-B-2), including which provide the most value when V&V time is limited.
Primary Header Checks
The CCSDS Space Packet primary header is 6 octets.
Version Number (bits 0 through 2): Required value is binary 000. Another value means a protocol version mismatch, not corrupted data. Non-zero values in live data may mean the ground system is decoding raw transfer frames as packets.
Packet Type (bit 3): 0 denotes telemetry (TM), and 1 denotes telecommand (TC). Combined pipelines often miss this field and decode TC acknowledgment packets as TM. Header structure matches, but data-field meaning differs.
Secondary Header Flag (bit 4): Value 1 means a secondary header exists. If the ICD assigns secondary headers to certain APIDs but software ignores this flag, it will select the wrong data-field byte offset. Secondary header size varies by mission and is defined per APID in the ICD.
APID (bits 5 through 15): This 11-bit field spans 0 to 2047. APID 2047 (0x7FF hexadecimal) is reserved for the CCSDS idle APID and packets using it should be discarded immediately. Check other APIDs against the ICD allocation table. An unlisted APID indicates misconfigured OBSW or frame synchronization data mistaken for a packet.
Sequence Flags (bits 16 through 17): Binary 11 means standalone, 01 means the first segment, 00 means continuation, and 10 means the final segment. Most spacecraft use standalone packets only. Where segmentation is not used, flagging values other than 11 as anomalous is appropriate and catches a class of OBSW framing errors.
Packet Sequence Count (bits 18 through 31): A 14-bit counter per APID, ranging from 0 to 16383. Each APID advances separately, so a gap on APID 100 says nothing about APID 200. Keep the last count for each APID and test continuity within each stream.
Packet Data Length (bits 32 through 47): This 16-bit value is the data-field octet count minus 1. Thus, declared length 15 means 16 data octets. If the declaration differs from the available bytes, the cause is a framing or OBSW encoding error. Treat this mismatch as a hard error, not a warning, because an incorrect length leads to undefined downstream field values.
Secondary Header Checks
Secondary headers come from the ICD and differ by mission. A common telemetry form contains a 4-octet or 8-octet spacecraft time field, usually in CDS or CUC format under CCSDS 301.0-B-4. Validate that time increases monotonically within a virtual channel and is no more than the one-way light time plus reasonable tolerance ahead of ground receipt time.
If a timestamp precedes the prior packet for the same APID, possible causes include an OBSW reset, confirmed against frame count, deliberate product retransmission, or an FDIR event restarting the time counter. These are not necessarily errors, but ground processing should flag each for operator review.
Sequence Count Continuity Across Link Gaps
During a link outage, the spacecraft keeps incrementing packet sequence counts. After downlink resumes, the first packet may be many counts beyond the last received one. That is expected, not packet loss.
A "missing count" metric misleads across link gaps. Reporting 15,000 missing packets during a 20-minute outage reflects the expected count advance, not data loss. Measure gaps within one continuous downlink pass, not between passes.
In a generated validation layer, make gap detection use a link-gap reset flag that clears expected-count state when the ground station records link acquisition. Spacebackend's generated validation code provides a reset hook, allowing connection to ground link-state events without changing the generated logic.
Idle Packet Handling
CCSDS idle packets (APID 0x7FF) are valid packets used to fill spare frame capacity. Treating them as errors creates false anomalies during low-data-rate phases when OBSW pads frames with idle data. Idle-packet rate is a valid telemetry metric for downlink utilization, but not an error condition.
An idle packet's data field has no defined content. Do not decode it as payload.
Priorities When Time Is Limited
With limited time for a first CCSDS packet validation layer, prioritize Packet Data Length consistency, per-APID sequence count continuity, and APID range validation. Together, these catch broad classes of OBSW encoding errors and ground configuration mistakes.
Version and packet type checks remain useful, but functioning ICD pipelines make them less common anomaly sources. Sequence flags matter when segmentation is used. Without segmentation, that check is low priority.
This guide addresses the CCSDS protocol layer: packet structure, header-field checks, and sequence integrity. Application-layer validation, such as testing whether parameter values are physically plausible or within mission limits, needs range tables from the OBSW ICD, maintained separately from the packet structure definition. Protocol validation confirms correct packet formation. Application validation confirms physically meaningful data. Both are required and use different inputs. Spacebackend generates the protocol layer from the ICD field schema. Mission-specific application range tables must be authored separately from physical design constraints.
