1. BaSaMa & HiWi
    2.  

CubeSat Space Protocol (CSP) Implementation Analysis for EventSat UHF Communications

Institut
Lehrstuhl für Spacecraft Systems (TUM-ED)
Typ
Bachelorarbeit / Semesterarbeit /
Inhalt
theoretisch / konstruktiv /  
Beschreibung

CubeSat Space Protocol (CSP) Implementation Analysis for EventSat UHF Communications

Start date: Summer Semester 2026

Duration: max. 6 months, adaptable

Topic

This project is embedded within the EventSat satellite mission at the Chair of Spacecraft Systems (TUM SPS): https://www.asg.ed.tum.de/en/sps/eventsat-mission/ 

The analysis of integrating the CubeSat Space Protocol (CSP) into a CubeSat mission that was originally baselined on a proprietary protocol stack is a problem faced by many university and small satellite missions that procure COTS platforms but need protocol flexibility. This work contributes a structured methodology for evaluating protocol stack replacement in a constrained embedded system: the framework for mapping existing architecture to CSP layers, the analysis of hardware interface compatibility, and the assessment criteria for protocol migration decisions are reusable. The CSP integration methodology and the general architectural analysis should be documented for independent publication, separable from EventSat-specific configuration details.

Goals

The goals of this project are the following:

  • Analyze the CubeSat Space Protocol (CSP) architecture, capabilities, and existing implementations (primarily libcsp) to establish its suitability as a replacement for the EnduroSat AirMAC protocol on EventSat's UHF link

  • Map the current EventSat COM and CDH architecture — including the UHF transceiver interface, OBC software framework, and ground segment protocol handling — to identify all integration points and constraints for a CSP implementation

  • Develop a detailed integration concept describing how CSP would be implemented within the existing architecture: which layers of the CSP stack replace which current components, what modifications are needed to the OBC software and ground segment, and what the interface to the EnduroSat UHF transceiver hardware looks like under CSP

  • Assess the impact of switching from AirMAC to CSP on mission-level parameters: data throughput, latency, reliability, ground station compatibility, and operational procedures

  • Provide a clear go/no-go recommendation with identified risks and a preliminary implementation roadmap

  • Provide a preliminary implementation concept or interface specification for the recommended option, sufficient for integration assessment by the COM and CDH sub-teams

Extension Points

BT scope (baseline): The Bachelor Thesis covers the full analysis chain: CSP protocol study, architecture mapping, integration concept, impact assessment, and recommendation. The deliverable is primarily analytical with architecture diagrams and a written recommendation — no working implementation is required.

BT → ST elevation: To elevate to a Semester Thesis:

  • Require a quantitative throughput and overhead analysis using either simulation or analytical modelling, not just qualitative comparison. The student should produce numerical estimates of achievable throughput under CSP vs. AirMAC for representative pass scenarios

  • Add a requirements-level analysis: derive communication subsystem requirements from mission-level needs and formally evaluate whether CSP satisfies them, using traceable requirement verification methods

  • Expect a more rigorous systems engineering perspective: the protocol choice as a system-level trade-off with implications traced across COM, CDH, OPS, and Ground Infrastructure sub-teams

 

BT → IDP elevation: To elevate to an IDP (CS variant):

  • Shift the deliverable emphasis from written analysis to working software: the IDP student should produce a prototype CSP implementation running on either the actual OBC development board or a representative embedded platform (e.g. STM32 or similar ARM Cortex-M board if the OBC dev board is not available — confirm hardware access before scoping the IDP variant)

  • Include a ground segment CSP implementation (or adaptation of an existing one) that demonstrates end-to-end communication through CSP between a ground station test setup and the OBC prototype

  • Require proper software engineering practice: documented APIs, unit tests, CI pipeline, deployment instructions

  • The written report is shorter (IDP format) but must include the architecture decisions and test results

Tasks

The tasks of the project are the following. Time to completion is given in full-time work dedication:

  • CSP Protocol Analysis: - Study the CSP specification and the libcsp reference implementation. Document CSP's layered architecture, supported transport mechanisms (UDP, RDP), routing model, and interface driver model (~2–3 weeks) - Survey existing CSP deployments in CubeSat missions: which missions use CSP, what hardware platforms, what lessons learned are documented in the community (~2 weeks)

  • EventSat Architecture Mapping: - Document the current EventSat UHF communication chain from ground station through transceiver to OBC, identifying all protocol layers, data formats, and interfaces as currently baselined with AirMAC (~2 weeks) - Identify the EnduroSat UHF transceiver's hardware interface capabilities: what physical-layer and data-link-layer services does the transceiver provide, and what must be handled in software on the OBC? Determine whether CSP can interface directly with the transceiver's UART/SPI interface or whether an intermediate adaptation layer is needed (~2 weeks)
  • Integration Concept: - Design the CSP integration architecture for UHF: map each CSP layer to the EventSat system, specifying which components run on the OBC, which on the ground segment, and how the transceiver hardware interface is handled. Note that S-Band will continue to use the proprietary protocol stack regardless of the UHF decision (~2–3 weeks) - Identify all required modifications to the existing OBC software framework and ground segment software to support CSP on UHF. On the ground segment side, a CSP plugin for the Mission Control System (YAMCS) already exists and provides reference code — assess whether this can serve as the ground-side CSP implementation or whether additional development is needed (~2 weeks) - Address ground station compatibility: in the target architecture, the ground station provides a generic SDR interface (see the related On-Ground Data Handling IDP). A CSP-based UHF service would run as a separate mission-specific instance alongside the proprietary protocol stack instance used for S-Band. Assess how CSP integrates with this multi-service model (~2 weeks)
  • Impact Assessment: - Compare AirMAC and CSP on key mission parameters: achievable net throughput, protocol overhead, retransmission behaviour, latency, ground station compatibility, and community support (~2 weeks) - Identify risks and open issues in the CSP migration path: hardware incompatibilities, missing drivers, testing requirements, schedule impact (~2 weeks)
  • Recommendation and Roadmap: - Provide a justified go/no-go recommendation for CSP adoption on EventSat UHF (~2 weeks) - If go: produce a preliminary implementation roadmap with work packages, dependencies, and estimated effort to reach flight-ready status (~2 weeks)
  • Documentation: - Compile the full analysis in a report/thesis document. Maintain analysis artefacts and any prototype code in a Git repository (~2 weeks, continuous)

Expected results

  • A CSP protocol analysis document covering architecture, capabilities, and community deployment status

  • An EventSat architecture map showing the current UHF communication chain and all CSP integration points

  • A detailed CSP integration concept with architecture diagrams, interface definitions, and required modifications

  • A comparative impact assessment (AirMAC vs. CSP) on mission-level communication parameters

  • A go/no-go recommendation with risk register and (if go) a preliminary implementation roadmap

  • All analysis artefacts and any prototype code in a documented Git repository

Prerequisites / Required Background

  • Understanding of communication protocols and layered network architectures

  • Programming experience in C (libcsp is C-based) and Python (ground segment tools)

  • Familiarity with embedded systems concepts (UART/SPI interfaces, resource-constrained software)

  • Willingness to engage with open-source community code and documentation (libcsp GitHub)

  • For IDP variant: strong software engineering background; the deliverable emphasis shifts toward a working prototype rather than a written analysis

Möglicher Beginn
sofort
Kontakt
Ramon Garcia Alarcia
Tel.: +49 89 289 55752
ramon.garcia-alarciatum.de
Ausschreibung