ACP SatOS Operations Manual

1. ACP Operational Overview

1.1. ACP Operate General Information

The Operate tab provides the interface for satellite operators to interact with the satellite. Upon entering the tab, the list of promoted satellites will be provided on the side, with a map of the globe in the center. Upon selecting a satellite, the operator will enter the Heads-up Display (HUD).

1.1.1. HUD

The HUD shows the operator the most important information about your satellites in a clear and easy-to-understand way. This information includes:

· The current location and orbit of a satellite (or a fleet of satellites).

· The tasks your satellites are currently working on and any upcoming events.

· Any warnings or alerts that need attention

From the HUD the operator can access multiple windows using buttons to assist their work. Each of these buttons opens up a secondary window that can be dragged or pinned on the screen. The top left has a home button to return to the previous screen, as well as the satellite name and TLE details. By accessing the TLE details the operator can view the TLE currently uploaded to the satellite, the date it was updated, and potentially manually update the TLE.

In the top right the operator will find the quick actions panel with 4 more buttons: Onboard Schedule, Console, Telemetry, and File Queue.

Example of the HUD in the Operate tab

1.1.2. Onboard Schedule

This button opens a window showing the schedule onboard the satellite. It shows the details for each event in sequence for the satellite, including telemetry and payload downlinks, payload events, and scheduled uplinks.

1.1.3. Console

This button opens up the command console and messages for the operator.

Viewing Live Telemetry through the Console

A table with the most recent command and telemetry messages sent and received will populate. The command field indicates whether the message was a command (TC) or telemetry (TM) message, and the message color indicates whether the message was successful or not. Selecting the message will display additional information about the message in the space below, including the undecoded hex data and the decoded JSON packet details of the message. Each message is unique in the packet details and more information can be found in the telemetry and command database.

Console with TM message details open

Message Colors:

  • Yellow: Successful command that induced a corresponding telemetry response from the satellite

  • Green: Telemetry response from a corresponding command

  • Blue: Beacon or health metric telemetry

  • Red: Incomplete, potentially corrupted message

  • None: Command that did not induce a telemetry response detected by ACP

Manual Telemetry and Raw Bytes

At the top of the console window, in addition to the typical minimize, pin, and close buttons found on most windows, there is a toggle for raw bytes and a button to upload a file. The raw bytes toggle will show only the raw bytes for each message but may also display messages that were partially corrupted due to loss of data. The upload file button allows an operator to manually import a telemetry file in the event that telemetry is not visible in ACP.

Upload File/Raw Bytes details

From this window the operator can select a band type, ground station ID, and epoch to upload the file to the satellite. The file itself can be dragged onto the section once that information has been filled out, or the operator can select it manually. Once the telemetry is imported, a success message will be displayed and the file will be visible in the command telemetry messages window.

Commanding and Uploading Files through the Console

The left side of the window offers the command console, an interface for the operator to send manual commands to the satellite. Starting from the top, the operator may select TT&C to send single manual commands from the database, or TASK to send ad hoc tasks or upload a schedule. The TASK window can also be used to manually upload files to the satellite, like payload firmware updates. The operator can select “Upload File” from the task type window and select a file to upload or provide the information manually. Once everything is confirmed, the file upload and corresponding details will appear in the file queue window.

If TT&C is selected, the operator can filter the tasks using selections for bus, payload, or raw input components, as well as filtering based on subsystem or an editable text field for command id or command number. After the operator has selected a command or group of commands to upload, it needs to be assigned to a contact. This can be done at the bottom of the contact window. By default, the next contact appears showing the location and time until the start of the contact window. The operator can also select the calendar button below, to select a specific contact window instead. Once the contact is selected, the operator can hit “Schedule Now” and the command or commands will be added to the queue of telecommands for the satellite in that contact window. These telecommands will have a Bytes Length of 0 until they are sent during their scheduled contact. If the operator selects a contact window for which the satellite is already in, the “Schedule Now” button will instead say, “Execute”, and the command will be sent immediately.

If an operator would like to send commands or downlink telemetry on a specific band (UHF or SBand), the operator should select the contact that has the desired configuration. No explicit telecommands are needed to configure the communications link.

Example of a Telecommand about to be scheduled for a future contact
Example of telecommands queued for a subsequent contact (note the Bytes Length of 0)

It is possible to send raw commands in the form of undecoded hex data by selecting Raw Input as the Command Type. This is useful for sending commands that are complicated to modify within the JSON view. Typically, these raw commands are provided by a subsystem specialist. The operator will need to specify whether or not the packet header is included in their provided byte stream.

1.1.4. Telemetry

The 3rd button in the quick action panel provides a quick option to display some of the more important historical telemetry of the satellite. This display provides graphical information that is easy to digest for each of the satellite subsystems. The operator can select which subsystem from a drop-down menu at the top. From each graph, the operator can use hover their cursor over a location to provide more information. The operator can also click and drag over an area to home in on key ranges. The information provided here is a subset of the information provided on the Monitor tab.

1.1.5. Contacts and Events

The HUD also provides the operator with important upcoming information for contacts and events. Ground contact opportunities are provided by the ground station provider as inputs into ACP and then will be displayed in several locations. The bottom of the screen shows a running window of the satellite schedule, that can be configured between 30 minutes and 3 hours. In it the operator is able to visualize any upcoming, current, or previous events as well as look further ahead or back by selecting arrows at the far right or left respectively. On the left side, the operator can filter the events displayed by selecting drop down and choosing between ground contacts, onboard schedule, or both options. Above the dropdown, the HUD displays the most recent completed contact and the next upcoming contact as well as some information about each.

1.1.6. Settings

The settings button in the bottom right allows the operator to configure the display of the Earth to their preference. This gives the operator the ability to zoom in and out of the map, toggle a 2d or 3d view, change the mapbox style to a satellite/dark/light view, as well as an eclipse toggle to show the light and dark sides of the Earth.

1.1.7. Plan

In addition, the HUD tab, there is also the Plan and Monitor tab. Both of these tabs provide expanded information for that is displayed in the Onboard Schedule, Ground Contact, and Telemetry Displays. The Plan tab has two subtabs for Onboard Schedule and Ground Contacts. This Onboard Schedule subtab provides a larger number of schedule events as well as additional information about each event. The operator can also use the buttons at the top right of the display to manually import or generate schedules for the satellite.

Example of Schedule Generation from Task Plan

The Ground Contacts subtab displays all available ground stations in a table with their scheduled and previous ground contacts. The operator can select a ground contact to display additional information about it on the right-side including contact type, duration, start time, and an image of the location of the ground station on the world map.

Example of Ground Contact Subtab View

1.1.8. Monitor

The Monitor tab provides the similar graphical views of historical telemetry of the satellite as the telemetry quick action button in a larger format. These graphs have the same subsystem filters as well as the same analytical capabilities. The operator may change the view to grid or list in the top right, as well as filter based on date range.

Example of OBC telemetry in the Monitor tab

2. Operating a Satellite

2.1 Satellite Behavior

The satellite often experiences repeated behavior while on orbit. While this behavior may change, it is intended to help the operator with some activities, observations, and operational procedures performed during the daily monitoring of a satellite.

2.2.1. Orbit Characteristics

The satellite operates in a Sun-Synchronous Orbit (SSO) at an approximate altitude of 450 km. It will complete one Earth revolution every ~90 minutes, maintaining consistent local solar time for surface overpasses. During each orbit it will experience sunlight ~55-60 minutes and eclipse ~30-35 minutes. It will also undergo the following during an orbit:

· Battery systems alternate between charging (sunlight) and discharging (eclipse)

· Elevated Battery Discharge during payload and propulsion states

· Thermal states fluctuate with sunlight exposure

· Attitude control systems maintain nadir pointing or payload-specific orientations

2.2.2. Ground Contacts

The satellite will pass within view of a ground station while it is in orbit. With sufficient pass parameters (time, elevation, weather) the satellite can communicate with the ground station in a contact. These contacts are usually 5-10 minutes and occur roughly 3-6 times per station per day. These contacts serve as the only way to uplink and downlink data from the satellite. While the satellite is not in a contact window, it is operating autonomously and collecting and storing payload and telemetry data. Then during a contact window, this data can be downloaded from the satellite. The longer the satellite goes without downlinking the data stored onboard, the more data it has stored within and there can be issues with both data storage as well as downlink bandwidth to address. These contact windows are also where the operator can communicate through a ground station with the satellite to issue commands or update the satellite firmware. These commands can be scheduled ahead of time or run manually during a contact.

2.2.3. Beacons

The satellite will automatically emit beacons at regular cadences that are predetermined in the SatOS software. These beacons contain top-level satellite health information and will appear in the Console regularly, and are not induced by any telecommand. Beacons are emitted from both the UHF and S-Band modules at different cadences, but contain the same information

  • TM-815 = OBC beacon transmitted via UHF (4 packets emitted every 1 minute)

  • TM-411 = OBC beacon transmitted via SBand (2 packets emitted every 2 minutes)

Beacons are a good way to passively verify the ground receive/satellite transmit path as well as gather onboard information prior to executing any activity.

2.2.4. Day-in-the-Life Operator Tasks

Common operator tasks for a satellite vary by mission and by the phase that mission is in, but in general some procedures would include the following:

· Review and trend downlinked telemetry to monitor long term satellite subsystem health.

· Prepare command loads and scheduling updates for upcoming passes.

· Plan and verify payload tasking for upcoming daylight passes.

· Identify and address anomalous behavior

Please see Section 3.1 and 3.2 for examples of pre-launch and post-launch operator tasks

2.3. Upload Files

  1. in Operate > HUD open the Console

  2. Go to the Task tab in the left pane

  3. Choose Task Type = Upload File

  4. Select Choose File to upload a locally-stored file to ACP

  5. Use the following parameters

    1. App ID: 134

      1. ID 134 = PS (Payload Server)

    2. File ID: same as file name

    3. Destination ID: 134

    4. Max Transmission Unit: 1300

    5. Delay: 200

    6. Activity Timeout: 200

    7. Connection Timeout: 200

    8. Loss Detection: Enabled

  6. Click Upload File

  7. Look for a pop-up message indicating success or failure

Example of Upload File configuration

2.4. Command Sequencing with Adhoc Tasks

ACP can automate sending a set of commands from the ground with relative delays (in seconds) between each telecommand. While they does not completely remove the operator from the loop, adhoc tasks significantly reduce operator error and bandwidth when taking contacts.

Create Task

  1. Go to Design > Satellites and click on your desired satellite

  2. Go to Operations > Tasks and click Create Task

  3. Enter a Task Name

  4. Choose Task Type Adhoc

  5. Click + Telecommand

  6. Add your desired Telecommand based on Input Type

    1. Use Telecommand Builder for telecommands that can be sent with their default values

      1. Component: Subsystem to send telecommand to

      2. Telecommand: Telecommand ID and string

        • Can use ID in dropdown for easier search

      3. Preview: Telecommand JSON with default values (cannot be modified)

    2. Use Raw Input for telecommands that need their default values modified

      1. Copy and paste your desired telecommand JSON into the input box

  7. Add Delay (in sec) at the bottom of the Task Creation window

    1. It is recommended to add at least 7 seconds of delay for each telecommand to avoid undesired OBC resets

  8. Add the telecommand

  9. Repeat steps 5-8 for all telecommands

  10. To rearrange the order of telecommands, click the 6 dots to the left of the telecommand and drag to the desired order

  11. Save the Task Plan

Example Task Plan

Execute Task

  1. Go to Operate and click on the desired promoted satellite

  2. In the top right of the HUD view, click on Console

  3. In the Console, go to the Task tab

  4. Choose

    1. Task Type: Adhoc Task

    2. Task: Title of desired task

  5. In the bottom left of the console, click on the calendar icon next to Schedule Now

  6. Choose the contact to deploy this adhoc task to

  7. A highlighted box with the contact info will appear. Make sure that this is the desired contact

  8. Click Schedule Now

  9. Check to see if the telecommands are in the queue by cross-checking TC IDs. These queued telecommands will have a Bytes Length of 0

    1. You may need to close and re-open the Console to see the queued telecommands

  10. The AdHoc tasks will begin 15 seconds after expected AOS. One can verify that telecommands are being sent by watching each Bytes Length field change to a nonzero value.

3. Common Operational Tasks Using ACP

3.1. Examples of Pre-Launch Tasks

Common flatsat activities performed before launch can be broken down into functional tasks which focus on validating subsystem behavior, and mission planning tasks which focus on higher-level operations and flight team readiness.

  • Functional Tasks

    • Test subsystem commissioning and health checkouts (EPS, ADCS, OBC, TT&C, Propulsion, and Payload)

    • Validate command execution and telemetry generation

    • End-to-end communication verification between ACP, ground software services, and the flatsat or

    • Power modeling (e.g., boot, safe, nominal)

    • ADCS Modeling (Detumble, Sun pointing, Nadir Pointing, Target Pointing)

  • Mission Planning

    • Verify automated LEOP sequences and scripts

    • Verify LEOP procedures that require operator intervention

    • Train operators and familiarize them with the satellite, procedures, tooling, and operational workflow and intuition

    • Rehearse LEOP procedures with subsystem specialists and greater flight team

3.2. Examples of Post-Launch Tasks

Flatsat activities commonly performed after launch focus on recreating and debugging anomalies that transpired in the production environment, verification of future activities, and further software development.

  • Anomaly response analysis and verification

  • Onboard schedule and adhoc task acceptance testing

  • Software development and acceptance testing

3.3. How to Execute Routine Operator Tasks

3.3.1. Induce an Automated Health Metric Dump

The OBC logs predefined telemetry from various subsystems. To access this stored telemetry, one can induce a health metric dump in three ways:

  1. Send any TC at least 2.5 minutes after the last TC has been sent. This will dump all historical telemetry across all subsystems

  2. Send TC - 621 Get Health Data of All Submodule All Queue to explicitly dump all historical telemetry across all subsystems

    • If inducing over UHF over-the-air, it may take up to 2 minutes to receive all telemetry. Commanding may be limited during this downlink period

  3. Send TC-621 for your desired subsystem

    1. The operator can look up the appropriate command string for TC-621 when using Console or Ad-Hoc Task Creation (ex: for OBC-specific health metrics, choose 621 - Get OBC Health Telemetry Configuration)

The Submodule IDs and Queue IDs for each health metric packet is located on the far right side of the Console under Info. The Submodule ID’s are listed below as reference:

  • 0 = EPS

  • 1 = ADCS

  • 2 = COMMS SBAND

  • 3 = COMMS UHF

  • 4 = SENSORS

  • 5 = OBC

  • 6 = ERROR HANDLER

If an operator would like to downlink health metrics on a specific band (UHF or SBand), the operator should perform this downlink over a contact that has the desired configuration. No explicit telecommands are needed to configure the communications link.

3.3.2. Disable an Automated Health Metric Dump

Sometimes, the automated health metric dump can impede operations in several ways:

  • Makes commanding impossible during the downlink during bi-directional UHF operations (since UHF is half-duplex)

  • Takes a non-trivial amount of power to transmit all health metric data, especially over S-Band

  • Crowds the telemetry logs, impeding time-sensitive decision-making

To disable this feature, send TC-622 Change Queue Priority of All Submodules

  • CurPriority = 0

  • IsSingle = 3

  • Priority = 2

  • QueueID = 255

  • SubmoduleID = 255

To re-enable automated health metric dumps, send TC-622 Change Queue Priority of All Submodules again with the following parameters:

  • CurPriority = 2

  • IsSingle = 3

  • Priority = 0

  • QueueID = 255

  • SubmoduleID = 255

3.3.3. Query EPS Power State

  • To query the current power state of the batteries, boards, and solar panels, send TC-200

  • To query historical power states, induce an EPS health metric dump with TC 621 - Get EPS Health Telemetry Configuration

3.3.4. Payload/Edge Application Upgrade

  1. Build application artifacts (upgrade_artifact.tar) with Docker

    1. Create .tar images of the “factory” version and the “updated” version. command: docker save -o <image_name> <image>:<tag>

      • “Factory” version should be available at <payload directory prefix>/factory_image/ directory on PS

      • ex) satos-payload-antaris:factory is the name of the docker image of factory version. docker save -o satos-payload-antaris-app_factory.tar satos-payload-antaris-app:factory

      • ex) satos-payload-antaris:latest is the name of the docker image of updated version.

        docker save -o satos-payload-antaris-app_latest.tar satos-payload-antaris-app:latest

    2. Generate upgrade_artifact.tar using the factory image tarball and the updated app image tarball

      • Use the bash script create_docker_artifact_tar.sh to generate the app artifacts. This script assumes that docker version being used is >=25.0.0

      • Run the bash script with bash create_upgrade_docker_artifacts_tar.sh -f <factory image tarball> -u <updated image tarball>

  2. Upload upgrade_artifact.tar with the parameters (refer to section 2.3)

    1. App ID = 134

    2. Destination ID = 134

  3. Send TC-609 (app id = 136) to confirm the current app image tag on the flatsat

  4. Send TC-610 (app id =136) to upgrade the app image to the new tag

    • This upgraded image will be stored under the factory_image directory with the tarball titled "<PAYLOAD_IMAGE_NAME>_update.tar"

  5. Verify in TM-610 that Response = 0 (success)

    1. IF Response != 0: Skip to step 8

  6. Send TC-611 (app id = 136) to upgrade the factory image to the latest update tag

  7. Verify in TM-611 that Response = 0 (success)

  8. IF app image response was not successful, restore the previous factory image with TC-612 (app id = 136)

  9. Send TC-609 (app id = 136) to confirm that the current app image tag is the updated tag

PreviousTrueTwin TechnologyNextGround Communications

Last updated