[FirmwareBurner]

>NASA engineers are working on a software patch that will order the Voyagers to fire their thrusters less often but for longer periods to maintain their attitude

Anyone got any detailed info on what CPU, software and programming language is used on the Voyager that can support something as "advanced" as OTA software patches?

It was launched in 1977 and since aerospace uses tech older than consumer tech, it probably isn't running anything remotely as advanced as a Z80, 6800 or 6502 which came out only a few years before Voyager was launched.

Any info I found point to a custom 18 bit CPU built out of discrete TTL 7400 series parts which would be period correct, but not much details on how the SW, programming and OTA updates work.

I assume NASA has the full HW-SW stack, compiler, toolchain, version control, plus HW and SW simulators for it so making some of them public would be really cool considering the source code of the moon lander is already public. What do they have to loose?

[sho_hn]

The main CCS computers are a custom 18-bit (not all registers are 18 bit) design from General Electric, used on both the Viking and Voyager missions. The onboard software is mostly in assembly.

There's two of them.

They send software updates fairly regularly (including a nearly full rewrite in 1990) and this is a common question. You can find some statements in older reporting on other updates..

It's in some sense not very exciting. Basically, it's an interrupt-driven system and you can, by radio command, invoke handlers that will rewrite some memory holding the program with new contents and hand control back to other routines. Of course with the expected error handling and failover protections in place. NASA got quite good at it during the Mariner missions, which saw the first remote updates for their programmable sequencers, and by the time of Viking and the CCS, it was a routine part of the requirements.

There's tooling written in Fortran (and later partially ported with C) that supports the Earth-based team in preparing the updates.

The patches discussed in the article are actually for a different type of computer in the system, the AACS (Attitude and Articulation Control Subsystem). But it's similar there: There's redundancy (there's two) and you patch memory contents, do a memory read-out to double check and kick things into gear.

[FirmwareBurner]

>It's in some sense not very exciting.

Well, neither is the Doom source code for most people, but for others it could be pretty cool to read, especially that the moon lander's source code is already public.

[sho_hn]

Don't get me wrong, it's a space ship so of course it's incredibly exciting and no doubt also a career highlight to work on! :)

Just sayin', the OTA part is fairly mundane implementation-wise, flipping bits. The decision to engineer a system around it and have it in the requirements is maybe more audacious. Also, the technology involved with us still being able to radio into these remore devices at all is amazing and the unsung hero here.

Edit: If you go to the FSW section here, you can read a little bit of what amounts to release notes for the onboard software changes:

https://csclub.uwaterloo.ca/~pbarfuss/VIMChallenges.pdf

Includes a cute anecdote about dealing with a randomly flipped bit in memory.

My favorite bit:

"A CCS FSW patch was developed and implemented in 1995, and linked on the spacecraft in 2006 for V1 and 2005 for V2 to automatically restart some of the critical functions in the event of an Error entry. This patch was exercised in flight in 2014, nearly 20 years after it was installed, when one of the CCS processors went into an error entry on V1; the patch worked as designed."

But hey, the Pixel gets 7 years now! :-)

[phlipski]

"as OTA software patches"

Technically it's like 0.0001% OTA and 99.9999% OTVoS (Over The Void of Space).