CubeSats are fascinating learning tools for space
(jeffgeerling.com)166 points by warrenm 13 hours ago
166 points by warrenm 13 hours ago
I have launched raspberry pi based PicoBalloons and had one fly for over a year at 40k ft. They are remarkably resilient.
I have used CubeSats in LEO to make amateur radio contacts. AMSAT is trying to get one to MEO/HEO. New cubesats are being released frequently. Not all RPi based and usually custom PCBs. You can buy desk based CubeSats for STEM
> had one fly for over a year at 40k ft
inquiring minds want to know. was this tethered? what kind of clearance did you need and what kind of equipment was necessary for safety purposes?
It was connected to an Orbs 32” PicoBalloon
https://balloons.online/orbs-32-clear/
I used 36 awg wire and fishing line. The lower half of the dipole is also 36 awg wire.
No flight clearances are required
If any aircraft were to hit it, then it would be obliterated. This includes Cessna’s as well
As a bugsmasher pilot, I’d be most worried about 40k ft of fishing line wrapping itself around the spinny bits on the front. What’s the tensile strength on that stuff?
Doubt it’d cause an immediate issue, but doesn’t sound very fun to remove.
It’s not required at all. These are so small that they are not covered by like FAA type regulations
https://www.zachtek.com/product-page/wspr-tx-pico-transmitte...
Solar cells are polycrystalline. You can buy them on AliExpress (very brittle - takes practice soldering them)
I didn’t use the Traquito Solar truss. Too hard to solder. I used a foam dinner plate and solar tabbing wire
I concur with building picoballoons. It's much more economical. It's hard to recover from a malfunctioning rocket that carried your precious payload, but a burst Yokohama is just a learning lesson.
I prefer the Clear Orbs 32” these days due to the cost of Yokohamas
If you want to build a "mars rover" yourself you can even simulate that at home :-)
Use LoRa in the slowest and most reliable mode as radio link. Write software to plan your tours, firmware updates over super limited bandwidth (delta updates are a must), transfer telemetry (buy a few sensors from ali) or even pictures. Autonomous driving? Yes why not.
Bonus 1: build a small PCB with a solar panel and charging circuit. That doubles the horror.
Bonus 2: Place it into your families garden that is at least 1km away.
Lots of very hard challenges to tackle for even super experienced programmers.
It's even a nice group project for an university lab. If you have to connect a real debugger to get your bot running again your team lost.
You can do even more than that if you want to see it moving! And without designing it completely by yourself.
Designing it is half the fun :-) Chassis aren't expensive from far east - so it's mostly the electronics.
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?
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.
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.
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.
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.
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.
There are many Raspberry Pis on the International Space Station (AstroPis). They're subject to a similar amount of space radiation as CubeSats in LEO, and they work just fine. There's also an increasing trend of building CubeSat On-Board Computers (OBCs) as some form of Linux System-on-Module (these would traditionally be microcontrollers). I think Raspberry Pis (especially the Compute Modules) are quite suitable for Payload Data Handling (PDH) systems, although I've personally not had a chance to launch a RPi chip yet.
I personally haven’t seen confirmed SEUs in the satellites I’ve designed/operated (as in, an ionized particle affecting a transistor/MOSFET in a way that creates a short circuit and can only be cleared with a power cycle). But it’s good practice to design space systems to have current monitoring and automatically power off in case of such events.
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.
About 50% of cubesats fail, at least partially. I've worked with a dozen or so of them, supporting different people and companies trying to use them. Only one failed to work at all. But many of the others had serious problems of one kind or another that limited their usefulness.
Sattelites in LEO without the ability to boost their orbits back up will fall out of orbit in a few years due to natural atmospheric resistance. Exactly how long it takes depends on the shape and mass of the sattelite. It's of very very low Kessler syndrome risk.
>I’m really confused how you communicate with it? That seems like the most (expensive?) and technically difficult part.
Not really. They typically use standard amatuer radio frequencies and protocols. Making space to ground contacts is doable with a handheld radio and directional antenna. Main limitation is low data rates (dialup or worse) and low coverage (you'll probably only get 1-2 passes a day from a single ground station). A decent semi-permament ground station can be built from off the shelf parts at a fraction of the cost of the overall satellite.
A combination of amateur radio operators, university ground station cooperatives (most universities with a cubesat program set up their own and join something like UniCOGS), open source ground station networks like SatNOGS, and commercial services like AWS Ground Station.
On the satellite it’s just an off the shelf UHF/VHF transmitter or SDR.
it would be awesome for this to become popular enough to see teams of people race each other out of the solar system
Enough to maintain your CubeSat's orbit and do a bit of pointing, but you'd need something bigger to have the propellant and power to get out of the solar system
Very very little, but not nothing. I've seen a few tiny deployable solar sails and a few tiny electric motors in my brief research for my video. They seem mostly experimental, to test out theories and miniaturization.
It's beyond cool you can pretty cheaply get cube sats on Space X rockets too
...so how do you keep it secure?
I didn't see a lot of detail at https://ethoslabs.space/ besides a Contact Us form, but it sounds like a fascinating problem.
Is hosting a RPi in space different from hosting one on the ground, reachable over the public internet? I assume it is, but tell me more!
> ...so how do you keep it secure? > Is hosting a RPi in space different from hosting one on the ground, reachable over the public internet? I assume it is, but tell me more!
It is somewhat different from a security point of view, but the gap between them is getting smaller. The main "obstacle" to hackers taking over your satellite is that it is somewhat difficult to set up a UHF/VHF/S-band ground station with enough transmit power to reach the satellite. And you need knowledge of the command protocol that the satellite uses. But ground stations are getting cheaper every day, IMO you can build a fairly capable transmitting setup for ~1000€. So the remaining protection is a form of security by obscurity: "we invented this command protocol, so nobody knows how it works". But that can obviously be defeated by recording ground station signals and some dedicated reverse engineers.
When those protections fall away, you'll find that a lot of satellite/CubeSat software out there is quite vulnerable (see https://jwillbold.com/paper/willbold2023spaceodyssey.pdf). You often find things like commands that are literally "arbitrary memory read/write". While they are a nightmare from a security point of view, they are extremely useful for operators of experimental satellites, e.g. to patch software in memory to fix bugs or read variables that are not exposed as telemetry. I have written a few of these patches myself, and my friend PistonMiner used them brilliantly to hack in a software update capability and revived a 15 year old CubeSat that was assumed to be dead - see their 38C3 talk: https://www.youtube.com/watch?v=KdTcd94pVlY
If you ask me, the way to keep satellites secure is to basically apply the lessons that we have learned in terrestrial computing to space applications. Things like using encryption/authentication, process isolation backed by a MMU, memory safe languages, etc. That's what we're trying to do with RACCOON OS btw. You can take at the flight software of CyBEEsat, a 1U CubeSat that is launching soon(tm): https://gitlab.com/rccn/missions/cybeesat
> So the remaining protection is a form of security by obscurity: "we invented this command protocol, so nobody knows how it works".
ChaCha20-Poly1305 authenticated encryption is cheap for low-resource systems and trivial to implement. There's no reason not to use some form of encryption, if at least to prevent forged commands. (Preventing replay attacks is left as an exercise to the reader.)
There are some reasons. As a satellite operator, the worst thing that can happen is getting locked out of the satellite for any reason. So the risk of implementing a “new” technology that has a high risk of locking you out if you lose the keys for some reason sometimes outweighs the benefit of increased security. So I think there’s some work to do in building generally applicable key management practices and backup ways of reestablishing a command link.
Embedded guys don't like command authentications, I think because it's an SPoF with probability attached that are repeatedly tried. They know bits flip and program counter skips, and so they even avoid use of "or equals to" conditions for loops. But they're using signature enforcement in cars nowadays, so that particular fear should be slowly subsidizing.
This takes me down a memory lane! For my undergrad capstone project, we made a cubesat tracker for our university's satellite using a RPi/Arduino/Software-defined-radio to receive transmissions every time it passed over us. I cringe a little looking at the code now - but it worked!
I agree, cubsats are a wonderful way, for college students even, to tinker with space(-adjacent) tech.
https://github.com/hazrmard/SatTrack