Inside the New OBC Block Diagram
Space is becoming more accessible — and more demanding.
A growing industry needs engineers who don’t just know how to write firmware or design PCBs, but who understand what it really means to put hardware into orbit.
That’s why this project exists.
The CubeSat Learning Kit is built to help learners:
🔧 Learn by doing — no black boxes, just real subsystems you can control and modify
🚀 Understand what it means to send a satellite into space — and what the environment will do to your system
🌍 Prepare for a growing industry — where the people who truly understand space systems will shape the future
The On-Board Computer (OBC) is a key part of that vision. It’s the hub where sensors, memories, and subsystems connect. It’s where fault simulation happens. It’s where you experiment, debug, and design — just like you would in a real mission.
Today we’re sharing the block diagram of the OBC and walking through how its design supports these goals.
A Board That Doesn’t Just Work — It Teaches
We set out to build a CubeSat kit that could do more than blink LEDs or send telemetry to a serial port. The goal is deeper: helping early-stage engineers understand what they’ll really face when building hardware for space.
The OBC is the brain of the system, and it’s where several important ideas come together: modularity, fault injection, data logging, and sensor interfacing. But it’s also where the learning really begins.
So, let’s take a closer look.
Block Diagram of the Zero2Orbit Kit OBC
🧠 Dual-MCU Architecture
At the core of the OBC are two microcontrollers:
1. Main MCU — STM32F401
This MCU is responsible for all the typical tasks you'd expect from an on-board computer:
Reading sensor data (gyro, accelerometer, temperature)
Storing mission data to memory (FRAM, SD)
Communicating with other systems
Running user-defined mission logic
It’s the system the user will mostly interact with — and debug when things go wrong.
2. Fault Inducer MCU — STM32F042
This microcontroller plays a very different role.
It comes pre-programmed to simulate space environment effects — including resets, memory bit flips, current spikes, and latch-up scenarios. These are triggered based on expected fault rates in a typical low Earth orbit mission.
Users can adjust the fault frequency and severity by changing configuration parameters, which means:
👉 You’ll need to understand your target orbit,
👉 Estimate what kind of issues you’re likely to face,
👉 And connect those risks to actual system behavior.
That link between orbital environment and hardware impact is one of the most valuable lessons this board offers.
And while it’s ready to use out of the box, the Fault Inducer MCU can also be reprogrammed for custom experiments or adapted to simulate different mission profiles.
It’s a space simulation tool — but also an open-ended platform for creative fault injection.
📦 What’s in the Box? (Well, on the Board)
Here’s what the OBC connects to — each component chosen not just for technical reasons, but also for its pedagogical value:
Gyroscope – MPU6050
Standard for many CubeSats; used to simulate attitude sensing.Accelerometer – ADXL345BEZ
Useful for detecting motion or mechanical vibrations (especially during launch simulation).Temperature Sensor – DS18B20
Helps demonstrate thermal conditions and real-world thermal drift.FRAM – CY15B104QN
Non-volatile memory ideal for radiation-rich environments. More robust than flash.SRAM – MT52L0L128
Volatile memory that's fast — probably required for different subsytems that will come in the future.SD Card – MEV9Q90-00
For local data logging. Important when the kit is used without a host computer.
These parts are selected to reflect real subsystems found in flight, while remaining affordable and easy to understand.
🔁 Power Management and Fault Injection
Below the sensors and memories, we’ve added a few key support systems to simulate more advanced space-related behaviors.
Power Bus & Latch-Up
A regulated 3V3 power bus connects the main system. A power switch and current measurement unit are integrated into the board to monitor consumption and simulate radiation-induced events like latch-up.
The Fault Inducer MCU can:
Reset the main MCU (simulate SEFI)
Corrupt memory values (simulate SEU)
Trigger a latch-up simulation by shorting power rails (simulate SEL)
Add artificial load to simulate long-term TID effects (simulate TID)
Inject transients into the current measurement path (simulate SET)
These aren’t random faults — the idea is that users will estimate fault rates based on their target orbit and program the Fault Inducer MCU accordingly.
This turns the board into a safe testbed for building space-grade countermeasures.
🎮 Try These Space Engineering Scenarios
You're a software engineer working on an OBC system test. Suddenly, the main MCU restarts and your memory integrity checker flags unexpected values in the FRAM. A known SEU fault pattern was recently triggered by the fault inducer. Can you recover the correct data using redundancy? Can your system log the event without corrupting mission-critical operations?
You’re simulating a latch-up event by activating the fault inducer’s power switch control. Moments later, the current draw spikes unexpectedly. Can your main MCU detect this event fast enough to shut down the subsystem before permanent damage occurs?
These are the kinds of situations we’re enabling learners to explore. They aren’t limited to “watch this happen” demos — they ask for reasoning, response, and redesign.
Final Thoughts
The OBC block diagram marks an important milestone for this project. It's not just a diagram — it's a reflection of how we want people to learn.
By designing systems that embrace faults, rather than fear them, we hope to prepare more engineers to take on the challenges of space with confidence, creativity, and resilience.
We're continuing to build this kit in the open, and we’d love your feedback. If you're working on similar systems, mentoring early-stage teams, or just curious about how we’re designing each part — reach out. I’d be happy to share more.
