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.

  • 16
    $\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
    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
    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
    Aug 8, 2019 at 22:23

3 Answers 3


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
    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
    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$ Aug 8, 2019 at 9:22
  • 8
    $\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$ Aug 8, 2019 at 15:57

The Voyager spacecraft are not reprogrammed anymore, so the language in which they are programmed is largely irrelevant.

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.

This pdf 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 the core program on the CCS (Computer Command Subsystem) is not changed during the mission.

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


Your Answer

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

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