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.

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

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.)

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...

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!

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."

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

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

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.

"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.)

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.)

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.

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, ..."

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 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!

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.