An Earth observation mission requires coordinated orbital planning, attitude control, energy management and data transfer. SLX OrbitLab integrates these functions in a PC-based software system: a simulated satellite receives a target, plans the pass, acquires an optical product and transfers it during ground-station contact. Commands, telemetry and events track software decisions and the physical model's response.
SLX OrbitLab is the Silicon LogiX platform for satellite mission software development and simulation, autonomous systems and embedded controllers. Version 0.7.0 integrates a native NASA F Prime deployment running on Linux, a proprietary C++ core, Basilisk simulation, a Qt desktop console and Godot 3D inspection. An optional subsystem executes RTEMS firmware on a LEON3 processor emulated in Renode. The platform executes a complete command, physics simulation and telemetry cycle on a PC. Integration tests connect operational decisions, spacecraft dynamics and firmware behavior.
Embedded engineering and mission software integration
- Flight software: F Prime components, FPP interfaces, dispatching, telemetry, events and native command sequencing.
- Simulation and control: orbital and attitude dynamics, sensor measurements, reaction wheels and energy accounting.
- Embedded systems: RTEMS firmware, the LEON3 BSP, timers, periodic tasks, UART and CRC-protected protocols.
- Verification: repeatable faults, recording, synchronized replay, strategy comparisons and measured results.
- Integration: Qt operation, Godot visualization and a C++ core that can be supplied separately as a binary library.
Mission software architecture: commands, simulation and telemetry
The operational path is explicit: command → mission software → physical simulation → telemetry → console and 3D update. The GUI sends a request; F Prime receives it through its dictionary and dispatcher; the Mission component calls the C++ core to assess conditions and select actions. Basilisk applies actuator commands and power loads, integrates the dynamics and returns new measurements.
At the next step, mission software consumes those measurements, updates its decisions and emits telemetry and events. GUI refreshes do not advance physical time. This boundary makes it possible to repeat an experiment, pause it, advance by individual steps and inspect the same moment through different views.
| Technology | System responsibility |
|---|---|
| F Prime 4.3.0 / C++ | Commands, components, events, telemetry channels, responses and native sequencing. |
| Silicon LogiX C++ core | Mission decisions, target management, energy assessment, protection and attitude control. |
| Basilisk 2.12.0 / C++ and Python | Orbit, attitude, sensors, reaction wheels, solar generation, battery and applied thrust. |
| Qt 6.12 / QML | Mission console, command and sequence editors, telemetry, recordings and reports. |
| Godot 4.5 / Blender and GLB assets | Synchronized spacecraft, interior, exploded, orbit and ground station inspection. |
| RTEMS 5 / Renode 1.16.1 | Energy-controller firmware running on an emulated LEON3/SPARC target as an optional subsystem. |
F Prime: C++ components, native commands and telemetry
F Prime organizes flight software into components with declared ports and connections. OrbitLab uses this architecture as its command execution path. FPP definitions describe parameters and interfaces, the Ground Data System uses the generated dictionary to encode requests and decode packets, and the native dispatcher delivers each command to its destination component.
Version 0.7.0 exposes 28 dictionary commands and 50 native channels. Selecting a command shows its parameters, examples and operational meaning. Operators can request panel deployment, a relative rotation, Sun or Earth pointing, payload and downlink permissions, a beacon and the orbital maneuvers supported by the model. Diagnostic commands also verify the communication path.
For example, OrbitLab.mission.MANEUVER [3,30] requests a 30-degree relative rotation in mode 3. The dispatcher response confirms acceptance of the parameters; telemetry subsequently shows pointing error, attitude and actuator state. Acceptance, physical effect and operational completion are separate pieces of evidence. An accepted request may remain pending while simulation time is paused or energy, sensors and protection inhibit the action.
For a commissioned project, this executable path supports concrete discussions about interface contracts, parameter bounds, component behavior, failure handling and integration tests.
![Actual SLX OrbitLab interface: native MANEUVER command with [3,30] arguments, a confirmed response and F Prime telemetry channels](https://www.siliconlogix.it/assets/news/article-body-20261014122953-1-c7ff7786.webp)
F Prime sequences: planning, validation and execution
OrbitLab integrates native Svc.CmdSequencer execution. Operators prepare plans of 1 to 64 steps with relative delays in simulated seconds and validate them against the session dictionary. F Prime tools compile the binary file; native validation checks its format and CRC before execution.
A plan can run automatically or advance through manual steps. Cancellation, completion verification and responses for each step are preserved. Delays follow simulation time and begin after the previous command's response. Pausing stops this clock as well, keeping sequencing and dynamics consistent.
The eight-step example deploys the panels, suspends the optical instrument, requests Sun pointing, enables the beacon after five seconds, commands a 30-degree rotation after another 45 seconds, disables the beacon after another 60 seconds, and restores the payload and automatic mission. Events and telemetry show the executed list and its consequences for the spacecraft.
Sequences time command requests; they do not automatically wait for attitude convergence. Acquisition conditions remain in the C++ mission state machine. Separating the operational plan from control of physical behavior supports focused testing and a correct interpretation of the results.
Basilisk: orbital dynamics and attitude control
Basilisk combines C++ numerical modules and Python configuration for space-system simulations. OrbitLab uses this foundation to integrate orbital position and velocity, attitude and angular rate, sensor measurements and reaction-wheel action. Python coordinates the laboratory and adapters; mission decisions execute in the C++ component.
The reference case declares an initial circular orbit at approximately 550 km, a 65 kg rigid body and three reaction wheels. Quantities cross the simulation boundary with explicit units: metres, metres per second, seconds, radians, watts and joules. Attitude and measurements use declared frames, distinguishing the controller's available information from diagnostic simulator truth.
Orbital maneuvers integrate mission commands, operational constraints and propulsion dynamics. An RTN delta-v command is checked against energy, propellant, sensors, alignment and orbital conditions. Basilisk integrates finite thrust applied to the body; reports retain delivered delta-v, remaining propellant and changes to orbital parameters. Adding a terrestrial target during a mission preserves the existing trajectory. The software predicts accessible passes, while a physical burn changes the orbit gradually.
Energy management and activity planning
The battery has a finite capacity of 180 Wh. Solar generation, panel orientation and deployment, eclipse and active loads contribute to the physical balance. The core compares available energy, reserves and activity demand, using a short-horizon energy forecast. The numerical foundation includes Basilisk's storage model and solar-generation model.
When energy is insufficient, acquisition is deferred, loads are reduced and the reason is recorded. The physical model therefore experiences a different consumed power from the load required to capture an image. Battery telemetry reflects an energy balance changed by the software decision. Protection remains active during manual requests.
Two comparable strategies, priority-first and energy-aware, use different planning margins while both protect the minimum reserve. A comparison starts from the same initial conditions, targets, seed, faults and recorded stimuli, with separate F Prime processes and Basilisk simulations. Results include completed or deferred observations, final energy and pointing accuracy during acquisition.
Earth observation: targets, acquisition and downlink
The operator selects coordinates and priority. Software predicts access windows, commands pointing and requires stability before exposure. The reference configuration requires a measured error below 0.5 degrees, three seconds of stability and a twelve-second exposure. These values are parameters of the simulated mission.
The synthetic optical product uses actual simulated body attitude, camera-ray intersections with the spherical Earth and the geographic texture. Raw data is a 256 × 256 monochrome PGM image. A derived PNG preview relates the target, sensor footprint and cartographic context, making the experiment's content easier to interpret.
Bytes are saved in modeled onboard storage and transferred during a geometric ground-station contact window when energy permits downlink. Storage capacity, the product queue and link availability can change the plan. Delivery is confirmed when the received file passes its SHA-256 integrity check. The link model verifies data handling and mission constraints; it does not calculate an RF link budget or radio modulation.
Qt console and 3D visualization with Godot and Blender
Qt Quick and QML compose the operational console: mission control, F Prime commands, sequence editing, channels, targets and products, orbital passes, tests and recordings. The telemetry model updates values while preserving the operator's browsing position. Parameters and descriptions connect a command to its function, operational response and telemetry. One operator controls a session; viewers receive its state.
Godot 4.5 presents close-up spacecraft, interior, exploded, orbit and ground station views. Component selection connects geometry to subsystems and available commands. Attitude, panel joints, the beacon and antenna follow confirmed backend telemetry.
Blender assets and GLB exports retain original component names, hierarchy and pivots. Earth's illustrative scale and exploded-view offsets belong to presentation and do not enter the dynamics. Blender/glTF axis conversion is explicit and applied once. This integration choice makes 3D a useful inspection tool while keeping it distinct from the physical model.
RTEMS and Renode: embedded firmware on emulated hardware
RTEMS provides the kernel and services for real-time embedded applications. In OrbitLab it executes an independent energy-controller firmware. F Prime remains a Linux process; RTEMS is a separate subsystem. Interfaces between mission software, the energy model and firmware handle power requests, controller responses and load states.
Renode emulates the LEON3/SPARC target, including the peripherals needed for timers and UART. Antmicro's public RTEMS/LEON3 example documents the platform overlap; OrbitLab's integration was verified with its own firmware. Compatibility requires alignment between the ELF, BSP, memory map, clocks and timer, followed by boot and execution tests.
The adapter sends battery energy, capacity, requested power and explicit mission time through sequence-correlated, CRC-protected UART messages. Firmware returns permitted power, flags and the task heartbeat. This permission constrains the loads applied to Basilisk. Tests cover boot, timer interrupts, a periodic task, load reduction at low and critical energy, malformed CRC rejection and recovery after an invalid message.
Emulated time advances in controlled intervals. Missing firmware responses stop the experiment; the laboratory does not silently replace RTEMS with PC logic. Compatibility and integration tests cover this specific combination of firmware, BSP and emulator. Qualification of electronics or a flight processor requires dedicated work.
Mission scenarios, synchronized replay and results analysis
| Scenario | Expected operational outcome |
|---|---|
| Nominal mission | Target access, stable pointing, acquisition, storage and a delivered file with verified integrity. |
| Insufficient energy | Deferred activity, a recorded reason, reduced loads and a recorded recharge balance. |
| Temporary sensor outage | Acquisition held while measurements are invalid, tracked sensor state and renewed condition checks after recovery. |
The extended campaign also covers actuator faults, loss of solar generation or ground link, multiple products, full storage and continuous operation. Fault-injection intervals and operator commands are retained as test evidence.
SQLite recording preserves configuration, commands and native packets, events, physical snapshots and products. Replay restores recorded state without redispatching actuator commands. Timeline, telemetry, imagery and 3D follow the same instants. HTML, JSON and CSV reports and SHA-256 manifests support investigation from a shared trace and strategy comparisons with explicit metrics.
The release 0.7.0 acceptance evidence records 26 Linux integration tests, three Windows CTest checks, eight publication-boundary regressions and GUI workflows with native commands, sequences and maneuvers. Operation with a binary SDK, without the proprietary core sources, was verified separately.
The documented SDK case delivers one product with an acquisition pointing RMS of approximately 0.0586 degrees. A maneuver delivers 2 m/s and updates remaining propellant. These are results for the stated configuration and test conditions, rather than an accuracy promise for arbitrary satellites.
Proprietary C++ core, binary APIs and simulation models
The proprietary Silicon LogiX engine exposes a versioned C ABI with fixed-size structures, declared units and an opaque handle. Its interface contains no Qt, Godot, Python or F Prime types. The core can be supplied as a shared library and integrated or updated while preserving the binary contract, independently of presentation and adapters.
The public GitHub repository contains the GUI, integrations, API, example firmware, scenarios, approved assets, documentation and tests. Proprietary core implementation is excluded. Building and running OrbitLab from public source requires the matching evaluation binary SDK; distribution and commercial development follow the project's terms.
The model declares its scope: spherical Earth, simplified reference frames, no J2 perturbation, atmosphere, terrain or thermal environment, an ideal battery, constant dynamic mass and a synthetic optical instrument. It does not represent cell chemistry, analog power electronics or a complete RF link. Repeatability is verified with the pinned Linux environment and the same seed; cross-platform bitwise identity is not promised. The model documentation makes parameters, criteria and simplifications available for review.
Custom engineering for companies and research organizations
OrbitLab's architecture integrates engineering capabilities applicable to mission software, embedded controllers, simulation benches and operational consoles. For companies and research organizations, a project can begin with operational requirements, available measurements, energy constraints, abnormal conditions and system acceptance criteria.
- F Prime components: FPP definitions, topologies, commands, telemetry, events, service integration and native tests.
- Simulation and autonomy: Basilisk models, C++ control, planning, resource management and fault scenarios.
- Embedded firmware: RTOS/BSP integration, protocols, peripherals and emulated-target verification before hardware tests.
- Consoles and tools: Qt/QML applications, 3D inspection, evidence acquisition and presentation.
- Verification and delivery: repeatable campaigns, agreed metrics, reports, documentation and distributable interfaces.
Explore the OrbitLab repository and technical documentation, or contact Silicon LogiX for a technical presentation, an evaluation SDK or a custom project. The starting point is to define what the system must do, how it should respond at its limits and which tests must document compliance with those requirements.
