After more than four decades in space and having traveled a combined 44 billion kilometers, it’s no secret that the Voyager spacecraft are closing in on the end of their extended interstellar mission. Battered and worn, the twin spacecraft are speeding along through the void, far outside the Sun’s influence now, their radioactive fuel decaying, their signals becoming ever fainter as the time needed to cross the chasm of space gets longer by the day.
But still, they soldier on, humanity’s furthest-flung outposts and testaments to the power of good engineering. And no small measure of good luck, too, given the number of nearly mission-ending events which have accumulated in almost half a century of travel. The number of “glitches” and “anomalies” suffered by both Voyagers seems to be on the uptick, too, contributing to the sense that someday, soon perhaps, we’ll hear no more from them.
That day has thankfully not come yet, in no small part due to the computers that the Voyager spacecraft were, in a way, designed around. Voyager was to be a mission unlike any ever undertaken, a Grand Tour of the outer planets that offered a once-in-a-lifetime chance to push science far out into the solar system. Getting the computers right was absolutely essential to delivering on that promise, a task made all the more challenging by the conditions under which they’d be required to operate, the complexity of the spacecraft they’d be running, and the torrent of data streaming through them. Forty-six years later, it’s safe to say that the designers nailed it, and it’s worth taking a look at how they pulled it off.
Volatile (Institutional) Memory
It turns out that getting to the heart of the Voyager computers, in terms of schematics and other technical documentation, wasn’t that easy. For a project with such an incredible scope and which had an outsized impact on our understanding of the outer planets and our place in the galaxy, the dearth of technical information about Voyager is hard to get your head around. Most of the easily accessible information is pretty high-level stuff; the juicy technical details are much harder to come by. This is doubly so for the computers running Voyager, many of the details of which seem to be getting lost in the sands of time.
As a case in point, I’ll offer an anecdote. As I was doing research for this story, I was looking for anything that would describe the architecture of the Flight Data System, one of the three computers aboard each spacecraft and the machine that has been the focus of the recent glitch and recovery effort aboard Voyager 1. I kept coming across a reference to a paper with a most promising title: “Design of a CMOS Processor for use in the Flight Data Subsystem of a Deep Space Probe.” I searched high and low for this paper online, but it appears not to be available anywhere but in a special collection in the library of Witchita State University, where it’s in the personal papers of a former professor who did some work for NASA.
Unfortunately, thanks to ongoing construction, the library has no access to the document right now. The difficulty I had in rounding up this potentially critical document seems to indicate a loss of institutional knowledge of the Voyager program’s history and its technical origins. That became apparent when I reached out to public affairs at Jet Propulsion Lab, where the Voyagers were built, in the hope that they might have a copy of that paper in their archives. Sadly, they don’t, and engineers on the Voyager team haven’t even heard of the paper. In fact, they’re very keen to see a copy if I ever get a hold of it, presumably to aid their job of keeping the spacecraft going.
In the absence of detailed technical documents, the original question remains: How do the computers of Voyager work? I’ll do the best I can to answer that from the existing documentation, and hopefully fill in the blanks later with any other documents I can scrape up.
Good Old TTL
As mentioned above, each Voyager contains three different computers, each of which is assigned different functions. Voyager was the first unmanned mission to include distributed computing, partly because the sheer number of tasks to be executed with precision during the high-stakes planetary fly-bys would exceed the capabilities of any single computer that could be made flyable. There was a social engineering angle to this as well, in that it kept the various engineering teams from competing for resources from a single computer.
To the extent that any one computer in a tightly integrated distributed system such as the one on Voyager can be considered the “main computer,” the Computer and Command Subsystem (CCS) would be it. The Voyager CCS was almost identical to another JPL-built machine, the Viking orbiter CCS. The Viking mission, which put two landers on Mars in the summer of 1976, was vastly more complicated than any previous unmanned mission that JPL had built spacecraft for, most of which used simple sequencers rather than programmable computers.
On Voyager, the CCS is responsible for receiving commands from the ground and passing them on to the other computers that run the spacecraft itself and the scientific instruments. The CCS was built with autonomy and reliability in mind, since after just a few days in space, the communication delay would make direct ground control impossible. This led JPL to make everything about the CCS dual-redundant — two separate power supplies, two processors, two output units, and two complete sets of command buffers. Additionally, each processor could be cross-connected to each output unit, and interrupts were distributed to both processors.
There are no microprocessors in the CCS. Rather, the processors are built from discrete 7400-series TTL chips. The machine does not have an operating system but rather runs bare-metal instructions. Both data and instruction words are 18 bits wide, with the instruction words having a 6-bit opcode and a 12-bit address. The 64 instructions contain the usual tools for moving data in and out of registers and doing basic arithmetic, although there are only commands for adding and subtracting, not for multiplication or division. The processors access 4 kilowords of redundant plated-wire memory, which is similar to magnetic core memory in that it records bits as magnetic domains, but with an iron-nickel alloy plated onto the surface of wires rather than ferrite beads.
The Three-Axis Problem
On Voyager, the CCS does almost nothing in terms of flying the spacecraft. The tasks involved in keeping Voyager pointed in the right direction are farmed out to the Attitude and Articulation Control Subsystem, or AACS. Earlier interplanetary probes such as Pioneer were spin-stabilized, meaning they maintained their orientation gyroscopically by rotating the craft around the longitudinal axis. Spin stabilization wouldn’t work for Voyager, since a lot of the science planned for the mission, especially the photographic studies, required a stable platform. This meant that three-axis stabilization was required, and the AACS was designed to accommodate that need.
The physical design of Voyager injected some extra complexity into attitude control. While previous deep-space vehicles had been fairly compact, Voyager bristles with long booms. Sprouting from the compact bus located behind its huge high-gain antenna are booms for the three radioisotope thermoelectric generators that power the spacecraft, a very long boom for the magnetometers, a shorter boom carrying the heavy imaging instruments, and a pair of very long antennae for the Plasma Wave Subsystem experiment. All these booms tend to wobble a bit when the thrusters fire or actuators move, complicating the calculations needed to stay on course.
The AACS is responsible for running the gyros, thrusters, attitude sensors, and actuators needed to keep Voyager oriented in space. Like the CCS, the AACS has a redundant design using TTL-based processors and 18-bit words. The same 4k of redundant plated-wire memory was used, and many instructions were shared between the two computers. To handle three-axis attitude control in a more memory-efficient manner, the AACS uses index registers to point to the same block of code multiple times.
Years of Boredom, Minutes of Terror
Rounding out the computers of Voyager is the Flight Data Subsystem or FDS, the culprit in the latest “glitch” on Voyager 1, which was traced to a corrupted memory location and nearly ended the extended interstellar mission. Compared with the Viking-descended CCS and AACS, the FDS was to be a completely new kind of computer, custom-made for the demands of a torrent of data from eleven scientific experiments and hundreds of engineering sensors during the high-intensity periods of planetary flybys, while not being overbuilt for the long, boring cruises between the planets.
It was evident early in the Voyager design process that data-handling requirements would outstrip the capabilities of any of the hard-wired data management systems used in previous deep space probes. This led to an initial FDS design using the same general architecture as the CCS and AACS — dual TTL processors, 18-bit word width, and the same redundant 4k of plated-wire memory. But when the instruction time of a breadboard version of this machine was measured, it turned out to be about half the speed necessary to support peak flyby data throughput.
To double the speed, direct memory access circuits were added. This allowed data to move in and out of memory without having to go through the processor first. Further performance gains were made by switching the processor design to CMOS chips, a risky move in the early 1970s. Upping the stakes was the decision to move away from the reliable plated-wire memory to CMOS memory, which could be accessed much faster.
The speed gains came at a price, though: volatility. Unlike plated-wire memory, CMOS memory chips lose their data if the power is lost, meaning a simple power blip could potentially erase the FDS memory at the worst possible time. JPL engineers worked around this with brutal simplicity — rather than power the FDS memories from the main spacecraft power systems, they ran dedicated power lines directly back to the radioisotope thermoelectric generators (RTG) powering the craft. This means the only way to disrupt power to the CMOS memories would be a catastrophic loss of all three RTGs, in which case the mission would be over anyway.
Physically, the FDS was quite compact, especially for a computer built of discrete chips in the early 1970s. Unfortunately, it’s hard to find many high-resolution photos of the flight hardware, but the machine appears to be built from eight separate cards that are attached to a card cage. Each card has a row of D-sub connectors along the top edge, which appear to be used for card-to-card connections in lieu of a backplane. A series of circular MIL-STD connectors provide connection to the spacecraft’s scientific instruments, power bus, communications, and the Data Storage Subsystem (DSS), the digital 8-track tape recorder used to buffer data during flybys.
Next Time?
Even with the relative lack of information on Voyager’s computers, there’s still a lot of territory to cover, including some of the interesting software architecture techniques used, and the details of how new software is uploaded to spacecraft that are currently almost a full light-day distant. And that’s not to mention the juicy technical details likely to be contained in a paper hidden away in some dusty box in a Kansas library. Here’s hoping that I can get my hands on that document and follow up with more details of the Voyager computers.
The risk in using CMOS memory was well-founded, as it turns out. As far as I know, the CCS/AACS have been happily running for nearly 50 years without a hiccup, whereas *both* Voyagers have lost portions of the FDS in the same timeframe. And in fact, V2’s memory failure happened less than *1 week* before the Uranus encounter and the fix was only deployed __4 days__ before closest approach. V1 at this point has less than half its originally installed FDS memory working.
Great job, even if it’s unsuccessful, following up on the FDS design document. I similarly knew it existed but never went far enough down the rabbit hole to try to contact anyone. The other bit of information that’s currently publicly unobtainable is the actual FDS (and possibly CCS/AACS, not sure) software – people have tried to request that but it’s only available via internal JPL access and not publicly available.
To be fair the software could (and would) be repurposed by bad people to do evil things.
And I know the argument that the information is out there and anyone could do similar maths these days, but I am sure there is still some neat secrets in the code. Small chunks of code that you stare at for hours and eventually it clicks and you think “That was so smart, they saved so much resources doing it that way, I would have never have thought of doing it that way”.
I know that if I dedicated 1 year of my life I could probably make a guidance system that would work in a totally different way. I will not provide any details about how I would approach the problem (I do not want to give bad people good ideas), but my current thinking on a solution would be nearly impossible to do in my self imposed time frame even just 5 years ago.
“To be fair the software could (and would) be repurposed by bad people to do evil things.”
Neither the FDS nor CCS actually do any guidance control. There’s no reason for it to be secret unless you think some nefarious country would, uh, build its own version of the Deep Space Network to like, take out Voyager or something.
The properties of a probe designed to operate harsh radiation environment in deep space is similar (and probably shared some of the same coders) as some mil equipment from that period or before. So even the commands, protocol and handshakes used to transfer data “might” leak unintended information. I honestly do not know, I’m just giving you a possible reason why I suspect that the software is still well protected even today.
Yeah, you’re being too generous, it’s just JPL being JPL.
A lot of the information you’re thinking of – data formats, commanding, etc. – are publicly available, they were published years ago. It’s just the software that isn’t.
Amazing what one can do with captured technology.
https://fstoppers.com/film/how-soviet-union-snapped-first-picture-far-side-moon-captured-air-force-kodak-325971
This grandiose tech safetyism thing has to be another facet of the engineer-as-savior complex.
For me, this is exactly the problem that mankind faces in every aspect of its existence: documentation. I mean, what quality industrial (for example) document can you get from, say, 100 years ago? almost none. Buildings electrical and plumbing layout from 10 years ago? inexisting (at least where I live, in Brazil). And the digital of all that is no different… imagine if Github goes out of service.. boom, no more billions of lines of code, instantly.
Some of us are actually servicing controllers with quality documentation from when the Voyagers were made.
And to be clear the reason why the documentation issue exists for Voyager is just that the user base has a size of 1. Considering they’re exceptionally close to getting the absolute maximum amount of science out of the probes possible, I’d say their documentation procedures were great! Not anticipating that people might be interested in your one-off design 50 years in the future is understandable.
“Not anticipating that people might be interested in your one-off design 50 years in the future is understandable” yes but my point is that somebody someday in the future would require it, and we humans are not collectively capable of supplying it.
Yes, and I don’t agree with that statement for mass-produced things. There are probably regions of the world where that kind of documentation is terrible, but not everywhere.
In fact, in general, electronics documentation from the 60s-90s or so was actually fairly insanely good. For Voyager, it’s just a case of these things being one-offs (well, ‘few-offs’ but you get the idea). Consumer products are definitely worse nowadays, but again, that’s just intended end-use.
The problem of analog documentation not findable online is a thing, indeed. Most of the things we can find are from the 2000s onwards (not taking into account website rot). Many things published in magazines, newspapers, and even research from before are lost, sometimes they exist as scans but they can’t be accessed through text search, and finding them requires going to physical places.
Um, here in Germany, at least, we still have copies/reprints of crystal radio books from the 1920s or so.
But I suppose it depends on point of view, though.
About every nation has copies of national/international documents (books, schematics, news papers) on microfilms.
These are usually being stored in old bunkers, in mountains, mines and other distant places.
The space thing is a bit special, also. Back in the 1960s/1970s amateur satellites and space probes were being built in a garage, so to say.
The people working on those projects took their documents home, whereas they ended up in the attic, the garage etc.
The story of OSCAR-1 or AO-7 was a bit similar, I think. The documents about the satellites weren’t being located at AMSAT HQ, but privately at home of the satellites’ own creators.
But that’s understandable, I think, considering that these early Oscars and and Voyagers were pioneers in their field.
People involved back then couldn’t know how historical important their creations might be.
If they knew, they surely would have properly documented things and had made multiple copies, too.
Finding the elusive “Design of a CMOS Processor for use in the Flight Data Subsystem of a Deep Space Probe.” document sounds like a job for a document bounty hunter. I’m sure Hackerday could post up $100 for the first person to get their hands on it?
….. or get CrapGPT to write one for you ….. Write a technical paper called: “Design of a CMOS Processor for use in the Flight Data Subsystem of a Deep Space Probe.”
That’s one way to make a hundred dollars I guess
I’d chip in another $100 for historical reasons.
But, is there a schematic of the CCS or FDS ? a detailed description of innerworkings ?
Okay, speed issues, but, TTL chips are, and were indestructible. Every logic gate can be made from a NAND gate 7400 chip. Unless the 1976 Mars probe or Pioneer 10 used CMOS chips, I would never risk it on V1 and V2. CMOS bought you more voltage swing (not 4.75 to 5.25VDC like TTL) but scary volatile memory. I would have increased the digital tape buffers and keep TTL. Did Bucket-Brigade delays exist yet, or not until after Veegr1/2 ? Love the D-Shell connectors and Amphenol connectors: Keep It Simple Stupid (KISS). I hope there is a budget to keep a team to document and control the Voyager spacecraft. Engineering was quite the fun craft in the 70’s. Long Live the Voyager twins.
Thank you. Fascinating information.
Somewhere on a website long, long ago, NASA posted a page that had the type of processor, bit width, working memory size, storage size and type as well as what instruments various probes had. Never seen it again & it’s exactly the type of information I’m interested in. Added together with the National Geographic layouts they did for several of the probes and it becomes “Wow!!! They did THIS with THAT hardware?!?”
Hand those out in a computer or robotics club and see what happens. Funny, I started saving copies of interesting stuff I found on the Internet shortly after I couldn’t find the probe document.
I have tended to packrat info away too– having seen many pages and sites just vanish. But one day my drives and l will be gone too.
While Archive.org is seemingly nowhere near as comprehensive in archiving sub directory or even images, l do submit pages to them, just in case. And a good thing too, as I you would be shocked by what Archive has not backed up. I guess all those stupid lawsuits are eating up focus and resources. I have found portions of pages archived but almost no images. I find myself now also submitting absolute URL/paths/links to images to make sure they too, are archived.
This one, maybe…? https://ntrs.nasa.gov/citations/19880069935
Computers in spaceflight The NASA experience 1988 [Leather Bound] https://a.co/d/gF9jJVT
A little late … It’s not a NASA site, but this sounds similar: John Culver’s The CPUShack: “The CPUs of Spacecraft Computers in Space” https://www.cpushack.com/space-craft-cpu.html
After reviewing your write up, which is very interesting, it appears BOX 37 has a lot of additional information which maybe of interest to any software engineer working the fix. Below I found the following in the catalog entry.
Box 37 FF 6 Initial FDS Processor Design.
Box 37 FF 8 Response to FDS Flight Software Design.
Box 37 FF 10 FDS Flight Software Verification Procedure
Box 37 FF 11 FDS Flight Software Verification Procedure, Ref. 10M Voyager: 17.167, same subject, May 1, 1978, Ellis.
Box 37 FF 12 Response to AL 2416, “CDL Verification Test Plan for the FDS JSU EU Dual and Single Processing Program.”
Box 37 FF 13 MJS 77 Spacecraft memory usage: (1) MJS 77 FDS Program Development Priorities.
Box 37 FF 14 FDS Processor Changes Allowing Better Utilization of the Added Memory.
Box 37 FF 15 The New Command Package.
Box 37 FF 16 FDS Programming.
Box 37 FF 17 In-Flight Reprogramming of FDS.
Box 37 FF 18 “Reprogramming” the FDS in Flight.
Box 37 FF 19 MJS FDS Program Sequence Error Protection.
Box 37 FF 20 FDS Processor Changes Allowing Better Utilization of the Added Memory.
Box 37 FF 22 Design of a CMOS Processor for use in the Flight Data Subsystem of a Deep Space Probe.
Box 37 FF 23 Functional Requirement Mariner Jupiter/Saturn 1977, Flight Equipment Computer Command Subsystem Software.
Box 37 FF 24 AACS Fault Protection Proposal.
Box 37 FF 25 The Development and Demonstration of Hybrid Programmable Attitude Control Electronics.
Box 37 FF 26 Guidelines for General Command Format: (1) Proposal MJS77 Spacecraft Flight Software Configuration Management Plan.
Box 37 FF 27 CCS Flight Software Test Plan.
Box 37 FF 29 Clarification of Spacecraft Memory Redundancy Policies.
Box 37 FF 30 CCS-AACS Handshaking or The Case of the Neurotic Computer.
Box 37 FF 31 Preliminary List of MOS Concerns About Spacecraft Software Design.
Box 37 FF 32 Computer Command Subsystem MJS77 Software Products.
Box 37 FF 34 CCS, FDS and AACS Simulation.
Box 37 FF 35 MJS77 Onboard Software Design Team.
Box 37 FF 36 MJS77 Software System Engineer.
Box 37 FF 37 Spacecraft Software System Engineer.
Box 37 FF 38 MJS Software Responsibilities.
Box 37 FF 39 Attitude and Articulation Control Subsystems.
Box 37 FF 41 Voyager Computer Command Subsystem Flight Software Design Description.
Box 37 FF 42 MJS FDS Processor Architecture and Instruction Set.
I may need to renew my library card for this one.
It’s too bad that Box 37 is in the same warehouse that has The Ark of the Covenant.
B^)
But there are top men working on it.
I feel like simply showing up in the flesh would go a long way to getting around this “ongoing construction.” Somebody needs to go digitize it. Anyone nearby?
i will attempt to start a dialog with the library to find out when the collection will be available in person as well as their policies on digitizing the documents… it is a 5 hour drive for me but this is an epic document hoard!
If you need help from a bunch of developers and technical folks in Wichita please look up devICT and email us or join our Slack. There are WSU employees here and many here who could help with in-person communication and digitization as well as just knocking on doors.
is there a link to search some of the other boxes? i am looking for a specific document:
Merwarth, A., Multimission Modular Spacecraft (MMS) Onboard Computer (OBC) Flight Executive Definition, NASA S-700–55, March 1976.
oh wow! it’s in box 35!!!! this is a huge find! is anyone planning to go and scan these?
Set up a crowd funding page to send someone over to scan box 35. I wonder what’s in box 36?
full list is here: https://specialcollections.wichita.edu/collections/ms/87-08/87-8-a.html#listings
Have you readthrough this?
https://researchworks.oclc.org/archivegrid/collection/data/733100114
Voyager Computer Command Subsystem Document Collection, 1967-1977
Jet Propulsion Laboratory (U.S.). Spacecraft Data Systems Section
This is good doc see about the Voyager control system came from. This covers a lot including…
https://www.dropbox.com/scl/fi/m6k2k6mjiq2q6vc511m3m/19880069935_Optimized.pdf?rlkey=8g0uy3uaw7c637mdh31l8qghz&dl=0
There might be another source for that article. WSU lists “Design of a CMOS Processor for use in the Flight Data Subsystem of a Deep Space Probe.” as part of Dr. James E. Tomayko’s collection of NASA documents – but it doesn’t explicitly list him as author.
And there’s good reason to think he’s not. NASA itself hosts a single paper by Dr. Tomayko, Computers in Spaceflight: The NASA Experience at https://ntrs.nasa.gov/citations/19880069935.
This paper references the above CMOS paper in it’s source notes:
40. Interview with John Wooddell, Jet Propulsion Laboratory, May 21 1984.
…
42 . Interview with Don Johnson, Jet Propulsion laboratory , May 16 1984;
Undated at the time, [John] Wooddell thinks he wrote the “Design of a CMOS Processor
for Use in the Flight Data Subsystem of a Deep Space Probe” in 1974, which
makes sense as the development process lasted from 1972 to 1974.
43. J. Wooddell, “Design of a CMOS Processor,” pp. 2-3, files of J. Wooddell.
… in other words, you might try contacting JPL to see if they still have that paper on hand, if you haven’t done so as of yet!
Also, there’s a much higher quality scan of the FDS hardware package at https://books.google.com/books/content?id=KbIFcxOqKosC&pg=PA181&img=1&zoom=3&hl=en&ots=VkLoyfRm7_&sig=ACfU3U0HPoqQoOUKU8jLLcdctjr02S2Gow&w=1280
What is that Google link part of? It had no option to turn pages.
Try https://www.google.com/books/edition/Encyclopedia_of_Computer_Science_and_Tec/KbIFcxOqKosC?hl=en&gbpv=1&dq=%22The+Flight+Data+System+hardware+in+its+package%22&pg=PA181&printsec=frontcover
You can thank me for the low-quality PDF of Tomayko’s report! When NASA posted the report as a PDF around the beginning of this year, the PDF was about 500 MB in size! I submitted a request that they at least warn about the size on the download page and they substituted the lower-quality 35-MB optimized version now there.
Prior to the PDF at the beginning of this year, Tomayko’s report was available as a hierarchical set of pages on NASA’s history website. They’re now gone unfortunately, but they’re archived at the Internet Archive. Here’s a link to the archived Table of Contents; from there you can get to the different chapters. https://web.archive.org/web/20230320180447/https://history.nasa.gov/computers/contents.html
Regarding the CMOS paper and such … When you read old academic papers about Voyager from JPL personnel, the papers often cite internal JPL documents, just like the late Dr. Tomayko did. Bummer!
“Uptime 15,364 days – The Computers of Voyager” by Aaron Cummings:
https://youtu.be/H62hZJVqs2o?si=jiRE0Gw5MvYichCU
It seems as if most of this article either relies on the Aaron Cummings video, or they both used many of the same source materials.
What I want to know about is the stabilization system. The article mentioned thrusters firing. How is there still fuel after 50 years? How much longer will the fuel last? How often do the thrusters fire?
There’s very little fuel. You don’t need much, since it’s mostly going to be using a tiny puff at a time to slowwwwwwwlyyy alter attitude. It got its speed from the rockets and then the gravity slingshot assist from Jupiter. But I do think they were ready to burn more fuel than ideal, should they need corrections entering the Jupiter system.
I happened to meet the JPL engineer, while out at JPL for a conference, who calculates the fuel required for thruster maneuvers of Voyager 1 and 2. We both hail from Wichita, co-incidentally.
Upshot: The RTGs will decay to a level insufficient to run the radios before the fuel runs out. At that point, game over.
Is the rate of decay known? Since it has a long way to go to get to the nearest star JPL may be planning to accelerate it with the last command.
*Extremely* well known. But the fuel remaining wouldn’t do crap to accelerate it anyway. Years ago you would’ve actually said “plus the thrusters being used are just the attitude thrusters, the trajectory thrusters haven’t been used in decades” but they actually started using the trajectory thrusters for periodic attitude adjustment a number of years ago to give the attitude thrusters a break.
The frustrating thing figuring out when Voyager will run out of power is that the engineers are stupid conservative with the “minimum power” level. All the documentation says “200W min” (well, 200W V1, 198W V2) to run the radios, but then the team comes out and says stuff like “stretch goal of reaching 2035” at which point the power levels will be way under that. They keep buying bits and pieces of power by turning off heaters and giving up regulation – all of those things are risky, but they don’t seem to have done anything bad yet.
At nominal usage the hydrazine would last through the 2040s (if there was power!) but unlike the RTGs that’s harder to predict: the attitude thruster efficiency decays over time (hence using the trajectory thrusters) so the hydrazine usage will increase over time. If they really can reach 2035 using weirdo power tricks they haven’t talked about, then the hydrazine limits start to come into play, too.
Excellent sleuthing and write up. You’re spot on about losing legacy knowledge about Voyager and other systems. I had hoped that NASA was doing a better job these days, but given the effort and dearth of details around the James Webb’s FDS, I am not hopeful.
Looking forward to any additional you uncover and publish.
BTW: I have heard the name FORTH mentioned in conjunction with Voyager’s computers, but never found any documentation to confirm it.
>JjV<
“I kept coming across a reference to a paper with a most promising title: “Design of a CMOS Processor for use in the Flight Data Subsystem of a Deep Space Probe.” ”
i’ve been searching for a number of documents related to NASA’s computing projects. a while back when Hubble went offline, i started digging around for more info about it’s computers. while some details are available, a wide range of references documents are no where to be found. one specific one i would really like to find is: https://hackaday.io/project/180467-nasa-standard-spacecraft-computer-1-nssc-1/log/194538-in-search-of-a-document
as a side note the Hackaday staff: a good write up on Ann Merwarth would be interesting!
https://hackaday.io/project/180467-nasa-standard-spacecraft-computer-1-nssc-1/log/194542-ann-merwarth
I do recall this…. Even I’m not a programmer neither a scientist, just an enthusiastic of science, I do recall this news:
https://www.theverge.com/2017/12/2/16727690/nasa-voyager-1-trajectory-correction-maneuver-thrusters-first-time-37-years
Amazing, still fire-up!!
My two cents…
best tape decks in the universe.
Is this the ultimate tape delay unit?
I worked on that mission. Goddard sent me out to JPL to swap jobs with a guy who came back to GSFC.
I knew the 3 computer types inside and out. It blows my mind that they are still working, still sending back good data (from outside out solar system). Before I left, my boss said, “try not to break anything.: And, I didn’t.
This is a brilliant and understated comment! We know aspects about the Honeywell computers they’re related to, but it’s still hard to find complete information on the instruction set. Do you have it?
Somehow this leaves me with a sense of vindication for having spent 40 years of my life as a technical writer. I remember once so documenting the design of a big, complicated device of a new type in Silicon Valley in the 1980s. After the engineers os various dispersed specialities has finished their part they were all scratching their heads as fo how to turn the monster machine on. So I handed them the Operating Manual I had written after getting information from all of them.
The real unsung hero of the electronics is a properly made solder joint! The most common component on a PCB. One 16 pin DIP = 16 solder connections. That’s 16 points of failure! Without the solder connection, everything is just a bunch of discreet, loose components waiting to be brought to useful purpose. The connection is EVERYTHING! NASA has the highest soldering requirements, bar none.
And yet if you read their standards document their acceptance criteria are surprisingly lax, which goes to show all the internet experts who get incredibly heated about these things (also solder Vs crimp) need to calm down.
Probably wave soldered using a nitrogen blanket and functionally tested multiple times to verify functionality, then conformal coating of the PCB’s and potted. The engineering to accommodate the cold temperature extremes is absolutely amazing…
I posted the link to the Wichita collection as part of a lengthy, url and physical address heavy comment for a Voyager computer-related post back in December, mainly in the hope someone(s) local to the sites might take the bait. But, after the comment was nuked the second time, I took the hint that I might have been going overboard.
> Note the D-sub connectors for inter-card connections
Now that’s a long-lived technology, given we are still using those on new equipment with no signs of stopping.
“The plated wire storage” meybe anybody can create similar memory and put it to arduino or similar?
As always Dan your articles are excellent you’re fantastic writer and a great journalist I enjoy writing your pieces and really enjoy learning the things that you communicate quite well. That would be a nice Segway into the new 3D laser pulse storage onto Crystal medium and the instantaneous reading of those for long term long-term storage. It was Japanese to begin with if I remember correctly from the research paper I read and then it was acquired by a few other companies or they came up with their own different enough that it’s not a patent or intellectual property violation but more or less is the same idea you use the 3D space within or lattice basically within a very durable crystalline Crystal medium and you can store an enormous amount of data on the different layers as long as the reader is able to quickly and accurately decode the data by quickly scanning through the various layers which I assume would be nothing more than a very precise camera sensor hooked up to like a microscope plan so it’s just quickly goes through each they are picking up the marks left by the laser. This actually reminds me so much of cure reform tablets of all things and given that those things have been the most enduring forms of communication next to either etching into rock or art painting in caves. We all thought that the compact disc and various other iterations of that we’re going to be the long-term archival storage, which they could be if the company’s didn’t make them with such poor quality and actually made them archival and with the ability again and the foresight to use a three-dimensional lattice. But I was actually thinking of making some nicely made a very strong ceramic tiles and allowing a person to put whatever they want on there and whatever format be it Morse code going to make any language binary hex or whatever you like and Laser engrave it into two sides of a crystal strengthened and perhaps even I wish some graphene added for strength into a new form of for a newer form of basic ceramics and then fire it up and harden it or harden it and then etch it whichever way it would work out I would have to test it. Then load them into a especially made cubesat that could survive the max q and then deploy a solar cell or do some gravitational assists to send it out into space. I mean it might have to be something more than just a one you cubesat it might have to have some more additional features perhaps a propulsion element navigation and it would be really cool if it had a self-orienting high game set of experimental antennas to allow for communication back to our big blue and green and sometimes brown big ball which isn’t so big compared to everything else in our solar system.. it would also be nice to have some cameras on there that actually don’t activate until they get to the heliopause and in the art Club in addition to having people submit ideas for mapping and surveying the arts cloud and the heliopause as it passes through them and put it on the fastest possible trajectory using the most cutting edge quick propulsion technology that someone submits as one of the trial form factors with redundant systems of course if have failed. It would be really nice to have a community based space probe or set of space probes that we send out in various directions loaded with peoples most important contributions that they wish to contribute as representing humanity be at art a computer program math whatever they want and sell those to help fund the project and also have it be a test bed for new technologies coming out of the universities all of whom are developing new systems to give him a try and actually have them on one maybe even 16u microsat sized probe but as long as we could get a ride share certification and funding a community Pro with the instruments we would like on it and cameras we would like on it that we could actually receive with our own dishes and radio gear and even perhaps a laser receiver. The data should be made immediately available to the public as it comes in real time and no filtering no interruption by the various space agencies as they like to control absolutely everything that humanity discovers and space before humanity gets to see it. Not only would that go a long way in promoting interest in space and space programs but it would do a lot to quiet all the conspiracy theorists out there when you can go to your local club or someone who has a larger see your one of the old version of the geosynchronous satellite dishes and actually be able to receive the data or have it absolutely real time streamed to the public on questionably.. why they didn’t Reserve power or think about cameras just to see what I hit the heliopause was like the art cloud and maybe interstellar space is just black but I’d like to know that….. Why is it that the space station she’s in the governments think like that they have this exclusivity to the data that comes from our taxpayer money?
In
In my experience to build something as spectacularly successful given the technology available needs a few people with great skill and vision. Is there any record of who they are and is there anywhere they are given the massive credit they deserve?
On the NASASpaceflight forum, this thread (https://forum.nasaspaceflight.com/index.php?topic=9476.0) contains a lot of useful information on the Voyager computer systems.
> There was a social engineering angle to this as well
There is also a software engineering angle to all that: If you manage to split a project into many independent small parts, the software engineering effort is reduced. In my early days, I did a “should take a year and a half of programming effort” in 12 weeks by splitting almost everything into reasonably independent chunks that could be “done in a day”.
So for example by giving the AACS team a clear assignment the “2x half the project” can be done in less time than if you keep looking at it as “one project”.