Inside MIST: Keeping Tabs on the PRESET Satellite From Earth
Written by: Kusali Palihwadana
Work on a satellite doesn’t stop after launch. The success of a mission depends heavily upon controlling the satellite from a distance and receiving data in real-time, therefore reliable software is critical. To learn more about what goes into the design and testing of these systems, we recently sat down for a Q&A with Leo Calogero, the Flight Software Team Lead at MIST.
When asked to describe, in his own words, the software team’s main responsibilities for the PRESET mission, Leo highlighted that they work to “ensure the software runs reliably on-orbit” such that it can “handle data routing, command execution, and fault events.” Specifically, this involves developing and testing the firmware and embedded software that runs on the satellite in flight, such as the FreeRTOS-based logic* and communication interfaces between subsystems.
To anticipate challenges in orbit, the team has several layers of verification in place. The intensive process begins with unit-testing, where each software module is tested in isolation: “This helps catch logical issues early and keeps components stable,” Leo explains. Once each subsystem can stand on its own, they are integrated and tested on the FlatSat, which is a bench-top replica of the satellite’s electronics. In this stage, the goal is “to validate integrated functionality across multiple subsystems in a controlled environment.”
The next step is one that the team recently completed: a week-long burn-in test, where the full software stack is run continuously. Leo describes it as a “stress-test” for subsystem stability, where small issues in timing, memory management, and other steadily compounding bugs tend to reveal themselves. “The test yielded valuable lessons about how the satellite behaves under sustained operation and how different subsystems interact,” he continues. “Overall, [it] was a major success and a key milestone on the road to launch.”
Pictured above is the Engineering Qualification Model (EQM) Assembly of the satellite used during the burn-in test. This assembly included the bus stack electronics which includes the communications module (COMMs), the command & data handling (CDH) subsystem, the electrical power system (EPS), and the MAG subsystem. The FlatSat motherboard, featuring the CDH and Altitude Determination and Control System (ADCS) on-board computers (OBCs), is shown below.
On top of that achievement, the team recently integrated real-time housekeeping data streaming between the satellite and ground station. Housekeeping data captures live health metrics from each subsystem — including temperatures, voltages, and error counters — giving operators a snapshot of each subsystem's state and overall satellite health.
*Real-time operating system. An operating system designed to ensure that data processing and event handling occur within specific time constraints. [1].
Designing for Orbit
When asked about the biggest challenges in software flight development, Leo is quick to answer: “Reliability.”
“Space imposes constraints that add difficulty to every task,” he says. “During flight, cosmic rays can flip bits in memory, potentially corrupting stored data or the program state.”
The team prepares for such events by incorporating multiple layers of protection, including watchdog timers* and error correction code. “We do not use heap in our code, as dynamic allocation can fragment memory over time and introduce unpredictable error[s],” Leo notes. Rather, all memory is statically allocated at compile time.
This approach to structuring software is different from what is taught in school and requires more careful planning. And unlike many student software projects, flight software cannot be debugged directly once the satellite is in orbit. “Every line of code must be written, reviewed, and tested as if it needs to work correctly on the first try.”
*A timer that expects a periodic pulse signal from the processor in a specified time frame. Otherwise it initiates a hard reset of the system [2].
Building Across Disciplines
Collaboration within the Software Team takes a project-based approach. “We do not use subteams,” Leo clarifies. “Instead, each member is assigned a project – such as CAN driver*, File System, Command Scheduler – and is directly responsible for its development and testing with their team lead.” This way, ownership stays with the person assigned to that project.
During firmware development, the team regularly collaborates with MIST hardware developers. “Firmware development is inherently cross-disciplinary, so we coordinate to ensure that both sides are in alignment.”
*Controller Area Network. A physical and data link layer standard protocol.
The Next Phase
Keeping the momentum following the successful burn-in test, the team will be assembling the complete EQM in the next few weeks. Throughout, the focus remains on refining and validating the systems that will guide the final satellite through the PRESET mission.
At the end of our time, it is clear that the Software Team isn’t simply writing code, but steadily building the intelligence that will allow the satellite to operate, communicate, and adapt once it reaches orbit.
References
[1] P. A. Laplante and W. Cedeno, "An Overview of Real-Time Operating Systems," SLAS Technology, vol. 12, no. 1, pp. 40-45, 2007.
[2] K. Odom, "What Is a Watchdog Timer and Why Is It Important," Texas Instruments, 2023. [Online]. Available: https://www.ti.com/document-viewer/lit/html/SSZTAH7. [Accessed 30 June 2026].
