I've always wondered how well these RPi based cubesats really work in space. Really hard to find out. Also, people (naturally) aren't always eager to talk about failed projects. Maybe some people here on HN have experiences to share?
Yes, a Raspberry Pi isn't radiation hardened, but in LEO (say around 400-500 km) the radiation environment isn't that severe. Total ionizing dose is not a problem. High energy particles causing single event effects are an issue, but these can be addressed with design mitigations: a window watchdog timer to reset the Pi, multiple copies of flight software on different flash ICs to switch between if one copy is corrupted, latchup detection circuits, etc. None of these mitigations require expensive space qualified hardware to reasonably address.
The usual issues I see in academic CubeSats are mostly programmatic. These things are usually built by students, and generally speaking a CubeSat project is just a bit too long (3-4 years design and build + 1-2 years operations) to have good continuity of personnel, you usually have nobody left at the end there since the beginning except the principal investigator and maybe a couple PhD students.
And since everyone is very green (for many students, this is their first serious multidisciplinary development effort) people are bound to make mistakes. Now, that's a good thing, the whole point is learning. The problem is that extensive testing is usually neglected on academic CubeSats, either because of time pressure to meet a launch date or the team simply doesn't know how to test effectively. So, they'll launch it, and it'll be DOA on orbit since nobody did a fully integrated test campaign.
It's all about the learning experience and evolution of these projects. Mistakes must happen.. but learning from them should take place too.
Imaging a group building an managing a robust power supply design for Cubesats that can be immediately ordered from JLCPCB. With a well maintain BOM list.
I agree though, my dream for years has been an open source CubeSat bus design that covers say 80% of academic CubeSat use cases and can be modified by the user for the other 20%. Unfortunately I have very little free time these days with family commitments.
And ... professors love making students reinvent the wheel
One should limit the number of wheels being reinvented each time, though. What would also reduce the time-to-space of those projects. The design should cover 100% of the CubeSat, so the students can redesign any part they want.
Surely this, or something like it, exists?
At one altitude does that make a difference?
I would say you certainly need to start seriously considering at least some radiation hardening at around 600 km, but missions that can accept a large amount of risk to keep costs down still operate at that altitude with non-hardened parts. Likewise, missions with critical reliability requirements like the International Space Station use radiation hardening even down at 400 km.
The "hard" limit is probably around 1000 km, which is where the inner Van Allen Belt starts. At this altitude, hardware that isn't specifically radiation hardened will fail quickly.
The inner Van Allen Belt also has a bulge that goes down as low as 200 km (the South Atlantic Anomaly), so missions in low inclined orbits that spend a lot of time there or missions that need good reliability when flying through the SAA may also need radiation hardening at comparatively low altitudes.
And that only helps with ionizing dose, which is already not really a problem in LEO. The issue is more high energy particles like cosmic rays, which cause single event effects (SEEs) - things like random bit flips in RAM or CPU registers, or transistor latchup that can cause destructive shorts to ground if not mitigated. These are impractical to shield against, unless you want to fly a few feet of lead. So instead we mitigate them (ECC memory, watchdog timers, latchup supervisor circuits that can quickly power cycle a system to clear a latchup before it can cause damage, etc).
If you want to get an idea of how much shielding is effective in a particular orbit, you can use ESA's SPENVIS software (online, free): https://www.spenvis.oma.be/. Despite being free, it's the tool of choice for initial radiation studies for many space missions worldwide.
It does work at the end, but shortly after we got our first data from space, I decided to quit the space industry and become a test engineer at a terrestrial embedded company instead
Resets etc. are common, most likely caused by software bugs. This is more or less assumed as a fact of life; software for space applications is often as stateless as possible, and when it’s required you’d implement frequent state checkpoints, redundant data storage, etc. These are all common practices that you’d do anyway, it doesn’t make a huge difference if the software is running on a rad-hard microcontroller or off the shelf Linux processor - although (IMO) there are many benefits to the latter (and some downsides as well.) Assuming a base level of reliability, of course - you don’t want your OBC/PDH to overheat or reboot every 5 minutes.