In my experience, having provided advice to a lot of academic CubeSats: the issues usually aren't related to the parts, the problems are usually lack of testing and general inexperience.

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.

▲

minetest2048 6 hours ago | parent | next [-]

As someone that have successfully flown a RPi CM4 based payload on a cubesat, I fully agree with this. There's not enough funding in my research group to hire a dedicated test engineer so I need to both design and test my payload. It was a long lonely road

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

▲

NoiseBert69 a day ago | parent | prev | next [-]

It's a bit like balloon projects that have a transmitter. I think now the 20th group found out that standard GPS receivers stop reporting data of at a specific height because of the COCOM limit implementation (They 'or' speed and height). Well.. there are quite a few modules around that 'and' this rule and so work perfectly fine in great heights.

It's all about the learning experience and evolution of these projects. Mistakes must happen.. but learning from them should take place too.

▲

dylan604 a day ago | parent [-]

That's kind of how I was thinking about it. Why does each cubesat project have to start over from scratch? Why isn't there a basic set of projects that a team can build on top of to make their own custom sensors for their purpose, but the basic operational stuff like the suggested multiple storage types with redundant code shouldn't need to be recreated each time. Just continue using what worked, and tweak what didn't. No need to constantly reinvent the wheel just because it's students learning.

▲

Sanzig a day ago | parent | next [-]

Yep, but students love reinventing the wheel ;).

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.

▲

marcosdumay 21 hours ago | parent | next [-]

Well, the point of a student's project is to 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.

▲

warrenm a day ago | parent | prev | next [-]

>Yep, but students love reinventing the wheel ;).

And ... professors love making students reinvent the wheel

▲

dylan604 21 hours ago | parent [-]

I thought professors loved making students by the latest version of the book they wrote discussing how the wheel was invented

	▲	warrenm 13 hours ago \| parent [-]
		And that

▲

jdiez17 a day ago | parent | prev | next [-]

Seems like we have similar thoughts as we wrote more or less the same comment 10 minutes apart :) Would love to chat about this, maybe we figure out a way to get there? Email is on my profile.

	▲	Sanzig 19 hours ago \| parent [-]
		Email sent. I am generally very busy with family commitments but happy to stay in touch.

▲

Palomides 16 hours ago | parent | prev | next [-]

have you seen https://github.com/the-aerospace-corporation/satcat5 ? sadly I don't have the FPGA skills to play with it, but the features are very cool

▲

vodou a day ago | parent | prev | next [-]

Not just students TBH...

▲

knowaveragejoe 21 hours ago | parent | prev [-]

> 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%

Surely this, or something like it, exists?

	▲	Sanzig 19 hours ago \| parent [-]
		Not really. There are a couple of open source projects (LibreCube being the biggest example) but they aren't flight-ready.

▲

NoiseBert69 a day ago | parent | prev [-]

And it would be much cheaper 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.

▲

jdiez17 a day ago | parent [-]

My dream is to build an open source CubeSat kit (hardware, software, mission control software) with an experience similar to Arduino. Download GUI, load up some examples, and you're directly writing space applications. Ideally should be capable of high end functions like attitude control and propulsion. The problem is that designing and testing such a thing is a rather expensive endeavour. So far I haven't found a way to get funds to dedicate time on this kind of "abstract"/generic project, most funding organizations want a specific mission proposal that ends generating useful data from space.

	▲	warrenm a day ago \| parent [-]
		Sounds like you have yourself a YCombinator startup proposal in the making

▲

mannyv 20 hours ago | parent | prev [-]

I wondered about the radiation hardening aspect.

At one altitude does that make a difference?

▲

Sanzig 19 hours ago | parent | next [-]

The annoying answer is "it depends." The main drivers are reliability (ie: how much risk of failure are you willing to accept) and mission life (ionizing dose is cumulative, so a 2 year vs. 10 year mission will have different requirements).

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.

▲

kulahan 18 hours ago | parent | prev [-]

Always wondered if you could mitigate this somewhat by basically putting your sat in a bag of water and leaving the antenna and solar panels sticking out.

	▲	Sanzig 16 hours ago \| parent [-]
		Not really. Radiation shielding has diminishing returns with thickness as the relationship is logarithmic. A few millimeters of aluminum cuts down most of your ionizing dose by orders of magnitude over unshielded, but doing appreciably better requires impractically thick shields. 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.