Or is just crazy luck and the thing avoided the beams ? Might be plausible, if the last flight is not explained, it was the one flight with less radiation luck ?
Or is just crazy luck and the thing avoided the beams ? Might be plausible, if the last flight is not explained, it was the one flight with less radiation luck ?
Edit: database here, but I haven't looked for data on the chip: https://radhome.gsfc.nasa.gov/radhome/raddatabase/raddatabas...
I wonder why they are testing GPUs? I would imagine there are at least some people somewhere writing papers about sending GPUs on rovers etc for better on-device AI/ML (e.g. image processing)
Also: brief mention of raspberry pi (no dedicated wreite-up like the GPU): https://nepp.nasa.gov/files/27888/NEPP-CP-2015-Campola-Paper...
Not surprised that they didn't do TID as it was only supposed to be a 90 day demo mission so not terribly long. And TID can be a costly test because it can take so long.
As to the GPUs, yeah the main application is some processing when you are comm bandwidth constrained. Then you can send down processed products or snapshots from something that is collecting a lot of data (like large imager or high bandwidth SDR)
Goddard does quite a lot of work on camera-based RPO (rendezvous and proximity operations) which require cameras and lidars to image a client spacecraft and calculate relative pose. This is the single most computationally taxing operation for robotic satellite servicing missions.
Rather, they're turning to other options to achieve rad tolerance in critical systems, stuff like soft cores specifically designed for redundancy running on radiation hardened FPGAs.
Also, the rad tolerant parts aren't there to do the crazy high speed work. When people talk about voting architectures with redundant COTS parts, what do you think is counting the votes and resetting the effected systems?