What Processors Power LEO Satellites: From Radiation-Tolerant ARM to NVIDIA Jetson
A CubeSat in a 550 km sun-synchronous orbit absorbs about 2 krad of total ionizing dose per year. An NVIDIA Jetson Orin, which was never designed to see a single rad, is currently flying on multiple commercial LEO platforms and running inference on live Earth imagery. The gap between those two facts explains most of what’s interesting about LEO satellite processors right now.
For decades, the answer to “what processor goes on the spacecraft” was a short list of rad-hard parts from three or four vendors, priced per unit like a used car. That list still exists. It just isn’t the whole conversation anymore. Mega-constellations, shorter mission lives, and AI payloads have pushed program teams toward a much wider menu, including automotive-grade SoCs and COTS GPUs with watchdog circuits bolted on.
This guide walks through the four processor classes powering modern LEO missions and gives you a five-factor framework to pick between them.
The LEO Radiation Environment: What Processors Actually Face
LEO is the friendliest regime above the atmosphere, but “friendly” is relative.
Radiation Exposure by Orbit (relative)
GEO |████████████████████| ~10-100 krad/yr
MEO |██████████████████ | (SAA + belts)
LEO-SSO|████ | ~1-5 krad/yr
LEO-EQ |██ | <1 krad/yrTwo things matter: total ionizing dose (TID), which accumulates over the mission, and single-event effects (SEU, SEL, SEFI), which happen instantaneously when a heavy ion or proton punches through silicon. LEO TID budgets are low enough that shielding plus a 3-5 krad-tolerant part is often fine for a 3-year mission.
Sun-synchronous orbits see more dose than equatorial ones because polar passes clip the horns of the Van Allen belts. Separately, the South Atlantic Anomaly dominates SEU rates regardless of inclination.
The practical consequence: mitigation strategy matters more than raw rad-hard pedigree. A COTS part with EDAC memory, a hardware watchdog, and a clean power-cycle recovery path can out-survive a mid-tier rad-tolerant chip with none of those things.
The Four Processor Classes Powering LEO
Most selections end up in one of four buckets.
Rad-Hard MCUs
These are the parts built from the ground up to survive, with hardened cells, triple-redundant registers, and qualification pedigrees going back decades. Vendors like Vorago, Microchip’s SAMRH family, BAE, and Cobham sit here. They run at tens to low hundreds of MHz, burn under a watt, and cost in the thousands per unit.
Use them for command and data handling (C&DH), attitude control loops, and safety-critical supervisors where you can’t tolerate a reset or a corrupted instruction. You’re paying for deterministic behavior and flight heritage, not performance. Keep the rest of the stack away from anything that keeps the spacecraft alive.
Rad-Tolerant ARM SoCs
The fastest-growing tier. Teledyne e2v’s LS1046-Space and NXP’s rad-tolerant ARM variants deliver Linux-capable compute with TID tolerance in the 30-100 krad range. Microchip’s PolarFire SoC sits alongside them, blending ARM cores with an FPGA fabric.
They hit the sweet spot for modern C&DH, moderate payload processing, and software-defined networking on the bus. NRE is lower than full rad-hard, the ecosystem is familiar (standard ARM toolchains, Yocto, mainline Linux), and the performance gap with terrestrial embedded SoCs has closed considerably. For most new LEO programs, this tier is the default main processor unless a specific workload forces a different choice.
Space-Graded FPGAs
AMD/Xilinx Kintex and Versal AI Core (space grade), Microchip RTG4, and Lattice CertusPro-NX cover workloads where fixed-function silicon doesn’t fit: SAR processing, software-defined radio, high-rate downlink encoding, and reconfigurable payloads that need to change behavior in orbit.
The engineering cost is real. Triple modular redundancy (TMR), configuration memory scrubbing, and SEU-aware HDL design aren’t optional. But when you need 100+ GMACs of DSP throughput with deterministic latency, nothing else in the space-grade world competes. Versal AI Core adds hardened AI engines, which blurs the line with the next category.
COTS AI Accelerators
Here you’ve got NVIDIA Jetson Orin (Nano, NX, AGX), Qualcomm’s automotive SoCs, Intel Movidius, and Hailo-8 accelerators. None are radiation-qualified. All are showing up in orbit anyway.
The use cases are specific: onboard inference for cloud masking, ship and aircraft detection, change detection, and lossy video compression that turns gigabits of raw imagery into kilobits of useful metadata before downlink. ESA’s Φ-sat-1 flew Movidius. Φ-sat-2, Loft Orbital’s YAM missions, and D-Orbit’s ION platform have all flown Jetson-class hardware. The flight heritage is still thin but growing fast. You can track some of the open-source work at github.com/HubbleNetwork/.
Deep Dive: Jetson Orin in Orbit
The Jetson conversation deserves its own section because it’s reshaping payload architectures.
At the AGX tier, Orin delivers roughly 275 TOPS at 15-60 W. That’s orders of magnitude above anything rad-hard or rad-tolerant can touch. If your mission involves running YOLO or a segmentation model on 4K imagery in real time, the math gets hard to argue with: downlinking the raw data costs more (in bandwidth, in latency, in ground station time) than processing it on the spacecraft.
The engineering challenges are real:
- Thermal dissipation in vacuum. No convection. You’re conducting heat into the chassis and radiating it out. A 40 W Orin running continuous inference needs serious thermal design, usually a deployable radiator or a duty cycle.
- LPDDR5 SEU susceptibility. Memory is the weak point. EDAC at the application layer, periodic scrubbing, and checkpointing are standard practice.
- Boot reliability. Orin’s boot chain wasn’t designed for cosmic rays. Teams wrap it in a rad-hard supervisor that can force a clean power cycle on hang.
The architecture pattern that’s becoming the default for LEO AI missions looks like this:
┌──────────────┐ ┌──────────────┐
│ Rad-Hard MCU │◄──►│ Jetson Orin │
│ (supervisor) │ │ (AI payload) │
└──────┬───────┘ └──────┬───────┘
│ watchdog/reset │
▼ ▼
Bus/EPS Payload I/OThe supervisor owns the bus, talks to the EPS, and power-cycles the Jetson on fault. The Jetson owns the payload and does the heavy compute. Each does what it’s good at.
Jetson is overkill for low-rate telemetry, simple imaging missions, and anything under 1U. If your payload is a thermometer and a magnetometer, a rad-hard MCU is still the right answer.
The Five-Factor Selection Framework
Walk every candidate through these five questions in order. Most selections resolve in the first three. For deeper specs, see hubble.com/docs/.
Radiation budget. What’s the orbit, altitude, and mission duration? Multiply expected dose rate by years, add margin, and you have your TID requirement. SEU rate follows from the same analysis. This alone eliminates one or two tiers.
Power envelope. How much of the bus power budget does the processor get? A 1 W ceiling excludes Jetson AGX immediately. A 30 W allocation opens the door.
Compute intensity. What’s the MIPS or TOPS target? What data rates are you ingesting? If the answer is “a few MB/s of housekeeping,” you don’t need an FPGA. If it’s “100 MB/s of SAR raw data,” you do.
Mission life and reliability class. Class A (crewed, flagship) and Class D (smallsat, risk-tolerant) have very different answers. Redundancy strategy (cold spare, hot standby, TMR) flows from this.
Cost and schedule. NRE, qualification timeline, and supply chain risk. Rad-hard parts can have 12-18 month lead times. COTS AI accelerators ship next week but carry qualification burden on your side.
A quick decision flow:
┌─────────────────────────┐
│ Safety-critical C&DH or │
│ attitude control? │
└──────────┬──────────────┘
│ yes → Rad-Hard MCU
│ no
▼
┌─────────────────────────┐
│ AI inference or >50 │
│ GMAC signal processing?│
└──────────┬──────────────┘
│ no → Rad-Tol ARM SoC
│ yes
▼
┌─────────────────────────┐
│ Deterministic latency │
│ and reconfigurable? │
└──────────┬──────────────┘
│ yes → Space-Grade FPGA
│ no → COTS AI + supervisorAnd the summary matrix:
| Rad-Hard | Rad-Tol | FPGA | COTS AI
| MCU | ARM SoC | (Space) | (Jetson)
------------------|----------|----------|---------|----------
TID tolerance | ★★★★ | ★★★ | ★★★★ | ★
Compute/Watt | ★ | ★★ | ★★★ | ★★★★
Unit cost | $$$$ | $$$ | $$$$ | $
AI workloads | ✗ | ~ | ✓ | ✓✓✓
Flight heritage | ★★★★ | ★★★ | ★★★★ | ★★Matching Mission to Silicon
There’s no single best LEO satellite processor. A weather sat doing simple imaging and a defense payload running real-time object detection have almost nothing in common at the silicon level, and they shouldn’t.
What’s changed in the last 5 years is that hybrid architectures (rad-hard supervisor plus COTS performance node) have normalized. Teams that resisted COTS are flying it. Teams that started with COTS are adding rad-hard supervisors. The middle is where most new programs are landing.
Run the five-factor framework before the vendor meetings. The answers you give yourself will be more honest than the ones a sales deck gives you, and the processor shortlist usually falls out within an afternoon.
Hubble Network brings Bluetooth connectivity directly to LEO satellites, letting devices reach orbit without cellular, LoRa gateways, or custom radios. See how it works →