I assume that the vast majority of the people who created the software for these missions are now retired (the "space pensioners" of the Voyager mission).

But in the last 40 years of progressive development, programming languages have advanced a lot. Once, the Voyager team had over 200 employees, now there are 8 (here's a very good audio article about the Voyager Team, here is a summary).

After all, the two probes were programmed with Fortran and Assembler. In the space probes themselves, General Electric's ancient processors do their work. They have to make do with a 64 kilobytes of memory (this interview explains that they are 64 kB, not less as some claim).


Interestingly, there is a Fortran wrapper in Python (more info). Is this or a similar solution used by the Voyager team?

It would certainly be a possibility to adapt the aging source accordingly. Whether the Voyager team uses Fortran 77, or C, or wrapper for both, I couldn't see that yet. There the information is simply still too spongy.

  • 18
    $\begingroup$ It ought to be possible: the question is why would you do it? F77 is an easy language to learn and work with (as long as the original authors of the code didn't use things like assigned & computed GOTOs from earlier FORTRANs), much easier IMHO than Python. $\endgroup$
    – jamesqf
    Commented Aug 7, 2019 at 22:36
  • $\begingroup$ I'm certainly no expert in this, but I am a software engineer. I would suspect that the needs to call a Fortran module from Python code would be something needed on the ground, not in space. I doubt the spacecraft is running Python. Why? Perhaps to allows unit testing of the Fortran code, with all the goodies that come with Python available for use. Or, there could be routines in Fortran to process spacecraft data, and it's easiest to use these unmodified, but then take advantage of the available Python libraries for processing. Just a guess, TBH, though... $\endgroup$
    – Steve
    Commented Aug 8, 2019 at 18:25
  • $\begingroup$ Who's claiming less than 64 kB? Wikipedia seems to claim more: 32 kwords at 16 to 18 bits per word. $\endgroup$
    – pipe
    Commented Aug 8, 2019 at 22:23
  • $\begingroup$ I think the most relevant answers are those by Ludo and Alex Measday because a) the "commands" themselves are short strings of bits there is no relationship to any well known language, only a command list and b) the on board "computers" could more easily have been programmed in assembler or even just be elaborate finite state machines that wouldn't qualify today even as micro-controllers let alone as a "computer". $\endgroup$
    – Puffin
    Commented Jun 7 at 11:09

4 Answers 4


In 2015, the last original Voyager engineer still on the project, retired. NASA specified that his replacement would have to know FORTRAN.

The software was updated regularly after launch:

The last true software overhaul was in 1990, after the 1989 Neptune encounter and at the beginning of the interstellar mission. "The flight software was basically completely re-written in order to have a spacecraft that could be nearly autonomous and continue sending back data to us even if we lost communication with it,"

The configuration of the spacecraft changes regularly: turning off instruments to reduce power requirement, and both spacecraft switched from using their attitude control thrusters to their trajectory correction maneuver thrusters. I don't know whether these changes involve new code, of if they're done just by uploading configuration files. I suspect code changes are involved (because of the small amount of memory available).

New programming languages would introduce new risks and would require extensive testing. It'd be cheaper to keep using Fortran rather than create a new build environment.

  • $\begingroup$ Certainly an aspect, but the question also regarding the saving of equipment and adaptation with regard to economical use of resources, must one also take modern paths ? Do you adapt the development? And what processes and possibilities are there? $\endgroup$
    – Mornon
    Commented Aug 7, 2019 at 13:43
  • 1
    $\begingroup$ Other issues that speak for programming natively in Fortran would/could be: performance (is a Python code converted to Fortran equally performant as natively written Fortran) and inspectability (how well does Python translate to Fortran? Would people be able to fully inspect the Fortran code resulting from the conversion?) $\endgroup$
    – Dohn Joe
    Commented Aug 8, 2019 at 8:22
  • 1
    $\begingroup$ @DohnJoe I don't think anybody would propose trans-compiling any Python code to Fortran for this purpose. (That's no doubt possible today as well, but dynamic languages like Python are a pretty bad starting point for this, especially if you want hard performance guarantees.) As I understood the question, it was just about using a wrapper of (standard, interpreted) Python around the existing Fortran routines, to make top-level scripting easier without changing anything about the performance-critical low-level code. That is an approach which makes lots of sense in many applications. $\endgroup$ Commented Aug 8, 2019 at 9:22
  • 11
    $\begingroup$ "The flight software was basically completely re-written" - that must have been a pretty terrifying deployment! No one wants to be the guy who bricked the Voyager probe... $\endgroup$ Commented Aug 8, 2019 at 15:57

The Voyager spacecraft are still being patched as of 2023.

The uplink is only 16 bits/second, just enough to send (simple) commands. How these commands are generated is irrelevant to the spacecraft. Any language that can generate a sequence of bits theoretically suffices.

NASA's 1981 Voyager Background document describes on p. 11 fairly detailed how commands are issued to the Voyager spacecraft by sending discrete commands. However, it also describes how commands can be relayed to subsystems, and it's not entirely clear to me if such subsystems can be reprogrammed. In any case, on p. 18 it states that for the Computer Command Subsystem (CCS), "Half of each memory stores reusable fixed routines that do not change during the mission. The second half is reprogrammable by updates from the ground." A 1988 NASA publication says "Both the CCS and Flight Data System computer have been reprogrammed extensively. No less than 18 loads were uplinked to Voyager l during its Jupiter encounter."

That being said: Fortran is still actively used and developed (the latest standard is from 2018), so to maintain a Fortran source base is definitely not impossible even after 40 years, so it's not hard to imagine they just use the same ground station software as back then.

  • 1
    $\begingroup$ Comments are not for extended discussion; this conversation has been moved to chat. $\endgroup$
    – called2voyage
    Commented Aug 9, 2019 at 0:46

I didn't work on Voyager, but can tell you that deep-space missions tend to retain the original ground hardware, software, language, and build environment, both for continuity/safety as well as budget reasons. There may be little or no funding to continue the mission; it may even fall to outright volunteers. It's amazing and sad to me how much we depend on this dynamic for long-term stewardship, and the people who do it are true heroes.

One person who I'm glad to be able to give a shout-out to, because it's already public knowledge, is Larry Kellogg, who put in the effort to stay in contact with Pioneer 10 -- I ran into him at NASA Ames in the late 90's, and was amazed when I realized what he was managing to accomplish: http://lkellogg.vttoth.com/LarryRussellKellogg/

In the case of Voyager, any remaining funding or other resources that do come along would be best spent doing exactly the same thing. If someone wants to work on it badly enough, they will take the time to learn the idiosyncrasies of the spacecraft -- language is normally not the gating factor.


The Voyagers' onboard flight software was written entirely in assembler, not in Fortran; see Voyager and Fortran 5 for more details. The ground system control and analysis software used in the 1980s by Suzanne Dodd (the interviewee in your Popular Mechanics link) ran on a Univac mainframe and was written in Fortran V. This software was later ported to Fortran 77 and then C, etc., etc. as the ground system software was moved to minicomputers and then Unix workstations or PCs. The actual flight software running on the onboard computers has always been written in assembler. As other replies and comments note, you really don't want to mess with the software running on spacecraft around 15 billion miles away by switching programming languages! :)

There were 6 computers on each probe: two command computers (CCS), two attitude control computers (AACS), and two flight data handling computers (FDS). The two computers in each pair could operate in a primary/backup configuration or in parallel. The two CCS computer (previously used on the Viking orbiters) were built by General Electric, as you point out. The AACS computers were modified CCS computers; I don't know if GE made the modifications or if JPL did. The FDS CPU was designed at JPL, so there would be 2 or 3 assembly languages depending on whether or not the AACS modifications affected the CCS instruction set.

Regarding memory, the ~64KB figure is misleading. That's the sum total for all 6 computers. Also, that's the byte equivalence of total RAM and implies a greater number of addressable data units than is actually the case. As @pipe noted, the CCS and AACS were 18-bit computers, the FDS was a 16-bit computer, and the RAM was structured for these word sizes:

 CCS computer - 4,096 18-bit words =  73,728 bits =  9.2Ki bytes
AACS computer - 4,096 18-bit words =  73,728 bits =  9.2Ki bytes
 FDS computer - 8,192 16-bit words = 131,072 bits = 16Ki bytes
Total = 34,816 bytes x 2 for primary/backup computers = 69,632 bytes

So 69,632 bytes total for all 6 computers, but only 32,768 addressable memory units. Each CCS and AACS CPU could only address 4,096 instruction and data units; i.e., all the code and data for the CPU had to fit in 4,096 words of RAM.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.