SoylentNews is people
SoylentNews
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
(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.