Telemetry Features
This page describes features of the protocol supported by the Telemetry Encoder Shell and Telemetry Decoder Shell. For the formal definition of the features described here, see the TM standards documents.
Note: Older issues of the standards use the term Packet Telemetry for
the protocols that transport data units, such as packets, in
TM Transfer Frames.
However, the protocols are not limited to packets. The current standards
no longer use the term.
Packets and the Virtual Channel Packet Service (VCP service)
The Telemetry Encoder Shell and Telemetry Decoder Shell handle the following types of packets on the Virtual Channel Packet (VCP) service:
- CCSDS Space Packets (also known as Source Packets or Telemetry Packets)
- CCSDS Encapsulation Packets
The VCP service runs within a Virtual Channel and is also known as the
Packet Service.
Physical Channel
A Physical Channel is a telemetry bitstream. A single instance of the Telemetry Encoder Shell
or the Telemetry Decoder Shell supports
one Physical Channel.
Virtual Channels (VCs)
Multiple Virtual Channels (VCs) can share the capacity of a single Physical Channel. The Virtual Channels are assigned transmission capacity on a frame-by-frame basis. Typically, Virtual Channels are used to separate sources or destinations with different characteristics. For example, a source which generates very large packets may use a different VC from other sources which generate short packets.
A Virtual Channel is identified by a Virtual Channel Identifier (VCID) and a Spacecraft Identifier (SCID).
The Telemetry Encoder Shell and Telemetry Decoder Shell support up
to 8 Virtual Channels on the Physical Channel.
Master Channels (MCs)
The set of Virtual Channels on the same Physical Channel and which have the same Spacecraft Identifier constitute a Master Channel. A Master Channel may have up to 8 Virtual Channels.The Telemetry Encoder Shell and Telemetry Decoder Shell support multiple Master Channels on
the Physical Channel. The overall
limit (8) on the number of Virtual Channels on the Physical Channel still applies.
Transfer Frame
TM Transfer Frames are the fixed-length protocol data units used by the TM Space Data Link Protocol to transfer data through the space links.
The Transfer Frame Data Field is generally used to carry packets. Multiple asynchronous sources on board a spacecraft can generate variable-length packets at different rates. The packets can then be multiplexed together into a synchronous stream of fixed-length Transfer Frames for transmission. A Transfer Frame may carry data from one or more packets.
The Transfer Frame has optional fields for carrying other data: the Transfer Frame Secondary Header and the Operational Control Field.
Within a Physical Channel, all the Transfer Frames have the same length.
The Transfer Frames supported by the Telemetry Encoder Shell and Telemetry Decoder Shell
are the Version-1 frames defined for the TM Space Data Link Protocol.
(The AOS Encoder Shell and
AOS Decoder Shell support the Version-2 frames (VCDU) defined for
CCSDS Advanced Orbiting Systems in the AOS Space Data Link Protocol.)
Buffered services (Synchronous services)
The data transfer services which use the Transfer Frame Secondary Header and the Operational Control Field are buffered services. The buffered services are also called synchronous services.
In a buffered service, the data unit for transfer is placed in a special buffer. Whenever the user has a
data unit to send, it is placed in the special buffer, overwriting any earlier contents. Whenever a frame
for the service is about to be sent, the data unit is read from the special buffer and placed in the frame.
Therefore, the fate of any particular data unit depends on the timing. A particular data unit may be
transmitted more than once, if the special buffer is not updated between frames for the service. Also, a
particular data unit may not be sent at all, if it is overwritten by another data unit before the next frame
for the service.
Transfer Frame Secondary Header (FSH)
The Transfer Frame Secondary Header (FSH) can be used to carry fixed-length mission-specific data. The use of the FSH is optional. If present, the length is from 2 to 64 octets.
There is a service, MC-FSH, for transferring data via the FSH at the Master Channel level. In this case, the length of the FSH is fixed for all Transfer Frames for the Master Channel. Each frame on the Master Channel will carry the latest available copy of the data.
There is a service, VC-FSH, for transferring data via the FSH at the Virtual Channel level. In this case, the length of the FSH is fixed for all Transfer Frames for the Virtual Channel. Each frame on the Virtual Channel will carry the latest available copy of the data.
If the MC-FSH service is configured for a Master Channel, this excludes the use of the VC-FSH service for all Virtual Channels on that Master Channel.
The FSH services are buffered services (synchronous services).
The Telemetry Encoder Shell and Telemetry Decoder Shell support the use of the MC-FSH and VC-FSH services.
Operational Control Field (OCF)
The Operational Control Field (OCF) can be used to provide the status of telecommand or other spacecraft operations activities. Telecommand Communications Link Control Words (CLCWs) may be carried in the OCF. The use of the OCF is optional. If present, the length is 32 bits.
There is a service, MC-OCF, for transferring data via the OCF at the Master Channel level. In this case, the OCF is present in all Transfer Frames for the Master Channel. Each frame on the Master Channel will carry the latest available copy of the data.
There is a service, VC-OCF, for transferring data via the OCF at the Virtual Channel level. In this case, the OCF is present in all Transfer Frames for the Virtual Channel. Each frame on the Virtual Channel will carry the latest available copy of the data.
If the MC-OCF service is configured for a Master Channel, this excludes the use of the VC-OCF service for all Virtual Channels on that Master Channel.
The OCF services are buffered services (synchronous services).
The Telemetry Encoder Shell and Telemetry Decoder Shell support the use of the MC-OCF and VC-OCF services.
Idle Packets, Idle Data and Only Idle Data (OID) Frames
Sometimes, a frame must be released before sufficient packet data is available to fill the frame. In this case, an Idle Packet may be used to complete the frame. Idle Packets are Space Packets with a special Application Process Identifier of "all ones". A system configured to use Encapsulation Packets may also use Encapsulation Idle Packets.
Idle Data is data which caries no information. To meet timing or synchronisation requirements, it may be necessary to send a Transfer Frame of Idle Data. In this case, the Idle Data occupies all of the Transfer Frame Data Field, though there may be meaningful data in other fields, such as the FSH. The frame is called an Only Idle Data (OID) Frame.
The Telemetry Encoder Shell generates Idle Packets and OID Frames as required. The Telemetry Decoder Shell
processes any Idle Packets or OID Frames it receives.
Privately formatted data and VCA service
The Virtual Channel Access (VCA) service of the TM Space Data Link Protocol provides for the transfer of privately formatted fixed-length service data units.
The current versions of the Telemetry Encoder Shell and Telemetry Decoder Shell do not support the VCA service.
Support may be included in a later version if required.
Source Packet Segmentation
Earlier issues of the CCSDS recommendations defined an optional Source Packet segmentation
scheme. It has been removed from all current issues of the CCSDS recommendations.
The Telemetry Encoder Shell and Telemetry Decoder Shell do not support Source Packet segmentation.
Frame Error Control Field
A Frame Error Control Field may be included at the end of each Transfer Frame. It uses a CRC mechanism, which enables the receiver to detect errors in the frame.
The Telemetry Encoder Shell and Telemetry Decoder Shell support the use of Frame Error Control. It is a run-time configuration
option for a Master Channel.
Virtual Channel Multiplexing
The streams of Transfer Frames from the Virtual Channels are multiplexed into the single Physical Channel. The Telemetry Encoder Shell uses a round-robin algorithm for this multiplexing. Each Virtual Channel in turn is given the opportunity to send a frame. If a channel has no packet data available at that time, it forfeits its turn.
The Telemetry Encoder Shell provides an override mechanism for selecting the next Transfer Frame to be sent. This mechanism is intended, for example, to force the sending of FSH data for a channel which currently has no packet data to send.
Alternative multiplexing algorithms may be added to the Telemetry Encoder Shell in future versions if
required.
Channel Coding
The Telemetry Encoder Shell and Telemetry Decoder Shell do not include any of the features of the TM Synchronization and Channel Coding recommendations. For example, they do not perform Reed-Solomon or convolutional coding or decoding for the transfer frames they handle.