First-Hand:To Randomize or Not to Randomize Should Not Be A Question
Submitted by John O’Donnell, IEEE Life Member
Rick Volz and I donned the bunny suits and booties required to pass through the air lock into the high bay where the EOS AM1 spacecraft was under test at Lockheed Martin Astro (LM Astro) in Valley Forge, PA. (See Figure 1 - courtesy of NASA.) This was early 1998, before EOS AM1 was renamed Terra in a NASA naming contest for the flagship of its Earth Observing System (EOS) fleet of remote sensing, polar orbiting satellites. Rick and I worked for L3 Communications Telemetry East, formerly a division (Aydin Telemetry) of Aydin Corporation in Newtown, PA. Rick was program manager and I was Project Engineer for space data receivers. We provided receivers for testing the Direct Access System (DAS) data comm links of the spacecraft. From this point I’ll refer to the spacecraft by Terra, its name at launch.
NASA is a signatory to the Consultative Committee for Space Data Systems (CCSDS) and follows CCSDS Recommendations in design of its data systems, spacecraft communications, and downlinks. Terra’s data formatting and DAS downlinks followed CCSDS Recommendations.
Terra is a bus for five earth observing instruments:
- MODIS - MODerate resolution Imaging Spectroradiometer (U.S.)
- MISR - Multi-angle Imaging SpectroRadiometer (U.S.)
- MOPITT - Measurement of Pollution in the Troposphere (CANADA)
- ASTER - Advanced Spaceborne Thermal Emission and Reflection Radiometer (Japan/U.S.)
- CERES - Clouds and the Earth’s Radiant Energy System (U.S.)
The Terra DAS modulator accepts Dual Input Direct Playback data of all instruments at 75 Mbps, MODIS instrument Direct Broadcast (DB) data at 13.125 Mbps, Direct Downlink ASTER (DDL) data at 105 Mbps, and Direct Playback (DP) data at 105 Mbps. Depending on the mode it will output a balanced or unbalanced SQPSK (staggered quadrature phase shift keyed) IF (intermediate frequency) signal and LO (local oscillator) signal to the DAS upconverter for X-band transmission at 8212.5 MHz.
Figure 2 (from author’s papers) shows the Terra Space Data Receiver. It receives a 375 MHz IF signal from an X-band to IF downconverter, demodulates it, provides bit synchronization, Viterbi decoding, and resequencing of the recovered I and Q channels into a single stream depending on the mode. Figure 3 (from author’s papers) shows a block diagram of the receiver. Figure 4 (from author’s presentation at Fourth International Conference on Direct Broadcast of Earth Observation Data, University of Dundee June 27-30, 2000) shows the Terra (EOS AM1) DAS downlink modes and Figure 5 shows Terra Direct Access System modes, instruments, data rates, and power (from The Direct Broadcast Service on Office of Earth Science Spacecraft by Charles D. Wende and James C. Dodge Office of Earth Science NASA Headquarters Washington, DC 20546).
We were there, Rick and I, because LM Astro’s Terra program management called, saying that our receiver was not working, that it would not lock up on the DAS downlink. This was the reason for Rick and I making the trip to Valley Forge.
We asked for a demonstration of the problem and they showed us that when the DAS DB/DP was active, connected to the test receiver, that the receiver would not maintain lock. To diagnose the problem, LM Astro provided a digital tape recorded with the output of the spacecraft SFE (science formatting equipment). At our engineering lab I played the recorded data thru a test modulator into a prototype of the test receiver we supplied LM Astro and saw the same results as in the high bay at Valley Forge. See figure 6 (from the author’s papers) for a block diagram of the test setup. (Instead of BERT PN data the taped SFE data fed the Digital Test Set.) A look at the taped digital input to the test modulator gave a hint of the problem.
The SFE, in CCSDS parlance, generates a sequence of Channel Access Data Units (CADUs). See Figure 7 for the format of the CADU, taken from the Direct Access System User’s Guide for the EOS–AM Spacecraft (ICD–107), November 1998, published by Lockheed Martin Corporation, Lockheed Martin Missiles & Space Valley Forge Operations.
Consider the CADUs to be the downlink container for instrument data, overhead information, and telemetry. The CADUs carry Coded Virtual Channel Data Units (CVCDUs) as shown in Figure 7. CADUs can also be Fill CADUs when they carry instrument fill to keep a constant data rate on the downlink when the instruments have no data to forward to the ground. See Figure 8 for the Fill CADU layout. This is also taken from the Direct Access System User’s Guide for the EOS–AM Spacecraft (ICD–107).
When I looked at the digital data stream I saw data artifacts incompatible with achieving carrier lock on a ground receiver. There was random data, of course, but there were also long runs of ones, high level signal, and runs of zeros, low level signal, along with runs of alternating high and low signal levels of equal duration, at half the bit rate, a “dotting pattern”. After differential conversion , i.e. converting the level signal coding, NRZ-L (non return to zero - level), put out by the SFE to NRZ-M (Non Return to Zero - Mark) a run of NRZ-L ones converts to a dotting pattern at half the bit rate, and a run of NRZ-L dotting pattern at half the bit rate converts to a dotting pattern at one- quarter the bit rate. Figure 9 shows an example of NRZ-L vs. NRZ-M line coding.
See Figure 10 below also taken from the Direct Access System User’s Guide for the EOS–AM Spacecraft (ICD–107). It shows the Spacecraft to user Direct Broadcast configuration of the DAS with Q at 4 to 1 power advantage over I. This configuration of the modulators produces USQPSK (Unbalanced Staggered Quadrature Phase Shift Keyed) modulation. Note the differential encoders that convert NRZ-L signaling to NRZ-M in the I, in-phase, and Q, quadrature phase channels. NRZ- M represents a baseband level one with a transition and level zero with no transition, so, as pointed out above a long run of baseband level one data in NRZ-L level coding is converted to an alternating one-zero pattern at one half the bit rate, i.e. a dotting pattern at half the bit rate.
Looking at the Fill CADU in Figure 8 we can see that the fill pattern in the VCDU data zone is an alternating 1 and 0 pattern corresponding to what I saw on the SFE-recorded output tape. This bit pattern and the long runs of ones, high signaling level from the instruments, when passed through the NRZ-L to -M converter would cause significant spectral energy spikes in the carrier spectrum presented to the receiver, specifically at half the bit rate and one quarter the bit rate, interfering with the receiver’s ability to acquire carrier lock. This could have been prevented if the downlink data stream had been randomized.
The CCSDS publishes its Recommendations as a series of color- coded books and uses blue as the color for active, in force Recommendations. Versions of Recommendations that are retired fall into the historical category and receive the designation, silver books. See the CCSDS Publications web page for a breakdown of categories of approved documents. Telemetry Channel Coding blue book from that era, CCSDS 101.0-B-3, May 1992, invoked the need for randomizing the downlink only as a means to aid in bit synchronization by ensuring sufficient bit transitions to aid in bit clock recovery, and allowed the designer of the spacecraft data system to skip on that requirement if “sufficient” bit transitions were assured by other means. There is no recognition in the blue book of the need to assure carrier recovery which is a necessity before demodulation and bit clock recovery. Here is the relevant language from that issue of the recommendation:
6.1 PSEUDO-RANDOMIZER
6.2 INTRODUCTION
In order to maintain bit (or symbol) synchronization with the received telemetry signal, every ground data capture system requires that the incoming signal have a minimum bit transition density (See Ref. [6]).
If a sufficient bit transition density is not ensured for the channel by other methods (e.g., by use of certain modulation techniques or one of the recommended convolutional codes) then the Pseudo-Randomizer defined in this section is required. Its use is optional otherwise.
The presence or absence of Pseudo-Randomization is fixed for a physical channel and is managed (i.e., its presence or absence is not signalled in the telemetry but must be known a- priori by the ground system).
The pseudo-randomizer, if used, is synchronized to the insertion of the Attached Sync Marker, referred to as “SYNC” in the CADU layout in Figure 7. Here is the relevant language and description of the pseudo- random sequence insertion process, again from the blue book of May, 1992:
6.2 PSEUDO-RANDOMIZER DESCRIPTION
The method for ensuring sufficient transitions is to exclusive- OR each bit of the Codeblock or Transfer Frame with a standard pseudo-random sequence. On the receiving end, the same sequence is exclusive-ORed with the received Codeblock or Transfer Frame to remove the randomized pattern and restore the original data.
If the Pseudo-Randomizer is used, on the sending end it is applied to the Codeblock or Transfer Frame but before convolutional encoding. On the receiving end, it is applied to derandomize the data after convolutional decoding and codeblock synchronization but before Reed-Solomon decoding, if used.
The configuration at the sending end is shown in Figure 6-1.
When I reported my findings to LM Astro Terra management they were skeptical and launched an investigation at VP level but they finally agreed that the downlink data stream had to be randomized. However they had a problem in that the spacecraft had already completed thermal/vac testing and no hardware changes were permitted, and to randomize the CADU stream in accordance with the blue book recommendation could only be done with additional hardware. However they did have off-board programming access to a programmable logic device where they could instantiate a PN sequence generator exclusive-ORed with the VCDU data unit zone in the CADU.
This less than perfect outcome can be seen by taking a close look at the CADU and Fill CADU from ICD-107, figures 7 and 8 respectively, and noting that the VCDU Data Unit Zones of both are labeled as “randomized”. (Note that ICD-107 was written and published after this change was made to the spacecraft.) With this partial randomization the receiver was able to acquire carrier lock and demodulate, synchronize, and decode the I and Q bit streams of the downlink but at the cost of non-compliance with the CCSDS Recommendations.
The author worked with individuals at NASA Goddard and sub panel 1B of the CCSDS to have the PN randomization requirement strengthened and recognize its importance to carrier recovery but it was not until the October, 2002 issue of the Telemetry Channel Coding blue book, CCSDS 101.0-B-6, that language was inserted recognizing that randomness or lack thereof of the data stream can impact carrier recovery, though not stated explicitly.
In order to ensure proper receiver operation, the data stream must be sufficiently random. The Pseudo-Randomizer defined in this section is the preferred method to ensure sufficient randomness for all combinations of CCSDS- recommended modulation and coding schemes. The Pseudo-Randomizer defined in this section is required unless the system designer verifies proper operation of the system if this randomizer is not used.
Note that the Telemetry Channel Coding 101.0 series of blue books was discontinued and superseded in 2003 by the TM Synchronization and Channel Coding series of blue books, 131.0. In the first edition of the 131.0 series, CCSDS 131.0-B-1, September, 2003 the following note was added:
NOTE – Problems with telemetry links have been encountered because this Pseudo-Randomizer was not used, and sufficient randomness was not ensured by other means and properly verified.
The two statements presented above, added to Telemetry Channel Coding blue books in 2002 and 2003 merely hint at the issues inherent in a downlink connection that does not randomize the data. It was not until the August, 2011 issue of CCSDS 131.0-B-2, CCSDS Recommended Standard for TM Synchronization and Channel Coding, that specific language was added about avoiding spectral lines in the received carrier spectrum. This is from section 9.1 of that issue, Pseudo-Randomizer Overview:
In order for the receiver system to work properly, every data capture system at the receiving end requires that the incoming signal have sufficient bit transition density (see recommendation 2.4.9 in reference [5]), and allow proper synchronization of the decoder. The incoming signal must also be free of significant spectral lines, and be free of patterns that interfere with codeword synchronization and validation (see 2.2.2).
Conclusion: The LM Astro designer of Terra’s SFE stated to me that he thought he had done what was necessary for a functional downlink by incorporating differential coding in the I and Q channels’ SQPSK modulated data link. Indeed he was adhering to the intent of the Telemetry Channel Coding blue book of the time, 101.0-B-3, issued May, 1992, with regard to assuring the downlink would have sufficient transition density to allow ground bit synchronization. But the writers of the 1990s-era recommendation for telemetry channel coding had a blind spot for carrier recovery which must occur before demodulation and bit clock recovery (bit synchronization). So the SFE and DAS designer had adhered to what was an insufficient requirement.
CCSDS eventually came to understand that carrier recovery (carrier lock) is a necessary first condition in establishing a ground terminal connection to the spacecraft downlink. In the case of Terra, though, the insufficient requirements for a functioning downlink led to the workaround described earlier where only the VCDU data was randomized rather than all of the CADU exclusive of the Attached Sync Marker.
This had unfortunate and wide ranging consequences. Why? Because the MODIS instrument functionality of Terra was designed for Direct Broadcast, meaning that the instrument’s observations were continually being broadcast to the ground and anyone around the world could set up a MODIS Direct Broadcast receiving site to capture MODIS data from local flyovers.
If Terra was the only satellite providing direct broadcast functionality it wouldn’t be so bad that its downlink characteristics deviated from the CCSDS Recommendations, but it is not the only satellite providing MODIS Direct Broadcast. Its sister ship, Aqua, originally named EOS PM, also incorporates a MODIS instrument and provides a direct broadcast of its MODIS data. The Aqua downlink does follow the CCSDS suggestion to use the PN Pseudo-Randomizer for randomization of its downlink rather than relying solely on differential coding, and thus all of the CADU is randomized except for the attached sync marker. So a MODIS Direct Broadcast receiving site, and NASA estimates there are over 150 around the world, has to incorporate two approaches to recovering the broadcast data. The implications are illustrated by the following description of MODIS downlink CADU processing published by the Dundee Satellite Receiving Station at the University of Dundee in Scotland:
Packet Format
The CADU packets are transmitted with several layers of encoding. Terra and Aqua use RS (Reed-Solomon) encoding and PN (Pseudo-Noise) encoding but only Aqua abides by the CCSDS recommendations. Terra does not PN-encode the VCDU primary header, only the VCDU data, whereas Aqua does both. Terra data needs to be RS decoded before being PN decoded, whereas Aqua, which follows the CCSDS recommendations, is the reverse.
This is a clear indication of the dangers of writing requirements, or in this case, recommendations, as CCSDS calls them, without having a complete understanding of the subject matter. In this case the author of the Telemetry Coding blue book was familiar with the necessary requirements of transition density to achieve bit synchronization but not with the effect of concentrated spectral energy in the transmitted carrier spectrum on the ability of the receiver to acquire carrier lock. The differential coding used to guarantee transition rich signaling to aid in bit clock recovery produced spectral artifacts that prevented carrier lock.
