CubeSat vs SmallSat vs Microsatellite: Satellite Sizes and the Chips Inside Them
The most expensive mistake in a first satellite build rarely happens at launch. It happens 18 months earlier, when someone picks a processor that’s either wildly overqualified (burning budget on rad-hard silicon for a 1-year LEO demo) or dangerously underqualified (a bare COTS chip with no firmware mitigation heading into a high-inclination orbit). Terminology confusion between “CubeSat,” “SmallSat,” and “microsatellite” makes this worse, because people assume the size class dictates the chip. In practice, it’s the mission profile and power budget calling the shots.
This article gives you three things: a clear breakdown of satellite size classes and where they overlap, a map of which chip architectures (MCUs, FPGAs, SoCs) fit which missions, and the radiation tolerance trade-offs that connect them. You’ll walk away able to make a category-level decision about your compute hardware, not just parrot part numbers from someone else’s BOM.
Satellite Size Classes: Where the Overlaps Trip People Up
The terms get swapped constantly. Here’s what they actually mean.
CubeSat is a form-factor standard. One “unit” (1U) is a 10×10×10 cm cube, roughly 1.3 kg. You can stack them: 3U, 6U, 12U. The standard (originally from Cal Poly and Stanford, now codified in ISO 17770) defines mechanical interfaces, deployment switches, and rail specs. A 12U CubeSat can weigh up to about 24 kg.
Microsatellite is a mass class: 10 to 100 kg. No standardized form factor. You’re designing a custom bus or buying one from a vendor like NanoAvionics or York Space. Some larger CubeSats (6U, 12U) fall into microsatellite mass range, which is where the confusion starts.
SmallSat is the umbrella. Anything under about 500 kg counts, including CubeSats, microsatellites, and minisatellites (100 to 500 kg). When someone says “SmallSat,” they could mean a 1U student project or a 300 kg commercial imaging bird.
Class Mass Range Typical Form Power Budget (typ.)
─────────────────────────────────────────────────────────────────────
PocketQube <0.25 kg 5×5×5 cm unit <0.5 W
CubeSat (1U) ~1.3 kg 10×10×10 cm 1–2 W
CubeSat (3U) ~4–5 kg 10×10×34 cm 5–10 W
CubeSat (6U) ~8–12 kg 10×20×34 cm 10–20 W
CubeSat (12U) ~18–24 kg 20×20×34 cm 20–40 W
Microsatellite 10–100 kg Custom bus 20–200 W
Minisatellite 100–500 kg Custom bus 100–1,000 W
◄──── CubeSats ────►◄── Microsats ──►◄─ Minisats ─►
◄──────────────── "SmallSat" (umbrella) ──────────────────►Mass class tells you your volume and power constraints, but mission complexity determines your compute needs. A 3U CubeSat running an IoT relay needs almost nothing in terms of processing. A 3U CubeSat doing onboard hyperspectral image classification needs 10x the compute. Same size, completely different chip strategy.
MCUs, FPGAs, and SoCs: What Goes Where and Why
Most CubeSat and microsatellite avionics stacks are built from some combination of three chip categories. Many missions use two or all three.
MCUs are the workhorse. For command and data handling (C&DH), housekeeping, attitude determination, and power management, an MCU is almost always the right call. ARM Cortex-M variants (STM32, SAMV71), TI’s MSP430, and even AVR chips have extensive flight heritage at the CubeSat scale. They’re low power (often under 100 mW active), the dev tools are mature, and there’s a deep bench of engineers who know them. For housekeeping on a 3U, you’re looking at single-digit milliwatts in sleep and maybe 50 to 150 mW active.
FPGAs show up when you need parallel processing or hardware-defined I/O. Software-defined radio (SDR) payloads, real-time image preprocessing, high-speed data routing between subsystems: these are FPGA territory. Microsemi’s RT ProASIC3 and RTG4 are probably the most common rad-tolerant FPGAs in the small satellite world. The big advantage is reconfigurability: you can update FPGA bitstreams in orbit if you build in that capability.
SoCs and System-on-Modules are the growing category. When your mission needs Linux-class compute (onboard ML inference, complex scheduling, or store-and-forward data management), you’re looking at something like a Zynq-based board (which pairs ARM cores with FPGA fabric) or, in experimental missions, an NVIDIA Jetson. These pull more power, typically 2 to 15 W depending on load, so they’re realistic for 6U and up.
Here’s how they typically connect inside a CubeSat:
┌─────────────────────────────────────────────────┐
│ CubeSat Avionics │
│ │
│ ┌────────────┐ ┌────────────┐ ┌──────────┐ │
│ │ MCU │ │ FPGA │ │ SoC │ │
│ │ (C&DH / │ │ (Payload │ │ (ML / │ │
│ │ Housekpng) │ │ Processing)│ │ Linux) │ │
│ └─────┬──────┘ └─────┬──────┘ └────┬─────┘ │
│ │ SPI/I²C/UART │ High-speed │ │
│ ├────────────────┤◄──────────────►├ │
│ ┌─────▼──────┐ ┌─────▼──────┐ ┌────▼─────┐ │
│ │ Sensors, │ │ Radio/SDR, │ │ Storage, │ │
│ │ Power Mgmt,│ │ Camera │ │ Downlink │ │
│ │ ADCS │ │ Interface │ │ Queue │ │
│ └────────────┘ └────────────┘ └──────────┘ │
└─────────────────────────────────────────────────┘The MCU talks to everything over familiar buses (SPI, I²C, UART). The FPGA handles high-bandwidth payload interfaces. The SoC, when present, sits at the top of the data chain doing the heavy cognitive lifting. Many 1U to 3U missions skip the FPGA and SoC entirely: just an MCU and a transceiver.
The Radiation Question: Picking the Right Tier Without Overpaying
Two radiation effects matter for chip selection. Total Ionizing Dose (TID) is cumulative damage over the mission life, measured in krads. Single Event Effects (SEE) are one-off disruptions when a high-energy particle hits a transistor: bit flips (SEU), latch-ups (SEL), or gate ruptures (SEGR).
The component world splits into three tiers:
Cost: $ $$ $$$$$
┌───────────┬───────────────┬──────────────┐
│ COTS │ Rad-Tolerant │ Rad-Hardened │
└───────────┴───────────────┴──────────────┘
Orbit: LEO short LEO long / GEO /
(<2 yr) MEO / SSO Deep Space
Typical: STM32, SAMV71, RAD750,
MSP430 Microsemi Vorago,
RT ProASIC3 BAE RAD5545COTS (commercial off-the-shelf): no radiation specification. The STM32 you’d put in a terrestrial IoT device. Cheap, widely available, extensive dev ecosystem. Acceptable for LEO missions under about 2 years if you build firmware-level protections.
Rad-tolerant: tested and characterized for moderate radiation environments. These chips aren’t redesigned at the transistor level, but they’re screened, sometimes fabricated on more radiation-resistant process nodes, and come with TID and SEE test data. The sweet spot for most NewSpace missions.
Rad-hardened (rad-hard): designed from the ground up with radiation-resistant circuit techniques. They cost 10–100x more than COTS equivalents and often trail several process generations behind in raw compute. A RAD750, still flying on Mars rovers, is roughly equivalent to a mid-1990s PowerPC.
The rule of thumb: orbit altitude multiplied by mission duration determines your radiation tier. LEO below 600 km for 1 to 3 years? COTS with watchdog timers, ECC memory, and triple modular redundancy (TMR) in firmware is a defensible choice. Polar or sun-synchronous orbits get more radiation from the South Atlantic Anomaly, so bump up to rad-tolerant. GEO, MEO, or anything beyond Earth orbit? Rad-hard.
Matching CubeSat Chips to Mission Profiles
Here’s where it comes together. Three representative missions and the chip strategy for each.
1U to 3U CubeSat, LEO IoT relay. An ARM Cortex-M4 or M7 MCU handles all C&DH, sensor polling, and packet routing. No FPGA needed; a low-power transceiver (sub-GHz or UHF) manages comms. Total compute power budget: under 0.5 W. COTS silicon with firmware-level SEU mitigation. Budget for the OBC: $500 to $3,000 for a commercial module. For IoT-focused satellite hardware, the communication protocol matters as much as the processor; BLE-based devices talking to satellites rely on carefully structured advertising packets to get data through.
6U CubeSat, Earth observation. The stack expands here. An MCU handles housekeeping while an FPGA takes on image compression and preprocessing (JPEG2000 or a custom pipeline). Some missions add a SoC for onboard classification to reduce downlink bandwidth. The FPGA might be a Microsemi RTG4 (rad-tolerant) or a Xilinx Artix in a COTS-risk-accepted configuration. Compute power budget: 5 to 15 W. Every watt your FPGA burns is a watt your solar panels need to generate and your batteries need to store.
50 kg microsatellite, multi-payload. At this scale, you’re typically buying or licensing a commercial avionics stack rather than building from scratch. A rad-tolerant MCU handles C&DH, a space-grade FPGA manages payload data routing and SDR, and dedicated payload computers (possibly SoC-based) serve each instrument. You might have 2 or 3 separate compute boards. Compute power budget: 20 to 50 W.
The decision matrix, stripped down:
Mission Need Recommended Chip Category
────────────────────────────────────────────────────────
Housekeeping only MCU (ARM Cortex-M)
+ Sensor polling MCU
+ Onboard image processing MCU + FPGA
+ Software-defined radio FPGA (or FPGA + MCU)
+ ML / AI inference SoC (Zynq, Jetson*)
+ Multi-payload routing FPGA + MCU + SoC
* Jetson = experimental, COTS risk acceptance requiredAdvice for Teams Building Their First Bird
Start with a flight-proven OBC module. Designing your own board from scratch is tempting (and educational) but burns 6 to 12 months and introduces untested failure modes. Commercial OBC boards from GomSpace, ISIS, or Endurosat give you space heritage out of the box.
Budget for radiation testing, even with COTS. Proton or heavy-ion beam time at a facility like Texas A&M’s Cyclotron Institute costs $5,000 to $15,000 per test campaign. Characterization isn’t the same as qualification, but it tells you where your chip fails and at what dose. That data shapes your firmware mitigation strategy.
Build firmware-level radiation mitigation from day one. Watchdog timers, ECC on all memory (not just external SRAM, but internal registers where possible), TMR on critical state machines.
Plan thermal management early. In vacuum, the only heat paths are conduction to the structure and radiation to space. That chip dissipating 2 W on your bench with convective cooling? It’ll run significantly hotter in orbit. Check junction temperatures under vacuum conditions, not just ambient.
Lean on open-source reference designs. Projects like LibreCube and the Open Source Satellite Initiative publish schematics and firmware. They won’t replace your own testing, but they’ll save you weeks of architecture decisions. If your mission involves ground-to-satellite IoT data, the Hubble device SDK is worth looking at for the BLE-to-satellite communication layer.
Building Chip Selection Into the Mission Budget
Here’s the sequence that works: define your mission’s data and processing requirements first, then pick the chip category, then pick the radiation tier based on orbit and duration, and only then start comparing specific parts or OBC modules.
Size class sets your constraints (power, volume, thermal). Mission profile sets your compute architecture. Radiation environment sets your component tier. Get the order wrong and you’ll either overspend on silicon that’s more hardened than you need, or under-spec a chip that’ll flip bits 8 months into a 2-year mission.
Since about 2018, flight-proven COTS and rad-tolerant components have become available at price points unthinkable a decade ago. But cheaper components don’t mean easier systems engineering. The teams that succeed match their silicon to their mission, not to their ambition.
Hubble Network enables direct satellite connectivity from standard BLE chips—no custom hardware, no ground infrastructure. See how it works →