Files
sat-rs/satrs-example
Robin Mueller 86d8528d21 feat: add FDIR fault counter and wire it into the MGM device handler
Add satrs::fdir::FaultCounter, an FSFW-style error threshold counter:
counts faults, decrements over time when faults stop, and reports
when a threshold is exceeded. Two variants for now, mirroring the
hk.rs helper pattern:
- FaultCounterStd, backed by std::time::Instant
- FaultCounterEmbassy, backed by embassy_time::Instant (embassy-time
  feature), with an optional defmt::Format impl gated on the defmt
  feature

Add satrs::health::HealthTableMapSync::default() for easy construction
of a shared, global health table.

Wire both into the example app's MGM device handler as the first real
FDIR use case:
- the minisim MGM model gains SpiFaultMode (None/AllZeros/AllOnes) and
  a SetSpiFault request, so a stuck SPI bus can be injected for testing,
  independent of switch state
- MgmHandlerLis3Mdl::poll_sensor checks the SPI transfer result: a
  comm timeout or an all-1s stuck-bus reply (the same pattern the sim
  already uses for "device off") counts as a fault. Above threshold,
  the component is marked Faulty in a HealthTableMapSync shared from
  main.rs. This logic lives in the device handler, not the SPI comm
  layer, since deciding what a failed transfer means for FDIR is a
  handler concern.
- an all-0s reply is deliberately not treated as a fault, since it
  collides with a legitimate zero-field reading
2026-09-16 13:56:47 +02:00
..
2025-02-13 12:18:05 +01:00
2024-01-31 00:02:27 +01:00
2026-08-25 17:53:38 +02:00
2024-06-03 15:22:27 +02:00
2023-01-25 21:39:35 +01:00
2025-02-13 12:18:05 +01:00

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. It is recommended to read the dedicated example chapters inside the sat-rs book.

The application opens a UDP and a TCP server on port 7301 to receive telecommands.

You can run the application using cargo run.

Features

The example has the heap_tmtc feature which is enabled by default. With this feature enabled, TMTC packets are exchanged using the heap as the backing memory instead of pre-allocated static stores.

You can run the application without this feature using

cargo run --no-default-features

Interacting with the sat-rs example

Simple Client

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 interactively:

pip install -e .

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

pip install -e .
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 -p /test/ping

You can also simply call the script without any arguments to view the command tree.

Adding the mini simulator application

This example application features a few device handlers. The satrs-minisim can be used to simulate the physical devices managed by these device handlers.

The example application will attempt communication with the mini simulator on UDP port 7303. If this works, the device handlers will use communication interfaces dedicated to the communication with the mini simulator. Otherwise, they will be replaced by dummy interfaces which either return constant values or behave like ideal devices.

In summary, you can use the following command command to run the mini-simulator first:

cargo run -p satrs-minisim

and then start the example using cargo run -p satrs-example.