The first STELLAR payload in space. Hosted on a partner spacecraft. Designed to prove that compute and storage can be operated as a mission service inside real orbital limits.
Fly a hosted payload that proves STELLAR can operate compute and storage as a mission service inside real spacecraft limits.
STELLAR’s thesis is that orbital compute is infrastructure, not a satellite mission. Node-1 makes that claim concrete: a self-contained data-center payload integrated as a hosted module on a partner spacecraft, sharing power, thermal interfaces, attitude, and downlink while behaving as an independent service for STELLAR’s customers.
First, that the payload software stack survives real orbital conditions radiation, resets, contact gaps, thermal cycles. Second, that the operations model tasking, scheduling, delivery, evidence works without an engineer intervening in the loop. Third, that an external customer can submit a job and receive a verifiable result through the Node-1 service contract.
Node-1 fits inside a 95 kg hosted-payload allocation in a 500 km sun-synchronous orbit at 97.4° inclination. Peak compute thermal load is 838 W; radiator hot-case capacity caps duty cycle. X-band downlink delivers 100–500 Mbps over a 42–55 minute daily contact window. Every architectural choice is downstream of those numbers.
The profile is the mission’s physical truth every architectural choice descends from these numbers.
The mission is the sum of these subsystems and the way they constrain each other.
| System | Specification | Design note |
|---|---|---|
| Compute fabric | XQRVC1902 FPGA inference fabric, ~26 TOPS | Radiation-tolerant FPGA chosen for predictable behavior under SEU events. Workload-isolated execution lanes; ECC; checkpointable restart. |
| Management CPU | GR740 quad-core LEON4 SPARC | Watchdog, command authorization, FDIR (failure detection / isolation / recovery), payload state machine, telemetry mux. |
| Storage path | ECC DDR4 + 2 TB RAID-1 SSD + 128 GB priority queue | Mission products land in the priority queue, hash-chained for integrity, and are persisted on RAID-1 for continuity through pass gaps. |
| Thermal | Cold plates → loop heat pipe → deployable radiators | Compute waste heat is collected at the cold-plate interfaces, transported by LHP to two deployable radiator panels sized for hot-case heat rejection plus margin. |
| Comms | X-band downlink, S-band TT&C | Mission data downlink at 100–500 Mbps class over X-band; redundant S-band telemetry, tracking and command path through host bus. |
| Software & ops | GroundLab-validated flight-candidate software baseline | Same software control loop rehearsed in the GroundLab digital twin. Operations console, tasking workflow, and customer API contract are inherited with explicit hardware-qualification limits. |
Each mission is justified by a specific new capability not just a larger payload.
Hosted payload interface with spacecraft bus services
Radiation-aware compute path with checkpoint and restart behavior
Resilient storage queue with integrity checks and delivery receipts
Thermal duty-cycle management tied to orbit, power, and radiator capacity
Operator-authorized tasking and scheduling from ground
End-to-end customer demo workload submit, execute, deliver
The plan is broken into reviewable phases. Each phase ends in a deliverable a stakeholder can read.
Lock orbit, mass/power/thermal allocation, host-bus interface document, and customer API contract.
System architecture, ICDs, and verification plan reviewed against mission baseline.
Detailed design closure: FPGA build, thermal correlation, software flight baseline, ops procedures.
Funded EQM in thermal-vacuum chamber; flight unit assembly; payload-to-bus integration.
Launch + L+24h power-on, L+48h initial downlink, 30-day commissioning campaign.
Twelve-month nominal window: customer demo workloads, telemetry calibration, GroundLab feedback loop.
A serious mission tracks risks honestly. Closed, mitigated, in design, and open items are listed without softening.
| Risk | State | Description |
|---|---|---|
| Host-bus interface alignment | In design | Power, mechanical, thermal, data, and command interfaces with the partner spacecraft are tracked as the dominant pre-PDR risk. |
| X-band link budget reconvergence | Open | Current draft link budget uses 600 km nominal range; closed orbit ADR sets 500 km SSO. Reconvergence in progress before PDR. |
| Single-event upset (SEU) recovery | Mitigated | GR740 watchdog + FPGA partial-reconfiguration recovery + checkpointed workload restart. Validated first through SIL and interface-emulation fault injection; hardware validation remains a later gate. |
| Thermal hot-case margin | Mitigated | Current sizing carries ~43% margin against hot case. Final correlation against TVAC test moves this to Closed. |
| Customer delivery SLA on first flight | Open | No formal SLA on Node-1; design-partner workloads run in best-effort demo mode. SLAs are introduced on Node-2. |
| Funded flight hardware boundary | Open | Node-1 is currently a software-first pathfinder baseline. Physical EM/QM/FM hardware, environmental qualification, launch-provider acceptance, and flight heritage remain future funding and partner gates. |
The right way to read a mission page: claim → evidence → state. If a row is in the wrong state, the page is what is broken not the program.
| Claim | Evidence | State |
|---|---|---|
| Payload survives ascent + commissioning + 30-day shakedown. | Vibration + thermal-vacuum + commissioning report | Planned |
| Compute path completes a customer demo workload in orbit. | Customer-receipt + ground-cloud reconciliation log | Planned |
| Storage queue delivers products through three consecutive pass gaps. | Telemetry + receipt chain over 7-day campaign | Planned |
| Thermal duty cycle stays within hot-case margin under peak compute. | On-orbit thermal telemetry vs. SINDA prediction | Draft |
| X-band downlink hits class throughput envelope. | RF link-budget reconverged to 500 km SSO + on-orbit measurement | Open |
Each mission is a step on a single staircase. These bridges spell out what comes from the prior step and what becomes possible after.
Node-0 GroundLab’s flight-candidate software baseline, customer API contract, mission rehearsal evidence, and operations console are inherited by Node-1. The physical flight unit remains a separate partner, funding, and qualification gate.
← Open Node-0Once Node-1 proves the payload, ICD, and operations model in orbit, Node-2 expands compute density, introduces scheduled customer service windows, and replaces "demo workload" with paid jobs.
Open Node-2 →