VST104 OBC board series


At VisionSpace Technologies we are currently developing the free and open source VST104 board series for our developments of an onboard computer series for CubeSats. The boards are compatible with the LibreCube PC104 specifications.

  • board_zero - VST104 prototype board

    This board is designed to be connected to other LibreCube boards for hardware and software testing and development. The main working area contains of 25x25 THT universal array and two SO16 footprints. For easier access and cable management, the standard PC104 headers are brought to the sides of the working area. Plus, the shared signals have separate connectors, which might be useful for standalone testing. Thanks to these features, the board should provide an efficient tool for soldering temporary circuits with THT technology (plus the two SMD chips).

  • element_foxtrot - FlatSat

    For integration and individual testing of the different components it is convenient to have a so called FlatSat board. The different modules are interconnected and can easily be accessed. The board comes with its own 3.3 V and 5 V regulated power supply that can also be disconnected.

  • board_sierra - Single OBC

    The first onboard computer board is based around the ultra low power STM32L496xx ARM M4 MCU. For connectivity it offers a redundant CAN bus interface, I2C, SPI and UART. We further added triple redundant FRAM and flash memory blocks.

  • board_delta - Redundant OBC

    We took the design of board_sierra and put a second MCU at the bottom layer for a fully redundant CubeSat onboard computer.

  • board_whiskey - WiFi radio
    WiFi radio subsystem equivalent for testing without the need for a real radio. It will simulate a radio communications subsystem and integrate with the VisionSpace mission control system.

  • board_mike - Redundant OBC with FPGA
    This board will extend the board_delta and is the main goal to achieve within this activity. It adds a radiation hardened FPGA for compute intensive applications.

We started to order and test the already finished boards, element_foxtrot, board_zero and board_sierra have been soldered and they are working fine.


An estimation around pricing would be interesting (for me).


For the board_sierra material costs are estimated to be around 100 euros. This includes the 6 layer PCB manufacturing, connectors, the MCU and memory. If you want to go cheaper you can simply not use the PC104 connectors and less memory cells, this will reduce the price by around 50%. The same is true for the board_zero that costs approximately as much as you want to spend on the connectors (around 20 euros). Interpolating this I assume board_delta will be around 180 euros.

There is currently no plan to produce and sell these on a larger scale, the design is open and everyone is free to build it.


Thanks, that’s totally fine to decide which boards to build to play around with!

1 Like

Thanks for sharing! Awesome work and progress! I will dive into them a bit more and provide some feedback here, but one initial request (so it is easier to contirbute and track issues too) would be to maybe split the project in different repositories please? :slight_smile:


We had a quick internal chat and decided that we will move the sub folders to separate repositories in a few weeks from now :+1:


A quick update

We have just released Prust, a bare metal, Rust based free and open source implementation of the ECSS PUS-C standard (ECSS-E-ST-70-41C) for our VST104 Sierra board.

PUS tells you how to use the CCSDS Space Packet Protocol to command ( TC ) and receive telemetry ( TM ) from your spacecraft, it is used in most European spacecrafts and Mission Control Systems (SCOS2000, EGS-CC).


  • Service 1 - Request Verification: It has 9 response TM types which indicate different states for the send sub-service (for example failure, success, …)
  • Service 3 - Housekeeping: It has plenty of TM and TC packets in it. It provides one-time or periodic reports of onboard values.
  • Service 8 - Function Management: It has one request TC and executes a function defined by the user by giving the name of the function.

There are plenty of PUS services available but we limited our initial prototype to these three to allow the execution of onboard functions (service 8), receiving the current status for their execution (service 1) and scheduling housekeeping telemetry frames (service 3).

On the lower right you can see the board that is used to program the Sierra board to its left and on top of them is a populated prototyping board, connected to Sierra. Testing is ongoing, we already validated that onboard LED’s can be toggled and buttons (digital) as well as analog values can be read and sent back as telemetry packets.

We had a quick internal chat and decided that we will move the sub folders to separate repositories in a few weeks from now

We still have it on our list, currently there are just to much other things ongoing :wink:


We have split the project into separate repositories, as requested:

[edit] VST104 - Parent repository

VST104-Libraries - Project overview, KiCAD libraries, footprints, …
VST104-Zero - Prototyping board
VST104-Sierra - Single processor unit
VST104-Delta - Double processor unit
VST104-Foxtrot - FlatSat board

There are still some image links broken but we will fix this soon, just open an issue if you experience any other problems.


There is currently no plan to produce and sell these on a larger scale, the design is open and everyone is free to build it.

That’s the problem. If you don’t do that, it becomes just another open-source science project that only the most dedicated hackers will have the time or means to turn into reality.

If this was a cheap, serially produced, well-documented board like the BeagleBone Black that people could actually buy and easily use in their project… well, then we could see some actual change in this world.


I will look into this. Documentation will be made available. But getting access to more boards will likely require some sort of kick-starter. It will then depend on price and amount of persons interested.

But even serially produced, I dont think it will be cheap ( we could descope some components like the triple redundant F-RAM to save cost).

1 Like

See here for the follow-up :slight_smile:

Dear all,

We just migrated our barebone implementation of PUS-C in Rust to FreeRTOS.
Follow it on: https://github.com/visionspacetec/Prust

We now have a Rust app running on top a FreeRTOS kernel. The app itself hasn’t changed much, and still contains implementations of PUS services 1,3 & 8.

The overall stack can be seen below.

1 Like