Skip to content
← All projects

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.

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.

V0.1 / intended command & data pathNon-flight testbed

Future inputs: simulated spacecraft state, environmental conditions and faults.

  1. LaptopCommand / data injection · telemetry display
  2. OBCSTM32 NUCLEO-H753ZI
  3. Payload computerRaspberry Pi 5
  4. Camera / sensorsRepresentative hardware
First planned end-to-end loop: laptop simulated uplink → OBC → payload computer → camera / sensor → payload computer → OBC → simulated downlink → laptop. This path is a build objective, not a completed test result.

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.

Real hardwareOBC + payload computer
Simulated / emulatedSensor inputs
Real hardwareAn EPS subsystem
Simulated / emulatedThe surrounding spacecraft
Real hardwareAn experimental payload
Simulated / emulatedMission conditions + communications

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.

  1. First build objective

    Command + telemetry

    Connect the real OBC and payload computer through the simulated uplink/downlink path.

  2. Planned

    Sensor + payload injection

    Add representative or simulated inputs and swappable experimental hardware.

  3. Planned

    Subsystem emulation

    Introduce EPS and RF emulation and additional subsystem interfaces.

  4. 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
  1. Loss of simulated solar input
  2. Changed power availability
  3. EPS response
  4. Spacecraft / payload response
Tumble
  1. Unexpected simulated attitude
  2. ADCS response
  3. Changed modeled solar exposure
  4. Altered power availability
  5. System-level effects
Solar / power fault
  1. Degraded solar generation
  2. EPS response
  3. Changed power budget
  4. Payload / software reaction
Sensor / component fault
  1. Bad or missing data
  2. Fault recognition
  3. Subsystem response
  4. Telemetry / operator observation
RF degradation
  1. Changed communications conditions
  2. Link behavior
  3. 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.

GroundSat V0.1

Hardware integration