2. TELEMETRY

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

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

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

6. Example of Telemetry Data Flow

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

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

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

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

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

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

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

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

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

16. 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.The TRANSFER FRAME DATA FIELD may be one of three types of data, but source packets shall not be mixed whit privately defined data.

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

18. –G(X)= X 16 +X 12 +X 5 +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

19. TELEMETRY CHANNEL CODING 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.

20. CONVOLUTIONAL CODING 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:

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

22. 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 = 2 J -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) = x 8 + x 7 + x 2 + x + 1 Code generator polynomial over GF(2 8 ), where F(  )=0

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

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

25. Maximum Codeblock Length: L max =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:

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

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

28. Turbo encoder block diagram Backward connection vectorG0=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.

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

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

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

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

33. 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)= x 8 + x 7 + x 5 + x 3 +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.