Author Topic: NASA - Voyager 1 and 2 updates  (Read 303454 times)

Online MickQ

  • Full Member
  • ****
  • Posts: 1027
  • Atherton, Australia.
  • Liked: 276
  • Likes Given: 772
Re: NASA - Voyager 1 and 2 updates
« Reply #540 on: 03/26/2025 05:44 am »
V 1 is now into Madrid at 160 b/sec.

Offline calex

  • Member
  • Posts: 26
  • Maryland, USA
  • Liked: 57
  • Likes Given: 50
Re: NASA - Voyager 1 and 2 updates
« Reply #541 on: 03/28/2025 07:51 pm »
... the software/hardware contractor to build the FDS system and software ...
I assume JPL/Caltech was the contractor for the FDS flight software.  I haven't seen anything about the hardware, but there are probably multiple vendors.  JPL at least designed the CPU and Steven Pietrobon posted earlier about Algorex Data Corporation providing the FDS memory circuits.

The following ArchiveGrid links are inventories of JPL's Viking CCS and Voyager CCS document collections which I came across recently.  They are NOT what you asked for, but they're the type of thing you're looking for as they include paper copies of contract information.  I couldn't find a similar document collection for FDS, but others may have better luck than me.  (To get copies, you would probably have to go through a months-long process similar to Steven's for the FDS CPU paper in order to obtain the documentation.)

* Viking Computer Command Subsystem Document Collection, 1969-1977 Jet Propulsion Laboratory (U.S.).  Spacecraft Data Systems Section

* Voyager Computer Command Subsystem Document Collection, 1967-1977 Jet Propulsion Laboratory (U.S.).  Spacecraft Data Systems Section



The remainder of this message has nothing to do with FDS and is just interesting information I found in the Voyager CCS document inventory:

- Multi-Layer Board (MLB) Subassembly Problem

Failures in initial testing in plated through-holes (PTH) of the multi-layer electronic circuit boards.  Changes made to avoid a problem found in the Viking Orbiter MLBs introduced a different problem in the Voyager MLBs.  The contractor fabricated and tested a new set of MLBs, which were delivered to JPL in April 1977.  (As documented a few items down in the inventory, this affected both the CCS and AACS computer assemblies.)

- Flatpack IC "Rusty IC" Problem

Porous gold used on flatpack integrated circuit "lids" allowed contamination and humidity to cause corrosion.  The contractor refabricated new ICs.

- Plated-Wire Memory Problem

Berylium-copper wire used to make tunnels in the plated-wire memory introduced foreign matter into the tunnels.  The fix was to seal the tunnels (to prevent corrosion by the foreign matter in the tunnels?).  I'm not an expert, so my description may be wrong.  The archive listing does say that problem report also included a comparison with the Viking Orbiter plated-wire memory, but doesn't say whether or not the Orbiter had that problem or if the Orbiter's shorter timeline made the problem moot.  (The Viking document collection inventory mentions an Orbiter plated-wire memory problem at Mars, but it doesn't detail the cause.)

- Name Change

A memo dated March 16, 1977 officially changed the project name from MJS to Voyager (and that the spacecraft numbers would be 1 and 2, not I and II)!

- 3 Spacecraft

VGR77-1 was the Proof-Test Model, VGR77-2 was Voyager 2, and VGR77-3 was Voyager 1.

Plans were made for the Proof-Test Model for two extraordinary cases.  The first case was the Mariner Jupiter-Uranus (MJU) mission.  If Voyager 1 or 2 failed, the other Voyager would be routed to Saturn's moon Titan (a higher priority target) and would then skip Uranus.  The Proof-Test Model would be launched from a Space Shuttle flight in 1980 and it would do the Uranus fly-by.  Fortunately, both Voyagers 1 and 2 didn't fail as the Space Shuttle would not fly until 1981.  The second case was for the Proof-Test Model to be launched from the Shuttle, swing by Mars, and have one or more encounters with asteroids.  (The Proof-Test Model is the one on display at JPL.)



Offline Targeteer

  • Senior Member
  • *****
  • Posts: 7490
  • near hangar 18
  • Liked: 4991
  • Likes Given: 1638
Re: NASA - Voyager 1 and 2 updates
« Reply #542 on: 04/04/2025 03:33 pm »
https://x.com/NSFVoyager2/status/1907749995815567375 NSFVoyager2 @NSFVoyager2 On this day in 1991, my photopolarimeter subsystem (PPS) was turned off due to degraded performance, saving 2.4 W of power.
« Last Edit: 04/04/2025 03:37 pm by Targeteer »
Best quote heard during an inspection, "I was unaware that I was the only one who was aware."

Offline StraumliBlight

  • Senior Member
  • *****
  • Posts: 2798
  • UK
  • Liked: 4618
  • Likes Given: 638
Re: NASA - Voyager 1 and 2 updates
« Reply #543 on: 04/07/2025 03:28 pm »
Keeping Voyager Alive: NASA’s Project Scientist Faces Painful Choices as the Iconic Mission Nears Its End [Apr 5]

Quote
Gizmodo: What are the challenges that come with operating a mission for this long?

Spilker: The spacecraft was built in the 1970s, and so that’s the technology that we had in those days. And we didn’t have very much computer memory, so we had to be very careful and think through what we could do with this tiny amount of computer memory.

So the challenge with these aging components is, how long until a key piece fails? We’re well past the warranty of four years. We also have less power every year, about 4 watts less power so we have to find 4 watts per year to turn off on the spacecraft. The spacecraft had a lot of redundancy on it, so that means two of every computer and two of all the key components. We’ve been able to turn off those backup units, but we’re now at the point where, to really get a significant amount of power, all that’s left are some of the science instruments to turn off. So, that’s where we’re at.

Then, of course, if you have less power, the temperature goes down inside. There’s something called a bus that has all the electronics inside, and that’s getting colder and colder. Along the outside of the bus are these tiny lines of hydrazine that go to the thrusters, so we started to worry about the thermal constraints. How cold can the lines get before they freeze? How cold can some of these other components get before they stop working? So that’s another challenge.

“But we’re hopeful that we can get one, possibly two, spacecraft to the 50th anniversary in 2027.”
Then there are individual tiny thrusters that align the spacecraft and keep that antenna pointed at the Earth so we can send the data back, and they’re very slowly clogging up with little bits of silica, and so their puffs are getting weaker and weaker. That’s another challenge that we’re going through to balance.

But we’re hopeful that we can get one, possibly two, spacecraft to the 50th anniversary in 2027. Voyager’s golden anniversary, and perhaps even into the early 2030s with one, maybe two, science instruments.

Offline calex

  • Member
  • Posts: 26
  • Maryland, USA
  • Liked: 57
  • Likes Given: 50
Re: NASA - Voyager 1 and 2 updates
« Reply #544 on: 04/10/2025 07:01 pm »
In the latest article by Eric Berger:

https://arstechnica.com/space/2025/03/white-house-may-seek-to-slash-nasas-science-budget-by-50-percent/

Quote
Scientists told Ars that NASA would be forced to make difficult decisions, likely including shutting off extended missions such as the Voyager

Ricardo11's early March post about the Trump administration seeking to cut NASA's science budget by 50% was concerning both for the Voyager project specifically and, more generally, for JPL and NASA.  Also, in late March, there was news of the Trump administration, as part of its anti-DEI efforts, launching investigations into the admission practices of Stanford University and of several University of California campuses.  Caltech, the university associated with JPL, might not be far behind.  Universities elsewhere in the U.S.  have complied with the administration because of threatened and actual cuts to government funding.  News in the last couple of days has been about foreign students at California colleges having their visas revoked without warning.

JPL already laid off an eighth of its workforce last year, dropping it down to 5,500 employees (including contractors).  Seeing how indiscriminate large-scale layoffs and spending cuts have been done in other government departments, it's easy to imagine critical infrastructure support for Voyager (e.g., DSN and mission control support) being decimated even if actual Voyager project personnel still have their jobs.

Some of my recent reading shows that this state of affairs, though not as rapid, has been an ever-present problem for JPL for decades.  In "Voyager: The Grand Tour of Big Science", Andrew J.  Butrica makes it sound as if Voyager itself was assigned to JPL to keep JPL alive:

Quote
The decision [on Voyager] to go with JPL versus an industrial contractor was viewed at NASA Headquarters by John E.  Naugle, Associate Administrator for Space Science, as a "many faceted problem" whose resolution was "of paramount importance to the future of NASA's Planetary Program as well as to the future of JPL." In short, JPL needed the contract to maintain employment levels in the laboratory, and NASA Headquarters needed it to maintain the vitality of its planetary program.

Bruce Murray was the Director of JPL from 1976 to 1982.  In the Voyager chapter (PDF) of his 1989 book, Journey into Space, he describes how friends of JPL in the Nixon adminstration in the early 1970s were warning him and others to start looking into military contracts and energy research since NASA spending would be ramping down in the post-Apollo years:

Quote
Things were going less well for JPL as an institution, however.

NASA, JPL's sole sponsor, lacked the presidential political support that it had enjoyed before the Apollo moon landings.  Since then the agency had steadily declined in national clout and technical capacity.  The challenging and uplifting Apollo project had become a glorious, almost mythic, memory for NASA, rather than a gateway to the future.  JPL was NASA's only center not staffed by government employees.  That made it a natural target for elimination in tough times, a circumstance that added to the "creative tension" inherent in the three-sided relationship between NASA, JPL, and Caltech.  Furthermore, JPL had no important role in the post-Apollo focus on the Shuttle and on related uses of astronauts in low-Earth orbit.  In fact, JPL seemed to be on everybody's rumored "hit list", awaiting the next big NASA cut.  Russ Drew [on Nixon's President Science Advisory Council] sometimes dropped alarming hints to me of draconian measures under discussion at OMB that would have eliminated JPL....
The message was clear: NASA, a declining institution, felt it could not support JPL as it had during the halcyon days of the building of America's first satellite, first moon probes, and first planetary explorers.

Unlike my predecessor Pickering, I would thus have a twofold task as director of JPL - to push U.S.  planetary exploration to the hilt and, at the same time, to develop a second governmental role for JPL that would be independent of NASA.  In 1976, following the oil-ptice shocks of 1973, government-supported energy research and development was the best (really the *only*) practical alternative for a high-tech, nonprofit, civilian-oriented place like JPL.

So, on April 1, 1976, my first day as director of JPL, I promoted Bud Schurmeier with great fanfare and with instructions to carve out a meaningful role for JPL in energy R&D.  Neither Bud nor I, as it turned out, would find deep satisfaction in these new strategic responsibilities.  The ebbing of the old Apollo spirit was merging with a broader retreat of American self-expectations in the face of failures in Vietnam and at home.  America would not blaze new paths in either alternative energy or planetary exploration.  But in 1976 we had to try to create the kind of future that JPL, and America, deserved.

Understandably, Murray gives a somewhat rosy view of his years at the helm of JPL.  Peter J.  Westwick adopts a more dispassionate view in his 2006 book, Into the Black: JPL and the American Space Program, 1976-2004.  Most striking to me was the possible cancellation of Voyager operations after the Saturn encounters at the behest of the Reagan administration in 1981:

Quote
But after a month of negotiations between NASA and the White House, on 30 September 1981 NASA directed Murray to stop all work on Halley['s Comet] missions.

The official end of JPL's hopes for Halley came as a jolt to Murray, who spoke bitterly of "Black September".  That was not all.  First, budget cuts on the Centaur project again put Galileo at risk, until JPL designers came up with yet another gravity-assist trajectory to get to Jupiter on the IUS booster.  Then NASA floated a proposal to shut off the Voyager spacecraft, saving $222 million by foregoing the Uranus and Neptune encounters.  It became clear that not just single projects but the entire deep-space program was at stake.  In summer 1981 the OMB cut $1.1 billion from NASA's budget request.  The new NASA administrator, James Beggs, insisted that such a shortfall would require dropping one of NASA's major programs, such as the shuttle, earth applications, or planetary exploration, and requested higher-level policy approval.  But he did offer a suggestion.  At his confirmation hearings in June, Beggs had called planetary exploration "a hallmark of the agency.  It would be a disaster if we gave it up." He now pushed the planetary program on the table as a high-stakes wager in the budgetary standoff, naming it as the first item NASA would be willing to cut.  He again cited the program's value, but he ranked it below astronomy in immediate potential: "the most important missions" in deep space had already been done, and the next phase of landers and sample returns could await the shuttle.  He added, "Of course, elimination of the planetary exploration program will make the Jet Propulsion Laboratory in California surplus to our needs."

(I won't get into it here, but Westwick goes into detail about the decades-long tensions between Caltech, JPL, and NASA, calling the relations "a three-body problem, whose solution proved far more difficult"!)

I don't envy NASA's and JPL's leaders and I imagine Voyager's Project Manager, Suzanne Dodd, is going to be spending a lot of time lobbying on behalf of Voyager, just 2 years shy of the spacecraft's 50th anniversary in space.  (And lobbying on behalf of the DSN, as she is also the director of the Interplanetary Network Directorate.  Incidentally, a couple of days ago, she spoke at an event celebrating the 60th anniversary of the Canberra station joining DSN.)


Offline calex

  • Member
  • Posts: 26
  • Maryland, USA
  • Liked: 57
  • Likes Given: 50
Re: NASA - Voyager 1 and 2 updates
« Reply #545 on: 04/10/2025 07:56 pm »
An interesting tidbit from Andrew J. Butrica's "Voyager: The Grand Tour of Big Science" (1998) I mentioned in my last comment ...

In 1978, Voyager 2's primary command receiver failed completely and its backup command receiver had failed partially, becoming unable to track changes in frequency caused by Doppler shifts of DSN radio signals.  (The shifts are caused mainly by the Earth's rotation moving the DSN antennas back and forth relative to the Voyager spacecraft, although the Earth's orbit and the spacecraft's movements contribute as well.)  In April 1978, the Voyager team successfully tested having the DSN transmitters vary the frequency of transmitted signals to compensate for Doppler shifts so that Voyager 2's backup receiver would see a constant-frequency signal.  That was not the only possible fix though:

Quote
An alternate solution to Voyager 2's radio problem considered by NASA was to send commands through one of the science instruments, namely the planetary radio astronomy receiver.  Tests conducted during September 1978 using the Stanford radio telescope indicated less received signal strength than had been anticipated, and the approach required both major changes in the onboard computer programs and the construction of a suitable ground transmitter facility.  Implementation would cost an estimated $10 million ($7.5 million facility, $2.5 million project) and would require about twenty-four months to develop.  Realizing that if the capability were never used, NASA would be open to criticism for having built an unnecessary facility, the Voyager Program Office decided against the planetary radio astronomy solution.  (Butrica, Footnote 79)

Since the DSN solution had already been proven to work, I suppose the alternate PRA receiver solution was investigated because the Voyager team was worried the backup receiver might fail completely at some point?  In any case, the backup receiver continued working for the next 49 years ...  and longer hopefully!

An additional complication is that the constant frequency at which the backup receiver is listening varies depending on the temperature of the receiver, which is affected by activities on the spacecraft.  Consequently, after a series of activities, a command moratorium is instituted for a day or two to let the receiver settle down to a stable temperature.  And the constant frequency, known as the best-lock frequency, has to periodically be recalibrated by sending a bunch of (dummy?) commands at different frequencies around the expected BLF and seeing which ones get through.

Offline calex

  • Member
  • Posts: 26
  • Maryland, USA
  • Liked: 57
  • Likes Given: 50
Re: NASA - Voyager 1 and 2 updates
« Reply #546 on: 04/17/2025 07:17 pm »
I recently searched for any Voyager information at WorldCat.org.  The results were mostly a bunch of science papers, but the search also turned up entries for images from a Voyager logo contest held in 1978 at JPL.  The summary from the entry for a mug featuring the logo:

Quote
In 1978 both Voyager spacecraft were on their way to Jupiter and a contest was held at JPL to find an amusing logo for a Voyager t-shirt and mug.  Hugh von Delden, a temperature control hardware engineer at JPL, proposed the winning design.  The illustration was done by artist Bill Haines, a friend of his.  Von Delden had also won the design contest in 1975 for the official Mariner Jupiter/Saturn '77 logo, before the project was renamed Voyager.

The three WorldCat entries are as follow (the image links in the entries are obsolete, so I've provided links to the archived images):

(1) "Voyager logo contest winner, 1978" (archived JPEG image)
I'm not sure, but I think the man on the left is Robert "Bob" Parks (named Voyager project manager in January 1978) and the man on the right is Hugh von Deiden.

(2) "U.S.S. Voyager line drawing, 1978" (archived JPEG image)

(3) "U.S.S. Voyager Mug, 2007" (archived JPEG image)
I'm not sure why the entry is dated 2007; was this a mug released on Voyager's 30th anniversary?

7 years ago, atomic_lobster posted a picture on Reddit of a Voyager pin with the logo given to them by someone at Goddard Spaceflight Center (Greenbelt, Maryland, USA).  (I provide a reduced, cropped version of the picture; for the full-size image, see the Reddit post.)

"As requested, a close up of my old Voyager pin" (Reddit)

A commenter on the pin post wrote that "JPL recently started selling memorabilia with this design on it." That would approximately coincide with Voyager's 40th anniversary ...  which brings me to my last picture.

JPL released some posters for the 40th anniversary celebration in 2017.  I've included the retro 1970s-disco-style poster below; the full-size images for it and the other posters are available at the following site (note that the image files are very large):

https://science.nasa.gov/mission/voyager/downloads/

Online MickQ

  • Full Member
  • ****
  • Posts: 1027
  • Atherton, Australia.
  • Liked: 276
  • Likes Given: 772
Re: NASA - Voyager 1 and 2 updates
« Reply #547 on: 04/18/2025 11:26 pm »
V1 currently into Madrid and V2 into Canberra. Both at 160 b/sec and at similar received power levels.  Good to see.

Offline StraumliBlight

  • Senior Member
  • *****
  • Posts: 2798
  • UK
  • Liked: 4618
  • Likes Given: 638
Re: NASA - Voyager 1 and 2 updates
« Reply #548 on: 05/14/2025 05:02 pm »
https://twitter.com/NASAVoyager/status/1922689732137427018

NASA’s Voyager 1 Revives Backup Thrusters Before Command Pause [May 14]

Quote
The mission team wanted to fix the thrusters, deemed unusable decades ago, before the radio antenna that sends commands to the probe went offline for upgrades.

Engineers at NASA’s Jet Propulsion Laboratory in Southern California have revived a set of thrusters aboard the Voyager 1 spacecraft that had been considered inoperable since 2004. Fixing the thrusters required creativity and risk, but the team wants to have them available as a backup to a set of active thrusters whose fuel tubes are experiencing a buildup of residue that could cause them to stop working as early as this fall.

In addition, the mission needed to ensure the availability of the long-dormant thrusters before May 4, when the Earth-bound antenna that sends commands to Voyager 1 and its twin Voyager 2 went offline for months of upgrades.

Thruster Clogging
The Voyagers launched in 1977 and are hurtling through interstellar space at around 35,000 mph (56,000 kph). Both spacecraft rely on a set of primary thrusters to gently pivot them up and down as well as to the right and left in order to keep their antennas pointed at Earth so they can send back data and receive commands. Within the primary set of thrusters are other thrusters that control the spacecraft’s roll motion. Seen from Earth, the roll motion rotates the antenna like a vinyl record to keep each Voyager pointed at a guide star it uses to orient itself. Both spacecraft have a primary and backup set for these roll movements.

(Another set of thrusters, intended to change the spacecrafts’ trajectory during the flybys of the outer planets, were revived on the spacecraft in 2018 and 2019, but they can’t induce roll motion.)

To manage the clogging tubes in the thrusters, engineers switch between the sets of primary, backup, and trajectory thrusters of both Voyagers. But on Voyager 1, the primary roll thrusters stopped working in 2004 after losing power in two small internal heaters. Engineers determined the broken heaters were likely unfixable and opted to rely solely on Voyager 1’s backup roll thrusters to orient the star tracker.

“I think at that time, the team was OK with accepting that the primary roll thrusters didn’t work, because they had a perfectly good backup,” said Kareem Badaruddin, Voyager mission manager at JPL, which manages the mission for NASA. “And, frankly, they probably didn’t think the Voyagers were going to keep going for another 20 years.”

But without the ability to control the spacecraft’s roll motion, a variety of issues would arise that might threaten the mission, so the engineering team decided to reexamine the 2004 thruster failure. They began to suspect that an unexpected change or disturbance in the circuits that control the heaters’ power supply had effectively flipped a switch to the wrong position. If they could turn the switch back to its original position, the heaters might work again, enabling them to reactivate the primary roll thrusters and use them if the backup roll thrusters that have been used since 2004 become completely clogged.

Communications Pause
The solution required some puzzle-solving. The team would have to turn on the dormant roll thrusters, then try fixing and restarting the heaters. If, during that time, the spacecraft’s star tracker drifted too far from the guide star, the long-dormant roll thrusters would automatically fire (thanks to the spacecraft’s programming). And if the heaters were still off when they fired, it could trigger a small explosion, so the team needed to get the star tracker pointed as precisely as possible.

It would be a race, and the team faced additional time pressure: From May 4, 2025, through February 2026, Deep Space Station 43 (DSS-43), a 230-foot-wide (70-meter-wide) antenna in Canberra, Australia, that’s part of NASA’s Deep Space Network, would be undergoing upgrades. It would be offline for most of that time, with brief periods of operation in August and December.

Although the Deep Space Network has three complexes equally spaced around the globe (in Goldstone, California, and Madrid, in addition to Australia) to ensure constant contact with spacecraft as Earth rotates, DSS-43 is the only dish with enough signal power to send commands to the Voyagers.

“These antenna upgrades are important for future crewed lunar landings, and they also increase communications capacity for our science missions in deep space, some of which are building on the discoveries Voyager made,” said Suzanne Dodd, Voyager project manager and director of the Interplanetary Network at JPL, which manages the Deep Space Network for NASA. “We’ve been through downtime like this before, so we’re just preparing as much as we can.”

The team wanted to make sure the long-dormant thrusters would be available when the dish is back online briefly in August, by which time the thrusters currently in use on Voyager 1 might be completely clogged.

The advance work paid off: On March 20, the team watched as the spacecraft executed their commands. Because of Voyager’s distance, the radio signal takes over 23 hours to travel from the spacecraft to Earth, meaning everything the team saw happening had occurred almost a day earlier. If the test had failed, Voyager might already have been in danger. But within 20 minutes, the team saw the temperature of the thruster heaters rise dramatically and knew they had succeeded.

“It was such a glorious moment. Team morale was very high that day,” said Todd Barber, the mission’s propulsion lead at JPL. “These thrusters were considered dead. And that was a legitimate conclusion. It’s just that one of our engineers had this insight that maybe there was this other possible cause and it was fixable. It was yet another miracle save for Voyager.”

« Last Edit: 05/17/2025 01:24 pm by StraumliBlight »

Offline illectro

Re: NASA - Voyager 1 and 2 updates
« Reply #549 on: 05/18/2025 04:13 am »
Thanks for linking the video. I really should say how much I appreciate this thread as a source for research. I realize I could have told almost the same story last year, but I was expecting more details on how the PB-15 mode began transmitting the memory dump, but David Cummings straight up admitted they didn't know exactly why this was the case. So the video is late, but, I'm happy it's finally done.

Re: NASA - Voyager 1 and 2 updates
« Reply #550 on: 05/18/2025 01:46 pm »
Sorry, I can’t find the video link. Where’re is it?

Online lightleviathan

  • Full Member
  • ****
  • Posts: 502
  • washington dc
  • Liked: 436
  • Likes Given: 172
Re: NASA - Voyager 1 and 2 updates
« Reply #551 on: 05/18/2025 03:17 pm »
Sorry, I can’t find the video link. Where’re is it?

It should be the post above. But if you can't see it, it's Scott Manley's newest video ("The First Interstellar Software Update - The Insane Hack That Saved Voyager 1")

Offline ugordan

  • Senior Member
  • *****
  • Posts: 8700
    • My mainly Cassini image gallery
  • Liked: 3937
  • Likes Given: 819
Re: NASA - Voyager 1 and 2 updates
« Reply #552 on: 05/18/2025 06:29 pm »
the PB-15 mode began transmitting the memory dump

That was a stroke of luck, if I ever saw one. As someone who has had experience tshooting an elusive SW issue that we simply couldn't pin down for 2 years, I can totally relate. In my case, it eventually took a capable/eager onsite engineer giving us a memory dump, and here Voyager 1 provided it by itself without anyone expecting it.

Online catdlr

  • Member
  • Senior Member
  • *****
  • Posts: 18274
  • Enthusiast since the Redstone and Thunderbirds
  • Marina del Rey, California, USA
  • Liked: 15906
  • Likes Given: 11257
Re: NASA - Voyager 1 and 2 updates
« Reply #553 on: 05/19/2025 03:38 am »
Here is the Link to Scott's video

https://youtube.com/watch?v=p0K7u3B_8rY
It's Tony De La Rosa, ...I don't create this stuff, I just report it.

Offline calex

  • Member
  • Posts: 26
  • Maryland, USA
  • Liked: 57
  • Likes Given: 50
Re: NASA - Voyager 1 and 2 updates
« Reply #554 on: 05/22/2025 07:47 pm »
Thanks to @StraumliBlight for posting the Scott Manley video and @illectro for pointing the video out to those like me who overlooked it.  In the video's description, Manley links to his two sources of information: Bruce Waggoner's August 2024 !!Con presentation, "Saving Voyager 1", and Dave Cummings's March 2025 Flight Software Workshop presentation, "How We Diagnosed and Fixed the 2023 Voyager 1 Anomaly from 15 Billion Miles Away" (see video at end of post).

The slides for the latter presentation can be downloaded as a PDF from the Workshop's Day 2 download page (first entry on the page).  (There is another PDF of the slides available in the JPL Open Repository, CL25_1086.pdf, but steer clear of it.  The bottoms of the slides are truncated and the code listings are mangled.)

In the widely circulated photo of the Voyager team cheering the resumption of telemetry from Voyager 1 after the fix, Dave Cummings is the guy in the back with both arms raised high above his head - "Field Goal!"

Cummings mostly focuses on the software side of things, but the middle of the presentation (29:30 in video) does get into how the DSN telecom engineers were able to make sense of the radio signals and eventually decoded the unexpected FDS memory readout.  Most of this was over my head, but it is still very interesting.

I was confused by the discussion of hardware pokes in the presentation.  At issue was switching telemetry modes.  The FDS telemetry MODE variable is in write-protected memory and "is only set via ground command" (i.e., via the CCS command computer?).  However, they could not set the MODE variable with a spacecraft command (executed by CCS?) because the "flight software was not functional" (slide 16, 27:30 in video).  The CCS and AACS computers were both working, so Cummings must have meant the FDS flight software.  Can the CCS only write to the FDS memory with FDS's cooperation?

[Add June 4, 2025:
I partially answered my own question two paragraphs down without realizing it.  I think I understand now.  There are two telemetry mode variables.  CMODE is the current telemetry mode; MODE is the pending, new telemetry mode that doesn't take effect until the end of the current 48-second frame.

A spacecraft command, SC06BB, instructs the CCS computer to set the FDS computer's MODE variable.  The FDS computer continues processing in the current CMODE and then, at the end of the frame, updates CMODE from MODE.  The Voyager team had a strong suspicion that, because of the corrupted memory block, the code that checked for the end of frame was never getting executed and thus CMODE was never updated.  Hence the flight software was "not functional".

In order to change the telemetry mode, the Voyager team consequently had to set CMODE directly and not indirectly through MODE.  This should be possible via a software load or patch, which I assume tells the CCS computer to store N words of binary code/data beginning at address Y in the target (FDS) computer's memory.  Could "hardware poke" be the team's nickname for a single-word software load into CMODE's memory location?  However, Cummings also said that hardware pokes had never been used after launch.  Now the FDS software has been modified many times since launch, so I'm still missing something ...
End add]

So they had to use "hardware poke" commands, which had never been used after the spacecraft were launched.  Does that mean there is a separate channel between the telecom subsystem and the FDS memory that does not involve either FDS or CCS intervention?  In other words, the telecom subsystem itself decodes address-value pairs from the ground and stores the values in the specified memory locations?  (I can see this being a useful capability in case the CCS computer has a problem and can't process ground commands.)

Incidentally, Cummings explains that changing the telemetry MODE variable wouldn't have worked anyway because the FDS software works from a companion CMODE variable that is updated from the MODE variable every 48 seconds and they were pretty sure that, because of the memory problem, the code that performs the update was not getting called (slide 16, 25:30 in video).  They tried it anyway and it didn't work (slide 18, 28:30 in video).  But something -- they aren't sure what -- caused the spacecraft to start sending an unformatted FDS memory dump.

Hey, @leovinus, JPL needs your disassembler!  They didn't have an FDS disassembler and had to disassemble the memory dump by hand (all 8K?).  (Slide 28, 39:00 in video)  They also didn't have an assembler and hand-assembled all the code changes.  And they had no simulator or testbed.  The operations folk were pressuring them to solve the problem as soon as possible as they were worried about the health of the spacecraft, possibly discouraging Dave and the others from writing new tools.

YouTube video: David Cummings, "How We Diagnosed and Fixed the 2023 Voyager 1 Anomaly from 15 Billion Miles Away"

« Last Edit: 06/04/2025 05:20 pm by calex »

Offline calex

  • Member
  • Posts: 26
  • Maryland, USA
  • Liked: 57
  • Likes Given: 50
Re: NASA - Voyager 1 and 2 updates
« Reply #555 on: 05/22/2025 08:34 pm »
David Cummings's March 2025 Flight Software Workshop presentation, "How We Diagnosed and Fixed the 2023 Voyager 1 Anomaly from 15 Billion Miles Away", has some welcome examples of FDS assembly language.  Below are 3 of the major code listings in his presentation, along with some comments.  (A 4th code listing is a repeat of the listing shown in Bruce Waggoner's August 24 presentation; see an earlier post for that code listing.)  A PDF of the presentation slides can be downloaded here, first entry.

To refresh your memory (pun not really intended!) ...

First, see Steven Pietrobon's short description of the FDS computer.  Then see his longer description with the FDS instruction set.

The FDS computer has 8K 16-bit words of memory, requiring 13 address bits.  The CPU can only access 4K words (12 address bits).  Consequently, the full 8K words of memory are treated as two 4K memory banks: the lower 4K is write-protected/read-only (mostly!) and the upper 4K is writeable.  Nominally, the write-protected lower bank is intended for code and the writeable upper bank is intended for data/variables.  Bank selection is via two independent 13th address bits that can be set by the software, one for instruction fetches of code and the other for reading/writing data.  Over the decades, I guess, more and more code has been placed in and executed from the upper bank.

The Interrupt "Handler" (slide 9)

The FDS computer is structured around time slots ("P periods") created by a regular 2.5-msec timer interrupt.  24 time slots constitute a cycle corresponding to an image line from the cameras.  The computer performs different processing during each of the 24 slots and then begins the cycle anew.  800 cycles constitute a 48-second "frame", which corresponds to the 800 lines in an image.

When a timer interrupt occurs, execution is immediately forced to address 0x0000 in the lower memory bank.  I assume the 13th address bits are reset to the lower bank for code and the upper bank for data.

Here is the code listing at 0x0000 from the presentation:

ADDR CODE
---- ----
0000 9FCF          ISZ  PCTR            /INCREMENT P-COUNTER FOR THIS P-PERIOD
0001 801F          ABS  31              /FORCE IT TO BE BETWEEN 0 AND 31
0002 93E0          AND  PCTR,R1         /INCLUSIVE BY KEEPING ONLY 5LSB
0003 9C52          SKP  CMODE           /IS LOWER MEMORY P-TABLE TO BE USED
0004 002B          JMP  GOUP            /NO
                                        /YES
0005 8009          ABS  PTAB            /GENERATE ADDRESS WITHIN PTAB TABLE
0006 900F          ADD  R1,PCTR
0007 0FC0          JMI  R1              /AND JUMP TO IT
0008 11AF  PROGID: CON  $X11AF          /PROGRAM ID
0009 0028  PTAB:   JMP  PILL            /ILLEGAL
000A 002D          JMP  P1
000B 0185          JMP  P2
...
0020 0486          JMP  P23
0021 048F          JMP  P24
0022 0028          JMP  PILL            /ILLEGAL
...
0028 91FF  PILL:   LXR  PCTR,PCTR       /RESET P-COUNTER TO 0
0029 9F86          ISZ  PILLCT          /INCREMENT ILLEGAL P-PERIOD COUNTER
002A 3FFD  PX:     WAT  4095            /WAIT FOR NEXT CLOCK-400 INTERRUPT
002B F087  GOUP:   OUT  7,SETJU         /SET JUMP UP
002C 0000          JMP  UPINT           /JUMP TO UPPER MEMORY INTERRUPT
...
1000 F097  UPINT:  OUT  7,SETAU         /SET ADDRESS UP

Basically, the code increments the P period counter (1..24 with wrap-around), indexes into the P table of functions to execute in specific periods, and jumps to the new period's function.

A few items I noticed ...

First, there is a third jump instruction, JMI, to be added to the two shown in Bruce Waggoner's presentation.  The three instructions - JMP, JMS, and JMI - are all aliases for the same CPU jump instruction; i.e., a 4-bit opcode of 0 plus a 12-bit address.  The code beginning at address 0000 builds the 12-bit address of the current time slot's P-table entry in register R1.  With the 4 bits of zero and 12 address bits, the contents of R1 are now a jump instruction.  The code then JMIs to the jump instruction at address 0FC0, R1's memory location in the top 128 words of memory.  (I don't know what the "I" stands for, but, on other CPUs, this might be called jumping indirectly through a register.)

Second, we see an example of switching execution from one memory bank to the other at the GOUP label (location 002B).  As Steven explained, the OUT instruction changes the 13th instruction address bit, but the bit does not take effect until the next jump instruction, "JMP UPINT".

Lastly, at the PILL label (address 0028), we see the old 8086's and other CPUs' trick of zeroing a value with an exclusive OR!

Steven: In this listing, it looks like the ABS instruction loads an immediate value into register R1.  In the third code listing below, there is another ABS followed by an MLD -- so MLD writes the value in R1 out to memory?

Telemetry Mode Variables (slide 10)

This assembly language listing defines the telemetry mode variables, MODE and CMODE:

0BE5 81C0  MODE:   CON  $B1000000111000000  /LOAD-STATE IS EL, NO PPS SAFING, ENG
                                            /MODE 7 (MODIFIED CRUISE TABLE AND
                                            /AACS MANEUVER (50) TABLE), AACS TEL
...
0FD2 FFE0  CMODE:  CON  $XFFE0              /CURRENT MODE (IN HEX), WHERE
     0001  GS5   EQU  1                     /1 = GS-5
     0003  GS4B  EQU  3                     /3 = GS-4B PWS REPLACEMENT
     0007  GS8   EQU  7                     /7 = GS-8
     000B  PB5   EQU  11                    /B = PB-5
     000C  PB14  EQU  12                    /C = PB-14
     000F  PB15  EQU  15                    /F = PB-15
                                            /FFE0 = EL
                                            /FFE1 = EH
                                            /FFF2 = UV-5A (UV-5)
                                            /FFF3 = PB-16
                                            /FFF5 = CR-5T (AKA CR-5A)

MODE is stored in write-protected memory (i.e., the lower 4K bank) and is usually modified by the CCS computer, not by the FDS software.

CMODE is the actual telemetry mode variable that the FDS software generally references.  Since you don't want to change the telemetry mode in the middle of an image, CMODE is updated from the MODE variable at the end of the current 48-second frame (image line 800, 24th P period).

CMODE is stored in writeable memory, which one would think was the upper 4K bank.  However, without switching data banks, the software can't easily reference variables in two different data banks.

The definition of CMODE at location 0FD2 places it in the top 128 locations of the lower bank, the range reserved for the registers (see Steven's longer description).   This would seem to work if only the bottom 3968 (4096-128) locations are write-protected and the top 128 are not.  I don't know how this restricted writeability is implemented.  I wonder if the register-oriented instructions are implemented such that they temporarily assert an overriding write signal.  This would allow only them to write to the registers, while general memory-write instructions like MLD could not write to those locations.

Set CMODE from MODE (slide 11)

Here is the code that sets the CMODE variable:

053C 1C08  SETMO:  SRB  LMRA            /SAVE RETURN ADDRESS
053D 9B20          SLC  800             /IS LINE COUNTER AT 800
053E 0543          JMP  SETMOA          /YES
                                        /NO
053F 8000          ABS  0               /RESET SKIPPR HERE BECAUSE IT IS A
0540 4F83          MLD  SKIPPR          /CONVENIENT TIME TO DO IT
0541 305D          WAT  95              /EQUALIZE TIME WITH L800 PATH
0542 2C08          EXC  LMRA            /RETURN
                                        /LINE COUNTER IS AT 800
0543 5BE5  SETMOA: MRD  MODE            /GET MODE WORD FOR UPCOMING 48 SECONDS
...

The SLC instruction at address 053D is a conditional skip instruction that tests if the image-line counter has reached 800; i.e., the 48-second mark.  This suggests that one of the CPU's 128 registers is dedicated to counting image lines and the SLC instruction is hard-coded to only reference that register.

The FDS code listing in Bruce Waggoner's 2024 presentation showed a technique for returning from a subroutine using self-modifying code, which Steven helpfully explained.  When a subroutine is called with a jump instruction, the return address is stored in register B.  An SRB instruction in the subroutine saves the return address in register B to a memory location as a JMP instruction.  When the subroutine finishes, it then JMPs to that JMP instruction in order to return to the caller.

The code listing for the SETMO subroutine shows another technique for returning from a subroutine.  Save the return address with an SRB instruction as before, but use an EXC instruction to execute the saved JMP instruction.  I hadn't thought of this, but the self-modifying code technique in Waggoner only works if the code and data are in the same 4K memory bank.  If they are in different banks, a JMP in the code bank can't jump to a saved return-address JMP in the data bank because you can't do an instruction fetch from the data bank.  However, you can do a data read from the data bank.  The EXC instruction presumably does such a read, loading the saved address and executing it as an instruction.  This might be the more prevalent means of returning from a subroutine if the normal mode of operation is running code out of the write-protected lower 4K memory bank and reading/writing data in the writeable upper 4K bank.
« Last Edit: 05/22/2025 09:00 pm by calex »

Offline Targeteer

  • Senior Member
  • *****
  • Posts: 7490
  • near hangar 18
  • Liked: 4991
  • Likes Given: 1638
Re: NASA - Voyager 1 and 2 updates
« Reply #556 on: 05/24/2025 06:28 am »
https://twitter.com/NASAVoyager/status/1925589712510886095

NASA Voyager @NASAVoyager
At our current distance from the Sun, solar panels are all but useless – so we use something called radioisotope thermoelectric generators (RTGs) for power.

Each spacecraft is equipped with three RTGs, and current power output is about 220 watts for V1 and 223 watts for V2.
« Last Edit: 05/24/2025 10:52 pm by zubenelgenubi »
Best quote heard during an inspection, "I was unaware that I was the only one who was aware."

Online Blackstar

  • Veteran
  • Senior Member
  • *****
  • Posts: 16915
  • Liked: 9544
  • Likes Given: 2
Re: NASA - Voyager 1 and 2 updates
« Reply #557 on: 05/24/2025 12:21 pm »
https://x.com/NASAVoyager/status/1925589712510886095

NASA Voyager @NASAVoyager
At our current distance from the Sun, solar panels are all but useless – so we use something called radioisotope thermoelectric generators (RTGs) for power.

Each spacecraft is equipped with three RTGs, and current power output is about 220 watts for V1 and 223 watts for V2.

I was a bit surprised when they posted that image before, because I don't remember ever seeing the RTG by itself. Probably not new, but new to me.

I know somebody who was involved in the RTG for Perseverance and he explained a bit about the handling procedures when they installed it on the spacecraft. They do have movable shields that they put in the room for people to stay behind. Although RTGs are not very dangerous (mostly alpha particles?), they do put out a little bit of dangerous radiation, hence the shields.

Offline leovinus

  • Full Member
  • ****
  • Posts: 1321
  • Porto, Portugal
  • Liked: 1052
  • Likes Given: 2019
Re: NASA - Voyager 1 and 2 updates
« Reply #558 on: 05/24/2025 12:25 pm »
David Cummings's March 2025 Flight Software Workshop presentation, "How We Diagnosed and Fixed the 2023 Voyager 1 Anomaly from 15 Billion Miles Away", has some welcome examples of FDS assembly language.  Below are 3 of the major code listings in his presentation, along with some comments.  (A 4th code listing is a repeat of the listing shown in Bruce Waggoner's August 24 presentation; see an earlier post for that code listing.)  A PDF of the presentation slides can be downloaded here, first entry.

To refresh your memory (pun not really intended!) ...

First, see Steven Pietrobon's short description of the FDS computer.  Then see his longer description with the FDS instruction set.
Thanks for this! PS: I did a FOIA on the FDS software listings but no luck. Long story. Let me know if you need info on what worked and what not.

Offline calex

  • Member
  • Posts: 26
  • Maryland, USA
  • Liked: 57
  • Likes Given: 50
Re: NASA - Voyager 1 and 2 updates
« Reply #559 on: 05/26/2025 06:27 pm »
NASA Voyager @NASAVoyager
At our current distance from the Sun, solar panels are all but useless – so we use something called radioisotope thermoelectric generators (RTGs) for power.

Each spacecraft is equipped with three RTGs, and current power output is about 220 watts for V1 and 223 watts for V2.

The more I read about Voyager, the more I'm amazed that they even worked, let alone performed so successfully as they have done.  I just read about the longevity of the RTGs being a serious concern in the development of the spacecraft (emphasis added by me):

Quote
At the time, the longest operating planetary mission had been for nine months, and the most advanced RTGs, used to convert the heat produced from the natural radioactive decay of plutonium, lost power after ten thousand hours, slightly more than one year.  Thus, even a three-year mission was a technological challenge.  The power problem was eventually solved with the development of special wrappings for the thermocouples that substantially extended the life of the RTGs, and the computer systems were redesigned in order to reduce power consumption.
...
Another crisis involved the RTGs.  A material used as insulation sublimed, that is, it passed from a solid to a gaseous state and then redeposited itself on an insulating blanket, causing an electrical short in the system and lowering the power output to less than the required levels.  The solution, discovered by an RCA engineer, was to put a nitride coat on the thermocouple device, which prevented the subliming and the shorts.

(The two paragraphs are on widely separated pages and are describing the same thing.) From Henry Dethloff and Ronald Schorn, Voyager's Grand Tour: To the Outer Planets and Beyond (2003).

And the RTGs were tested rigorously for safety reasons.  I imagine the testers enjoyed this part of the project:

Quote
The RTGs' fuel spheres and housings were put through elaborate tests to demonstrate their safety in the event of a catastrophic launch abort or atmospheric re-entry.  The assembled heat source was fired into cement walls, dropped from high altitude on to concrete pads, exposed to plasma arc jets to simulate atmospheric re-entry heating, and exposed to high temperature explosions simulating launch vehicle explosions.

From Raymond Heacock (Voyager's Spacecraft System Manager) in David Swift's Voyager Tales: Personal Views of the Grand Tour (1997).

It would be great to go back in time and tell the Voyager engineers that 50 years later the Voyager team would still be wringing out every last little bit of power they could from the RTGs.


Tags:
 

Advertisement NovaTech
Advertisement
Advertisement Margaritaville Beach Resort South Padre Island
Advertisement Brady Kenniston
Advertisement NextSpaceflight
Advertisement Nathan Barker Photography
0