# Based on which aspects should the on-board computer microcontroller of a CubeSat be chosen?

I think most of the CubeSats have an ARM Cortex-M microcontroller. Like, e.g. CubeComputer or NanoMind.

Why are the Cortex-M the most frequently used microcontrollers for On-Board Computers (OBC)? Or are they? I have even seen some OBCs having a combination of an M0 and an M4 in some way.

Which aspects are the most important when choosing the microcontroller for a CubeSat?

• I don't know enough about this to give a full answer, but I'd say low power requirements must be a big consideration. The various new ARM based chips seem to be popular in lots of embedded hardware for this reason. Also, radiation hardening: I've read various comments from amateurs interested in cubesats that full rad hardening isn't thought to be essential for low earth orbit. (I know some of the experts here might be able to comment on that.) – Andy Feb 25 '16 at 14:29
• ...is chosen, or should be chosen? The difference is quite significant. – SF. Jun 25 '16 at 2:24
• @SF. just corrected it: "should be" – LandonZeKepitelOfGreytBritn Jun 30 '16 at 13:42

I'm not an expert on cubesats either, but the factors to take into account would be:

• environmental stability. Definitely the "Industrial" or better versions of the chips, rated for a broad range of temperatures. You will need a thermal control system, but don't count on it to be perfect and provide you with neat 4-60 centigrades, for which "consumer" equipment is rated at all times.
• power consumption. You have some wiggle room here, but you will strive for power for every subsystem, so a low-power CPU is definitely a boon. Rich power management options like throttling down, sleep etc are quite welcome.
• reliable features you need - the set of peripherals you need for your application. Before making the purchase, download the errata sheet for your CPU and check if nothing on your list is bugged. The sheer size of the document for more complex CPUs (like the Cortex family) is really eye-opening...
• playing well with realtime application. Either RTOS, or working without OS. If you need fancy closed-source drivers not available in RTOS version to use given feature, you won't be happy with it. Alternatively, you may go with a "hybrid" approach: Realtime, low-level for time-critical roles (attitude, radio); and a second CPU for a nice friendly OS that will do protocol conversions, media control (camera?), non-time-critical control (power, thermal) and such.
• either known to you, or known to be learner-friendly. There are some that when you look at the specs, seem very nice, but once you try to program them, you'll be ripping hair off your head.

What not to worry too much about:

• The cost, comparing to other subsystems isn't all that high; pretty much any reasonable board for your needs can be found below \$500; attitude control will cost you more; making the structure to specs won't be cheap (unless you have good contacts), and launch cost will totally overshadow the CPU cost. So concentrate on other properties and your own ability to use it. • rad-hardening. If a massive Coronal Mass Ejection comes, your cubesat is a toast unless you spend good \$300,000 on rad hardening, and outside of that event, it will be mostly fine. You will need a watchdog, and while most embedded CPUs come with these on board, you may want an external one as well. Also, if you manage to run under the weight budget, consider embedding in epoxy.
• Thank you very much for your answer, would you however mind claryfying a few things regarding those points: - hybrid setup for embedded OS: you suggest to use closed source OS for the time critical tasks and an open source for the less time-critical things? Why does this choise matter? I mean, e.g.: why not use the closed source OS (and try to make it very lightweight, by loading the least possible drivers in it when you (cross)compile it) just for what you need it, and use the open source one as much as possible for all the rest? - why would you replace radhardening by watchdog timers? – LandonZeKepitelOfGreytBritn Jun 30 '16 at 15:31
• @trilolil: Absolutely not. I'm quite adamant about anything closed-source unless you really, really know what you're doing. If it's closed-source, you won't be cross-compiling anything; you get the binaries for the platform, or nothing, period. In this particular case, I was referring to Raspberry Pi, sometimes chosen for cubesats despite being a really poor choice. It uses a proprietary driver for the 'multimedia' part of the CPU, and if you want to replace the OS with e.g. RTLinux, you'll have to give the feature up, because the driver won't play nice with RT (and you can't fix it.) – SF. Jun 30 '16 at 15:44
• Personally, I'd recommend going entirely without any OS for the realtime part, writing this for 'raw iron' - that way it's RT "by default" - but I realize it's pretty difficult. Especially high-level functions like advanced protocol handling (incl. error correction) and multimedia is difficult without OS, that's why I'd suggest a second CPU running a common OS (non-RT) to handle these. – SF. Jun 30 '16 at 15:46

I have not specifically worked cubesats, but generally the cheapest, lightest, smallest hardware that will meet requirements is used. Cheapest would include the entire lifecycle, including programming. And those requirements include reliability, and the environments are taken into account. So it depends on the requirements of the mission, including duration and environments, and what functions the controller must perform. I'm sure many of those requirements change for the different missions of cubesats.