Frequently Asked Questions

Raspberry Pi CM5 · View all FAQs

Submit a Question

It is a shared orbital software rideshare aboard a Blackwing Sparrow nanosatellite. Multiple independent software payloads run on Blackwing's Raspberry Pi Compute Module 5 (CM5) payload, with Parsimoni SpaceOS as the primary deployment and application-management environment. Blackwing provides the spacecraft, launch integration, licensing, ground systems, and mission operations.

The mission is intended for startups, commercial technology companies, research organizations, and university teams seeking flight heritage or on-orbit validation for software, AI, autonomy, edge computing, data processing, cybersecurity, middleware, fault detection, or software-defined sensor applications.

The target is no earlier than Q3 2027 on a commercial rideshare mission. Commissioning and software operations are planned for Q3–Q4 2027. The schedule is subject to launch-provider readiness, satellite integration, regulatory requirements, and mission readiness.

The standard hosted-software slot is $20,000:

  • $5,000 refundable reservation to begin technical qualification
  • $5,000 at flight integration
  • $5,000 at launch
  • $5,000 at on-orbit execution

The milestone timing is subject to the definitive payload agreement and mission schedule.

Yes. The $5,000 reservation remains refundable until both technical acceptance and execution of the definitive payload agreement. Once accepted, it is applied to the mission price. If software cannot be made flight-ready for this mission, applying the reservation to a future mission may be considered under the mission terms.

To reserve a spot, complete the mission agreement and submit your initial deposit through our mission reservation page. Once both are received, your payload slot will be confirmed and the Blackwing Space team will begin the technical onboarding and integration process.

  • Technical qualification and compatibility review
  • Access to the SpaceOS development workflow
  • Defined compute, memory, storage, runtime, and data allocations
  • Flight acceptance review
  • Scheduled on-orbit deployment and execution
  • Access to approved telemetry and mission data
  • Agreed workload logs, outputs, and evidence of execution
  • Mission operations support
  • Agreed rights to reference participation and resulting flight heritage

The flight baseline is a Raspberry Pi CM5: a 2.4 GHz quad-core Arm Cortex-A76 system with configurations up to 16 GB LPDDR4X RAM and 64 GB eMMC. It is a scheduled, duty-cycled compute resource operating within spacecraft power, thermal, communications, and operational limits. Wireless is disabled on orbit.

SpaceOS is the mission operating system. You may use any programming language and dependencies, provided the final deployment artifact runs on ARM64, fits within the launch image size limit, and stays within the approved CPU, RAM, and storage limits at runtime. Compiled languages such as C, C++, and Rust are recommended for resource efficiency. Final language, dependency, and deployment choices require mission approval during technical qualification.

SpaceOS supports two integration paths:

  • OCI container image: Supply a Docker/Podman-compatible image built for ARM64. The application and its dependencies run in a minimal virtualized Linux environment supervised by SpaceOS. This is the simplest integration path, with a small CPU and RAM overhead.
  • Unikernel: Frameworks such as MirageOS and Unikraft can run over KVM/Virtio on ARM64. This path requires more build and integration work and restricts language and dependency choices, but can produce much smaller binaries and improve resource efficiency. Parsimoni can support customers using this approach.

Other deployment paths are considered only when technically necessary and approved during qualification.

SpaceOS supports deploying, updating, and managing software in orbit. However, the baseline schedule includes a flight-software freeze and flight-acceptance review before launch. Post-launch updates, while possible, are not planned for this initial mission.

The baseline minimum per payload is one full week of cumulative CPU time across all duty cycles and 2 GB of persistent eMMC storage. CPU time is scheduled across execution windows, not provided as an uninterrupted week of operation.

Usable SDRAM allocation is confirmed during technical qualification against the final flight hardware configuration. The CM5 module's maximum supported memory is not a guaranteed per-payload allocation.

Resource allocations are reviewed and tuned during qualification. Communications budgets, execution frequency, and telemetry access limits are also established during qualification and recorded in the payload agreement.

The baseline is scheduled, duty-cycled operation. Specific activation windows and duration will be determined during payload integration and confirmed in the payload agreement.

No hardware-level throttling is currently planned. Power, thermal, and operational constraints still apply, and final limits are confirmed during integration review.

Yes. Customers should develop and test on commercially available Raspberry Pi CM5 hardware matched to the mission's development specifications. Blackwing Space provides the hardware specifications, while Parsimoni provides a SpaceOS development environment and tools for simulating and validating customer software on that hardware.

This development environment does not reproduce the full complexity of the flight payload or spacecraft. It supports development and compatibility testing; final mission integration and qualification are still required.

Approved read-only data may include:

  • Power and battery status
  • Platform and battery temperatures
  • System-health telemetry
  • GNSS position, velocity, and altitude
  • Filtered attitude quaternions and body rates
  • Approved onboard sensor or camera data

The final fields, update rates, permissions, and interfaces are established during qualification. Access to sensitive controls or bus commanding is not implied.

Both models are supported in concept: a workload may request approved data on demand, or the platform may push selected packets at agreed intervals—for example, GNSS vectors every five or ten seconds while the workload is running (subject to change).

Yes, the operating concept includes limited uplink of configuration data or command arguments and downlink of payload-generated data during ground passes. Multiple uplink/downlink opportunities are expected during an execution window. Daily bandwidth and total data allocation remain TBD and are confirmed during qualification; results are not necessarily withheld until mission closeout.

An Earth-imaging system is planned but remains to be confirmed. Two low-resolution cameras connected to the CM5 are planned for the mission. Access to imagery from these cameras is still being determined and will be confirmed in the payload agreement. The cameras are intended primarily for platform monitoring and demonstration purposes, not high-resolution Earth imaging.

Blackwing and Parsimoni review the workload architecture, software dependencies, CPU/RAM/storage needs, runtime and scheduling, data inputs and outputs, telemetry permissions, communications needs, security, failure behavior, and mission objectives. Final allocations and interfaces are documented during qualification and integration.

The SpaceOS environment is hardware agnostic, so the work tested and demonstrated here can be re-used with zero (or close to zero) change on future missions with Blackwing Space or others. As an option, it can also become part of the soon-to-be-launched Parsimoni App Store to enable future revenue streams.