Creating a Custom Telemetry Recorder¶

This example shows how to implement a Telemetry Recorder. A Telemetry Recorder listens on a shared memory queue for a specific topic. Topics are different for each RTC system and each topic requires a specific implementation to store the data in a FITS file.

Provided Example¶

The provided example implements a Telemetry Recorder for one of the example topics. It is not intended to be used in an actual implementation, but rather as a template for an actual Telemetry Recorder.

Source Code Location¶

The example source code can be found in the following sub-directory of the rtctk project:

_examples/exampleTelRec

Modules¶

The provided example is composed into the following waf modules:

app - The data task application including default configuration
scripts - Helper scripts for deployment and control

Dependencies¶

The provided example code depends on the following modules:

Component Framework - for RTC Component functionality with services
Client Application - to steer the application
ExampleShmPub - this is the example telemetry publisher from the DataTask example to provide example data

Running the Example Telemetry Recorder¶

The exampleTelRec can be run in isolation or as part of a SRTC system. To record telemetry data a shared memory queue needs to be created. This can be achieved using a shared memory publisher (shmPub) or a telemetry subscriber (telSub). The queue name and the destination file name need to be provided through the Runtime Configuration Repository.

To make the example as simple as possible a script rtctkExampleTelRec.sh is provided to start an example telemetry publisher and an example recorder.

rtctkExampleTelRec.sh¶

After installing the RTC Tk run the example using the following sequence of commands:

# Deploy and start the example applications
rtctkExampleTelRec.sh deploy
rtctkExampleTelRec.sh start

# Use the client to step through the life-cycle of the respective component instance
rtctkExampleTelRec.sh send Init
rtctkExampleTelRec.sh send Enable
rtctkExampleTelRec.sh send Run

# all commands until here can also be run using
# rtctkExampleTelRec.sh run


rtctkExampleTelRec.sh send Idle
rtctkExampleTelRec.sh send Disable
rtctkExampleTelRec.sh send Reset

# Gracefully terminate the applcations and clean-up
rtctkExampleTelRec.sh stop
rtctkExampleTelRec.sh undeploy

The recorded data will be stored in the exampleRecording.fits in the current working directory. This can be overridden in the tel_rec_1.yaml in the Runtime Configuration Repository.

Note

The commands indicated above, e.g. when using run, may generate the following output:

rtctkExampleDataTaskTelemetry: no process found
rtctkExampleShmPub: no process found

This is expected and should not be treated as an indication of failure.

Development Guide¶

This section explains how to create a simple Telemetry Recorder from scratch. For more detailed description see the Telemetry Recorder section.

FitsRecorder¶

This is the class that is responsible for writing the telemetry data to the fits file. This writing needs to be implemented for each telemetry type. The class provided by the RTC toolkit creates a fits file on construction and closes it on destruction. A binary table needs to be set up in the fits file and the WriteData function needs to be overridden to implement the writing of the telemetry data into the fits file. The example telemetry recorder shows how this could be implemented. To implement a recorder for other telemetry data, a new class has to be created deriving from FitsRecorder<T>.

Business Logic Class¶

The ExampleComponent tutorial shows how to create the BusinessLogic for a RTC component. The Telemetry Recorder framework of the RTC Toolkit provides a TelemetryRecorderBusinessLogic that starts a RecordingThread. Unless some specific handling of some states is required or multiple topics need to be recorded in a single recorder, the TelemetryRecorderBusinessLogic should be sufficient. Multiple topics can also be recorded by creating an extra component per topic or implementing a BusinessLogic that starts multiple RecorderThreads.

RecordingThread¶

The Recording Thread is responsible for reading the data from the shared memory queue topic and calling the FitsRecorder to persist the data to disk. A single recording thread is responsible for reading from one SHM queue and writing to one fits file. To record multiple queues, a recording thread should be started for each queue.