This article is the first in a series of posts about ORCASat’s flight software. It provides a brief overview of many of the major components.

Core Functionality

The onboard computer of ORCASat is responsible for providing the following functions:

1. Telemetry Collection: Collection, timestamping, and non-volatile storage of telemetry from all other subsystems.

2. Telecommand Handling: Processing and execution of immediate and time-tagged commands. Immediate commands are used during a radio contact (a “pass”) to bring down data and query state. Time-tagged commands are sent during a pass to trigger events in the future, such as payload operations.

3. Timekeeping: Since telemetry needs timestamps and commands can be scheduled to execute at a specific time, the flight software and OBC hardware is responsible for keeping track of time on the spacecraft.

4. Health Monitoring and Safety: In the event that unexpected errors occur or telemetry values reach dangerous levels, the flight software must ensure that the spacecraft is safe. For us, the definition of “safe” is contactable from the ground and power-positive. Health monitoring involves looking for errors, and safety involves managing spacecraft state in the event that an error is detected.

5. Data Storage and Configuration The flight software must handle storing telemetry and payload data in non-volatile media so that it is available to us even if the spacecraft loses power. It must also store configuration for the OBC and other subsystems so that we can modify their behaviour without needing to do full flight software updates.

Reliability Philosophy of ORCASat

There are at least five microcontrollers on ORCASat, all of which run flight software of some description. However, only the onboard computer microcontroller has features that provide radiation tolerance. It also has the most extensive test coverage among the embedded systems. For these reasons, the onboard computer is considered to be the most reliable part of ORCASat, so it is responsible for maintaining safety and controlling all other subsystems.

1. The onboard computer sequences power for all other subsystems because it has the most comprehensive view of spacecraft state.
2. The onboard computer features ECC memory, which protects against single-bit errors in RAM, and will trigger a reset if double-bit errors occur. Therefore, OBC flight software can use memory and assume that the contents are valid.
3. The onboard computer has multiple levels of watchdogs to catch software lockups.
4. Several parts of the onboard computer were radiation tested.

Low-level Hardware Drivers

Most low-level drivers are provided by TI’s HALCoGen hardware abstraction layer generator. We wrap all of the low-level drivers with our own layer that provides logging, thread safety, and error handling.

RTOS

Flight software is built on top of FreeRTOS. FreeRTOS was selected because it was already ported to the TMS570 microcontroller, and because it has excellent documentation. The following points apply to our FreeRTOS use:

1. All RTOS primitives are statically allocated
2. Commands exist to control task priority, although we have never used them on-orbit
3. We can enable a low-power mode using the idle task hook

Filesystem

We selected LittleFS from ARM as the filesystem because it is designed to work with NOR flash, has power-loss tolerance, and good testing and documentation. We also considered YAFFS, which was rejected because it is geared towards NAND flash, and imposes GPL licensing restrictions. Another candidate was SPIFFS, which was rejected because it does not support directories or bad block detection.

Timekeeping

Flight software queries the real-time clocks regularly and attempts to detect errors. Real-time clock errors include time not incrementing, or time moving backwards. While these error cases seem odd, we know that our real-time clock hardware is susceptible to these errors induced by radiation.

In the event of an error, flight software will either switch to the redundant real-time clock if it is working properly, or will switch to a backup time source implemented with a microcontroller timer. The backup time source is the last choice because it is less accurate than the real time clocks due to lack of temperature compensation.

The time can either be set manually from the ground, or can be set from the GNSS (generic term for GPS and other similar systems, such as Europe’s Galileo) unit. Typically we set time from the ground to avoid turning on the GNSS and needing to acquire a lock, but GNSS time syncs are most accurate.

Telemetry

Most telemetry collection is done in individual FreeRTOS tasks (one per subsystem). All telemetry collection periods are configurable, and we sometimes increase them when we want more data around a certain event. Telemetry can also be queried manually (by individual immediate telecommands). Telemetry collection tasks also monitor the telemetry values and can execute state changes or error handling procedures if off-nominal telemetry values are seen.

Commanding

ORCASat’s flight software handles two main types of commands called “prompt commands” and “long commands.” The difference between these two types is how much data they generate and how retries are handled.

Prompt commands are commands whose reply from ORCASat can fit into a single radio packet. The retry protocol is as follows:

1. If no response is received, query the spacecraft for its last-received command sequence number
2. If the sequence number matches, the spacecraft received the command, but ground did not receive the response. Request the last response.
3. If the sequence number does not match, the spacecraft never received the command. Send it again.

Long commands are commands that generate a lot of data (more than can fit in a single radio packet). Since it’s possible for any or all packets to be dropped, we use the CFDP file transfer protocol to ensure that long command data is received completely on the ground.

If commands are time-tagged to execute after a pass, their responses are saved in the onboard filesystem so that they can be downlinked later.

Schedule

When a command is sent to the spacecraft, it is placed in a list of commands called the schedule. A task called the scheduler runs frequently and determines if any commands need to run at the current time. If they do, they are placed in a queue to be executed by the executer task. This design preserves the execution order of tasks, and ensures that all commands are executed in the right sequence relative to each other even if a single command took a while to run.

Commands also exist for schedule maintenance. Some examples are:

1. Print the schedule
2. Remove a previously-scheduled action
3. Change the exection period of an action

• ORCASat