Recently, the New Horizons spacecraft on its way to Pluto suffered a "hard-to-detect timing flaw in the spacecraft command sequence." Does that mean that it was a multi-threading error or something like that? What kind of data would be sent back to Earth to help the NASA diagnose the issue? Would they receive a stack trace? I imagine that the enormous distance would cause some unreliability in the transmission besides the 4.5 hour transmission time, so I would guess that the data that gets sent back and forth needs to be rather minimal.


2 Answers 2


The first clue was in which frequency the spacecraft switched to, so they learned a great deal just from reestablishing communications lock. Then, it appears that the necessary data was in the normal housekeeping data/logfiles, as no special data collection is mentioned.

Multithreading was not the issue and in fact, the software never crashed. It was simply asked to do two computationally intensive things at once: (1) compress science data and (2) copy a command load to non-volatile memory. Doing so used more CPU percentage than the system expected, and the fault management systems decided that the processor was misbehaving, and forced a switch to the backup computer. A stack trace would not have been helpful in this case.

Source: Washington Post

  • $\begingroup$ But where were the log files living? It seems like it would be a lot of data to send log files back from Pluto. $\endgroup$
    – Daniel
    Commented Jul 10, 2015 at 20:59
  • $\begingroup$ This doesn't really address the question $\endgroup$
    – Daniel
    Commented Jul 10, 2015 at 21:06
  • $\begingroup$ Hopefully it addresses your title question. It's up to project management to decide what data to release and I don't want to release any information without their approval. I'll edit my answer re:multithreading, though $\endgroup$ Commented Jul 10, 2015 at 21:20

New Horizons carries two computer systems. As the New Horizons team posted on July 4:

The mission operations center at the Johns Hopkins University Applied Physics Laboratory, Laurel, Maryland, lost contact with the unmanned spacecraft -- now 10 days from arrival at Pluto -- at 1:54 p.m. EDT, and regained communications with New Horizons at 3:15 p.m. EDT, through NASA’s Deep Space Network.

During that time the autonomous autopilot on board the spacecraft recognized a problem and – as it’s programmed to do in such a situation – switched from the main to the backup computer. The autopilot placed the spacecraft in “safe mode,” and commanded the backup computer to reinitiate communication with Earth. New Horizons then began to transmit telemetry to help engineers diagnose the problem.

On July 5, they posted this, and explained the problem:

The investigation into the anomaly that caused New Horizons to enter "safe mode" on July 4 has concluded that no hardware or software fault occurred on the spacecraft. The underlying cause of the incident was a hard-to-detect timing flaw in the spacecraft command sequence that occurred during an operation to prepare for the close flyby. No similar operations are planned for the remainder of the Pluto encounter.

"I'm pleased that our mission team quickly identified the problem and assured the health of the spacecraft," said Jim Green, NASA's Director of Planetary Science. "Now - with Pluto in our sights - we're on the verge of returning to normal operations and going for the gold."

They mentioned nothing about needing to download logs, just "telemetry", and given the communications lag and rapidity that they diagnosed the issue, I doubt they downloaded much data. I know little about the technical details, but I would be absolutely shocked if they didn't have a simulator or duplicate MIPS R3000 CPU on Earth.

I presume they simply replicated the series of commands they sent to the probe to their "virtual New Horizons" computer on Earth, and realized the error of their timing glitch. The error, while they say was hard to detect, is perhaps (very simplified) something along the lines of:

  1. Command A executed.
  2. Probe requires X seconds to reorient.
  3. Command B executed Y seconds later.

Y < X. Command B Fails. Computer detects failure, switches to backup, phones home.

  • 1
    $\begingroup$ Basically, yes, but Command A was to compress science data, and Command B was to copy a command load to non-volatile memory. $\endgroup$ Commented Jul 10, 2015 at 21:24
  • 1
    $\begingroup$ @NateParsons Thanks Nate, I upvoted your answer because you found an excellent article with the details! ;-) $\endgroup$
    – ghoppe
    Commented Jul 10, 2015 at 21:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.