A Model Recovery: ESA Engineer Uses MATLAB to Help Save Mission to Titan
By Jack Wilber, MathWorks
On January 14, 2005, one engineer watched nervously as a probe named Huygens began its descent toward Titan, Saturn’s largest moon. Like many of his colleagues on the joint European Space Agency (ESA)-NASA program, systems engineer Luitjens Popken had worked for years to ensure the success of the Cassini-Huygens mission to explore Saturn and its moons. Just weeks before, the Cassini spacecraft had ejected the Huygens probe, sending it coasting toward a parachute landing on Titan to provide scientists with detailed information and dramatic photos of the moon’s atmosphere and surface.
Five years earlier, the team had discovered a critical communications implementation error that could not be remotely corrected. In a few hours, Popken would find out if his efforts to help rescue the mission from potential disaster would pay off. Huygens was about to begin sending data from its cameras and other scientific instruments back to the Cassini orbiter. For the mission to succeed, Cassini would need to receive the data and then relay it back to the engineers waiting anxiously at mission control. “We were hiding in the canteen, watching the broadcast out of the control room,” recalls Popken. “When mission control confirmed that they had received the data, it was a huge relief. We knew we could show ourselves.”
A Problem Millions of Kilometers Away
In the fall of 1997, the Cassini spacecraft left Cape Canaveral carrying the Huygens probe on a voyage to Saturn more than a billion kilometers away. After the launch, engineers at ESA decided to take advantage of the travel time to conduct additional communication tests of the relay-link receiver on Cassini.
ESA engineers conducted the tests in early 2000. The receiver captured and correctly interpreted data during tests that assumed the Huygens probe and Cassini orbiter would maintain the same relative distance during the probe mission. However, other test results were alarming: There was substantial data loss when the tests simulated the crafts’ trajectories and the actual, changing relative-link geometry during the planned descent.
As Huygens descended toward Titan, it would be moving at approximately 5.6 kilometers per second (20,000 kilometers per hour) relative to Cassini. The tests showed that the Doppler shift (see “The Doppler Shift”) resulting from this relative velocity caused a breakdown in communication between Huygens and Cassini that threatened to cripple the entire Huygens probe mission. As the Doppler effect compressed the probe’s radio wave, the length of each bit would shorten and the data rate would increase.
An Error in Implementation
ESA quickly assembled a team of technical experts, including Popken, to analyze the test results, further characterize the performance of the receiver, and gain a deeper understanding of the problem.
The Huygens telemetry receiver was based on a design that had operated successfully on several earlier space missions. That receiver was able to cope with a Doppler shift at data rates of up to 2 kilobits per second (Kb/s). The data rate between Huygens and Cassini, however, was 8 Kb/s—four times faster.
Due to an implementation error, a scaling parameter in the Huygens receiver’s embedded software was not adjusted to accommodate the higher data rate. As a result, the bandwidth of the receiver’s bit synchronizer was too narrow to compensate for the Doppler shift of the data stream frequency. The tests showed that errors, manifested as cycle slips, occurred at specific combinations of three key parameters: link performance in terms of signal-to-noise ratio (Es/No), bit transition density (Pt), and frequency offset (∆fs) from the nominal symbol rate. In turn, these cycle slips caused synchronization detection failures, decoding failures, and ultimately, data corruption (Figure 1).
If mission engineers could not resolve the problem, an estimated 90% of the data from Huygens would be lost.
From Test Results to Understanding
Popken’s task was to develop a model of the receiver that would help him explain the problem and propose strategies to solve it.
Modeling the receiver presented several challenges. The model had to represent a system that was not working as intended. In addition, it had to be transparent in every detail—not only to Popken, but also to his peers. And, of course, the model and the modeling environment had to be 100 % accurate.
Popken modeled the faulty receiver in MATLAB. He reports, “We had to be able to trust the equations and functions we used. I could not use blocks that model the nominal functionality of a receiver—I had to start from scratch. I used MATLAB because I needed to really know, equation by equation, what was going on. With MATLAB I can combine high levels of abstraction with very deep, detailed modeling at the equation level.”
Because MATLAB is widely used in the space industry it was easy to share results with the navigation team, the instrumentation team, and other groups. Popken explains, “MATLAB also enabled reviewers to verify the model and the core issue. It would not have been sufficient to present a black box with some behavioral description and leave it at that level. It was obvious to me from the very beginning that MATLAB was the best suited tool to exchange data, to visualize the data, and to present it in a clear way to many colleagues who had to understand it during the very strict review process.”
Verifying and Calibrating the Model
Popken continued to develop his analytical model of the receiver’s data transition tracking loop (DTTL) during 2000. In-orbit tests in the spring and autumn of that year helped Popken refine and calibrate the model. Using a ground station to simulate Huygens’ uplink signal, the engineering team sent test data to the receiver on Cassini. The tests mapped performance as a function of the critical system-level parameters Δfs, Es/No, and Pt. The team used the test results to compare the actual performance of the receiver with simulation results from the model.
Popken presented the verified and validated model to the Huygens Recovery Task Force (HRTF) in February 2001. The model explained the cycle slips in the bit synchronizer and the resultant data corruption. More important, the model provided the task force with a basis for evaluating possible recovery scenarios.
Finding a Solution
The most obvious solution to the problem was to simply adjust the scaling factor in the embedded software to enable the receiver to accommodate the Doppler shift at higher data rates. In the original receiver design, the scaling parameter in the software could be reprogrammed remotely. This capability would have enabled the engineers to correct the problem in a matter of hours. But this was not possible in the Huygens implementation because many reconfigurable parameters, including the scaling factor, had been frozen to reduce the complexity of the design.
Likewise, attempts to recover corrupted data proved unfeasible, as the relay-link receiver on Cassini would have rejected and discarded a significant portion of the data without relaying it back to earth.
The mission had only one alternative: alter the relative velocity of Huygens with respect to Cassini to bring the Doppler shift of the relay link frequency into the operational range of the receiver.
The mission’s original geometry would actually have maximized the Doppler shift because the probe and the Cassini orbiter were to fly almost in line with each other during the probe’s descent through the Titan atmosphere. The Cassini-Huygens mission team radically revised the relative geometry of the orbiter and the probe during Huygens’ descent. Cassini would fly by Titan at a much higher altitude than was originally planned. As a result, Huygens would decelerate along a path at a great angle to Cassini’s trajectory, instead of being virtually in line with it, and the signal’s Doppler shift would fall into an acceptable range (Figure 2).
The HRTF completed its work in June 2001, leaving the mission team time to plan, test, and implement such drastic changes to the flight geometry.
A Spectacular Descent
To Popken’s immense relief, Huygens began sending dramatic images of Titan during its descent in January 2005. The probe’s cameras snapped more than 750 images and successfully sent 100% of the data to Cassini. After a 2-hour-and-27-minute journey through Titan’s dense atmosphere, Huygens became the first spacecraft to land on a moon in the outer solar system.
Popken’s model was unquestionably vital to the success of the HRTF solution. He notes, “MATLAB played a crucial role in the recovery. The analytical model represented the core input to the redesign of the mission and for the revised relative geometry. Ultimately, it was this recovery that enabled the data to be successfully retrieved from the Huygens probe during its spectacular descent.”
The Doppler Shift
The Doppler shift, or Doppler effect, explains the change in frequency perceived by a receiver that is moving relative to the source of a signal. For example, the Doppler shift causes the siren on an approaching ambulance to have a higher pitch than the siren would have if it were stationary. Likewise, as the ambulance moves away from the listener, the siren will seem to have a lower pitch.
The Problem in Human Terms
A listener’s ability to hear and understand what a speaker is saying depends on a number of factors, including three that are analogous to the system-level parameters that affected the Cassini-Huygens communications link:
- How fast the speaker is talking: bit transition density (Pt)
- The amount of background noise: signal-to-noise ratio (Es/No)
- The proximity of the pitch of the speaker’s voice to the range humans can hear: frequency offset (Δfs)
Like a human listener, the Cassini receiver could not interpret communications that were significantly impaired by these factors. By changing the mission’s geometry, the mission team was able to lower (Δfs) enough to enable 100% accurate communication between Huygens and Cassini.