Voyager Status, What is it? Options

[stevesliva]

Oh, I'm not taking any truck with it, just wondering about particular players. And actually surprised that I came up 0/3 on, well, obituaries for those three, and I was looking for that mainly to get a sense of when they'd have stopped being involved in things. All retired in the 90s, maybe. But I dunno.

It sort of describes the shape of the problem to me. Because it sure looks like a fix will mean changing to FDS firmware, and how lost to history that process might be. So here's hoping it doesn't.

Oh, and maybe I can square my prior "internal redundancy" comment with the Ars report that 1 of 2 FDS on V1 is dead-- your text does say the processor could address memory in either unit. So the system is semantically two intertwined units, one of which is dead on V1. So some higher level block diagrams might call that intertwined unit "the FDS" which internally has lost some redundancy.

[Floyd]

I did sort of glean that the "registers" might simply be specific words in the memory, and "bad register" might be what means the other FDS was abandoned. Which might make a bad bit in a register harder to work around vs. like it was in a specific word of instruction memory like in the hard error in 1985. Yes, there are other registers, but rewriting that much of the code...

The Voygers were launched in 1977 and their computers date to the pre Intel microprocessor era. The 8080 came out in 1974 and had 7 8 bit registers. The 8085 came out in 1976 and also had only 7 key registers. The 8086 came out in 1978 and had about 14 registers. What the registers do in each of these computer is explained in Wikipedia. Registers are specific memory locations often with very specific functions such as stack pointer, program counter, status register flags and a limited number of Main register. Most every instruction in 8080 and 8085 code referenced registers A thru E. If one of these registers died, you don't just rewrite your program using the 4 remaining registers. A register was the accumulator, so used in math operations. You lose any of the registers and you are dead. Someone who know how many registers were in the Voyager computer can speak up, but I assume it was no more powerful than the early Intel chips and had similar limitations. My first 8080 computer had 16 K of 8-bit memory. Programs usually occupied 4-8 K leaving 8 to 12 K of memory (minus 2K for screen memory).

I'm 77 and did machine programing for these chips in the late 1970's and early 1980's. Anyone with better memory of early computers please correct my misstatements.

[mcaplinger]

The Voyager FDS was designed several years before the first microprocessors. It has some unusual architectural features, including 128 general-purpose registers (mapped from the main RAM and not as separate logic entities) and a six-clock basic instruction cycle operating on 4-bit values per clock.

I'm not sure how the Voyager team is proceeding. If I were faced with this problem, I would try to build the smallest possible software load that would send useful telemetry to the transmitter. And to support that, I would build a software simulator of the system and make sure the behavior of existing loads was understood. The FDS memory (8K, I think) is loaded through the CCS, so it should be possible to experiment a bit with new FDS loads without the possibility of bricking everything, assuming of course that the CCS keeps working.

[stevesliva]

What I gathered from Ars was simply that they're going to try to command it into "encounter mode" or some such other modes. Which make sense, try that before software reload, see what happens.

Floyd -- the very long PDF linked by mcaplinger above has lots of details, including that tidbit about the massive amount of registers. The images basically look like the "8K" memory is probably something like 256 discrete CMOS ICs -- making each 32 bits, so if each register is 4bits, maybe there are 16 chips for the "registers" and 240 for the rest of the memory. All that to say -- the reason the registers are mapped from "main" memory is because the MPU itself is a collection of discrete ICs on a huge board with probably hundreds of SRAM ICs... the memory bottlenecks aren't analogous to CPUs.

In any event, if there really were 128 x 4 = 512 bits of registers over 16 separate chips, simple programs probably don't need to use all 128. So I was thinking a bad register would be hypothetically easy to work around, esp since there's not image processing happening. There is some text on page 187 of the PDF about how DMA instructions take the same time that all other instructions take... or I don't quite follow. Probably the biggest distinction between the regs and the other memory words was that the regs were addressable with 7 bits of a 16-bit instruction, while the memory addresses were 4k/16=8bits? So separate instructions were needed to access the "lower 4k" instruction memory vs. upper 4k scratch vs. upper 4k scratch in other unit? Also not clear to me how a 16-bit memory word would load into 4-bit registers, but this is a special ISA, so perhaps 4 registers load at a time. The other thing indicated is that arithmetic would be slow... a several cycle operation because it was doing 4-bits a cycle. Perhaps a more common operation was to simply forward along specific ranges of data, or MSBs, etc.

All that to say, a bit flip in one of the registers shouldn't be more fatal than a bit flip in instruction memory... just even harder to work around at this stage, because you have to change and reload the firmware. And sure, if a 16-bit word has to load into 4 registers, maybe there are effectively 32 and not 128 registers, when it comes to programs loading from memory. But 32 --> 31 should still be manageable.

[mcaplinger]

if each register is 4bits

I don't think the registers are 4 bits, I think the ALU does arithmetic 4 bits at a time on presumably 16-bit registers. This is called bit-slicing and was a fairly common design technique at the time: https://en.wikipedia.org/wiki/Bit_slicing

[Doug M.]

So, does anyone have a prognosis here? How likely does it seem that we'll get Voyager back?

[MahFL]

So, does anyone have a prognosis here? How likely does it seem that we'll get Voyager back?

My gut feeling, is sadly no.

[mcaplinger]

So, does anyone have a prognosis here? How likely does it seem that we'll get Voyager back?

I wouldn't count the team out, but not being able to get any useful debugging telemetry back makes it much harder to diagnose than the last problem. And it's not clear they have the resources it would take to either recreate the problem on the ground or start over with a new FDS software image.

[Doug M.]

I wrote a post on the situation here: https://crookedtimber.org/2024/02/19/death-lonely-death/

Written by a non-technical person for a non-technical audience, so please be kind to any errors.


Doug M.

[mcaplinger]

Nice post, but I feel compelled to nit-pick a little, sorry.

This is a problem NASA long since solved. These days, every space probe that launches, leaves a perfect duplicate back on Earth. Remember in “The Martian”, how they had another copy of Pathfinder sitting under a tarp in a warehouse? That’s accurate. It’s been standard practice for 30 years. But back in 1977, nobody had thought of that yet.

They had all of that for Voyager, they just don't have it today, probably because the hardware died and couldn't be repaired. Missions I've worked on (MGS for example) have been severely challenged late in the mission to keep those resources going. The situation has been improving, but I wouldn't call it "solved". And it is rarely if ever a "perfect duplicate" -- on MGS our MOC ground hardware was a bare circuit board mounted to a big sheet of plywood. The spacecraft simulator is usually what's called a "flatsat" -- a collection of boards on tables or in racks, hardly a complete spacecraft.

And good luck finding any of that Pathfinder hardware even today, much less in the near future of "The Martian". All of that stuff was likely scrapped shortly after the mission ended.

[Tom Tamlyn]

What about the Pathfinder models that JPL occasionally trots out for "group portrait" photo ops to show the evolution of Mars rovers from, e.g., Pathfinder to Perseverance? Are those dummies without the electronic innards?

[mcaplinger]

What about the Pathfinder models that JPL occasionally trots out for "group portrait" photo ops to show the evolution of Mars rovers from, e.g., Pathfinder to Perseverance? Are those dummies without the electronic innards?

Pathfinder wasn't a rover, do you mean Sojourner?

It's possible that they still have a working flight-like Sojourner, maybe. But the last time I saw it in person actually driving was nearly 20 years ago now.

[Tom Tamlyn]

<groan>

Naturally I meant to refer to the Sojourner component of the Pathfinder mission.

A few ... well, quite a few years ago, Doug Ellison put up some interesting posts on twitter showing how he had borrowed a Sojourner-shaped object from JPL and taken it into his home shop, to spruce it up for a JPL open house.

I guess it's unlikely to have been a drivable model.

[djellison]

The only flight-like rover testbeds in the wild are Marie Curie (Sojourner testbed rover, at one point destined to fly on the cancelled 2001 lander) and 'Dusty' ( MER testbed ) which are both now at the Air and Space museum. There were others 'driveable' MER and Sojourner testbeds that were significantly lower fidelity - more like the 'Scarecrow' rover used for Perseverance and Curiosity. The Perseverance and Curiosity Vehicle System Test Beds are both in the garage at the Mars Yard at JPL. Perseverance and Curiosity also share an avionics testbed (MSTB) which is more analogous to what testbeds are usually like for missions that are not rovers/landers - the 'flat-sat' Mike mentions above.

This is Marie Curie, Dusty, and Maggie - the Sojourner, MER and MSL testbeds...
https://mars.nasa.gov/resources/3792/three-...s-in-mars-yard/

I don't know if Voyager has an equivalent to the MSTB functioning right now. I would be surprised if it does. I will say, keeping our testbeds up and running is VERY non-trivial. Having spares to fix them when things break gets harder and harder with age - and can reach a point where it's simply not possible to get the parts to do it. Older missions get parts poached from their testbeds in support of newer missions etc etc. If there IS a Voyager testbed, I suspect in terms of technicians certified to maintain it or operate it, the engineer trained by the engineer trained by the engineer trained by the engineer who built it probably got laid off 2 weeks ago.

[Doug M.]

Nice post, but I feel compelled to nit-pick a little, sorry.

I would have expected nothing less!

They had all of that for Voyager, they just don't have it today, probably because the hardware died and couldn't be repaired. Missions I've worked on (MGS for example) have been severely challenged late in the mission to keep those resources going. The situation has been improving, but I wouldn't call it "solved". And it is rarely if ever a "perfect duplicate" -- on MGS our MOC ground hardware was a bare circuit board mounted to a big sheet of plywood. The spacecraft simulator is usually what's called a "flatsat" -- a collection of boards on tables or in racks, hardly a complete spacecraft.

Really! TIL.

And as for Voyager... they just tossed it? I mean, Voyager's not that big, and storage is cheap... But on the other hand, 46 years is a very long time, I guess.