Does the Voyager team use a wrapper (Fortran(77?) to Python) to transmit current commands?

Question

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

• Here's a very good summary of the current software team of the Voyager missions

• Here's another brief mention of exactly what programming language was used

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

FORTRAN TO PYTHON

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.