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.
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.
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."
Thanks! My primary source for this was Carl Sagan's book "A Pale Blue Dot" IIRC — don't have the folder in front of me to double check, but fairly certain.
Edit: found it!
Here's the excerpt. According to Sagan they sent these instructions up. Given his details on what had to be done to boost the signal upload, it sounds like this really did happen:
"...while taking a photograph of a street scene from a moving car.
This may sound easy, but it's not: You have to neutralize the most innocent of motions. At zero gravity, the mere start and stop of the on-board tape recorder can jiggle the spacecraft enough to smear the picture.
This problem was solved by sending up commands to the spacecraft's little rocket engines (called thrusters), machines of exquisite sensitivity. With a little puff of gas at the start and stop of each data-taking sequence, the thrusters compensated for the tape-recorder jiggle by turning the entire spacecraft just a little.
To deal with the low radio power received at Earth, the engineers devised a new and more efficient way to record and transmit the data, and the radio telescopes on Earth were electronically linked together with others to increase their sensitivity. Overall, the imaging system worked, by many criteria, better at Uranus..."
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 really enjoyed it! Actually read it to my kids as a bedtime book, and although it was pretty advanced for them, they really stayed with it. Really too bad he's not around anymore.
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.
You're drawing a semantic distinction that doesn't really exist. Insurance for retirement, retirement funding -- it's all the same thing.
A 100% equities (or 100% Enron) portfolio is not the only or best option available to the SSA. And the SS portfolio can't be panic-sold by the individual retiree in a market downswing. Using equities to achieve some additional upside for SS in one way or another is plausibly a reasonable idea.
> 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, ..."
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...