OFJ Field Journal from Charlie Sobeck - 11/17/95
EXTENSION OF THE PROBE SYMBOL STORAGEThings keep moving fast on this project! It's certainly exciting, but it can also be very frustrating sometimes.
From our Probe perspective, watching JPL deal with the tape recorder problem has been interesting, but it didn't involve us directly. In fact, during the early part of this ... 'incident' ... I was doing my civic duty by serving on a jury in municipal court (we convicted). What did affect us though, was the extension of Probe symbol storage.
What is Probe symbol storage? Well, about three years ago or so, when we first found that the Orbiter's big antenna was stuck and that we would have to record the Probe data for later replay, we realized that we were entirely dependent on the tape recorder working properly. If it were to fail, we would lose all the Probe data! We couldn't send it back to Earth in real-time without the big antenna, and there was no place else to store it except on the tape recorder. So we scratched our chins and thought about it a bit, and came up with an idea.
The spacecraft has the tape recorder to store data temporarily, while it waits for an opportunity to send it back to Earth. The size of this tape recorder is rather large, much like a hard disk on your computer. But the spacecraft also has a relatively small amount of random access memory (RAM) which is uses to store its software. Again, just like your typical desktop computer. Now, the full set of Probe data is about 4MB (megabytes), which fits easily onto the tape recorder. But the Orbiter's RAM is only about 0.4MB. How could we get around this?!
Well, as it turns out, much of the full Probe data set is overhead. That is, it's coding that helps the data get to the ground cleanly, and information about the quality of the radio signal received from the Probe. If this overhead is stripped away (with the result that what's left is more prone to having errors in it), the data actually being sent from the Probe is only about 0.3MB. Would this much fit into RAM? Certainly the RAM was large enough, but there still had to be room to store the spacecraft's software. Eventually, we found that we could fit about half of this stripped Probe data set, or 147KB (kilobytes) into the spacecraft RAM. We refer to this as Probe symbol data because it consists of only the symbols (coded bits) actually transmitted by the Probe, without all the overhead. Although this was only about half of the data that the Probe would be sending, it was by far the most important information. Of course then the spacecraft CDS software engineers still had to figure out away to do all this data stripping onboard the spacecraft, but it was eventually accomplished and we could relax.
"There!" we said to ourselves. "Certainly the tape recorder will work just great, but even if something goes terribly wrong with it, we have our most important data backed up!"
Of course, then came October 11th and the Great Tape Recorder Snafu.
Immediately we decided that trusting the tape recorder may no longer be the wise thing to do, and we looked to see if there was anything else that could be done to improve the Probe data backup.
The thing that helped us here was that with nobody trusting the tape recorder all of a sudden, the mission management decided to scrap all the science observations that were planned to be done as Galileo neared Jupiter. All these observations were supposed to be accomplished by software stored in the RAM, and the results would be stored on tape to be read out through the RAM. Since this software was no longer needed, and since the tape recorder would not need to use the RAM for a while, we suddenly found that there was more RAM available to store Probe data. Our original plan was to store both "strings" of Probe symbols in RAM for 31 minutes, and then only one "string" for an additional 8 minutes, getting us down to 39 total minutes (the Probe sends two simultaneous streams of data, or "strings," up to the Orbiter). Now an extra 61KB was suddenly available and we were able to store even more Probe symbols--now we could save up to 72 minutes on a single string.
Once again, however, it's the implementation that made it all interesting!
Storing the data is one thing, reading it out is another. At first blush, having all this RAM for storage makes things easy. In fact, too easy! After changing Galileo's software to allow us to store some original data, we found that another planned change will write over some of the RAM that we will have just stored, erasing it. So this data has to be moved to another part of RAM before it's overwritten. And with RAM now so full of Probe data, there's not much left for everyone else. So a high priority in January (after the spacecraft comes back around from behind the Sun) will be to read out some of the Probe symbols, and send them back to Earth and free up the memory.
This week we've been struggling with the question of how to tell whether or not the symbols have been read out successfully before we overwrite them, because we don't want to write over any data until we're absolutely sure that it has been safely read out. The strategy right now is to read out the symbols three times, and then compare the three read outs. We will do a vote of best two-out-of- three on each bit of data: if two of the readouts agree on a value, and the third readout disagrees, majority rules, and we'll assume that the third readout was wrong. But there will likely be some cases where we will have an "outage" (we don't get the data for some reason, e.g. the spacecraft's signal is too "noisy" for the Deep Space Network antennas to receive properly) and not get the third read out. And then we'll find that there is a disagreement between the two bits we do have, so now what do we do?. These are the kinds of details we are working on right now.
But this problem will be resolved soon. The issues that are still looming up ahead are the timing of the data, and all the arrangements for the actual work in December. Getting close now!!!