SRG / Ground-based engineering
GroundSat
Reusable hardware-in-the-loop spacecraft testbed
An MDSE-led, reusable hardware-in-the-loop (HIL) spacecraft testbed. Real hardware meets simulated mission inputs—on the ground, not in flight.
Ground-based only. GroundSat does not fly.
- Current lead
- Mission Design & Systems Engineering (MDSE)
Why build a satellite that never flies?
A testbed for interactions. Not just components.
A component can work in isolation while the integrated spacecraft behaves incorrectly. Attitude changes solar exposure; available power changes payload operations. Sensor, software and communications faults can propagate beyond their starting point.
What does the rest of the spacecraft do when one component—or its environment—changes?
GroundSat is intended to make those interactions repeatable to investigate, without building a new test setup for every project.
01 / How GroundSat works
One command. A complete return path.
The first build aims to close a command-and-data loop through real computers and representative hardware. Arrows show intended information flow, not a confirmed electrical or bus interface.
Future inputs: simulated spacecraft state, environmental conditions and faults.
- LaptopCommand / data injection · telemetry display
- OBCSTM32 NUCLEO-H753ZI
- Payload computerRaspberry Pi 5
- Camera / sensorsRepresentative hardware
Planned extensions: EPS emulator · RF emulator · swappable experimental devices. Advanced simulation and a custom operator GUI are not built.
Real where it matters. Simulated where it helps.
GroundSat has no fixed hardware boundary. The real/simulated boundary can move depending on what is being tested. These are intended configurations, not existing demonstrations.
As the platform develops, larger portions of the emulated system can be replaced with real hardware.
02 / Initial reusable HIL baseline
GroundSat V0.1
The V0.1 computing architecture is selected and locked. Hardware is beginning to be ordered and assembled; the testbed is not yet operational.
Selected / being built
- OBC
- STM32 NUCLEO-H753ZI
- Payload computer
- Raspberry Pi 5
Representative hardware
- Camera
- IMU
- Temperature sensors
- Cables, harnessing and representative sensor interfaces
- Supporting interface electronics as required
V0.1 capability target
Intended baseline—not a completed capability list.
- Real OBC and payload computer with representative sensors and a camera
- Bidirectional communications through the command/data path
- Laptop-based command and data injection
- Telemetry return and display
- At least one swappable experimental device
- EPS emulator
- RF emulator
The bench is the platform
Built to change. Not built to fly.
GroundSat is intentionally unconstrained by flight packaging. Boards and subsystems can stay accessible for removal, replacement, instrumentation or substitution with emulators. The bench is not a compact, mass-optimized CubeSat stack or a replica of a particular mission.
- Accessible
- Modular
- Instrumented
- Reconfigurable
03 / Intended development progression
From component testing to system behavior.
The first command-and-telemetry loop is the immediate build objective. Each later stage expands the test boundary; none is presented as complete.
First build objective
Command + telemetry
Connect the real OBC and payload computer through the simulated uplink/downlink path.
Planned
Sensor + payload injection
Add representative or simulated inputs and swappable experimental hardware.
Planned
Subsystem emulation
Introduce EPS and RF emulation and additional subsystem interfaces.
Future
System + fault simulation
Change mission conditions, inject bad data and faults, and observe the connected system’s response.
04 / Future test scenarios
Follow the chain reaction.
Examples of intended coupled tests—not tests already performed. Simulated conditions would drive responses across connected real and emulated subsystems.
- Eclipse
- Loss of simulated solar input
- Changed power availability
- EPS response
- Spacecraft / payload response
- Tumble
- Unexpected simulated attitude
- ADCS response
- Changed modeled solar exposure
- Altered power availability
- System-level effects
- Solar / power fault
- Degraded solar generation
- EPS response
- Changed power budget
- Payload / software reaction
- Sensor / component fault
- Bad or missing data
- Fault recognition
- Subsystem response
- Telemetry / operator observation
- RF degradation
- Changed communications conditions
- Link behavior
- Command / telemetry response
First planned use case / Onboard image processing
One workload. Not one mission.
The first planned experiment uses a camera to supply imagery to the payload computer, where a small convolutional neural network (CNN) would process it. Results would return through the GroundSat data path.
This workload supports current UNP Mission Concept development while giving GroundSat a concrete end-to-end exercise. The testbed itself remains mission-independent and reusable; no processing or test results are claimed yet.
Explore UNP mission-development work ↗Designed for club-wide use.
MDSE currently leads GroundSat. The long-term aim is shared test infrastructure for SRG’s technical teams and future payload teams—not a claim that those teams are participating today. Structures can contribute when a relevant test calls for it.
Current lead
Intended future users
- RF & Ground Station
- Embedded Software
- Electrical
- Future payload teams
GroundSat V0.1