CubeSats are fascinating learning tools for space
jeffgeerling.com
jeffgeerling.com
I agree, cubsats are a wonderful way, for college students even, to tinker with space(-adjacent) tech.
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
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?
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
Doubt it’d cause an immediate issue, but doesn’t sound very fun to remove.
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
How did you communicate with it? Amateur bands? LoRa?
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.
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
[0] https://size-charts.com/topics/house-size-chart/wire-size-ch...
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.
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
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.
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 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 all about the learning experience and evolution of these projects. Mistakes must happen.. but learning from them should take place too.
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.
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.
And ... professors love making students reinvent the wheel
Surely this, or something like it, exists?
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.
At one altitude does that make a difference?
I would say you certainly need to start seriously considering at least some radiation hardening at around 600 km, but missions that can accept a large amount of risk to keep costs down still operate at that altitude with non-hardened parts. Likewise, missions with critical reliability requirements like the International Space Station use radiation hardening even down at 400 km.
The "hard" limit is probably around 1000 km, which is where the inner Van Allen Belt starts. At this altitude, hardware that isn't specifically radiation hardened will fail quickly.
The inner Van Allen Belt also has a bulge that goes down as low as 200 km (the South Atlantic Anomaly), so missions in low inclined orbits that spend a lot of time there or missions that need good reliability when flying through the SAA may also need radiation hardening at comparatively low altitudes.
And that only helps with ionizing dose, which is already not really a problem in LEO. The issue is more high energy particles like cosmic rays, which cause single event effects (SEEs) - things like random bit flips in RAM or CPU registers, or transistor latchup that can cause destructive shorts to ground if not mitigated. These are impractical to shield against, unless you want to fly a few feet of lead. So instead we mitigate them (ECC memory, watchdog timers, latchup supervisor circuits that can quickly power cycle a system to clear a latchup before it can cause damage, etc).
If you want to get an idea of how much shielding is effective in a particular orbit, you can use ESA's SPENVIS software (online, free): https://www.spenvis.oma.be/. Despite being free, it's the tool of choice for initial radiation studies for many space missions worldwide.
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.
Almost all cubesats are launched at about a 550km x 550km orbit or lower circular orbit. Cubesats (most satellites, in fact) will deorbit naturally within a few years (almost definitely <= 5Y) at that altitude due to orbit decay, mostly from drag.
Now, some cubesats will have onboard propulsion, which they'll use to extend their mission by burning back into higher orbits, allowing them to still naturally decay at the end of their mission. Indeed, they can even use remaining propellant to speed their orbit's decay.
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.
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’ve got some cool ideas for atmospheric Reentry but I’d imagine there are all kinds of permits needed?
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.
On the satellite it’s just an off the shelf UHF/VHF transmitter or SDR.
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!
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
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.)
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.