ORCASat Software: Telemetry Plotter, Database, and Timeline

ORCASat’s ground segment is composed of four separate applications. This article gives an overview of the entire ground segment software system.

1. The Telemetry Timeline is chronological view of actions done with the spacecraft, such as sending it commands or downlinking files from it. The timeline is built using Streamlit.

2. The Telemetry Viewer is a web app for plotting numeric telemetry data such as temperatures and voltages. It is based on OpenMCT from NASA.

3. The telemetry server is the backend that communicates between a hosted MongoDB instance and the Telemetry Viewer. It is written in Python using Flask.

4. Houston is ORCASat’s desktop app that is used for automated testing and spacecraft operations (actually sending commands to the spacraft). It is written in Python.

System View

The Houston application is the main command and control interface to the spacecraft. It formats commands, sends them through the ground segment radio, and parses responses from ORCASat. It also manages the directory structure of all data received from the spacecraft (the ground has a mirror of ORCASat’s directory layout).

All data sent to or received from the spacecraft is timestamped. Timestamps are a very important piece of metadata, since they allow us to sort events relative to each other. Properly ordered timestamps on all data allow us to confirm that power consumption increased after we enabled a spacecraft subsystem, for example.

There are two main data paths in the system. The first is the “live” path, which is for data that can be timestamped with UTC by the ground segment computer. Commands and responses received from the spacecraft during a pass are examples of live data. Live data is pushed to MongoDB as soon as it is timestamped.

The second data path is for data that is timestamped by the spacecraft’s onboard computer. Examples of data timestamped by ORCASat are telemetry lines, and commands scheduled to occur between passes. Data of this type is first checked and optionally time-corrected before it is uploaded to the database.

Regardless of the live or post-pass upload data path, all data from the spacecraft eventually ends up in the telemetry database. The telemetry timeline and viewer web apps interface with the database to provide convenient and publicly-accessible displays of all data.

Time Correction

Time corrections are necessary when we have telemetry with incorrect timestamps. This can occur when ORCASat has been unpowered for an extended period of time, since ORCASat’s real-time clock starts counting from January 1, 2020 when it loses power. So far, the only telemetry that has needed a time correction was from the first orbit because it was collected before we established contact and were able to set the time on the spacecraft.

Telemetry Timeline

The main use case of the telemetry timeline is to allow members of the operations team to see a history of commands sent to the spacecraft and data received from it. During development and testing, the chronological “timeline-style” view of command history was one of the primary ways we interacted with the hardware. We wanted to preserve this capability for mission operations, and make it remotely accessible for viewing by the team since most of us don’t have constant remote access to the ground segment computer.

ORCASat Telemetry Timeline App

The telemetry timeline app is built using Streamlit, which is an excellent way to build interactive web apps quickly. The timeline has the following features:

• Overall status view showing important immediate telemetry
• Chronological display of all spacecraft events
• Filtering of data by date, OBC info/error/debug status level, or data type (command, file downlink, etc.)
• Overview screen with plotting
• Collapsable sections for viewing file contents

The timeline is a view-only application, meaning it doesn’t allow you to command the spacecraft. We generally use it by selecting the “ORCASat day” which is a day’s range in UTC and then filtering through the data.

The app communicates with the telemetry database, which is hosted with MongoDB Atlas. The app itself is deployed on fly.io. These providers were chosen for their low costs and good ease of use. We wanted to deal with operating a spacecraft and not have to worry about security and server management.

Telemetry Viewer

The telemetry timeline is a lightly configured instance of OpenMCT.

ORCASat Telemetry Viewer App

The viewer is for numeric telemetry only, so it works for telemety like voltages and temperatures, and it can’t show one-time events such as commands or logged errors. By basing the app on OpenMCT, we gained OpenMCT’s extensive plotting, time coordination, and custom dashboard creation functions.

I developed the following things in order to make our telemetry available to OpenMCT:

1. A telemetry source. For us, this is the telemetry server app. We make API requests to the telemetry server, which include a time range and a telemetry point name. The server pulls the appropriate data from the database, and returns it as JSON. The server is a Python app using Flask.

2. A data dictionary JSON file which tells OpenMCT the names and types of each telemetry point.

3. An OpenMCT plugin that generates telemetry server API requests based on a telemetry data point name and query time range.

4. Some additional Javascript used by OpenMCT to construct the telemetry point hierarchy in the sidebar.

Houston

Houston is ORCASat’s main interface application. It started its life as a testing platform for the OBC, grew to be a spacecraft-wide testing app, and then the test features were extended for actual mission operations.

DB Uploads

One tab of Houston is for performing telemetry database uploads. In this tab, users have the opportunity to preview the data that will be added to the database, and perform time corrections to the data if required.

Uploading a pass in Houston

• ORCASat