Voyager 1 regains sanity after engineers patch around problematic memory NASA's Voyager 1 spacecraft has begun returning usable engineering data after engineers devised a way to work around a damaged memory chip. It is the first time the spacecraft has returned usable data since it began babbling nonsensically in 2023. The problem was eventually traced to a single chip responsible for storing a …
Human ingenuity --->
I wonder if AI was involved?
Assuming not, I wonder what it would have recommended: "More adverts before downloads."
On the other hand, could Copilot have been 'helping' with the transmission? "Looks like you're trying to send data. Would you like me to cock that up for you?"
According to NASA, there's about 68KB of memory in total. The FDS have 8198 16 bit words, so about 16KB for each FDS computer. I've created an empty Word doc which is actually just under 12KB as .docx and 26KB as .doc, so it depends on the format you want to save it as. Word used to be a lot worse I recall, so it also depends on which version you're using...
Regardless of that comparison, 8198 words doesn't give a lot of wiggle room to move stuff about...
Not sure what the processor(s) will be, but many of that generation (I'm thinking Z80, as that's what I learnt) traded "jump" space with functionality. Eg, the Z80 had a JR instruction was 2 bytes and could jump +-128 bytes. Whereas the JP instruction took 3 bytes - but could jump anywhere in the 64kb address space.
JR was your friend if you had either limited memory or code that needed to relocate as it didn't contain an absolute address
Downside being JR took longer than a JP
Retrive program counter, add the displacement to it, jump to that location
where as a JP was replace program counter with address (unless you were storing the address in memory pointed to by the HL register pair... but then you could do all sorts of fun with that.... such as a jump table that depended on a a calculated result)
<<wandering well off topic......
Icon... for excellent boffinery by JPL
A lot of code used a jump table - a list at a known address of jumps to each routine, so you could move the code around without changing external access. Some people at work once managed to hex dump the computer's code on the screen and were going "Wow, that's computer code". I took one look at the list of C3nnC3nnC3nn . . . and said "No, that's a jump table".
"The solution was to break the code into sections, tweak them so they still functioned as a whole, and store them in different places in the FDS."
A colleague and I used this approach in the very early eighties, to upgrade ROM-based applications for Acorn computers (fitting 4k EPROMs). We looked for unused spaces, or spaces that could be released by simplifying existing code, that were long enough for a few new instructions plus a jump in and out, and broke the new code into fragments to fit.
Nice that the technique hasn't been forgotten in this age of coding while ignoring the hardware.
Given the age of the hardware it's probably not that susceptible to radiation, even if it's not specifically rad-hardened, but get beyond the heliosphere and you're likely to get hit by a few very high energy particles. It'd be interesting to know if that's what happened here or if it's just the hardware showing its age.
No DevOps here - maturity and hundreds of years of experience!
Take a look at the scribbles on their whiteboard - looks like they have the signal clock (SC freq) and data bit pulse width calculations along with some amplitude compression recovery.
https://www.jpl.nasa.gov/news/nasas-voyager-1-resumes-sending-engineering-updates-to-earth
Nice to see them putting the ACE back in hACkEr !
or it makes ME think, of the difference between my first computer (a 48K Sinclair Spectrum) and my current Desktop. I got immense pleasure playing the spectacular (for its time) games on the "Speccy", and joy from the simple programs in BASIC I typed in from the micro magazines of the day. Probably more so as computers were a marvel to us then. My current box (2018 vintage), is way over powered and bloated (program/code wise) for what it is used for, By the time 47 years have gone by from now, no-one will be able to fix it like those Voyager 1 NASA guys and Gals!
I write a bit of JavaScript or whatever and high five myself for solving a silly problem.
Then I read this.
These people are so frickin’ smart I can’t even begin to imagine. I’m also glad I don’t have to deal with their deeper intellectual prowess than mine, given the mental struggles I have.
《The solution was to break the code into sections, tweak them so they still functioned as a whole, and store them in different places in the FDS. Any references to the code's location would also need to be updated.》
I (very) vaguely recall the Amiga OS originally(?) scatter loaded code into physical memory. The M68K had a wealth of addressing modes (much like the pdp11) which probably made this feasible unlike the x86.
In this situation today I would build an optomising tool chain to replicate the original code's function but in less space and constrained by a somewhat peculiar memory layout or model. Although you might end up with a threaded code forth interpreter. ;)
Still not to diminish this human achievement spanning unimaginable distances and nearly 50 years of time.
My personal record for remotely fiddling with kit is 13,000km (server in Johannesburg, me in Rotterdam). I scheduled an 'at' job in 10 minutes to reverse my changes and rebooting the server in case something wet wrong and the server would be left unreachable. Which was a good thing because I did cock it up at first.
But this? Wow. Just wow. Imagine:
$ ping -c 1 voyager1
PING voyager1 (128.156.0.1) 56(84) bytes of data.
64 bytes from voyager1 (128.156.0.1): icmp_seq=1 ttl=64 time=4.90 ms
--- voyager1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 163202000.606/163202000.606/163202000.606/0.000 ms
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
