Facebook

I worked at JPL from 1991 to 1993 on the SIR-C mission http://southport.jpl.nasa.gov/sir-c/ I quit at the end of '93 because I was frustrated with the hardware problems we were having, the endless schedule slips, and the feeling of working on a treadmill with no end. Still the project moved forward and was ready for launch in April 1994. (Perhaps I gave up too soon; I do tend to get impatient that way...) They invited me back to the Lab to watch the launch on April 9. As luck would have it, the hardware that I had been continually cursing over the years failed within a couple minutes of being activated. This item was called a DQA "Data Quality Analyzer" and it was the interface that all the digital data from the Space Shuttle had to pass through to get into the ground data systems. That failure meant that all of the Shuttle data was going to be lost and the mission would be a complete failure, and JPL would have egg on its face in the international aerospace community. Anyway, I told my former boss "I told you that hardware is junk. I can bypass it, feed the raw data directly into the GDPS computer and demux it in software." Everyone else in the Lab said "that's impossible, no software can be fast enough for that, that's why we have specialized hardware in the first place." The data was in a special compressed format; fortunately I also happened to be an expert in data compression (my ARC archiver/compressor program from 1988 is still in use all around the world, in fact. http://sourceforge.net/projects/arc/ ). I read the data specification in about 10 minutes and wrote a program to decode it in about 20 minutes. It worked perfectly on first try, and we started receiving the Space Shuttle data. (If you look at the mission statistics http://southport.jpl.nasa.gov/sir-c/html/mission.html you'll see that 90-some percent of the data takes were successfully acquired. Several of them vanished into the bitbucket while I was figuring out the spec and writing the code, oh well.) The code I wrote went on to be used in several Shuttle missions after that, SRTM and some other projects, and was the trigger for subsequent missions dropping the custom hardware completely from their designs.

By the way, this was seriously bleeding edge stuff, all the hardware in use was running at data rates no one else had ever attempted before (45 megabits per second, from earth orbit to ground) and it generated data volumes that would bring most of the computers of that day to their knees. It was a near thing to be able to do this in software at all, the transfer and computation consumed something like 95% of the hardware's available bandwidth. The actual computer interface was only capable of running at about 24 megabits per second, so sucking it in in compressed form was the only viable approach. The margin for error was pretty much nil, one extraneous instruction and it would all be for naught, the computer would be overloaded and the data would pile up and then be lost forever.

I got a cool Special Achievement certificate from NASA and the President for my work there. Nobody talks about it outside of NASA I suppose, because basically it's the story of someone else's f#ckup, but so it goes. At JPL they still talk about how I wrote realtime processing code, in realtime. No one else in JPL history has done anything like it. (Or anywhere else in the world, for that matter.)