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.
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
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.
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.
Yes, it is not tethered to the ground. The balloon is at the top, then 36awg wire, then solar panels and raspberry pi, then wire hanging down for lower half of dipole
Both top and lower part of dipoles are soldered to Raspberry Pi
It uses WSPR. Some of them use APRS but it is less common
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.
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.
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.
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.
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.
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.
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.
So it costs $85k to launch such cubesat. Too expensive for almost all of us. But if the cost comes down to say $5k, I'd probably be interested in this as a hobby project.
The question is how to deal with all of the space debris. It seems like they should factor in the total cost (retrieving anything that goes up) and not only the cost to launch it.
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 frequently wonder if alien didn't send RNA to Earth to start life here. It seems like that could be the payload for anyone shooting satellites out to the universe.
> ...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.
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
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
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
> 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.
3-6 newtons or about 0.7-1.3 pounds-force
Also it’s not 40k ft of wire. Altitude is 40k ft
The wire is about 16 ft for one leg of the dipole. That is the taught part. The other just floats in mid air underneath the payload
The community is very small and doubtful the sky will be filled with them
The balloons follow the jetstream from where they are launched. I have seen them fly over the Artic Circle, for example
I think there was confusion about whether it was tethered / what the tensile strength of the tether was. Reads like it wasn't tethered.
How did you communicate with it? Amateur bands? LoRa?
Yes, it is not tethered to the ground. The balloon is at the top, then 36awg wire, then solar panels and raspberry pi, then wire hanging down for lower half of dipole
Both top and lower part of dipoles are soldered to Raspberry Pi
It uses WSPR. Some of them use APRS but it is less common
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.
https://github.com/nasa-jpl/open-source-rover
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.
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.
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.
Not just students TBH...
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.
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.
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.
But even in LEO, there must be quite a few SEUs and resets?
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.
I’m really confused how you communicate with it? That seems like the most (expensive?) and technically difficult part.
I’ve got some cool ideas for atmospheric Reentry but I’d imagine there are all kinds of permits needed?
So it costs $85k to launch such cubesat. Too expensive for almost all of us. But if the cost comes down to say $5k, I'd probably be interested in this as a hobby project.
The question is how to deal with all of the space debris. It seems like they should factor in the total cost (retrieving anything that goes up) and not only the cost to launch it.
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.
it would be awesome for this to become popular enough to see teams of people race each other out of the solar system
I frequently wonder if alien didn't send RNA to Earth to start life here. It seems like that could be the payload for anyone shooting satellites out to the universe.
...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.
It's beyond cool you can pretty cheaply get cube sats on Space X rockets too