If you mention the word bus, you might think of public transportation or, more likely for us, a way to connect things together. But in the satellite world, the bus is the part of a vehicle that supports the payload but isn’t itself the payload. Typically, that means the electric power system, propulsion, radios, and thermal control, among other systems. If you are designing a CubeSat, you will want to read A Guide to CubeSat Mission and Bus Design by [Frances Zhu].
The Creative Commons-licensed book has twelve chapters, ranging from systems engineering — that is, defining what you want to do — to analyzing structures, handling power, setting up communications, and more. Of particular interest to us was the chapter on command and data handling. The final chapters cover software, system integration, and there’s even a chapter on Ethics.
If you want to build a CubeSat or just want to learn more about how satellites actually work, this is a great read. There are videos and other features, too. If you don’t like reading in your browser, you can download an EPUB, PDF, or MOBI near the top of the page.
There are many resources for the want-to-be CubeSat builder. You can even start with an open source design.
I’m just wondering if CubeSat and other small satellites need to have a lot of processing power? I mean aren’t they basically just sensor acquisition systems with radio comms?
Depends on the mission. To give you a good idea of what is commonly needed, NASA Goddard Space Flight Center develops the SpaceCube family of processors cards for both cubesat and large spacecraft form factors. These employ Xilinx FPGAs and Zynq SOCs. You can find more information by searching https://ntrs.nasa.gov.
On a spacecraft bus, the first thing that comes to mind is precision attitude control using star trackers. At a minimum, some amount of RAM is required to store a star catalog, along with enough processing power to match the last photo taken by the star tracker camera to your catalog rapidly enough for use in a control loop. The processor also needs to support the data interface to the camera, which can be some form of differential signalling like Spacewire.
And what would be the cap on the processing power needed for an “acquisition and radio comms” Cubesat in your opinion?
You can cram a lot of stuff in a liter of electronics these days, and some Cubesats are 2 or three units.
I won’t be surprised if some of these gather “many megabytes per second” of data. And how much of that is left after processing and compression to be transmitted is an even wilder guess. (Or simple to guess, based on available radio protocols?)
“It depends” is the answer. But if you look at the book in question, you’ll see on the front “Artemis CubeSat Kit” – and with the massive increase in lunar cube/smallsat missions of opportunity, lunar missions are the hot thing now.
Downlink telemetry is super-limiting for lunar missions (unless you’re a lander on a manned mission, and then it’s crazy-town). Think like, tens of kilobytes per second typically on average. To be clear, it’s not that you couldn’t do more, it’s that you’re communicating on very restricted ground station time and there’s this huge blocking thing called the Moon which gets in the way all the time. (I’ve said elsewhere one of the interesting things that sustained lunar missions enables is a massive upgrade in data bandwidth – never underestimate the bandwidth of a lunar capsule full of hard drives, I guess).
There’s a huge range of processing power available for cube/smallsats. Because of the bandwidth limitations, some missions need to do heavy onboard processing to get the science out of the data. But others are just minimal systems and don’t need it.
Back in 80s/early 90s the civillian Oscar sats had store&foreward and a mailbox.
Packet Radio at 300, 1200 or 9600 Baud or similar was sufficient to log-in into satellite and for users to use the mailbox.
I often wonder if a civillian Packet Radio network on the moon wouldn’t be a good first step to allow a basic communication that works with low radio bandwidth and a long delay.
It’s entirely vendor independent and PR stations can either communicate directly or via each other (every station can act as a relay).
So a satellite, orbiter or moon base can communicate to each other or via each other no problem.
There would be no complicated log-in or routing process.
A path requested on a serial terminal would be all there is.
Laser or microwave links would be possible with the protocol, too.
With FX.25 there’s even a forward error correction now.
Alternatively, there’s Pactor (Pactor IV being newest),
which is made for error prone shortwave and can provide almost speed of a mid-90s dial-up modem.
The Oscar 10 (’83) had a 400 Bit/s link for ground control using DPSK, for example.
AO10 and AO13 used the robust IPS satellite operating system.
Computers on ground used were humble Atari 400/800 and others.
https://amsat-dl.org/en/amsat-phase-3-b-oscar-10/
https://m.youtube.com/watch?v=GDR4pqkmmxE
This list mentions some Packet Radio links for Oscars launched in 1990.
http://www.qslnet.de/member1/dc9zp/page5.htm
My point simply is that it would be rational to use classic, proven technology first and not cell phone technology from earth.
The receiver technology used can be modern and DSP/SDR based, too, of course.
For an example of the lower end of system requirements, take a look at the cubesats developed or in development by AMSAT (Amateur Radio Satellite) organization (https://amsat.org). The Fox series of 1U cubesats have been in orbit for several years, although only two currently operational with limitations. Engineering documentation for the Fox series can be found at https://www.amsat.org/wordpress/wp-content/uploads/2018/06/AMSAT-Fox-Documentation.pdf.
The GOLF series, 3U cubesat design, is currently in development. It will be operating in a higher orbit and will have more capabilities and operational requirements. Information can be found at https://www.amsat.org/greater-orbit-larger-footprint-an-introduction-to-the-amsat-golf-program/.
A weighty tome, it is. Printed out, it would weight (er, out-mass) several times more than yer average cubesat.
Also interesting, a CubeSat simulator (for amateur radio)..
https://cubesatsim.org/
cube sat ;(
but othernet not working
meybe create one open source protocol and install it on any free hobby non ptofit satelite?