While doing all this, it should get out of the way by honoring LST best practices:

Must handle and dispatch to multiple struct definitions per project. Each struct has a unique ID at the second
byte position. When receiving binary payloads from UDP, the messages have to be dispatched appropriately. Example:

In order to make Kotori grok the message structs defined in standard C/C++ header files, there are some specific details
to be followed. The initializer flavor to be used currently is the “list-initializer” style as seen below.
Further, transformation rules can be attached to specific fields by adding annotations in comments.
See also example below and Transformation rules.

The purpose of transformation rules is to apply scaling factors to values and to rename fields.
This is achieved by adding a declarative annotation on the same line of the struct field definition. Example:

int16_thdg;//6 // @rule: name=heading; expr=hdg * 20.1; unit=degrees

This will:

rename the field from “hdg” to “heading”

perform scaling by applying the factor 20.1 to the raw value

configure value unit “degrees” in Grafana (TODO)

The evaluation of expressions is based on the fine SymPy library and can be made of a number of mathematical
expressions, see also SymPy Features.

There’s a commandline tool for applying transformation rules to payloads, see Transform message.

For using the channel operations, the user basti should navigate to /home/basti/kotori and then start “source .venv27/bin/activate”.
From this environment, the commandline-based channel operations should be available.

So, the canonical channel names are “h2m” and “sattracker”.
They can be configured in Kotori configuration file, e.g. etc/lst.ini.
Use them as the <channel> parameter to lst-message in the following commands.