TELEMETRY

1
TELEMETRY
2
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.

3
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 its usual function is
  to provide reliable, efficient transfer of all
  spacecraft data back to user.

4
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.

5
Example of Telemetry Data Flow
6
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.

7
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.

8
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 to1).
• 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.

9
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.

10
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

11
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.

12
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.

13
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.

14

• 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 doesnt
  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.

15
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.

16
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).

17

• G(X) X16X12X51 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

18
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.

19
CONVOLUTIONAL CODING

• The basic code selected for cross-support is
• Rate ½
• Constraint-length 7
• Connection vector G11111001 G21011011
• The convolutional decoder is a maximum-likelihood
  (Viterbi).
• If the decoders correction capability is
  exceeded, undetected burst errors may appear in
  the output.
• Encoder block diagram

20
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.

21
REED-SOLOMON CODING Specification

• J 8 bits per R-S symbol.
• E 16 R-S symbol error correction capability
  within a Reed-Solomon 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

22

• Its 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
  I1,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).

23

• 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.

24

• Maximum Codeblock Length Lmaxn I(2 j-1)I255 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

25
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.

26
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 k2238I
  are chosen for compatibility whit the
  corresponding Reed-Solomon interleaving depth,
  and the corresponding codeblock length in bits
  n(k4)/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 theres an
  algorithm that for s1 to sk to obtain
  permutation numbers ?(s).

27
Turbo encoder block diagram

• Backward connection vector G010011
• Forward connection vector
• G111011
• G210101
• G311111
• 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.

28

• Encoder b receives the same bits permuted by
  the interleaving.
• Both encoder are initialised with 0s.
• Both are run for k4 bit time, producing an
  output codeblock of (k4)/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, ...

29
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.

30

• 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. 25D5C0CE8990F6C9461BF
  79C
• 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

31
PSEUDO-RANDOMISER

• In order to maintain bit synchronisation, its
  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.

32

• 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.