mek6800d2

Those interested in more information about Voyager's DTR should check out a discussion on the Space Exploration Stack Exchange, "How was magnetic tape decay prevented in Voyager 1?", https://space.stackexchange.com/questions/2053/how-was-magne...

Answers #2 and #4 are by the person who designed the flanges on both Viking's and Voyager's DTRs. (The flange was "designed to absorb resonances created by the clear/transparent belt wrapped around the tape, generated by the movement of the tape drive itself.")

Answer #1 and #3 have useful information and links to contemporary sources that provide more detail about high-tech the recorders were.

Incidentally, Voyager's DTR was mounted so that it's mechanical movements had minimal impact on the spacecraft's pitch and yaw, which I assume means they had the most effect on the roll axis. For the Uranus and Neptune encounters, which required long exposures and panning, finer control of Voyager 2's attitude was implemented, including counteracting even the minimal pitch and yaw effects of the DTR.

The FDS CPU is very RISCy in nature, but it actually has close to 40 instructions! https://forum.nasaspaceflight.com/index.php?topic=9476.msg26...

And it has been compared to the PDP-8 like rahen suggests, although the Voyager computers are built from medium-scale ICs!

They didn't get access to the actual NASA software running in space. They wrote simple example programs to exercise the CPU emulator. The example program that is loaded when you first visit the web page simply counts down from 10.

And having the actual NASA source code would not be very useful, since the actual software interacts with complex hardware on the spacecraft, which you would have to emulate in addition to just the CPU. For example, the FDS computer interacts with all of the scientific instruments, the digital tape recorder, the telemetry output hardware, and the other two computer types on the spacecraft. (I'm not casting shade on the CPU emulator as it is an impressive achievement and the code is very high quality.)

Voyager 1 and Voyager 2 are identical, as are their computers. JPL's Voyager documentation is the property of Caltech, not NASA, and are thus not available via FOIA. People have gotten copies of selected documentation by requesting them from libraries that have copies of the original documents on file.

The 2025 YouTube video is "How We Diagnosed and Fixed the 2023 Voyager 1 Anomaly from 15 Billion Miles Away" by David Cummings of JPL.

There is a Vimeo video of the Voyager team reacting when data first began trickling in from Voyager 1 after the fix in April 2024. "Voyager 1 Team Reacts to Receiving Engineering Data From Spacecraft" (JPLraw channel): https://vimeo.com/939376171

Cummings is the one against the back wall who shoots his two arms up in the air in celebration. He and Armen Arslanian (in the blue shirt to his left, right in the image) developed the software fix.

The slides from Cummings' presentation can be downloaded as a PDF from the Flight Software Workshop Day 2 page, first entry: https://drive.google.com/drive/folders/1BXSBUgEJExsLSE-m585I...

For others, this truly excellent 2016 paper is "Voyager Interstellar Mission: Challenges of Flying a Very Old Spacecraft on a Very Long Mission" by Sun Kang Matsumoto. She was/is a Voyager Fault Protection and CCS Flight Software Systems Engineer (CCS was the onboard command computer) and she was also one of the "stars" in It's Quieter in the Twilight.

Thanks for the excerpt. I read a couple of Sagan's other books many years ago and I really should read APBD sometime.

Interesting to me, Sagan's "little puff of gas" was borne out in the paper I referenced (not that Sagan needed being borne out!) and that the resulting "imaging system worked ... better at Uranus" was something I hadn't thought of. Per the paper, the Voyagers originally had minimum thruster pulse lengths of 10 ms. In the lab and then on Voyager 1, the Voyager engineers figured out that they could reduce the pulses to 5 ms, thus allowing finer control of Voyager 2's attitude at Uranus (and later Neptune) and probably better image quality than at Jupiter and Saturn. Very interesting - I really should read Sagan's book!

I enjoyed your video and it is well done. Unfortunately, I don't think it's true. The Voyager tape drives were similar (if not largely identical) to the earlier Viking Orbiters' DTRs. The Voyager engineers were certainly familiar pre-launch with the motions imparted to the spacecraft by the mechanical movements of the tape drive. The Voyager DTRs were specifically mounted to minimize the effects on the roll axis.

Potential problem were expected and planned for with Voyager 2's flybys of Uranus and Neptune. Because of the long exposures required for these more distant planets, like you pointed out, the engineers had to account for the attitude effects of both (i) the DTR movements and (ii) panning the cameras to keep them focused on a single point while the spacecraft was moving past at high speed. This was especially a problem at Uranus, which is tilted on its side. Voyager 2 was approaching at its north pole; with the plane of the moon's orbits perpendicular to the ecliptic - like an arrow flying into an archery target. As a result of this configuration and Voyager 2's high speed, the high-resolution observations of Uranus and its moons were compressed into a 6-hour period.

These engineering efforts are described in detail in a 1985 paper, "Voyager Flight Engineering: Preparing for Uranus", by W.I. McLaughlin and D.M. Wolff. Abstract: https://arc.aiaa.org/doi/abs/10.2514/6.1985-287 (The full paper can be found online with some effort; doi:10.2514/6.1985-287) Here's a quote from the paper (AACS is the attitude control computer and CCS is the command computer):

   "The DTR is mounted on the spacecraft such that its angular momentum is introduced into the yaw and pitch axes of the spacecraft with almost none going into the roll axis. DSSCAN was first programmed to introduce cancelling momentum in the yaw axis only. The modification to the AACS and CCS software took place in an environment of a scarcity of available memory so that, from a programming point of view, it had to be carefully fit in. The "patch" was carefully tested in the Voyager Capability Demonstration Laboratory (CDL) before loading onboard Voyager 1. (The AACS and CCS programs were modified without being reassembled as is the case with all AACS and CCS changes since launch.) The CDL is a digital/analog simulation of many of the spacecraft capabilities. Modifications or tests of any degree of complexity are done first, whenever possible, on Voyager 1 before implementation on Voyager 2, a reflection of the fact that Voyager 2 still has two planetary encounters scheduled while Voyager 1 has none."

I still remember a very interesting article about him in the Electronic Engineering Times back in 1998: "Boston's Scholz Engineers a Rock Dynasty"

https://web.archive.org/web/19990224204558/http://www.eetime...

"Wherever there's a microprocessor, there's trouble."

Clickbait! If you read the article, there's no gloom or doom.

30 or more years ago (?), Consumer Reports did a report on toothbrushes and they did a follow-up note or article clarifying their recommendation of how often to change toothbrushes. Their recommendation was not because of bacteria as many readers apparently thought, but because the bristles get worn down and don't clean as effectively.

And the "toilet plume"? Is that more of a problem in Britain? Looking back at John Postgate's Microbes and Man (which I read back in the 1990s):

   Few people realize, however, that when a used toilet is flushed, a turbulence and spray of water and excrement is generated comparable to a sneeze: in any toilet one can isolate faecal clostridia and streptococci from the ceiling, walls and door handle as well as around and beneath the seat.  British water closets certainly generate such infectious aerosols; it is probable that the vortex type favoured in the USA, depending on a swirl rather than a splash to flush the closet, is less generous in the matter of dispersing faecal microbes around the room.

(That was written back in the 1990s or earlier; British folks and travelers can obviously provide more current insight than me, who has never traveled outside the U.S.!)

The Galileo hack was indeed incredible. From a post-mission paper:

"Although the primary mission was completed in December 1997, the mission was extended three times to take advantage of the spacecraft's durability with 24 more orbits. The extensions enabled additional encounters with all four of Jupiter's major moons: Io, Europa, Ganymede and Callisto. Galileo flew near a small inner moon, Amalthea, before making a planned mission ending plunge into Jupiter's atmosphere. In total, Galileo had 35 encounters of Jupiter's major moons -- 11 with Europa, 8 with Callisto, 8 with Ganymede, 7 with Io and 1 with Amalthea -- and returned more than 30 Gigabytes of data, including 14,000 images."

The paper is a very readable description of the problem, solution, and end results:

P.A. Jansma, "Open! Open! Open! Galileo High Gain Antenna Anomaly Workarounds" 2011, abstract: https://doi.org/10.1109/AERO.2011.5747657 (The full paper can be found online with some effort.)

With great respect to Doug McIlroy (in the CACM article), the shell pipeline has a serious problem that Knuth's Pascal program doesn't have. (I'm assuming Knuth's program is written in standard Pascal.) You could have compiled and run Knuth's program on an IBM PC XT running MS-DOS; indeed on any computer having a standard Pascal compiler. Not so the shell pipeline, where you must be running under an operating system with pipes and 4 additional programs: tr, sort, uniq, and sed.

McIlroy also discusses how a program "built for the ages" should have "a large factor of safety". McIlroy was worried about how Knuth's program would scale up to larger bodies of text. Also, Bentley's/McIlroy's critique was published in 1986, which I think was well before there was a major look into Unix tools and their susceptibility to buffer overruns, etc. In 1986, could people have determined the limits of tr, sort, uniq, sed, and pipes--both individually and collectively--when handling large bodies of text? With a lot of effort, yes, but if there was a problem, Knuth at least only had one program to look at. With the shell pipeline, one would have to examine the 4 programs plus the shell's implementation of pipes.

(I'm not defending Pascal and Knuth, Bentley, and McIlroy are always worth reading on any topic -- thanks for posting the link!)

Bringing this back to Forth, Bernd Paysan, who needs no introduction to the people in the Forth community, wrote "A Web-Server in Forth", https://bernd-paysan.de/httpd-en.html . It only took him a few hours, but in fairness to us mortals, it's an HTTP request processor that reads a single HTTP request from stdin, processes it, and writes it output to stdout. In other words, it's not really a full web server because it depends on an operating system with an inetd daemon for all the networking. As with McIlroy's shell pipeline, there is a lot of heavy lifting done by operating system tools. (Paysan's article is highly recommended for people learning Forth, like me when I read it back in the 2000s.)

A reminder to everyone: Social Security is NOT a retirement plan, it is an insurance plan. When your 401(k) is cratered by the stock market or your pension goes the way of Enron, SS is supposed to be there to hopefully keep you from being dumped in the gutter. Tying SS to the stock market would not be a smart move.

> Not understanding English from the early 1800's ... I can sometimes more easily understand written Greek, Spanish or French (I don't speak any of those languages) than old English.

Jane Austen's Pride and Prejudice, written in the 1790s and published in 1813, is more difficult to read than 3 languages one doesn't speak?

Yes, a modern reader may not understand a word here and there. I myself did a double take when reading a Victorian mystery novel by T.W. Speight and the detective was discussing his cup of tea while discussing the case. I didn't throw up my hands and stop reading. I understood the general drift of the scene and continued on enjoying the rest of the novel. I later confirmed that "discuss" had an archaic meaning of consuming a food or beverage, but even if I hadn't, I still would have enjoyed the book. And "whiskers" in a Dickens' novel per the article is not exactly a show-stopper.

Padding is perhaps a problem in books (especially when it takes 100-200 pages to get into a novel!), but I see a worse problem online: everyone and their brother gaming the systems (LinkedIn, Substack, Medium, Quora, Reddit, etc.) by posting articles about technical topics about which they know very little and getting the content very, very wrong. Incorrect information which then gets disseminated to countless readers who accept it as the gospel truth and who, in turn, then disseminate it in one form or another to countless others.

The enormity of the flood of information on the internet also makes it difficult to distinguish multiple perspectives, let alone decide which perspectives are credible. The reader has to rely on -- just like with books -- experience and will eventually learn to reach out to respected sources and references.

That's the way it was decades ago. In the mid-1980s, a headhunter cold-called me at work and asked what I did. I answered, "I'm a computer programmer." Sounding severely disappointed, he said, "Oh ... Is there anyone in your office who designs programs?" I responded, "Yes, we all do." I was aware of this mindset from books I'd read in the late 1970s when I first got interested in computers.

In the 1990s, I worked as a contractor at a very large engineering corporation and I was surprised to discover they still had developers who only designed programs down to the pseudocode level and then handed them off to "programmers" for coding. I thought this was stupid as all get out as there was no feedback mechanism in place, so the "designers" never learned of and from their mistakes. (And a feedback mechanism wouldn't be enough in my opinion, as the designers really needed to be mired in the mud of producing a working system.) This was especially serious as some of the programs ran on embedded real-time computers and the designers had no hands-on experience with the real-time OS and would not gain that experience simply through designing.

Experienced programmers do bits at all 4 of the levels without consciously thinking, "I'm doing engineering here, developing there, ..."

This Substack article should not be trusted - there are no sources given. I google'd each of the 4 example satellites and "netbsd" and the only results were the Substack article and people referencing the article. NetBSD may have been used in ground systems, but (i) that would have been a non-story and (ii) I couldn't find any evidence of that, so I wonder where the author picked up this information.

I am most familiar with SAMPEX, which was launched in 1992. The initial release of NetBSD, version 0.8, was in 1993 according to Wikipedia. Okay, the article says the project "transitioned" to NetBSD in the "extended mission". Okay, maybe in the 2000s, let's say they decided to replace the original OS/real-time-executive on a working spacecraft with a new OS. So you abruptly replace the old OS/RTE-based flight software with software based on a new OS/RTE. (You don't gradually transition from one OS/RTE to another.) I don't buy it. On a working spacecraft? No.

(I realize the article was probably AI-generated.)

I came to post the same link earlier. My mind is kind of slow these days and it wasn't until a few hours later that I made the connection with your username. I am not worthy!!! --a long-time reader

@kens beat me to it-I too was going to suggest Ken Shirriff's "Reversing Sinclair's amazing 1974 calculator hack". The page has a Sinclair Scientific emulator that displays the running, underlying calculator chip instructions.

I bought the Sinclair Scientific in 1974 for a physics lab class in college. It was much less expensive than the TI and HP scientific calculators of the time, but it was painful to use in the lab class. I subsequently changed majors, so I only had to bear with it that first year, but, all these years later, I'm still in awe of what Sinclair achieved with it though!

Just to be clear, the computers onboard the spacecraft are programmed in assembly language--3 types of computers on each spacecraft, so 3 assembly languages.

The original ground system was mostly written in Fortran. Mission control (i.e., the thing you see on TV!) ran on IBM 360 mainframes. Offline analysis/design/development activities (e.g., developing observation sequences for planetary encounters) ran on Univac 1108 mainframes. Circa 1990, after Voyager 2's flyby of Neptune, the project began moving off the mainframes onto Unix workstations and the original Fortran software was largely replaced by new software written in C and other languages.

70-meter dish antennas are needed to transmit to Voyager and there is one 70-m dish at each of the 3 DSN stations in California, Spain, and Australia. The Australian station is the only one that can see Voyager 2 and because of the Earth's rotation, that's only for part of the day. Downlink can make use of smaller arrayed antennas (including non-DSN antennas), but I still think they have to be scheduled; i.e., the antennas have to be pointed at the Voyager spacecraft and computer time for ground system DSN processing of downlink data has to be allocated. I don't know for sure though, so you may be right.

I recently started reading Peter Westwick's 2007 book, Into the Black: JPL and the American Space Program, 1976-2004. I've only gotten up into the 1980s so far and I find it a good read. Leadership? Sausage making. Per Westwick, there have always been contentious relations between NASA headquarters, the different NASA centers, JPL, and Caltech. (JPL is a NASA center, but staffed by Caltech employees, and relations between JPL and Caltech themselves are often strained.) At JPL, there were frequent shufflings of people in leadership roles. Add in the politics of the whole thing and trying to get funding from the government. If the Reagan administration had fully had their way, there wouldn't have been Voyager 2 flybys of Uranus and Neptune. Fortunately, many politicians (like Newt Gingrich, of all people!) supported NASA. (Westwick discusses all of this in his book.)

So my impression is that we were incredibly lucky that Voyager worked out so well in spite of its chaotic existence from its earliest developmental stages to now. I suppose there are some leadership lessons, but survivorship bias must be accounted for as many projects didn't make it off the drawing board.

46 hours ... if you're lucky! :) 23 hours for a command to reach the spacecraft and 23 hours more for the spacecraft's response to reach Earth. If you're lucky: the Voyager project has to compete with other projects for antenna time on the Deep Space Network. If they can't get two slots 46 hours apart, they rely on delayed telemetry to verify that a command was received and successfully processed.

Part of this excellent movie revolved around the months-long shutdown of the 70-meter antenna at the Deep Space Network station in Canberra, Australia. Coincidentally, the new JPL press release about Voyager 1's thrusters also details a new months-long shutdown (May 2025-Feb 2026) of that same antenna for more upgrades. It's the only antenna that can transmit to Voyager 2, which flew south of the ecliptic after its Neptune flyby. The DSN stations in Spain and California can still transmit to Voyager 1, which flew north of the ecliptic after its Saturn flyby. (Todd Barber, quoted in the The Register article and in JPL's press release, appears in the movie.)

You're porting in the WRONG direction. The existing COBOL code is undoubtedly using system utilities such as database management systems, etc. on the mainframe computers. And I doubt that you've written Python code that smoothly integrates into that system environment and just needs to be ported to COBOL. And I doubt that the mini-Musks can do so. (I'm not including the massive application-specific knowledge that you and they would or should need to grasp before attempting to insert code into the system.)

Thank you! Perhaps like you trying to get the source code, I was frustrated at the lack of information and began writing a letter seeking more information to Suzanne Dodd, the Voyager project manager. I couldn't find an address to send it to, but I figured "JPL, Pasadena, California" would get it to someone who could look up her mail stop. Fortunately, I didn't need to complete the letter as things began to fall in place thanks to different bits from others on the internet and to some obscure 40- and 50-year-old papers I managed to track down. (I am grateful to the shady websites that host scientific papers for the latter. I understand the concern of professional organizations about preserving their publication rights, but at some point the information is effectively lost.) Thanks again for the kind words!

Dusty Decks? First thing that popped into my head when I saw your name. I bookmarked it on one of my web pages back in 2004. Dang, between that and your other works, a computing rock star in our midst!

Dusty Decks: Preserving historic software https://mcjones.org/dustydecks/

Wow! Thank you! I had dropped out of school, got interested in computers, and returned part-time in 1978, eventually getting my degree in 1981. Although I used the Univacs, I never actually saw them! In 1980-1981, I worked as an undergraduate programmer for Dr. Kanal (pattern recognition and image processing), whose office was a step across the hallway from Dr. Rosenfeld's office (who founded the Computer Vision Lab). This gave me access to the graduate student computing facilities -- no more punch cards, but the extremely diverse array of terminals at that time made me understand the need for Unix's termcap! I also did work on the new VAX they got and Dr. Kanal's PDP-11/Unix in the computing lab, but, not yet being a hacker, I didn't take as full advantage of them as I should have!

Yeah, Goddard was great. I was in Building 28 off and on from 1982-1984 and then in Building 23 from 1994-1996. Good times! Thank you for sharing your memories and your father's.

Author here--thanks for the compliment! I too had never heard of Fortran 5, which is why it kept bugging me every time I heard it mentioned in connection with Voyager over the past few years.

Data General's compiler was "Fortran 5", not V. Univac and Control Data Corporation had their own Fortran Vs, but there was no relation between the two.

I too thought this way and I figured there were probably a lot of engineers who were comfortably well-off and would be happy to relocate and work for free on Voyager.

However, although there would be great emotional satisfaction working on such a unique project (not as great as in it's heyday though), there would not be an equal amount of intellectual satisfaction. Don't get me wrong--the current Voyager engineers are performing amazing intellectual feats. It's just that the project is nursing along the spacecraft in their final few communicating years as the power levels run out. There is probably very little programming done except to work around failing hardware. Non-emergency concerns probably mainly focus on which remaining subsystems to power down and when.

Also, the time frames for operations are really long. I believe some of the current Voyager staff work only part-time on Voyager and younger engineers probably don't want to sit around twiddling their thumbs for a good amount of time while waiting for results. (Neither do older engineers for that matter!) The quote about attracting younger programmers is from Matsumoto's paper; she also gives this account of a 2010 memory problem:

"For example, when the V2 experienced a bit flip in the FDS [computer] in 2010, it took about two weeks to recover enough to receive the engineering data, and another two weeks to receive the science data. It took another four and one-half months to adjust the timing delay caused by the anomaly and resynchronize the CCS and FDS clocks. Realigning the baseline events to the regular schedule had to be delayed even longer due to other activities competing for the resources."

https://arc.aiaa.org/doi/pdf/10.2514/6.2016-2415 (PDF)

We've seen a similar situation more recently with recovering from the failed FDS memory block. So, although enthusiasm is important for a Voyager programmer, patience is a virtue!