sat-rs/satrs-example

sat-rs example

This crate contains an example application which simulates an on-board software. It uses various components provided by the sat-rs framework to do this. As such, it shows how a more complex real on-board software could be built from these components. The application opens a UDP server on port 7301 to receive telecommands.

You can run the application using cargo run. The simpleclient binary target sends a ping telecommand and then verifies the telemetry generated by the example application. It can be run like this:

cargo run --bin simpleclient

This repository also contains a more complex client using the Python tmtccmd module.

Using the tmtccmd Python client

The python client requires a valid installation of the tmtccmd package.

It is recommended to use a virtual environment to do this. To set up one in the command line, you can use python3 -m venv venv on Unix systems or py -m venv venv on Windows systems. After doing this, you can check the venv tutorial on how to activate the environment and then use the following command to install the required dependency:

pip install -r requirements.txt

Alternatively, if you would like to use the GUI functionality provided by tmtccmd, you can also install it manually with

pip install tmtccmd[gui]

After setting up the dependencies, you can simply run the main.py script to send commands to the OBSW example and to view and handle incoming telemetry. The script and the tmtccmd framework it uses allow to easily add and expose additional telecommand and telemetry handling as Python code. For example, you can use the following command to send a ping like done with the simpleclient:

./main.py -s test -o ping

You can also simply call the script without any arguments to view a list of services (-s flag) and corresponding op codes (-o flag) for each service.

Structure of the example project

The example project contains components which could also be expected to be part of a production On-Board Software.

1. A UDP server to receive telecommands and poll telemetry from. This might be an optional component for an OBSW which is only used during the development phase on ground.
2. A PUS service stack which exposes some functionality conformant with the ECSS PUS service. This currently includes the following services:
   • Service 1 for telecommand verification.
   • Service 3 for housekeeping telemetry handling.
   • Service 5 for management and downlink of on-board events.
   • Service 8 for handling on-board actions.
   • Service 17 for test purposes (pings)
3. An event manager component which handles the event IPC mechanism.
4. A TC source component which demultiplexes and routes telecommands based on parameters like packet APID or PUS service and subservice type.
5. A TM sink sink component which is the target of all sent telemetry and sends it to downlink handlers like the UDP and TCP server.
6. An AOCS example task which can also process some PUS commands.