Galileo’s main antenna jammed on its way to Jupiter, leaving a small antenna that could manage about 10 bits per second instead of 134,400, so NASA rewrote its software and rebuilt how Earth listened - Make Tech Easier

In April 1991, NASA’s Galileo spacecraft was a year and a half into its journey to Jupiter when it ran the commands to open its main antenna. Minutes later, telemetry showed that the motors had stalled. The 4.8-meter, umbrella-shaped dish had only partly unfolded, and it never fully deployed.

Without that antenna, Galileo’s best remaining link to Earth was a small low-gain antenna that could carry only a tiny fraction of the planned data. What followed was one of the more inventive rescues in spaceflight: engineers rewrote the spacecraft’s software to edit and compress its data, rebuilt how Earth listened for it, and replanned the science around a far smaller data budget.

The antenna that wouldn’t open

Galileo’s high-gain antenna was built like an umbrella, with a wire mesh stretched over 18 ribs. It was designed to stay folded behind a sunshade while Galileo swung past Venus, then open once the spacecraft was far enough from the Sun. When the command came, it didn’t open fully. Engineers analyzing the telemetry concluded that 3 of the 18 ribs were stuck to the antenna’s central tower, according to JPL’s 2002 technical account of Galileo’s communications.

NASA’s 1995 Jupiter arrival press kit blamed friction in the ribs’ pins and sockets after a dry lubricant was lost, most likely shaken off during cross-country truck trips before launch. Over the next few years the team warmed and cooled the antenna by turning the spacecraft toward and away from the Sun, and “hammered” the deployment motors by switching them on and off more than 13,000 times. They spun the spacecraft up to 10 rpm and tried again. Nothing freed the ribs.

How small the pipe became

The opened antenna was designed to send data at up to 134,400 bits per second, which the press kit described as roughly one image a minute. Galileo’s low-gain antenna broadcasts in a much wider, weaker beam. NASA compared it to the difference between a spotlight and a bare bulb: the signal reaching Earth was 10,000 times fainter. Without any improvements, the press kit said, the low-gain antenna could manage only 8 to 16 bits per second from Jupiter.

To put that in perspective, an uncompressed image from Galileo’s camera was 800 by 800 pixels at 8 bits each, about 5.1 million bits. By our arithmetic, sending one at 10 bits per second would take almost six days, and that’s before any other instrument or engineering data got a turn.

Galileo’s computers made the problem harder. A 1994 JPL report described them as late-1970s designs, with 8-bit and 16-bit microprocessors and a total memory of less than 1 MB. Whatever software engineers sent up had to fit inside that.

Four fixes that added up

The rescue plan, which JPL called the S-band mission, was formally approved and funded in January 1993. No single trick was enough, so the plan stacked several gains on top of one another:

- Onboard editing and compression. New flight software, loaded in stages in 1995 and 1996, let Galileo cut and compress data before sending it.

- Stronger error correction. A more powerful coding scheme let the ground recover data from a signal that would otherwise be too weak and noisy.

- Bigger “ears” on Earth. NASA combined signals from up to six radio dishes, including antennas at Canberra and Goldstone and the 64-meter Parkes radio telescope in Australia, and fitted the Canberra 70-meter dish with a quieter receiver.

- Replanned science. Galileo recorded data from each close moon flyby onto its tape recorder, then spent the rest of each orbit editing, compressing and sending it home slowly.

Those fixes worked on two different problems: how fast bits could travel, and how many bits each observation needed. JPL’s technical account estimated that the communications improvements would lift the average rate about tenfold, and compression would add roughly another tenfold gain in useful information:

Compression did not make the radio transmit any faster. It reduced how much data Galileo needed to send. Before arrival, NASA expected the reworked mission to meet at least 70% of its original science goals. JPL’s 2002 technical account says the expected gains were achieved and that the orbiter completed 70% of the original primary mission’s objectives.

Error-correcting codes add carefully structured redundancy so the receiver can fix bits damaged in transit. On the ground, Galileo’s data was decoded in up to four passes, with blocks recovered in one pass helping to decode others in the next.

Compressing images without multiplying

Most of the data Galileo collected was images, and images compress well. The method JPL chose, described in a 1993 paper by JPL engineers Kar-Ming Cheung and Kevin Tong, was an integer cosine transform (ICT), a close relative of the discrete cosine transform behind the JPEG format.

Both work the same basic way. The image is cut into 8-by-8 pixel blocks, and each block is rewritten as a mix of simple patterns, from smooth gradients to fine stripes. Smooth areas need only a few patterns to describe them. Then the encoder rounds off the fine-detail patterns that matter least, which is where the savings and the losses come from.

A standard cosine transform requires lots of multiplication by awkward decimal numbers, which was expensive for Galileo’s processors. The ICT swaps those numbers for small integers that are powers of 2 or the sum of two powers of 2. A computer can multiply by 8 by shifting a binary number three places, and multiply by 6 by adding a value shifted twice to the same value shifted once. That’s how the transform avoided multiplication, using only shifts and additions. Cheung and Tong reported that its results were indistinguishable from a standard cosine transform.

To see what that rounding costs, we took a 320-by-320-pixel patch of a Galileo image of Europa’s Conamara Chaos region and saved it at several JPEG settings. Uncompressed, it is 100 KB. At about 11 to 1, fine texture begins to soften. At about 34 to 1, the 8-by-8 blocks show and small craters blur. At about 75 to 1, the ridges are still visible but most of the surface texture is gone.

Deciding what could be lost

Lossy compression had traditionally been avoided on deep-space missions, the 1994 JPL report noted, because each image is irreplaceable. Galileo’s scientists needed a way to decide how much loss was acceptable before the spacecraft started throwing information away.

Part of the answer was to ask them directly. In a 1994 NASA study, 15 evaluators from 12 institutions involved in Galileo’s camera experiment viewed pairs of compressed images side by side and rated how useful each would be. The study found no single acceptable compression ratio across the tested images. Scene content and simulated radiation noise, the kind of speckling Jupiter’s harsh environment causes, changed how much compression evaluators considered useful. A fairly uniform dark scene tolerated about 85 to 1. In the most extreme case, adding simulated noise cut the acceptable compression for one image from 57 to 1 to less than 3 to 1. The results fed into customized compression settings for different kinds of images.

The team also built in safeguards:

- Truth windows. Scientists could mark a 96-by-96-pixel area anywhere in an image to be sent without lossy compression. That preserved a key detail and gave them a reference for checking how faithful the rest of the image was.

- Error containment. Compressed data is fragile, because one lost packet can corrupt everything that follows. Synchronization markers every eight image lines limited error propagation and allowed decompression to resume at the next marker.

- Editing. The software could drop less valuable data, such as the dark background of space around a moon, before compression.

Scientists were wary of after-the-fact cleanup, too. JPL’s technical account says they worried that standard techniques for smoothing out blocky artifacts might make images “look better” while distorting the details they needed to measure. The restoration methods Galileo used were constrained to stay within the range of values the original data could have had.

What made it through: evidence for an ocean beneath Europa

Galileo began sending compressed images and data from Jupiter orbit in 1996. Looking back, NASA says the software strategies helped “salvage most of the science.”

One of its most important results didn’t come from a camera at all. Galileo’s magnetometer measures the strength and direction of magnetic fields, a stream of numbers that is tiny next to an image. As Europa orbits inside Jupiter’s magnetic field, that field can induce an electric current in anything conductive near the moon’s surface, which in turn creates a weak magnetic field of Europa’s own.

The direction of Jupiter’s field at Europa changes predictably. During a January 2000 flyby, it pointed the opposite way from earlier passes in 1996 and 1998. UCLA’s Margaret Kivelson and her team predicted that, if a conductive layer such as salty water existed beneath the ice, Europa’s induced field should flip too. Galileo’s measurements matched that prediction. Project scientist Torrence Johnson called the magnetometer data “the only indication we have that there’s an ocean there now,” while noting that the evidence was still indirect.

Galileo couldn’t send everything, so the team had to decide in advance what each bit was worth, from 96-pixel truth windows to dark sky that could be thrown away. A failed antenna turned the mission into an exercise in priorities. Among the results returned through that narrow link were magnetic-field measurements that strengthened the case for a salty ocean beneath Europa’s ice.