Execution Environment

Users software runs in a persistent sandboxed execution environment on a Spire payload, which is a specific Linux computer on a satellite controlling specific hardware. User software is uploaded to this sandbox environment through the Tasking API. User software has access to its own filesystem and various software libraries, the specifics of which depend on which payload the user is scheduling operations on. The file system is persistent between contacts, files saved to the users filesystem will persist until they are deleted by the user.

Filesystem

The execution environment includes two top level directories used to manage incoming and outgoing data:

• /inbox - Spire generated files during a payload window will be placed into this folder. For example, IQ files captured during a PAYLOAD_SDR window will appear in this folder. File names and types placed in this folder will vary between window types, please consult the Tasking API documentation for details about a specific window. Files placed in this folder should be handled by the user in the window which they are generated.
• /outbox - Any files placed in this folder by the user's software will be queued for downlink. Files placed here will be removed by the Spire Linux Agent after any payload window.

The root filesystem is writable to the user. Common Linux directories have been bind-mounted read-only, e.g. /bin, /usr, /proc, /var, /home etc. The user's home directory ~ is ephemeral (not persisted between restarts) and may not be on the same path for each payload. The Tasking API executes user applications outside of a shell. For these reasons it recommended to:

1. Create a wrapper shell script & to add environment variables for PATH and other user requirements
2. Create and use /persist or similar directory name at the root of the filesystem, for files that should remain on the payload for future windows
   1. When installing, install to this directory
3. Treat all existing directories as read-only

Wrapper Script

The Tasking API is used to deploy apps to payloads and execute them. It is helpful to use a wrapper script to provide a consistent environment between payloads, to set common environment variables and capture stdout and stderr to a log file for download at the end of the window. The wrapper script, named entry.sh can be deployed to each payload at /persist/bin/entry.sh and used for all execution commands. All tutorials require entry.sh to be deployed. The script can be deployed to a payload by running deploy in the dev-env directory:

$ dev-env/deploy "[YOUR_AUTH_TOKEN]" [YOUR_SAT_ID] [YOUR_PAYLOAD]

Networking

Payloads have direct IP network access via ethernet to listen on ports above 10000, as well as make connections to those ports. TCP & UDP are supported. Payload modules with overlapping windows have IP routes available between them for the duration of the overlap. Users are expected to setup server and client on each module to facilitate communication.

Inter-Satellite Links (ISL)

Inter-satellite data transfer is possible using ISL. In order to utilize inter-satellite data transfer, A LEASE_ISL windows must be scheduled concurrently with a PAYLOAD_* on each side satellite. One satellite is selected as a transmitter and the other as a receiver. A network gateway/route is available on the SABERTOOTH, LEMSDR & IPI payloads that routes IPv4 traffic via the ISL radio for SIMPLEX transmission to a receiving satellite. UDP transmission is possible over the SIMPLEX link. The ISL network uses standard IP networking. Using NAT, the remote payloads are addressable on the 172.16.0.x subnet (The subnet 10.2.1.x is replaced with 172.16.0.x by the NAT router).

IP Table

Payload Specifications

Below are the list of specifications for each payload type accessible to Software in Space users including the list of packages pre-installed on the payload.

SDR

IPI

SABERTOOTH

Dexter

NOTE

The ARM Cortex R5F real-time processors (RPUs) are only available with Payload In Space service.

Next Steps

• Attitude Control