130x1g2 - CCSDS

TM SYNCHRONIZATION AND CHANNEL CODING—SUMMARY OF CONCEPT AND RATIONALEIn case this condition is not satisfied, compliance with the regulations on the PSD may not beensured. A possible solution to this problem is to remove the constraint that Only Idle DataFrames are filled by all-‘zero’ bit patterns. This can be done as follows (reference [65]):1. Testing, within the Code & Sync layer, the TF first header pointer.2. If it is equal to ‘11111111110’, filling the TF data field with pseudo-noise bits beforeentering the encoder.In principle, the pseudo-noise bits should be generated by an ad hoc long asynchronousLFSR, i.e., an LFSR which is not restarted at the beginning of each frame but runsindependently (as an example, a 32-cell LFSR). This way, the transmission of OID frameswould become not different from the transmission of payload frames, and the autocorrelationfunction would not show any periodicity, thus becoming certainly compliant to the spuriousseparation constraint, nominally without margin.Anyway, OID frames may be sometimes used for BER evaluation (by exploiting the fact thattheir data-field is known). If this is the case, it would not be possible to fill the OID data fieldby a completely asynchronous long LFSR. Anyway, it could be possible to restart the longasynchronous LFSR every X frames, with X sufficiently high, without significantperformance losses.According to this proposal, the modified OID TFs are then scrambled by the randomizer asall the other Transfer Frames (possibly, by using the 15-cell randomizer described above).Moreover, since the change is performed within the Code & Sync layer, the Data Link layercan continue to use the common practice of filling OID data field by all ‘zero’ bits. At thereceiver side, the OID TF are individuated by testing the TF first header pointer andeliminated, so the data field change is inessential.9.2.5 USAGE CIRCUMSTANCES FOR THE RECOMMENDED PSEUDO-RANDOMIZERThe Recommended Standard (reference [3]) does not always require the use of the universalsolution provided by the pseudo-randomizer. As has been seen, its use would be superfluousin the case of convolutional coding with alternate symbol inversions and BPSK modulation.Less conclusively, Turbo codes might inherently provide sufficient randomness because of theirrecursive convolutional encoding of non-‘zero’ data headers at the beginning of each data block.I&T project personnel may prefer un-randomized data so that during testing, they can readthe binary data that they are familiar with. One answer is to implement the recommendedpseudo-randomizer but make it switchable so that during early testing it can be turned off.While the recommended pseudo-randomizer is not strictly required, the system engineermust take all necessary steps to ensure that the coded symbols have sufficient transitiondensity. Several projects have encountered unexpected problems with their telemetry linksbecause this pseudo-randomizer was not used and sufficient randomness was not ensured byCCSDS 130.1-G-2 Page 9-6 November 2012