🔧 Bits Flip . Code Breaks.
As many of you know, I want to learn about space and, along the way, build things that help others learn too. Over the past few weeks I kept coming back to a simple question. We always talk about radiation, bit flips, and Single Event Upsets, but what does an SEU actually look like from inside a microcontroller?
This matters because the next generation of New Space missions will rely heavily on commercial MCUs inside CubeSats. If we want to design reliable spacecraft with them, we first need to understand what a bit flip really does to software. What does the MCU “see”. When does it matter. And how do we protect ourselves.
So I took a great CPU simulator made by exuanbo
https://github.com/exuanbo/assembler-simulator
and I added one tiny superpower. The ability to flip a byte in memory into a random value.
Suddenly you can inject SEUs on demand and watch the program fall apart in real time.
You can try it here:
https://www.zero2orbit.com/simulator
CPU Simulator
🖥️ A Tiny Program, One Bit Away From Chaos
To start simple I took a small assembly program that prints “Hello World” into a simulated video RAM. When everything goes right the output is perfect. But the moment a single bit flips things get interesting.
A character changes.
A pointer goes somewhere it should not.
The string ends too early.
Or the whole program collapses instantly.
This is a miniature version of what happens in space.
☢️ How Many SEUs Can You Expect in Space
If you have ever wondered how often real spacecraft experience bit flips here is a striking example.
The X-Ray Timing Explorer, launched in 1995, carried solid-state recorders whose in-flight data has been analyzed in detail. In a long-term study published by Christian Poivey and colleagues, the spacecraft recorded between fifty and two hundred fifty Single Event Upsets per day depending on orbit altitude and solar activity.
That is not a typo.
Tens to hundreds of memory corruptions every single day.
Below is one of their plots showing the daily upset rate over eight years of operations:
In-Flight Observations of Long-Term Single-Event Effect SEE Performance on XTE Solid-State Recorders.
🧠 Why This Matters For Your Memory And Our Simulator
When you look at that chart it becomes obvious. Space is constantly trying to corrupt your data.
Some errors are acceptable:
A flipped bit in a non-critical buffer.
An occasional wrong pixel.
A corrupted telemetry packet that gets retransmitted.
Tolerable. You can live with it, But what if a critical bit flips.
What if the upset hits the program counter.
A control flag.
A pointer.
Your attitude control software.
A power switching command.
Your bootloader.
Your configuration memory.
Now the spacecraft may reboot, lock up, lose pointing, drain its battery, or command itself into a bad mode. This is where fault tolerance, scrubbing, ECC, redundant states, and safe-mode logic become mission critical.
Most of those errors are harmless. Some flip a pixel or corrupt a buffer and nothing bad happens. But a few land in critical places. A mode flag. A control variable. A pointer. The program counter.
That is when things break.
🚀 Why I’m Doing This
My goal is to understand how these failures appear at the software level and how we can defend against them. Over the next weeks I plan to create more assembly examples to demonstrate how error detection and correction algorithms work, and to explore practical ways to program for the space environment.
This simulator is just the first step. It is a small playground where we can break things safely and learn from the pieces.
So play with it. Flip bits. Corrupt memory. Destroy programs.
And together we will explore how to make software that survives space.
