Skip to main content

Background

Scheduling​

The Spire constellation is controlled via a globally synchronized calendar of fixed-duration operation windows. Each window has a fixed start time, a fixed duration, a type, and additional window-specific parameters that tune its operation.

A single window may consist of multiple steps that are scheduled together e.g. the PAYLOAD_SDR task can orient the satellite, record an IQ file, and perform an analysis of the recorded IQ file in one schedulable unit.

The canonical schedule is stored in Spire-controlled terrestrial infrastructure. Relevant windows are synchronized to each satellite during regular maintenance procedures and executed by each satellite's onboard controller.

Executing User Code​

Execution of a window may require execution of user code on the satellite. Each payload maintains a persistent per-user filesystem "sandbox". User-supplied executables are run with this sandbox as the root filesystem.

  1. Any files generated during pre-user code execution phases will be written to deterministic locations in /inbox (see particular window types for details)
  2. Any files written to /outbox will be queued for download and delivery to customer at the end of the window
  3. /inbox and /outbox are cleared between windows. Files written elsewhere will persist between window executions and may be used for staging data for transfer and processing on other payloads e.g. Sabertooth-generated waveforms for transmission on Dexter SDR or for followup operations.
  4. The stdout/stderr from a given executable will not be downloaded automatically, but can be included in the execute logs of a script by using "exec" as shown on the right.
#!/bin/bash

exec > /outbox/a_timestamped_filename
exec 2>&1

# script goes here

Note that within the "sandbox" filesystem, system folders cannot be uploaded to, as they mount to system libraries used by Spire. Please refrain from uploading to any "destination_path" starting in the following paths:

  • "/bin"
  • "/etc"
  • "/lib"
  • "/lib64" # on some systems
  • "/usr"
  • "/dev"
  • "/sys"
  • "/proc"
  • "/run"
  • "/var"

API Standards​

All responses to the API will be returned as JSON.

Successful requests will have a "data" parameter containing the results of the API call.

If the request fails, the returned JSON will have a "fault" parameter containing a dictionary with a "faultstring" parameter pointing to a string description of the error. The dictionary MAY also contain a "detail" key with additional details regarding the error. The contents of the faultstring and detail field(s) are intended for human analysis and should not be used by automated systems.

{ 
    "fault":
    { 
        "faultstring": "Failed to resolve API Key variable token",
        "detail": {
            "errorcode": "steps.oauth.v2.FailedToResolveAPIKey"
        }
    }
}

Data Delivery​

Spire maintains a minimum retention policy for customer data. All data files generated on behalf of a customer are published directly to the customer's specified S3 bucket and then deleted from Spire systems.

To enable delivery, the customer will need to add cross-account access to the desired S3 bucket for Spire. Spire will provide detailed instructions as part of initial customer signup.