The Sapling flight computer is a revision of the PyCubed V5, which was developed at Stanford University and flight proven on the NASA V-R3x mission. Information and documentation about the PyCubed is available at PyCubed.org. It is a SAMD51 based, COTS designed board which performs overall command of the spacecraft and commands all other subsystems. The PyCubed boards are assembled on campus by students at Stanford using a PickNPlace machine.
SSI’s sapling avionics and software, all of which comply with and address the following requirements, are publicly available on GitHub.
Demonstrating use of the PickNPlace machine to visiting high school students
Command and Data Handling Requirements
| Requirement | Parameter | Description | Parent(s) |
|---|---|---|---|
| Top Level Architecture | |||
| CDH-101 | The spacecraft shall use the PyCubed CubeSat framework. | SYS-701 | |
| CDH-102 | Flight code shall be written in PyCubed’s native CircuitPython. | CDH-101 | |
| CDH-103 | 32 GB | The spacecraft shall have onboard memory storage. | SYS-102, SYS-301 |
| CDH-104 | The spacecraft shall be able to access onboard sensor data. | SYS-102 | |
| Logging | |||
| CDH-201 | The spacecraft shall log data to the SD card. | SYS-102 | |
| CDH-202 | The spacecraft shall delete excess log files automatically. | CDH-103 | |
| Requirement to avoid increasing the time it takes to index the SD card. | |||
| CDH-203 | The spacecraft shall log exceptions and errors for debugging later. | SYS-102 | |
| CDH-204 | The spacecraft shall log data/errors with GPS time for more insightful analysis/debugging. | SYS-102 | |
| CDH-205 | The spacecraft shall move to logging on MRAM if the SD card fails. | CDH-103 | |
| CDH-206 | The software shall maintain persistent configuration storage for inflight counters and flags. | SYS-102 | |
| CDH-207 | The flight software shall maintain log files of exceptions and anomalies for downlink and analysis. | SYS-102 | |
| Spacecraft Reboot Criteria | |||
| CDH-301 | The spacecraft shall reboot if there is an uncaught exception in the software. | SYS-501 | |
| CDH-302 | The spacecraft shall reboot if the code locks up. | SYS-501 | |
| CDH-303 | The spacecraft shall reboot into CircuitPython normal mode if the power off of the 3.3V reg fails | SYS-501, CDH-102 | |
| Power Modes | |||
| CDH-501 | idle mode, low power mode | The spacecraft shall have a configurable power mode (“low power mode”). | OPS-102 |
| CDH-502 | Automatically enter safe mode based on configurable temperature and battery state of charge thresholds with deadbands. | OPS-102, OPS-301, OPS-302, OPS-303, OPS-304 | |
| Deadbands avoid jitter. | |||
| CDH-503 | 60 mins | The spacecraft shall beacon at some configurable interval while in low power mode. | SYS-101, SYS-102 |
| The spacecraft must still accomplish its primary mission goal while in low power mode, and the spacecraft must be able to return to nominal operational mode (“idle”) by meeting exit criteria or receiving ground command. | |||
| Flight Software Performance | |||
| CDH-601 | The spacecraft software shall be robust to peripheral failure. | SYS-501 | |
| CDH-602 | The spacecraft software shall be robust to corrupted config files. | SYS-501 | |
| CDH-603 | The onboard computer shall attempt to re-initialize hardware that fails to initialize upon first attempt. | SYS-501 | |
| The flight software shall be able to return arbitrary queries of state maintained throughout the software | CDH-101, CDH-102, SYS-101 | ||
| Radio and Command | |||
| CDH-701 | The spacecraft shall listen for commands after beacons, asynchronously. | SYS-101 | |
| CDH-702 | No-op, hreset, shutdown, query, exec_cmd, receive_file, TASP | The spacecraft shall upload command files received via radio. | SYS-101 |
| CDH-703 | boot count | The software shall Include a ground station contact counter that counts the number of successful contacts. | SYS-101 |
| CDH-704 | The software shall allow for modules to be updated over the air, and automatically used on next reboot. | CDH-702 | |
| CDH-705 | The spacecraft shall be protected against unauthorized command. | SYS-101 | |
| CDH-706 | The flight software shall be able to execute arbitrary commands. | CDH-101, CDH-102, SYS-101 | |
| CDH-707 | The spacecraft shall shutdown on command. | SYS-501 | |
| CDH-708 | The spacecraft shall hard reset on command. | SYS-501 | |
| CDH-709 | The flight software shall be capable of executing arbitrary command on the payload computer. | SYS-301 | |
| CDH-710 | The spacecraft shall take and downlink a picture on command. | SYS-301 | |
| CDH-711 | Files shall be put on or retrieved from the payload computer on command. | SYS-301 | |
| CDH-712 | Commands may be strung together by a multi command option. | CDH-706 | |
| Beacon Contents | |||
| CDH-801 | beacon | The spacecraft shall downlink data from onboard sensors about its status and environment | SYS-102 |
| CDH-802 | solar_charging (boolean), batt_voltage, system_voltage, system_current, batt_temp | The spacecraft shall transmit data about its EPS. | SYS-102 |
| CDH-803 | 16 bit int lat, 16 bit int lon, 16 bit int altitude, GPS time as seconds from epoch | The spacecraft shall transmit data from its onboard GPS. | SYS-102 |
| CDH-804 | ambient light sensor values, 16 bit magnetometer readings in 3 axes, | ||
| 16 bit gyroscope readings in 3 axis | The spacecraft shall transmit data about conditions on orbit from onboard sensors. | SYS-102 | |
| CDH-805 | 50-60 bytes | The spacecraft beacon shall pack telemetry data as tightly as possible. | SYS-101, SYS-102 |