CubeSat programme

Please do not repeat requests in multiple sections.

You only need to do a post in one place for it to get noticed.

Thank you.

DAB

Hi,

I have some questions for you.

1. What is the mission of your cubesat?
2. Are you making an engineering test model? Because reg Arduino / Pi are not flight ready for a cubesat
3. What are you sensing?
4. Are you transmitting data to ground?
5. Do you have attitude control system?
6. What are size of cubesat, power requirements, expected orbit

If you're making Engineering Test model to demonstrate craft activity on ground and demo your sensors, then Arduino type architecture is good to do the vast majority of your cubesat work.

You need to really think about answers to Q1 and Q2 before you proceed. If you seriously want to make a flight-ready cubesat that has a reasonable lifetime, it's very hard to make an Arduino / Pi solution. At minimum you're going to need to build in excellent thermal control, and you'll need to think about redundancy and error checking. Because cold/hot fluctuations can damage components over time, and radiation SEL/SEUs can mess up bits in your memory.

I'm not an OS expert, but I don't think you need an OS to get started. You just need an Arduino type system to read sensor data, send out controls, and send data to ground.

Also, I suggest you look to resources like this to flesh out your mission planning in more detail: https://www.nasa.gov/sites/default/files/atoms/files/nasa_csli_cubesat_101_508.pdf

Hope this helps!

Hi Jordan

1-The mission of my CubeSat is to observe different aspects of the Earth

2- My project is a full operational CubeSat. If the RPI isn’t a good option to be used, which SBC do you suggest me? I’m searching one that is good for my space purposes with a low cost like the RPI or similar (it could be a little more expensive)

3- I want to sense the atmosphere composition, co2 levels, intensity of the magnetic field and amount of radiation in different areas, and also take thermal, infrared and normal photos.

4- I want my CubeSat sends data to ground. By the moment, I intend to send data from my CubeSat to one computer to do tests, with this computer I will command my CubeSat. I’m thinking to design a computer program that will act like the ground segment. What do you think? Do you have any idea to improve the comm’s

5- My ACS will be a combination of GPS sensors and accelerometers. To be honest I don’t have any idea about what’s supposed to have an ACS. What elements should it have?

6- The size of my CubeSat will be a 3U: 10cm x 10cm x 34cm. By the moment my CubeSat won’t be launched, but I’m designing this project to reach a polar orbit.I will know the power requirements when I buy all the sensors and the SBC. When you talk about the power requirements, are you talking about the energy needed?, how to produce that energy?, its management, etc…?

The error and redundancy checking will be programmed later on, but I will take care of that now that I know of their existence.

If I finally end up using  an RPI (by any reason, maybe for it’s cost), It will be a good idea to protect my cubesat with a material that repels radiation to prevent SEL / SEUs? In these case, how can it be compatible with my radiation and magnetic field sensors? And with my differents cameras?

Thank you!

Hi Ale,

Are you designing on your own? With a team? Has anyone done this before? I recommend everyone in your group to do this course to increase breadth of understanding: https://actu.epfl.ch/news/mooc-space-mission-design-and-operations-5/

Are you doing this for a course? A team project?

Our team used a TMS570LS0714 MCU.

I don't think we bought any rad-hard components, since the cubesat has a short lifetime anyways. However our PCB design allowed for redundancy of components to help the system handle SEL/SEUs and reset itself. Part of redundancy is indeed software, but part of it is hardware choice and hardware placement. You'll need to research that a bit.

I suggest you get more specific on your mission and let this drive your sensing requirements. How do you plan to sense atmosphere composition and CO2 levels? What sensors would do this? Are these sensors feasible to mount in 3U cubesat from weight/volume/power perspective? Have past missions done this? Look at Gunter's space page and look through past cubesat missions to aid your research.

I don't have specific idea to improve comm to ground but you need to design and research this early and it needs to be 110% correct. Otherwise you won't get data to ground. You'll want to look for existing sources and examples. See where your groundstation would be, simulate some contact times in STK, and then look at the realistic downlink that is possible with a cubesat grade antenna. Let this help you calculate constraint on data downlink. You might not be able to send images down to ground very often.

For AODCS, your choice of GPS and accelerometer will mainly give you position. How will you get tilt and orientation? Photodiodes or sun spotting sensors can help this. And for attitude control you need to do some research. How precisely do you want to point your craft for sensing earth? This brings you back to your mission and sensing requirements. If you are just trying to demonstrate a basic sat and take general pictures of Earth, you could allow gravity to align your sat with long axis pointing to Earth. You could also explore a passive magnet system. If you want more precise pointing then you need active control instead of passive control. But this is much harder to do.

When I talk about power requirements, I'm asking you what average and peak power is needed by your craft when it's in regular operation. Note that peak power goes up when you transmit to ground or power an active sensor. Following these questions, you need to have a good knowledge of your orbit, ACS, and solar panel area. This will affect how much battery charging you can do per orbit. You effectively need to create an energy budget for how much power you want to use per orbit, and how much energy you can recharge while in the sunny part of your orbit. Because when you hit the dark part of your orbit, you are draining your batteries and likely needing additional power to heat the inside of your craft. Certain components require heating like batteries, MCU, and other ICs.

I don't recommend selecting an RPi for your design. It's not professional and not sturdy enough. And you can't do much to protect craft from SEL / SEU. They penetrate anyways. There are physical and software strategies to mitigate their damaging effects however. One idea is to have multiple processing cores or MCUs and a watchdog that compares their calculations. If a SEL / SEU damages one of these, then the watchdog will see that values from one IC is not matching and it will force the problematic chip to reset. Trying to physically shield from radiation is problematic because of the weight it adds to craft.

Hope this helps!

Depends DAB , not everyone follows the same spaces, so sometimes you can capture different users and find the one who can help

Jordan has given you some good advice.

To get an idea of what goes into a real Cube Sat then take a look at this website and see how it is really done by professionals.

https://www.clyde.space/

This will give you an impression of the kind of engineering involved.

Study a lot more websites to get a good feel as to what can be done by a small team.

Error correction/management can't be 'programmed later' - it has to be designed in from the very start, at the base hardware level.

MK

jdlui's controller choice handles a significant part of the problem domain. That controller has redundant hardware that can detect if rogue particles messed with the controller, memory and peripherals.

In some cases that family can even recover from space injected error conditions. If not, it can gracefully flag or restart from such situations. Plus it also allows to run on low energy.

To be honest,I don't see a working space device launched running on a Raspberry Pi or similar board. They are not hardened and use too much energy. My advice would be to get your base (including knowing how to tune linux for extremely low energy and redundant hardware)  right before engaging in a project. Otherwise, you would fail your school assignment.

I'd have to second that opinion. I've been involved in a project doing design work, and the amount of considerations that are needed given the harshness of space is quite numerous. For one, you must remember that anything launched into space cannot be retrieved and fixed like you would on the ground. The other thing is that you're entirely reliant on solar panels and batteries for your supply. Thirdly, the environment is particularly harsh in terms of temperature, vibration (during launch), pressures (vacuum) and in terms of charges/particles.

As a result, if you want anything to last, you really want to go with "older", simpler electronics which are more hardy to radiation because their internal traces are thicker, or because they run slower and have more operational margin or are shielded. Performance really is at a premium. I suspect commodity high-performance equipment that we can buy is not likely going to survive long at all - e.g. the microSD card is likely to see data corruption it cannot repair autonomously, the RAM for the SoC will see occasional bit-flips which cannot be corrected (without ECC). Best case is that it crashes, reboots and reloads some good code and keeps going. Worst case (and more probable as the satellite ages) is that it won't and it instead locks up and is rendered into a piece of space junk. If you're unlucky to be launched during high solar activity, this could be sooner rather than later.

An anecdote I'd like to share of just how much the design needs to consider the environment is of the issue of just getting enough capacitance onto the board. For power filtering, commonly electrolytic capacitors are used, but under vacuum they will probably vent and won't last very long. As a result, a redesign effort to use expensive ceramic/tantalum capacitors were used, but then it was found that their weight (of the larger ones) resulting them tearing off the board during simulated worst-case vibration during launch on a shake-table test. So it's less than straightforward. Another design issue was simply in the battery pack where the pack was glued together in plastic - the outgassing in a vacuum was producing some compounds which would likely fog any camera lens. Finally, we also realized the potential for electrostatic discharge between different parts of the craft and the potential for deep dielectric discharge (which further complicates the design). It's like trying to design some electronics that can work when a small bolt of lightning is happening nearby - it's not easy especially for low-voltage stuff to handle the transients.

Add to this, the Pi is pretty voracious on power. I somehow doubt a smaller cube-sat can have enough power to sustain a load close to 10W continually. Heat dissipation is another issue - without air, heatsinks aren't particularly effective, and direct solar radiation causes quite a bit of heat to accumulate. Commercial Li-Ion cells can be used but they don't last long.

Considering the cost of a launch - these are not small factors to be overlooked.