A consumer chip is a lot more likely to be permanently damaged by a "silver bullet" cosmic ray, though. Rad-hard chips don't just have shielding, they can also have redundant circuits and modifications to the foundry process. That said, I'm sure Ingenuity's processor is fit to purpose.

It's a bit of a shame that radiation hardened chips are stuck so far in the past.

I believe the volume is so low it does not warrant the investment to make radiation hardened versions more often.

Actually being stuck in the past might be a feature. Denser circuitry is likely to be more vulnerable to interference by ionising radiation and more vulnerable to physical damage from high energy particles.

Parts of hardening include enlarging physical features and increasing operating voltage

> A consumer chip is a lot more likely to be permanently damaged by a "silver bullet" cosmic ray, though.

How much more likely? Are the odds all that high over the mission duration?

I don't have any numbers for you, but here's a starting source: https://hps.org/publicinformation/ate/q11162.html

Most of my knowledge of the subject is from a friend who did his PhD dissertation on it; specifically, triply-redundant adder circuits for single-bit operations, allowing for some rad-hard chip designs using regular foundry processes.

Reminds me of SpaceX or Erlang; build a process that handles errors rather than an error free process.

I mean its space. Any computer expected to be in space and do non completely trivial things have tons of mechanisms in place to survive computer issues.

Reminds me of Apollo 11, where the computer kept resetting on the way down to the lunar surface but still got Neil Armstrong and Buzz Aldrin to the moon with the whole world watching.

It wasn't resetting, it was ditching lower priority tasks that it didn't have (real) time to accomplish. Notably, the computer was still doing important work (ahem, flying the LM :-) ), and the tasks it didn't have time to do were not critical.

The team had recently seen similar failures in simulation, and was able to quickly decide it was okay to proceed.

> Notably, the computer was still doing important work (ahem, flying the LM :-) ), and the tasks it didn't have time to do were not critical.

I believe this is incorrect. From an earlier HN discussion:

"The 1202s were also a lot less benign than is often reported. They occurred because of the fixed two-second guidance cycle in the landing software. That is, once every two seconds, a job called the SERVICER would start. SERVICER had many tasks during the landing. In order: navigation, guidance, commanding throttle, commanding attitude, and updating displays. With an excessive load as caused by the CDU, new SERVICERs were starting before old ones could finish. Eventually there would be two many old SERVICERs hanging around, and when the time came to start a new one, there would be no slots for new jobs available. When this happened, the EXECUTIVE (job scheduler) would issue a 1201 or 1202 alarm and cause a soft restart of the computer. Every job and task was flushed, and the computer started up fresh, resuming from its last checkpoint. It was essentially a full-on crash and restart, rather than a graceful cancellation of a few jobs. And unlike is often said, the computer wasn't dropping low-priority things; it was failing to complete the most critical job of the landing, the SERVICER.

Luckily, the load was light enough that of the SERVICER's duties, the old SERVICER was usually in the final display updating code when it got preempted by a new SERVICER. This caused times in the descent when the display stopped updating entirely, but the flight proceeded mostly as usual. However, with slightly more load, it was fully possible that the SERVICER could have been preempted in the attitude control portion of the code, or worse yet, the throttle control portion. Since each SERVICER shared the same memory location as the last one (since there was only ever supposed to be one running at a time), this could lead to violent attitude or throttle excursions, which would have certainly called for an abort. Luckily, this didn't happen -- and the flight controllers didn't abort the mission not because 1202s were always safe, but because they didn't understand just how bad it could be, were the load just a tiny bit higher."

[1] https://news.ycombinator.com/item?id=20791307

Yes, there's a flight qualified microsemi FPGA (a ProASIC, I think) that acts as a supervisor for the vehicle.

Presumably. That is all part of this test.