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
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.
These and other high-altitude balloons are almost never tethered nor recovered - they're not a kite, that would be completely impractical.
You're nearing the altitudes at which the tensile strength of even supermaterials like Dyneema fibers are unable to lift the weight of their own tail, much less hold up against the tension of the jet stream. You'd need some kind of reverse rocket equation pyramid, where the topmost thousand meters have to lift the entire line, and are therefore made from line 0.6mm in diameter, and the next thousand meters are made of a slightly thinner, slightly less strong, slightly lighter fiber (because they don't have to lift the top thousand meters of line), and so on for the next 50-100km, depending on how much sag you expect the line to have.
"Oops, the balloon popped, excuse me while I do an ultramarathon across town spooling up my thousand-dollar tether from everyone's backyards...please don't cut it or trip over it or drive over it..."
No, it merely trails a 5 meter length of wire that acts as an antenna. You can receive the signals from hundreds of amateur receivers set up across the globe, often receiving transmissions at very long ranges. When the balloon eventually falls, yes, it's litter, but it's only a couple grams - go to your local park and pick up some trash, you can atone for a lifetime of HAB hobby sins with a single black bag full of alcohol bottles, fast food wrappers, and cigarette buts.
yet you can't say never, hence the question. balloons are launched for different purposes. if you're trying to keep a balloon on station to gather local data, it's gotta be tethered. maybe not typical of a 40k' altitude, but they definitely use tethered balloons.
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
I’m familiar; I thought this was tethered to the ground. But it’s self contained within a few meters at 40k ft - not a problem.
I do suspect if you encountered small gauge fishing line being used as a tether, you’d find at least some of it wrapped tightly around your spinner on the ground. Probably not much friction at play.
I think you can file a NOTAM for a weather balloon even if you don't need clearance. Might depend on the size and payload, though, like if it's closer to a party balloon than a real weather balloon, and how high it's going.
That would explain the difference in experiences. My balloon was 8' diameter at launch and expanded to ~40' when it burst at ~90k'. Mine needed the radar reflector and blinky lights. They were supposed to blink at a certain rate, but we cheated and had lights blinking faster as that's all we could find for our budget/schedule.
No radar reflectors or blinking lights of any sort? The little flights up to 90k' with a parachute return required those for night flights. Maybe most people just ignore that??
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.
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.
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
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.
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.
> 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%
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.
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.
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.
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.
We’ve been using Raspberry Pis in CubeSats for a while, for LEO they are good enough for a year or two. It’s the common consumer grade SD cards that are the weakest point. There are more robust industrial grade SD cards and there are RPis with flash (the compute modules) that can work great.
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 all falls back down eventually. Anything too small will stay up for some time, but even the half-billion copper needles put in space by the US have almost all come down. Wikipedia says there are <50 clumps of needles left.
Cubesats in most cases must have documented materials that are burnt up in the atmosphere upon reentry, for this exact reason. They don't stay up there forever.
the video was long and depressingly commercialized, so I went to Wikipedia to just get the basic idea about this and im blown away how long cubesats have been around and fairly easily available.
> As of December 2023, more than 2,300 CubeSats have been launched.
> Academia accounted for the majority of CubeSat launches until 2013, when more than half of launches were for non-academic purposes, and by 2014 most newly deployed CubeSats were for commercial or amateur projects.[3]
2013?!?! Regular academics have been putting little cubes into space with whatever they want since 1998! amateurs have been doing it for more than eleven years?? There's 2300 of them! this is all blowing my mind that space is even this accessible to people who don't work for NASA, ESA or SpaceX.
My first thought was, even before reading the article, that these cubesats would be perfect for practicing satellite tracking.
Lo and behold the article mentions one of my favorite youtubers, Gabe from saveitforparts! I love that channel.
It's so much fun to see someone tinkering with old hardware to connect to these flying devices. He is a genuinely wholesome guy. It's really fun to watch his videos.
>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.
If you're interested in building something, Planet released an open source hardware/software satellite radio that works over amateur radio bands for ~$50: https://github.com/OpenLST/openlst
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.
Why would it be difficult? Amateurs talk to the ISS all the time. You're only going 200 miles, and it's line-of-sight at all times while above the horizon since it's in the sky. You mostly have to just wait for a good window.
> ...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.
I would imagine the overriding reason people resist encryption is that it’s a pain in the ass.
You have to worry about long term key storage and security. You introduce a whole new class of failure mechanisms. It’s always going to lurk at the bottom of the todo list.
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.
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
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.
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
> 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?
These and other high-altitude balloons are almost never tethered nor recovered - they're not a kite, that would be completely impractical.
You're nearing the altitudes at which the tensile strength of even supermaterials like Dyneema fibers are unable to lift the weight of their own tail, much less hold up against the tension of the jet stream. You'd need some kind of reverse rocket equation pyramid, where the topmost thousand meters have to lift the entire line, and are therefore made from line 0.6mm in diameter, and the next thousand meters are made of a slightly thinner, slightly less strong, slightly lighter fiber (because they don't have to lift the top thousand meters of line), and so on for the next 50-100km, depending on how much sag you expect the line to have.
"Oops, the balloon popped, excuse me while I do an ultramarathon across town spooling up my thousand-dollar tether from everyone's backyards...please don't cut it or trip over it or drive over it..."
No, it merely trails a 5 meter length of wire that acts as an antenna. You can receive the signals from hundreds of amateur receivers set up across the globe, often receiving transmissions at very long ranges. When the balloon eventually falls, yes, it's litter, but it's only a couple grams - go to your local park and pick up some trash, you can atone for a lifetime of HAB hobby sins with a single black bag full of alcohol bottles, fast food wrappers, and cigarette buts.
> almost never tethered
yet you can't say never, hence the question. balloons are launched for different purposes. if you're trying to keep a balloon on station to gather local data, it's gotta be tethered. maybe not typical of a 40k' altitude, but they definitely use tethered balloons.
You are right; but in this case the topic was picoballoons which are free floating
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
Got it. Really cool project.
if you're not familiar, 36AWG wire is thin. very thin. according to [0], it is 0.1270mm. seems to me that it might melt free from friction thin.
[0] https://size-charts.com/topics/house-size-chart/wire-size-ch...
I’m familiar; I thought this was tethered to the ground. But it’s self contained within a few meters at 40k ft - not a problem.
I do suspect if you encountered small gauge fishing line being used as a tether, you’d find at least some of it wrapped tightly around your spinner on the ground. Probably not much friction at play.
I think you can file a NOTAM for a weather balloon even if you don't need clearance. Might depend on the size and payload, though, like if it's closer to a party balloon than a real weather balloon, and how high it's going.
14 CFR Part 101, Subpart D – Unmanned Free Balloons excludes PicoBalloons due to their size and form
That would explain the difference in experiences. My balloon was 8' diameter at launch and expanded to ~40' when it burst at ~90k'. Mine needed the radar reflector and blinky lights. They were supposed to blink at a certain rate, but we cheated and had lights blinking faster as that's all we could find for our budget/schedule.
I would love to launch a HAB. I learned how to do PicoBalloons from a local group.
No radar reflectors or blinking lights of any sort? The little flights up to 90k' with a parachute return required those for night flights. Maybe most people just ignore that??
It’s not required at all. These are so small that they are not covered by like FAA type regulations
If you have any details written up on your kit (in partic what solar you used) I'd appreciate a link. I'm looking to do similar
https://traquito.github.io/
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
What happens if there are heavy winds?
It can crash.
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.
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.
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
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.
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.
>Yep, but students love reinventing the wheel ;).
And ... professors love making students reinvent the wheel
I thought professors loved making students by the latest version of the book they wrote discussing how the wheel was invented
And that
> 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?
Not really. There are a couple of open source projects (LibreCube being the biggest example) but they aren't flight-ready.
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.
Email sent. I am generally very busy with family commitments but happy to stay in touch.
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
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.
Sounds like you have yourself a YCombinator startup proposal in the making
I wondered about the radiation hardening aspect.
At one altitude does that make a difference?
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.
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.
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.
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.
We’ve been using Raspberry Pis in CubeSats for a while, for LEO they are good enough for a year or two. It’s the common consumer grade SD cards that are the weakest point. There are more robust industrial grade SD cards and there are RPis with flash (the compute modules) that can work great.
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 all falls back down eventually. Anything too small will stay up for some time, but even the half-billion copper needles put in space by the US have almost all come down. Wikipedia says there are <50 clumps of needles left.
Cubesats in most cases must have documented materials that are burnt up in the atmosphere upon reentry, for this exact reason. They don't stay up there forever.
the video was long and depressingly commercialized, so I went to Wikipedia to just get the basic idea about this and im blown away how long cubesats have been around and fairly easily available.
https://en.wikipedia.org/wiki/CubeSat
> As of December 2023, more than 2,300 CubeSats have been launched. > Academia accounted for the majority of CubeSat launches until 2013, when more than half of launches were for non-academic purposes, and by 2014 most newly deployed CubeSats were for commercial or amateur projects.[3]
2013?!?! Regular academics have been putting little cubes into space with whatever they want since 1998! amateurs have been doing it for more than eleven years?? There's 2300 of them! this is all blowing my mind that space is even this accessible to people who don't work for NASA, ESA or SpaceX.
commercialized? He just talks to people building open source cubesats
My first thought was, even before reading the article, that these cubesats would be perfect for practicing satellite tracking.
Lo and behold the article mentions one of my favorite youtubers, Gabe from saveitforparts! I love that channel.
It's so much fun to see someone tinkering with old hardware to connect to these flying devices. He is a genuinely wholesome guy. It's really fun to watch his videos.
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?
>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.
If you're interested in building something, Planet released an open source hardware/software satellite radio that works over amateur radio bands for ~$50: https://github.com/OpenLST/openlst
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.
Why would it be difficult? Amateurs talk to the ISS all the time. You're only going 200 miles, and it's line-of-sight at all times while above the horizon since it's in the sky. You mostly have to just wait for a good window.
...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.
I would imagine the overriding reason people resist encryption is that it’s a pain in the ass.
You have to worry about long term key storage and security. You introduce a whole new class of failure mechanisms. It’s always going to lurk at the bottom of the todo list.
Maybe they are using plain simple TLS. Lol.
it would be awesome for this to become popular enough to see teams of people race each other out of the solar system
how much of a propulsion system could you feasibly pack in a cubesat?
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.
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
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.
It's beyond cool you can pretty cheaply get cube sats on Space X rockets too