CubeSat Command Module Introduction

The Estonian Student Satellite Foundation has been working on the CubeSat command module since 2025 alongside our other project called the Strategic Upgrades Test Satellite (SUTS). The command module is intended to be a technology demonstration payload on the upcoming ESTCube-3 CubeSat. It is the main processing unit of the satellite, it controls all the subsystems and enables communication with the ground control station. The intent of the command module has been clearly outlined and is as follows:

1. The system shall serve as a spacecraft’s central control and data management authority.

2. The system shall provide a configurable platform for fast-paced in-orbit software based demonstrations.

3. The system shall implement cybersecurity measures to protect onboard data and communication systems.

4. The system shall be capable of onboard anomaly detection using Artificial Intelligence algorithms to increase spacecraft autonomy.

5. The system shall incorporate a software-defined radio.

6. The system shall be compatible with nano and micro satellite form factors.

7. The system shall maintain operational functionality for a minimum of 5 years in a 550 km Sun Synchronous Orbit.

Along with the intent of the command module, three use cases were outlined, which means, the command module has to be able to function and satisfy the requirements presented by each use case.

The first use case – Commanding the satellite

The Command Module shall serve as the CubeSat’s central control and data management authority, running flight software on the dual processing system of an Radio Frequency system on Chip (RFSoC). The RFSoC includes a real-time processing unit for operations like actuator control and an application processor for higher-level mission management and coordination. The Command Module as a whole  is responsible for receiving and validating telecommands, managing spacecraft modes, coordinating subsystems, collecting telemetry, and enforcing fault detection, isolation, and recovery (FDIR) strategies.

The Command Module also has the option to use a Software Defined Radio (SDR) in the RFSoC’s programmable logic section, enabling hardware-accelerated transfer of telemetry and telecommands without requiring a dedicated radio communications system. This design maintains operational control and deterministic timing in real-time functions while providing flexibility to support evolving mission-specific needs with flexible communications schemes via the SDR.

A diagram representing the different functions that the command module has to fulfil.

The second use case – Running scripts

The command module shall support an easily reconfigurable and reprogrammable software environment capable of running various software-based experiments. The environment shall be specifically designed to enable advancements in flight software verification and validation, cybersecurity, artificial intelligence for autonomous operations, in-orbit data analysis, and development & testing of new communication protocols. Providing a platform for in-orbit software demonstrations is crucial for developing future autonomous satellite systems, enhancing mission operations, and creating opportunities for new companies to expand into space.

The software environment shall have access to the satellite’s sensors and actuators, paving the way for rapid in-orbit software demonstrations of novel algorithms deemed too risky for conventional, high-cost missions. In dangerous situations or during code malfunctions, the Command Module monitoring software shall disconnect the scripting engine from the rest of the platform, restoring nominal operations.

Illustration of the second use case.

The third use case – Providing a software defined radio

The Software-Defined Radio of the Command Module will provide a flexible, high-performance communications channel for the CubeSat by leveraging the programmable logic section of the RFSoC. The SDR implements the complete digital baseband modem and RF signal processing chain, including modulation, demodulation, channel coding, filtering, and data framing, enabling reliable uplink and downlink communications across a range of mission-specific protocols and data rates.

The SDR operates under supervisory control from the Command Module firmware, which configures communication sessions, manages data flow, and monitors system health. By implementing the modem in reconfigurable logic, the SDR allows in-orbit adaptation of modulation schemes, coding rates, and bandwidth, while hardware acceleration minimises latency and power consumption. This separation of responsibilities enables independent development, testing, and fault containment of the communications system while maintaining tight integration with the real-time application processor through well defined control and data interface.

In the longterm, the subsystem also aims to support transponder functionality, enabling the CubeSat to respond to ground-based ranging and Doppler measurements commands. This capability allows accurate determination of the spacecraft’s distance and relative velocity from Earth, supporting spacecraft location determination. Such functionality is particularly beneficial for Low Earth Orbit (LEO) missions, where rapid orbital tracking is needed, and for lunar or deep-space missions, where precise range and velocity measurements are critical for navigation and trajectory corrections.

Illustration of the third use case.

Development timeline

The development of the Command Module has been divided into different phases, Phase A, B, C, and D the general timeline follows that of the ESTCube-3 satellite development as both are being developed in tandem.

Planned timeline of the Command Module development.

Currently, the Command Module development team is at the preliminary design phase where the development team is investigating different approaches to solve a problem and creating an initial plan to tackle them. This means that the team is looking at different hardware components and different software frameworks along with physical design mock ups to weigh their positives and negatives of each decision. These decisions include, what operating system to utilise, what components to build ourselves or buy in and the manufacturing and verification approaches to make sure the final product meets the requirements that were set in the beginning of the development.


Be sure to check back in the upcoming months, where we will be reporting on the architecture of the Command Module in depth by introducing its different subsystems.

Credit goes to the Command Module team for the provided text and assistance!

Comments

Leave a Reply

Discover more from Estonian Student Satellite

Subscribe now to keep reading and get access to the full archive.

Continue reading