Astro~/0.3
** CLI / astro xtce * PAGE 15 / 22
** Astro * CLI
** /cli/xtce

astro xtce

XTCE mission databases, validate, list, layout, decode, match.

XTCE mission database operations: validate a database, see what it defines, and decode packets against it (XTCE 1.2, CCSDS 660.1-G-2).

Subcommands

CommandDescription
astro xtce validateCheck a database for the errors the schema cannot catch
astro xtce listList the space systems, parameters and containers it defines
astro xtce layoutShow the fields a container lays out, with bit offsets
astro xtce decodeDecode a packet against a named container
astro xtce matchWork out which container a packet is, then decode it

Names are qualified paths, /Sat/Telemetry, not Telemetry. list prints them in that form so its output can be pasted straight into the other commands.


astro xtce validate

Load a database and run the semantic checks: unresolved references, duplicate names, container inheritance cycles, and enumeration members outside the schema's sets.

This is not schema validation. The Go standard library has no XSD validator and this package takes no dependencies, so a file that breaks the schema some other way will load and pass here. For real conformance run xmllint --schema SpaceSystem.xsd over the file first.

astro xtce validate <file>

Examples

astro xtce validate mission.xml

astro xtce list

Walk the database and list what it defines, by qualified name. Abstract containers are marked, because you cannot decode against one.

astro xtce list <file> [flags]

Flags

FlagDefaultDescription
--kindallWhat to list: all, systems, parameters, or containers
--formattextOutput format: text or json

Examples

# Everything
astro xtce list mission.xml

# Just the containers, which is what decode and match need
astro xtce list mission.xml --kind containers

astro xtce layout

Flatten a container into the fields a packet of that shape carries, in packet order, with each field's bit offset and width. Inherited fields come first, then the container's own.

This is what decode reads a packet against, so it is the thing to look at when a decode does not come out the way the database led you to expect.

astro xtce layout <file> <container> [flags]

Flags

FlagDefaultDescription
--formattextOutput format: text or json

Examples

astro xtce layout mission.xml /Sat/Housekeeping
Container: Housekeeping
Size: 24 bits (3 octets minimum)
────────────────────────────────────────────────────────────────────────
OFFSET   WIDTH    TYPE         NAME
────────────────────────────────────────────────────────────────────────
0        8        integer      /Sat/Type
8        8        enumerated   /Sat/Mode
16       8        float        /Sat/Battery

astro xtce decode

Read a packet against a named container and print each field's value.

Values are the engineering ones by default: calibrated numbers and enumeration labels. --raw gives the counts as the packet carried them.

A field that cannot be decoded is reported on stderr and the rest of the packet still comes out, so one unsupported encoding in the middle does not hide everything after it.

A container whose shape depends on its own contents (a delimited string, a blob sized by a length field, a packet-decided repeat count) is resolved against the packet being decoded, and the text output says so. The field map that results describes that packet only: the same container may read a different shape from the next one.

astro xtce decode <file> [packet-file] [flags]

Flags

FlagDefaultDescription
--container(required)Qualified container name to decode against
--inputhexInput format: hex or bin
--formattextOutput format: text or json
--rawfalseShow raw values rather than calibrated ones

Examples

# Decode a Space Packet header against a database that models it
astro spp encode --apid 100 --type tm --data 01020304 |
  astro xtce decode ccsds-header.xml --container /CCSDS/PrimaryHeader

# The raw counts instead of the labels
astro xtce decode mission.xml packet.bin --input bin \
  --container /Sat/Housekeeping --raw

astro xtce match

Search down from a root container for the one whose restriction criteria the packet satisfies, and decode it against that. This is what a ground station does with an unlabelled packet.

The deepest match wins, so a packet that is both a telemetry packet and a housekeeping telemetry packet is reported as the latter. A packet that satisfies nothing is an error, a normal thing for a ground station to see, but you have to be told.

astro xtce match <file> [packet-file] [flags]

Flags

FlagDefaultDescription
--root(required)Qualified name of the container to search down from
--inputhexInput format: hex or bin
--formattextOutput format: text, json, or name
--rawfalseShow raw values rather than calibrated ones

--format name prints just the container it chose, which is what you want in a pipeline.

Examples

# Identify and decode
astro xtce match mission.xml --root /Sat/Packet < packet.hex

# Just the name
astro xtce match mission.xml --root /Sat/Packet --format name < packet.hex

Limits

decode resolves a packet-dependent container against the packet it is given, so delimited fields, length-sized blobs, dynamic repeat counts and containerEnd all read. What stays refused is what no single pass can settle: a RepeatEntry offset, nextEntry, a LeadingSize string, a DiscreteLookupList, and a forward reference to a field that has not arrived.

match resolves candidates against the packet too, so a dynamic container can be identified as well as decoded. A CustomAlgorithm in the restriction criteria is refused, being by definition not in the file.


See also: the protocol page for the standard and the Go API, and the conformance statement for what is and is not implemented.