Transcript TELEMETRY - Libero.it

TELEMETRY
OVERVIEW OF TELEMETRY SYSTEM
• The purpose of telemetry system is to reliability and transparently
convey measurement information from remotely located data
generating source to users located in space or in Earth.
• The CCSDS is broken down in 2 categories:
– Packet Telemetry: the end-to-end transport of mission data.
– Telemetry Channel Coding: is a method by which data can
be sent from a source to a destination. This allows
reconstruction of the data with low error probability.
• The CCSDS Recommendations only address the five lower
layers of ISO-OSI model.
RELATIONSHIP BETWEEN TELEMETRY AND
TELECOMMAND SYSTEMS
• The two systems work hand in
hand to assure the transfer of
user directives from the
sending end to the receiving
end.
• The Telemetry System does a
great does more than simply
returning command receipt
status information to the
sender: it’s usual function is to
provide reliable, efficient
transfer of all spacecraft data
back to user.
PACKET TELEMETRY:
Sharing transmission resources
• Multiple users must share access to the downlink data channel
whit different types of data may be handled differently.
• This Recommendation provides the method of virtual
channelisation for controlling the data flow.
• If a payload contains an instrument which produces packets
containing many thousands of octets, a possible system
architecture would be to assign the instrument packets to one
virtual channel and to handle the rest by multiplexing them into a
second virtual channel.
• Virtual channels may also be used to separate real-time packets
from recorded packets.
Example of Telemetry Data Flow
SOURCE PACKET
• The source packet is a data structure generated by an on-board
application process.
• It can be generate at fixed or variable intervals and may be fixed
or variable in length.
• The source packet is completely under the control of the
application process.
• Each data source is thus able to define its data organisation
independently of other data source
• A source packet which contains idle data in its packet data field
is called an IDLE PACKET, it may be generated when needed
to maintain synchronisation of the data transport and the packet
extraction processes.
• A series of source packets generated consecutively by a single
application process may be designed as a Group of Source
Packets.
SOURCE PACKET
• A source packet encapsulates a block of application data which
have to be transmitted from an application process in space to
one or several sink processes on the ground.
• Two major fields
– Packet Primary Header
(48 bit)
– Packet Data Field
(variable)
• A source packet shall consist of at least 7 and at most 65542
octets.
Packet Primary Header
• The VERSION NUMBER contained within the bits 0-2 and shall
be set to “000”.
• The PACKET IDENTIFICATION FIELD (bit 3-15) 13-bits fields
– Type indicator shall be set to “0” (for telecommand packets
the type indicator will be set to”1”).
– Packet secondary header flag It shall be “1”, if a packet
secondary header is present; it shall be “0”, otherwise.
– Application process identifier (bit 5-15) shall be different
for different application processes on the same master
channel. For idle packets, it shall be “11111111111”,i.e., all
one.
Packet Primary Header
• The PACKET SEQUENCE CONTROL FIELD (bit 16-31) 16-bits field
– Grouping flag shall be set as follows:
• “01” for the first source packet of a group;
• “00” for a continuing source packet of a group;
• “10” for a last source packet of a group;
• “11” for a source packet not belonging to a group.
– Source sequence count shall provide the sequential binary
count (modulo 16384) of each source packet generated by an
application process.
• For idle packets are not required to increment this field.
• The purpose of the filed is to order this packet.
• The field will normally be used in conjunction whit a Time
Code to provide unambiguous ordering.
Packet Primary Header
• The PACKET DATA LENGTH FIELD (bit 32-47) 16-bits field
– This field contains a binary number equal to the number of octects
in the packet data field minus 1.
– The value contained may be variable and shall be in the range of
0 to 65535
Very long packets are permissible, these may present special
problems in term of data link monopolisation, source data
buffering and may add complexity to ground processing.
The Recommendation therefor provides the means to assign these
packets to individual Virtual Channels
Packet Primary Header
• The PACKET DATA FIELD shall contain at least one octet
– Packet secondary header is optional (signalled by the flag) and it
shall consist of either:
• a packet secondary header DATA field contains any ancillary
data necessary for the interpretation of the information
contained within the Source Data Field.
• or packet secondary header TIME CODE field consists of an
optional P-Field which identifies the time code and its
characteristic, and a mandatory T-Field.
• or a packet secondary header TIME CODE field followed by a
packet secondary header DATA field
– Source data field shall contain an integral number of octets either
source data from an application process or idle data.
TRANSFER FRAME
• The transfer frame is a data structure for the transmission of
source packets, idle data and privately defined data.
• The transfer frame shall be of constant length throughout a specific
mission phase (CCSDS limits the maximum length to 8920 bit).
• All Transfer frames whit the same spacecraft identifier on the same
physical channel constitute a MASTER CHANNEL, which shall
consist of among one and eight Virtual Channels.
Transfer Frame Primary Header
• The VERSION NUMBER (bit 0-1) and shall be set to “00”
• The TRANSFER FRAME IDENTIFICATION FIELD (bit 2-15) 14-bits
– Spacecraft identifier (bit 2-11) is assigned by CCSDS and shall
provide the identification of the spacecraft which created the frame.
– Virtual channel identifier (bit 12-14) provides the identification of
the virtual channel.
– Operational control field flag (bit 15) shall indicate the presence
(set to “1”) or absence (set to “0”) of the Operational Control Field.
• The MASTER CHANNEL FRAME COUNT FIELD (bit 16-23) shall
contain a sequential binary count (modulo 256) of each transfer frame
transmitted within a specific master channel.
• The VIRTUAL CHANNEL FRAME COUNT FIELD (bit 24-31) shall
contain a sequential binary count (modulo 256) of each transfer frame
transmitted through a specific virtual channel of a master channel.
• The TRANSFER FRAME DATA FIELD STATUS FIELD (bit 32-47)
– Transfer frame secondary header flag shall be “1” if present
– Synchronisation flag shall signal the type of data. It shall be “0” if
source packet or idle data (because they are inserted on octet
boundaries). It shall be “1” if it doesn’t observe octet boundaries
– Packet order flag is set to “0” (reserved for future use by CCSDS)
– Segment length identifier if sync flag is “0”  it shall be “11”.
(required for earlier version of this Recommendation)
– First header pointer shall contain the binary representation of the
location of the first octet of the first packet primary header.
Transfer Frame Secondary Header (optional)
and Transfer Frame Data Field
• The TRANSFER FRAME SECONDARY HEADER IDENTIFICATION
FIELD (bit 0-7) shall be sub-divided into two sub-field as follows:
– Transfer frame secondary header version number shall be set to
“00”. Recommendation recognises only one version.
– Transfer frame secondary header length (bit 2-7) in octet minus 1
• The TRANSFER FRAME SECONDARY HEADER DATA FIELD shall
contain the transfer frame secondary header data.
• The TRANSFER FRAME DATA FIELD may be one of three types of
data, but source packets shall not be mixed whit privately defined data.
Transfer Frame Trailer (optional)
• The OPERATIONAL CONTROL FIELD, if present, it occurs within
every transfer frame transmitted through a specific virtual channels.
– If the first bit is “0”  it hold a TYPE-1-REPORT which shall contain
a Command Link Control Word.
– If the first bit is “1”  it hold a TYPE-2-REPORT.
• The FRAME ERROR CONTROL FIELD is mandatory if the transfer
frame not Reed-Solomon encoded.
– Encoding procedure: generates a systematic (n, n-16) block code
FECF = [ ( X 16 M(X) )  ( X (n-16) L(X) ) ] modulo G(X)
where : M(X) is the (n-16)-bit message.
L(X) is the presetting polynomial (all ones).
– G(X)= X16+X12+X5+1 is the generating polynomial (same of HDLC)
– Possible implementation: Shift register set to “1” ;
For the first n-16 bit  Gate A and B closed, C open.
For the last 16 bit  Gate A is clamped to “0”, gate B open, C close.
– Decoding procedure: S(X) which will be zero if no error.
S(X) = [ ( X 16 C*(X) )  ( X n L(X) ) ] modulo G(X)
where: C*(X) is the receiving block, including the Frame Error Control.
– Possible implementation: Shift register set to “1”; After n-16 bit  B open
TELEMETRY CHANNEL CODING
• Telemetry channel coding is a method of processing data being
sent from a source to a destination so that distinct messages are
created which are easily distinguishable from one another.
• This allows reconstruction of the data whit low error probability,
thus improving the performance of the channel.
• Several space telemetry channel coding schemes are described
in CCSDS document, but they does not attempt to quantify the
relative coding gain.
• This Recommendation does not require that coding are used on
all cross-supported mission.
• For telecommunication channel which are bandwidth
constrained and cannot tolerate the increase in bandwidth
required by the convolution code, the Reed-Solomon code
specified has the advantage of smaller bandwidth expansion
and has the capability to indicate the presence of uncorrectable
error.
CONVOLUTIONAL CODING
• The basic code selected for cross-support is:
– Rate:
½
– Constraint-length:
7
– Connection vector:
G1=1111001; G2=1011011
• The convolutional decoder is a maximum-likelihood (Viterbi).
• If the decoder’s correction capability is exceeded, undetected
burst errors may appear in the output.
• Encoder block diagram:
REED-SOLOMON CODING
• The Reed-Solomon code is a power burst error correcting code
and it provides an excellent forward error correction capability in
a burst-noise channel.
• The (255, 223) Reed-Solomon code is capable of correcting up
to 16 Reed-Solomon symbol errors in each codeword (16x8bit).
• To achieve this reliability, proper codeblock synchronisation is
mandatory.
• However, should the Reed-Solomon code alone not provide
sufficient coding gain, it may be concatenated with the
convolutinal code.
• Reed-Solomon code is the outer code, while the convolutional
code is the inner code.
REED-SOLOMON CODING: Specification
• J = 8 bits per R-S symbol.
• E = 16 R-S symbol error correction capability within a ReedSolomon codeword.
• n = 2J-1 = 255 symbols per R-S codeword.
• 2E is the number of R-S symbols representing parity checks.
• k = n-2E is the number of R-S symbols representing information.
• F(x) and g(x) characterise a (255,223) Reed-Solomon code.
• Field generator polynomial over GF(2):
F(x) = x8 + x7 + x2 + x + 1
• Code generator polynomial over GF(28), where F()=0
g ( x) 
 x      G x
143
j 112
32
11 j
i 0
i
i
• It’s a systematic code (the input information sequence appears
in unaltered form as part of the output codeword).
• Symbol Interleaving:
– The allowable values of interleaving depth are I=1,2,3,4,5.
– The interleaving depth shall normally be fixed on a physical
channel for a mission.
– Functional representation of R-S Interleaving (this functional
description does not necessarily correspond to the physical
implementation of an encoder).
– Data bit enter at the port labelled “IN”.
– Switches S1 and S2 are synchronised together and advance
from encoder to encoder in the sequence 1,2,...,I, 1,2,…,I, ...
– One codeblock will be formed from 223I R-S symbol entering
“IN”.The synchronised action of S2 reassembles the symbols
at the port labelled “OUT” in the same way as they entered
at “IN”.
– Following this, each encoder outputs its 32 check symbols.
– With this method of interleaving, the original kI consecutive
information symbols which entered the encoder appear
unchanged at the output of the encoder with 2EI R-S check
symbols appended.
• Maximum Codeblock Length: Lmax=n I=(2 j-1)I=255 I symbols
• Shortened Codeblock Length:
– Virtual fill in a codeblock is increased (at a specific bit rate),
the number of codeblocks per unit time that the decoder
must handle increases.
– However, since the R-S code is a block code, the decoder
must always operate on a full block basis.
– To achieve a full codeblock,”virtual fill” must be added (not
transmitted).
– When an encoder received KI-Q information symbols 2EI
check symbols are computed over KI symbols (Q symbols
are treated as all-zero symbols).
• Reed-Solomon Codeblock Partitioning and Virtual Fill:
TURBO CODING
• Turbo codes are binary codes with large code block (1000 bit)
• They are systematic and inherently non-transparent 
Differential encoding after the turbo encoder is not
recommended  Phase ambiguities have to be detected and
resolving by the frame synchroniser.
• Turbo codes may be used to obtain even greater coding gain.
TURBO CODING: Specification
•
•
•
•
•
•
A turbo encoder is a combination of two simple encoders.
Code type: Systematic parallel concatenated turbo code.
Type of component codes: Recursive convolutional codes.
Number of states of each component: 16.
Nominal Code Rate: r = 1/2, 1/3, 1/4, 1/6 (no trellis termination).
The specified information block lengths k=223*8*I are chosen
for compatibility whit the corresponding Reed-Solomon
interleaving depth, and the corresponding codeblock length in
bits n=(k+4)/r.
• The interleaving for turbo codes is a fixed bit-by-bit permutation
of the entire block of data.
• For each specific block length k there’s an algorithm that for s=1
to s=k to obtain permutation numbers (s).
Turbo encoder block diagram
• Backward connection vector G0=10011
• Forward connection vector
– G1=11011
– G2=10101
– G3=11111
• Turbo encoder block diagram : Each input frame of k information bits
is held in frame buffer, and they are read out in two different order.
• Encoder “a” operates on the bits in unpermuted order.
• Encoder “b” receives the same bits permuted
by the interleaving.
• Both encoder are initialised with 0s.
• Both are run for k+4 bit time, producing an
output codeblock of (k+4)/r .
• For the first k bit times, the input switches are
in lower position, for the final 4 bit times this
switches move to the upper position (trellis
termination), output a nonzero encoded
symbol.
• The encoded symbols are multiplexed from
top-to-bottom along the output line for the
selected rate.
• The output sequence are:
– For r =1/2  0a, 1a, 0a, 1b, 0a, 1a, …
– For r =1/3  0a, 1a, 1b, 0a, 1a, 1b, ...
– For r =1/4  0a, 2a, 3a, 1b, 0a, 2a, …
– For r =1/6  0a, 1a, 2a, 3a, 1b, 3b, ...
FRAME SYNCHRONISATION
• Frame or codeblock synchronisation is necessary to proper
decoding of Reed-Solomon and Turbo Codeblock.
• Synchronisation is achieve by using a stream of fixed-length
codeblocks whit an Attached Sync Marker (ASM) between them.
• Synchronisation is acquired by recognising the specific bit pattern.
• Encoder side:
– If telemetry channel is uncoded, or only R-S coded or Turbo
coded, the ASM are attached directly to the encoder output.
– If an inner code is used in conjunction with an outer R-S code,
the ASM is encoded by the inner code but not by R-S.
• Decoder side:
– For R-S and convolutional, the ASM may be acquired in the
channel symbol domain or in the domain of bit decoding by the
inner code.
– For a turbo coding system, the ASM must be acquired in the
channel symbol domain.
• The ASM for data which is not turbo coded shall consist of 32-bit,
for turbo coded shall consist of a 32/r bit.
• The ASM bit patterns are represented in hexadecimal notation as:
– ASM for non turbo coded data:
1ACFFC1D
– ASM for r = 1/2 turbo coded data: 034776C7272895B0
– ASM for r = 1/3 turbo c.d.: 25D5C0CE8990F6C9461BF79C
• The ASM is NOT a part of the encoded data space of R-S
codeblock and it is not presented to the input of R-S encoder.
• A different ASM pattern may be required where another data
stream is inserted into the data field of the Transfer Frame of the
main stream. Pattern in hex. notation is:
35EF853
PSEUDO-RANDOMISER
• In order to maintain bit synchronisation, it’s requires that the
incoming signal have a minimum bit transition density.
• The method for ensuring sufficient transition is to exclusive-OR
each bit of the Codeblock or transfer Frame with a standard
pseudo-random sequence.
• Pseudo-Randomiser is applied after turbo encoding or R-S
encoding, but before convolutional encoding.
• The ASM is already optimally configured for synchronisation
purpose  used for synchronisation the Pseudo-Randomiser.
• On the receiving end, the original Codeblock is reconstructed
using the same pseudo-random sequence.
• The pseudo-random sequence is applied by EX-ORing the first
bit of its whit the first bit following the ASM.
• The pseudo random sequence shall be generated using the
following polynomial:
h(x)= x8 + x7 + x5 + x3 +1
• This sequence repeats after 255 bits.
• The sequence generator is initialised to an “all-ones” state for
each Codeblock or Transfer Frame during ASM period.