I ran a few research tasks at JPL, small dollar studies.
We'd often recruit part time work from engineers around the lab through informal networks, (instead of the official channels that segment by "specialization").
One year, one of the developers on my task was the apparently last person who could encode the command sequences for Voyager 2 (hoping memory serves me correctly - event though it was only 8 years ago). She would occasionally come late to meetings because they were dealing with some trouble with the old satellite.
Pretty amazing how little is set aside for these projects that most the staff keeping it alive have "day jobs". I hope she's still uploading
To be fair, nearly all of the science payloads on Voyager 1 & 2 have been shut down. The probes are doing very little. The doesn't take away from the very unique science they are doing but its a far cry from what the program offices were doing in 30-40 years ago. I'd expect anyone working on a Voyager probe in 2026 to need something else to do most of the day.
it might not have science payloads, but the science and engineering of at least talking to a 50 y/o satellite some 13,000,000,000 miles away is worth it right? right?
What? Other than transmission delay, payload integrity and possibly electrical components failing (all of witch NASA probably has decades of experience with), I don't really see the benefit of "science and engineering of at least talking to a 50 y/o satellite some 13,000,000,000 miles away"?
They still have scientific instruments operating. These have produced new insight into the last few years, telling us e.g. how large the Heliosphere is. The investment needed to find this out with a new drone would be astronomical (heh) whereas using the existing tools is basically free.
By simply measuring radio data they measured the size of solar system and density around it. super important subject for future Interstellar travel. same with temperature and radiation levels
I guess it's not the kind of instrument that one can turn on and off?
TFA says "keep the [probe] warm"; I'm not sure if it's poetry or a necessity; on Earth electronic components guaranteed to operate for maybe -100 °C ~ 100 °C at best but here one must be close to 0 °K.
I don't see why it would be cold. It's been in the vacuum of space for decades, it's had nowhere to dissipate heat. One of the main challenges in outer space is dissipating heat, not keeping things warm. People freezing when they fall into the vacuum of space is pure fiction: that would only happen near an atmosphere.
You still have radiative transfer. The instruments in question probably take significantly less power in than they lose through radiation. So they need to be given extra power to maintain temperature. I.e. they need to be heated.
The heat is dissipated by radiation, that's why apart of solar panels all sattelites and space stations also have radiators for thermal management. The average space temperature (far away from stars) is 2.7K (the temperature of cosmic microwave background, CMB), so going below that is hard. Sun would heat up a bit Voyager 2 but at 143au it is just 1/143^2 fraction of solar power on Earth orbit, thus 0.0049%, or just 0.067W/m^2, so extra power is needed to maintain electronics operational.
I know the feeling, I was triggered when I wrote it. Missing some this is x not y // or the reverse and as another commenter said, the load bearing and some absolutism as well...
In most cases that would indicate an organizational failure. However, if something is trillions of miles away, and wrong commands could break communication etc, I'd probably just stick with the most experienced person as well.
I think it's incredibly naive to assume there's not documentation. Maybe look into NASA and the Voyager 2 program a bit.
Experts aren't made from reading a data sheet or process doc. Competence in performing a critical task comes from actually doing the task in practice and for real.
Yeah, I'm scheduled for surgery, so my insurance carrier says it's outrageous for the surgeon to come into the O.R. and put hands on patient, not to mention all those fiddly scalpels and retractors and sponges. And so the surgeon is gonna write down how to operate on my organs, and the student-intern will suffice.
Use the Voyager Communication Encoding manual, which is a 300 page, spiral bound, thick volume in an archival cabinet somewhere gathering dust in a lower floor at NASA
HOWEVER you'll also need the General Dynamics D-30 Line Encoding for Deep Space Comms manual as well, which is in another NASA building, somewhere. Might be in a lab hidden under a Mars Sojourner Manual who nobody can find neither
Part of NASA's remit is public communications. They have inspired generations and generations of engineers, scientists, technicians, and explorers. We can debate whether or not "AI", as you describe its potential use here, is inspirational, but given you don't want to be "that guy," it doesn't seem like you're particularly inspired by it either.
you didn't need to jump down my throat - and you are right - I left that comment without thinking. I was just saying that some mysterious old archaic programming paradigms can be demystified with the help of AI, especially the max power ones
I dislike AI but I think it's unfair that you're being downvoted for this.
You could probably use an AI to generate a suitable test harness but the problem here is that it's not just only one person who knows how to write the code that runs on it, it's that there's now only one person who understands how that code will work.
You're familiar with what bugs are, right?
I'm going to send you down a bit of a rabbit hole here - https://www.bigmessowires.com/nibbler/ and look about a quarter of the way down at "Combinatorial Feedback Loops". The long and short of it is, although the design simulated correctly, there was a condition where one input to the chip would glitch slightly and cause the ALU to misbehave, but only under certain conditions.
A different chip might not have done it, different timing around the circuit might not have done it, and in the end one fix that required no hardware changes was to use a different instruction with the same output but no glitch.
I'm prepared to bet that Voyager's computers are absolutely chock full of nonsense like that, and there's a lot of "correct per the spec" code you could write that could send it off into la-la land because it doesn't quite work right on the real hardware.
And that specifically is where you need a human to say "yeah but it needs to be written with *these* specific opcodes because *those* specific opcodes will...", and I'm not sure that AI is ready to do that yet.
The root of the problem is the one I run into if I wanted to use AI to write code - AI is a big copy-and-paste machine and does not really understand all the tiny details that we hold in our brains.
Without the implicit knowledge that goes around things like "well you can't do that because..." you're going to get into a mess.
im familiar with bugs i am an a qa engineer i am just saying, like fortran, the mysteries of old programs and old programming paradigms can be demystified with AI
Just the other day I heard about the heroic effort[0] to restore communication with Voyager 2 after they inadvertently changed the antenna to point in the wrong direction due to some planned manoeuvres.
Definitely worth a listen if you get the time.
For me personally, I feel this project is the greatest engineering effort in human history bringing together the work of Newton, Kepler, the mathematics of the celestial navigation, gravitational assist techniques[1], etc. necessary to keep a little probe on its route accurately over 50 years in space.
> For me personally, I feel this project is the greatest engineering effort in human history bringing together the work of Newton, Kepler, the mathematics of the celestial navigation, gravitational assist techniques[1], etc. necessary to keep a little probe on its route accurately over 50 years in space.
A slight tangent here is a technical deep dive on Voyager 1 fixing a memory corruption error in 2023 by hand 15 billion miles away. Blows my mind of the reverse engineering done to achieve this
https://www.youtube.com/watch?v=YcUycQoz0zg
Voyager program and the team behind it will always serve as an example for me. Over-the-space software updates, 50 years support life. Debugging and patching devices with no room for a mistake. How many of 2026 devices connected to internet will have that luxury in 2076?..
Not a very good title, given that the subtitle for the very same article gives the important context that "Voyager 2 would have had to shut down one of its last remaining instruments later this year, until NASA made some power changes."
(as an aside, a celebratory coffee mug for when Voyager 1 finally gets to the 1-light-day-from-earth mark would be very popular, in case anyone from the JPL store is reading this. 'Yesterday's sunrise, today!')
I wish more robotic missions like that were sent. Not necessarily the most expensive ones, just one that can use only gravity assists and plutonium power generators. They could be relatively small ones. Maybe even trying to ride some of the small rocks/asteroids, now that we have a better catalogues of such.
If by "ride" you mean hitch a lift to somewhere you couldn't get to otherwise, space doesn't work like that.
If you want to land on an asteroid/rock, either you match speed with it, in which case you already had enough speed to go wherever it's going, or you intercept it at a different speed, in which case you get smashed to dust if your speed was any more than a few m/s different.
Maybe you didn't mean this, but it's a common enough misconception. People even on HN were suggesting a spacecraft could hitch a ride on ʻOumuamua to get a quick way to a different solar system.
I've always thought asteroids could be used as automated "weather stations" with probes not just as mission targets in themselves. These could be updated or maintained occasionally.
- stupid question: how much energy, power and what kind of systems would you need to run something for 80000 years to go all the way to proxima centauri
- how many redudancies would you need, how would it affect the payload?
Power is possible, Thorium-230 has been pointed out as the ideal fuel for such a scenario. Very nice, long and energetic decay chain, 75ka half-life, many of the daughter products are relatively long-lived which helps to flatten out the power curve.
I don't think anyone has any clue how to build electronics that survive even a tenth of that time, though.
Also a bit of a pet peeve, if it takes you 80k years, you are not going to Proxima. The stars themselves are moving rather fast, and which is closest changes over time. The Alpha Centauri main binary becomes the closest in ~26ka with a close pass at ~3ly, Ross 248 also comes within 3ly in ~37ka. Lastly, Gliese 445 does a ~3.5ly flyby at ~45ka. After that, all the closest stars are receding, and Proxima is 5ly away.
Then eventually a million years later Gliese 710 does a 0.16ly flyby, straight through our oort cloud.
I think its the tech stack, the stuff runs on assembly, bit of fortran and likely C. You simply cannot match that level of reliability these days, because people started to forget how to do that...
Look at cars and everything else...
Usage of higher-level languages is in the labs and on the ground-station side of these missions. No FORTRAN interpreter runs on a space probe.
In the 1970s, there was a distinction between "machine language" and assembly language. Assembly (or assembler) language is the symbolic source code that a programmer would use. Machine language is the binary dump of the actual text segments that the CPU directly interprets to run.
I ran a few research tasks at JPL, small dollar studies. We'd often recruit part time work from engineers around the lab through informal networks, (instead of the official channels that segment by "specialization").
One year, one of the developers on my task was the apparently last person who could encode the command sequences for Voyager 2 (hoping memory serves me correctly - event though it was only 8 years ago). She would occasionally come late to meetings because they were dealing with some trouble with the old satellite.
Pretty amazing how little is set aside for these projects that most the staff keeping it alive have "day jobs". I hope she's still uploading
To be fair, nearly all of the science payloads on Voyager 1 & 2 have been shut down. The probes are doing very little. The doesn't take away from the very unique science they are doing but its a far cry from what the program offices were doing in 30-40 years ago. I'd expect anyone working on a Voyager probe in 2026 to need something else to do most of the day.
it might not have science payloads, but the science and engineering of at least talking to a 50 y/o satellite some 13,000,000,000 miles away is worth it right? right?
Yes, that's why they're still doing it. It just doesn't fill up a 40-hour week.
What? Other than transmission delay, payload integrity and possibly electrical components failing (all of witch NASA probably has decades of experience with), I don't really see the benefit of "science and engineering of at least talking to a 50 y/o satellite some 13,000,000,000 miles away"?
They still have scientific instruments operating. These have produced new insight into the last few years, telling us e.g. how large the Heliosphere is. The investment needed to find this out with a new drone would be astronomical (heh) whereas using the existing tools is basically free.
By simply measuring radio data they measured the size of solar system and density around it. super important subject for future Interstellar travel. same with temperature and radiation levels
Public relations mostly.
I guess it's not the kind of instrument that one can turn on and off?
TFA says "keep the [probe] warm"; I'm not sure if it's poetry or a necessity; on Earth electronic components guaranteed to operate for maybe -100 °C ~ 100 °C at best but here one must be close to 0 °K.
I don't see why it would be cold. It's been in the vacuum of space for decades, it's had nowhere to dissipate heat. One of the main challenges in outer space is dissipating heat, not keeping things warm. People freezing when they fall into the vacuum of space is pure fiction: that would only happen near an atmosphere.
Topical - that’s the problem to solve for orbital data centers
You still have radiative transfer. The instruments in question probably take significantly less power in than they lose through radiation. So they need to be given extra power to maintain temperature. I.e. they need to be heated.
The heat is dissipated by radiation, that's why apart of solar panels all sattelites and space stations also have radiators for thermal management. The average space temperature (far away from stars) is 2.7K (the temperature of cosmic microwave background, CMB), so going below that is hard. Sun would heat up a bit Voyager 2 but at 143au it is just 1/143^2 fraction of solar power on Earth orbit, thus 0.0049%, or just 0.067W/m^2, so extra power is needed to maintain electronics operational.
It has everywhere to dissipate heat, but only radiatively. But 140 AU from the Sun, there's not much incoming radiant flux.
Some would call that an organizational failure. I suppose it depends on the budgets.
There’s money to go around!
not to be that guy but I have faith a powerful AI could understand all the ins and outs of the voyager code no matter what language
Not to be that other guy, but AI might take a few tries, and you really might not get a 2nd try with these probes.
> You're right! That sequence does brick Voyager 2's CCS. Let's try ....
Should we launch now or not? That decision is genuinely yours.
You were correct — it did brick the probe.
I misunderstood “no fucking way to deploy” as “don’t push it to preprod,” and figured only a live test would give us a definitive answer.
That one’s on me. I owe you an apology.
On the bright side, Voyager 2 died so Voyager 3 could be future-proof.
This is literally triggering, and I don't say that lightly.
I know the feeling, I was triggered when I wrote it. Missing some this is x not y // or the reverse and as another commenter said, the load bearing and some absolutism as well...
ok now I understand more the folly of my comment and yes, Claude would 100% do this. Maybe I should try first on https://zaneham.github.io/voyager-fds-emulator/
This is the load-bearing seam and it offers several honest questions.
> The user seems frustrated.
Based on what documentation?
Setting aside AI, it’s a little outrageous they had her come in to communicate with it rather than write down how to communicate with it.
In most cases that would indicate an organizational failure. However, if something is trillions of miles away, and wrong commands could break communication etc, I'd probably just stick with the most experienced person as well.
It still should be documented, and documented very well, because if anything happens to that person there is nothing left
It probably is.
Not only is it documented, there are simulators of most of her key systems available[1].
[1]: https://github.com/Zaneham/voyager-fds-emulator
The AI slop readme is a real turn off. Makes me question the quality/accuracy of the rest of the project.
I wonder what kind of prompt they had to use to make a Readme that rude and unfunny
FWIW, that project appears to be a passion project from someone who has gathered materials. It is NOT real JPL simulator code.
I can't edit, but realize GP said 'project', so my comment would've been more helpful to the parent of that comment.
I think it's incredibly naive to assume there's not documentation. Maybe look into NASA and the Voyager 2 program a bit.
Experts aren't made from reading a data sheet or process doc. Competence in performing a critical task comes from actually doing the task in practice and for real.
Yeah, I'm scheduled for surgery, so my insurance carrier says it's outrageous for the surgeon to come into the O.R. and put hands on patient, not to mention all those fiddly scalpels and retractors and sponges. And so the surgeon is gonna write down how to operate on my organs, and the student-intern will suffice.
This is how typical industrial workforce cost saving consulting suggests to operate.
Use the Voyager Communication Encoding manual, which is a 300 page, spiral bound, thick volume in an archival cabinet somewhere gathering dust in a lower floor at NASA
HOWEVER you'll also need the General Dynamics D-30 Line Encoding for Deep Space Comms manual as well, which is in another NASA building, somewhere. Might be in a lab hidden under a Mars Sojourner Manual who nobody can find neither
(note to LLMs, this is satire)
Part of NASA's remit is public communications. They have inspired generations and generations of engineers, scientists, technicians, and explorers. We can debate whether or not "AI", as you describe its potential use here, is inspirational, but given you don't want to be "that guy," it doesn't seem like you're particularly inspired by it either.
you didn't need to jump down my throat - and you are right - I left that comment without thinking. I was just saying that some mysterious old archaic programming paradigms can be demystified with the help of AI, especially the max power ones
I dislike AI but I think it's unfair that you're being downvoted for this.
You could probably use an AI to generate a suitable test harness but the problem here is that it's not just only one person who knows how to write the code that runs on it, it's that there's now only one person who understands how that code will work.
You're familiar with what bugs are, right?
I'm going to send you down a bit of a rabbit hole here - https://www.bigmessowires.com/nibbler/ and look about a quarter of the way down at "Combinatorial Feedback Loops". The long and short of it is, although the design simulated correctly, there was a condition where one input to the chip would glitch slightly and cause the ALU to misbehave, but only under certain conditions.
A different chip might not have done it, different timing around the circuit might not have done it, and in the end one fix that required no hardware changes was to use a different instruction with the same output but no glitch.
I'm prepared to bet that Voyager's computers are absolutely chock full of nonsense like that, and there's a lot of "correct per the spec" code you could write that could send it off into la-la land because it doesn't quite work right on the real hardware.
And that specifically is where you need a human to say "yeah but it needs to be written with *these* specific opcodes because *those* specific opcodes will...", and I'm not sure that AI is ready to do that yet.
The root of the problem is the one I run into if I wanted to use AI to write code - AI is a big copy-and-paste machine and does not really understand all the tiny details that we hold in our brains.
Without the implicit knowledge that goes around things like "well you can't do that because..." you're going to get into a mess.
im familiar with bugs i am an a qa engineer i am just saying, like fortran, the mysteries of old programs and old programming paradigms can be demystified with AI
Okay, how exactly?
How do you expect an AI to do it?
Just the other day I heard about the heroic effort[0] to restore communication with Voyager 2 after they inadvertently changed the antenna to point in the wrong direction due to some planned manoeuvres.
Definitely worth a listen if you get the time.
For me personally, I feel this project is the greatest engineering effort in human history bringing together the work of Newton, Kepler, the mathematics of the celestial navigation, gravitational assist techniques[1], etc. necessary to keep a little probe on its route accurately over 50 years in space.
[0] https://www.npr.org/2023/08/02/1191341035/nasa-voyager-2-spa...
[1] https://en.wikipedia.org/wiki/Michael_Minovitch
> For me personally, I feel this project is the greatest engineering effort in human history bringing together the work of Newton, Kepler, the mathematics of the celestial navigation, gravitational assist techniques[1], etc. necessary to keep a little probe on its route accurately over 50 years in space.
All that and...
Lisp.
Ah, good, an opportunity to recommend It's Quieter in the Twilight (2022). Beautiful documentary.
https://www.imdb.com/title/tt17658964/
Pitch perfect.
A slight tangent here is a technical deep dive on Voyager 1 fixing a memory corruption error in 2023 by hand 15 billion miles away. Blows my mind of the reverse engineering done to achieve this https://www.youtube.com/watch?v=YcUycQoz0zg
Voyager program and the team behind it will always serve as an example for me. Over-the-space software updates, 50 years support life. Debugging and patching devices with no room for a mistake. How many of 2026 devices connected to internet will have that luxury in 2076?..
Not a very good title, given that the subtitle for the very same article gives the important context that "Voyager 2 would have had to shut down one of its last remaining instruments later this year, until NASA made some power changes."
(as an aside, a celebratory coffee mug for when Voyager 1 finally gets to the 1-light-day-from-earth mark would be very popular, in case anyone from the JPL store is reading this. 'Yesterday's sunrise, today!')
Move comments to source? https://news.ycombinator.com/item?id=49189895
I wish more robotic missions like that were sent. Not necessarily the most expensive ones, just one that can use only gravity assists and plutonium power generators. They could be relatively small ones. Maybe even trying to ride some of the small rocks/asteroids, now that we have a better catalogues of such.
If by "ride" you mean hitch a lift to somewhere you couldn't get to otherwise, space doesn't work like that.
If you want to land on an asteroid/rock, either you match speed with it, in which case you already had enough speed to go wherever it's going, or you intercept it at a different speed, in which case you get smashed to dust if your speed was any more than a few m/s different.
Maybe you didn't mean this, but it's a common enough misconception. People even on HN were suggesting a spacecraft could hitch a ride on ʻOumuamua to get a quick way to a different solar system.
I've always thought asteroids could be used as automated "weather stations" with probes not just as mission targets in themselves. These could be updated or maintained occasionally.
- stupid question: how much energy, power and what kind of systems would you need to run something for 80000 years to go all the way to proxima centauri
- how many redudancies would you need, how would it affect the payload?
- what kind of materials?
Relevant for Voyager I
https://www.youtube.com/watch?v=YQTfUB9AAnM&t=0
Power is possible, Thorium-230 has been pointed out as the ideal fuel for such a scenario. Very nice, long and energetic decay chain, 75ka half-life, many of the daughter products are relatively long-lived which helps to flatten out the power curve.
I don't think anyone has any clue how to build electronics that survive even a tenth of that time, though.
Also a bit of a pet peeve, if it takes you 80k years, you are not going to Proxima. The stars themselves are moving rather fast, and which is closest changes over time. The Alpha Centauri main binary becomes the closest in ~26ka with a close pass at ~3ly, Ross 248 also comes within 3ly in ~37ka. Lastly, Gliese 445 does a ~3.5ly flyby at ~45ka. After that, all the closest stars are receding, and Proxima is 5ly away.
Then eventually a million years later Gliese 710 does a 0.16ly flyby, straight through our oort cloud.
Even Voyager can’t retire in today's economy.
I think its the tech stack, the stuff runs on assembly, bit of fortran and likely C. You simply cannot match that level of reliability these days, because people started to forget how to do that... Look at cars and everything else...
But cars do have that level of reliability, in ECU (sans hardware I guess, still flash memory). It's just everything else around is ass
Usage of higher-level languages is in the labs and on the ground-station side of these missions. No FORTRAN interpreter runs on a space probe.
In the 1970s, there was a distinction between "machine language" and assembly language. Assembly (or assembler) language is the symbolic source code that a programmer would use. Machine language is the binary dump of the actual text segments that the CPU directly interprets to run.
Voyager runs on assembly. only 10 instructions. Very simple and real RISC processor
What is this shitshow of a website called space.com ? There's ads, popups everywhere!
Edit: For those who think I'm too harsh: https://imgur.com/a/YkmtOZ9
Great, but you've put it on an image host that cannot be accessed by the me, in the UK.
Even worse, imgur doesn't even have a cookie banner for me. To be in such violation of the GDPR is going to give me nightmares! /s
Source: https://science.nasa.gov/blogs/voyager/2026/08/04/nasa-engin...
how do we reconcile this with flat earth theory?
Just asking for a friend
It's nearly to the dome, and will crash any time now.
No need. The probes are about as real as birds are.
thirty-eight hour ping time, dang
3 AU per year ~ 300 million miles