Days before NASA's New Horizons probe to Pluto experienced a technical issue, the Dawn spacecraft orbiting Ceres "experienced an anomaly":
NASA's Dawn spacecraft is healthy and stable, after experiencing an anomaly in the system that controls its orientation. It is still in its second mapping orbit 2,700 miles (4,400 kilometers) above dwarf planet Ceres.
On June 30, shortly after turning on its ion engine to begin the gradual spiral down to the next mapping orbit, its protective software detected the anomaly. Dawn responded as designed by stopping all activities (including thrusting), reconfiguring its systems to safe mode and transmitting a radio signal to request further instructions. On July 1 and 2, engineers made configuration changes needed to return the spacecraft to its normal operating mode. The spacecraft is out of safe mode, using the main antenna to communicate with Earth.
The Dawn issue is less serious than problems with New Horizons since the third and fourth mapping orbits can be executed whenever NASA is ready, and the final orbit around Ceres will last indefinitely. By contrast, New Horizons will speed past Pluto and reach its closest approach on July 14th at 11:49:57 UTC at a relative velocity of 13.78 km/s. After collecting data from Pluto, NASA will try to steer New Horizons towards one or two Kuiper belt objects within a narrow cone extending from Pluto.
NASA engineers have released an explanation for the July 4th glitch:
To prepare for these final days of its mission, the probe was doing two things at once. First, it was taking the scientific data it has already harvested, compressing it, and writing it to a portion of its 128 Gbit storage (two 8GB solid-state recorders). At the same time the instrument command sequence for the flyby was being uploaded. The combined workload slightly exceeded the processor's capabilities, and triggered a watchdog-like feature. This switched the main computer system over to the backup computer, while putting the main system into sleep mode as a safety measure. The processor is a Mongoose-V: a 12MHz MIPS R3000 CPU hardened against radiation. The R3000 is a 32-bit chip that's pretty similar to the one used in the original 1994-era Sony PlayStation among many other devices.
Original Submission
Related Stories
NASA's mission to Pluto lost contact with ground controllers http://www.forbes.com/sites/brucedorminey/2015/07/05/nasa-loses-contact-with-new-horizons-pluto-spacecraft-enters-safe-mode/ and went into "safe mode" when contact was re-established.
Ten days before NASA 's New Horizons spacecraft was due to make its closest approach to Pluto, the space agency reports that at 1:54 PM EDT on the afternoon of July 4th local U.S. time, it lost contact with the $700 million unmanned flyby mission for more than an hour and twenty minutes. Controllers were able to regain a signal from the probe via NASA's Deep Space Network at 3:15 PM. EDT, but as a result, the spacecraft's systems have entered safe mode until mission engineers can diagnose the problem.
Of course, New Horizons is way out there, which makes communications difficult.
Recovery from the event is inherently hamstrung due to the 9-hour, round trip communication delay that the agency says "results from operating a spacecraft almost 3 billion miles (4.9 billion kilometers) from Earth.
Fly-by is scheduled to take place on July 14th. Can't help but wonder if this is not revenge for being demoted to a dwarf planet.
Original Submission
(Score: 4, Funny) by jasassin on Tuesday July 07 2015, @11:56AM
It was probably a Maxtor.
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 2) by Gravis on Tuesday July 07 2015, @01:16PM
what i don't understand is why does it have such a large drive? you gotta figure that they are sending back the data as fast they can, so why does it have such a large buffer? did they put MP3s on it for when the probe gets bored or something?
(Score: 5, Insightful) by slinches on Tuesday July 07 2015, @01:53PM
It's cache space. This probe's mission is to do fly-bys of objects past the orbit of the outermost planet in the solar system. Data transfer rates over those kinds of astronomical distances are extremely slow compared to current internet standards. Combined with only having a relatively brief window to capture high quality data, a large buffer makes sense.
(Score: 0) by Anonymous Coward on Wednesday July 08 2015, @01:28AM
(Score: 2) by iWantToKeepAnon on Tuesday July 07 2015, @01:21PM
I know what New Horizons is, but I don't know many details. What did "final days of its mission" include and what is now different? Was New Horizons going to orbit Pluto or was it always supposed to speed by? Is it going to fail some of its mission objectives b/c of the malfunction?
"Happy families are all alike; every unhappy family is unhappy in its own way." -- Anna Karenina by Leo Tolstoy
(Score: 1) by Bromine001 on Tuesday July 07 2015, @01:59PM
It's going to do a flyby on Pluto.
It's not expected to see anything interesting after that, I believe.
(Score: 2) by takyon on Tuesday July 07 2015, @05:16PM
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 4, Informative) by nitehawk214 on Tuesday July 07 2015, @02:00PM
New Horizons was never going to orbit Pluto. It is going way way too fast. In order to orbit Pluto its orbital trajectory would have needed to have been slowing down just as it reaches Pluto. The problem with that is it would take maybe a century to arrive at the right speed. I believe NH is still going about twice Earth's escape velocity, and Pluto and Charon combined is not even the mass of the Moon.
If they did not get it back to normal operating systems before the flyby... well, then they missed it and its a billion dollars down the toilet.
I know NH's mission is to head into the Kupier Belt to study something else, but I did not think they had yet found a suitable target.
"Don't you ever miss the days when you used to be nostalgic?" -Loiosh
(Score: 1) by nitehawk214 on Tuesday July 07 2015, @02:03PM
Correction, Hubble has found a couple of targets [wikipedia.org] that NH can reach.
"Don't you ever miss the days when you used to be nostalgic?" -Loiosh
(Score: 4, Interesting) by VLM on Tuesday July 07 2015, @02:18PM
always supposed to speed by
Yes. "The mission" is pretty much the time that its local cameras get better images than hubble and thats a couple months. Obviously non-imaging data is important too. A little more than a week till closest approach. I guess you'd say the pluto mission is only about 45% complete so calling this its final days is a little journalistic, but whatever.
what is now different
Not much, they've been imaging like crazy on the way in, just in case there's some previously undiscovered moon in the flightpath, they could navigate out of the way, optimistically. But it seems the path is clear. Murphys law if they hadn't spent all this effort looking then hubble would see a bright flash as it hit an undiscovered moon at full speed, LOL. Also they lost a couple days of data, obviously while its in safe mode there's no science downlink and they need the storage space for closest approach, so hopefully we didn't miss any black monoliths or bug eyed monsters or WTF. Also I guess this is one stressful way to prove the watchdog timer works just fine, along with safe mode procedures, and seeing just how far this thing can be pushed to perform. I suppose better now than during closest approach.
I've been watching this mission for a couple years, thought about taking "the day" off for closest approach, but downlink is going to take hours, data embargoes, etc, so theres probably going to be nothing to actually see for months other than the usual bone they throw to the journalists and I don't need a day off for that.
(Score: 1, Interesting) by Anonymous Coward on Tuesday July 07 2015, @01:51PM
They couldn't nice(1) the compression process to allow the more critical workload to take priority?
(Score: 3, Informative) by forkazoo on Tuesday July 07 2015, @05:37PM
Basically, having a "nice" would mean sacrificing some of the hard real-time guarantees that they need for the rest of the system. It would also mean extra code that needs to be vetted as being solid enough to run far far away from remote hands that can reboot it for you. People will make fun of teh fact that it went into safe mode, but the reality is that the core of the spacecraft software is robust enough to have a watchdog capable of putting it into a safe mode, which is way more robust that your average web server. It can stay functional when being bombarded with crazy radiation and still stay at least partially up. It just has to be paranoid to do it.
(Score: 2) by quacking duck on Tuesday July 07 2015, @01:55PM
I'm a bit impressed at the size of the hard drive (128 GB), considering how deep space tech is usually years, even decades behind commercially available products in terms of power and capacity to ensure reliability and radiation hardening.
The probe arrived at the launch centre in late 2005 for an early 2006 launch, meaning its design specs were probably frozen several years earlier. Looking at the history of hard drive tech, the 137 GB addressing space space barrier was only broken in 2002, and the first 500 GB drive was shipped in 2005.
Maybe NASA's just simplifying the storage into everyday terms? It's definitely not spinning platters since they don't work in vacuum, but if it's flash-style memory that seems even more impressive. I suppose RAIDing several smaller drives is possible, to increase overall capacity as well as redundancy.
(Score: 5, Informative) by nitehawk214 on Tuesday July 07 2015, @02:22PM
I wonder where they got the 128GB from. This page [jhuapl.edu] says it has a pair 8GB solid state drives with one as a backup. The wikipeida page also uses the 8GB figure.
8GB is a much more believable figure considering the age of this tech and how space equipment can't be bleeding edge.
"Don't you ever miss the days when you used to be nostalgic?" -Loiosh
(Score: 2) by draconx on Tuesday July 07 2015, @05:35PM
The error in the article appears to have been corrected:
(Score: 3, Informative) by forkazoo on Tuesday July 07 2015, @05:41PM
Well, 8 Gigabytes is 64 gigabits. A pair of 8 Gigabyte devices is 128 gigabits. I don't have any specific insight into the hardware on the spacecraft, but the math checks out so I am wondering if that's where the confusion is coming from?
(Score: 3, Informative) by takyon on Tuesday July 07 2015, @08:17PM
I sent your link to the Reg editor, and it was corrected there and here. Thanks.
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 3, Informative) by VLM on Tuesday July 07 2015, @02:30PM
137 GB addressing space space barrier
IDE protocol limitation. Never existed for SCSI drives. Can't remember off the top of my head if any R3000 CPU based workstations ever used IDE drives although PATA IDE is/was so crude at a hardware level that it would be trivially technically possible to make a R3000 based machine that used IDE drives.
I'm not sure if anyone ever made large aerospace grade IDE drives. I have a laptop size industrial / automotive grade PATA drive laying around somewhere so "sorta hardened" IDE drives once existed.
I wonder if the playstation cdrom-ish drive was IDE or SCSI or some whacked out proprietary thing (like mitsumi which was kinda PATA but not PATA)
Could not find anything online about the new horizons computer system beyond the usual "Its a R3000 CPU just like a playstation".
(Score: 2) by quacking duck on Tuesday July 07 2015, @03:38PM
Thanks; the wiki article [wikipedia.org] I got that from unfortunately didn't specify this was an IDE limitation.
(Score: 0) by Anonymous Coward on Wednesday July 08 2015, @08:28AM
the summary says 128 Gbits, not GBytes. 128 Gbits is 16 GBs, which matches the mention of two 8GB SSDs.
(Score: 2) by takyon on Thursday July 09 2015, @07:42AM
I stealth corrected it and got TFA corrected too.
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 0) by Anonymous Coward on Wednesday July 08 2015, @03:21AM
To prepare for these final days of its mission, the probe was doing two things at once. ... The combined workload slightly exceeded the processor's capabilities, and triggered a watchdog-like feature.
Who screwed up to trigger that watchdog? I thought the ground crew always had an exact copy of the computer on the spacecraft -- to test out any new command sequences before sending them out?
Maybe they are running some emulator that isn't exactly the same? Or they haven't perfectly emulated the sensor data that the satellite computer is dealing with? This seems like the sort of error that should never happen.
(Score: 0) by Anonymous Coward on Wednesday July 08 2015, @09:15PM
I've read that the load was only SLIGHTLY more than than processor could handle. Since the purpose of the compression was to archive stuff not yet sent (to be sent after the encounter), the local probe emulator may have had to use dummy place-holder data that didn't push the processor past the limit. A future solution may be to always fill in dummy place-holder data with worse-case processing and/or size levels. Since compression processing time and result size may not be maximizable at the same time, they may have to make 2 runs. It wouldn't hurt to run it with minimal load/size tests also.