Spanish startup UARX Space has restored communications with its first orbital transfer vehicle after an early blackout complicated the opening days of the OSSIE-D mission. The company says the outage was traced to a configuration error in the interface for the ground-station service it was using, and that communications have been nominal since the configuration was corrected.
OSSIE-D launched October 1 on SpaceX’s Transporter-18 rideshare mission. The roughly 200-kilogram spacecraft is designed as an orbital transfer vehicle, or OTV: a platform that can carry and later release customer satellites and hosted payloads in orbit. UARX says at least 10 PocketQubes have now been deployed.
A mission decision made with limited visibility
Immediately after launch, UARX experienced a communications blackout with the spacecraft. With no reliable two-way contact, the company faced a decision about whether to wait for more certainty or attempt to protect customer missions by commanding the vehicle to release payloads.
According to Andrés Villa Granata, UARX co-founder and chief technology officer, the company sent a backup command two days after launch to activate fault-detection, isolation and recovery automation that would deploy payloads without ground-station intervention. The company could not initially confirm that the command had reached the spacecraft.
UARX made the call because it wanted to prioritize customer missions if the vehicle had a more serious problem and because it was mindful of the spacecraft’s battery-limited operating life. It was a consequential choice: the OTV’s purpose is to place customer spacecraft into orbit, but releasing payloads earlier than planned reduces operators’ ability to control the timing of their deployment sequence.
The decision illustrates a basic reality of small-spacecraft operations. Launch is not the end of a mission’s highest-risk period. Initial acquisition of signal, configuration of ground communications, power management and first-system checkouts all occur when teams are working under time pressure and with incomplete information.
Telemetry confirms the command sequence
Once communications were restored, UARX was able to wake the sequencer from ultra-low-power mode and download deployment telemetry. The company said the records showed that the command sent two days after launch had been received and that all commanded deployments were executed correctly.
The company attributes the blackout to the ground-station-service interface configuration error rather than a failure of the spacecraft itself. UARX said that after the correction, system checkouts were completed and spacecraft systems were performing nominally.
That outcome is significant for both the startup and its customers. A communications issue can leave operators unable to distinguish among a ground-segment problem, a spacecraft anomaly or a combination of failures. Restored contact and downloaded telemetry gave UARX evidence that the vehicle had carried out the requested deployment actions rather than merely appearing to have done so from indirect signs.
Deployments continue on a staggered mission
Not every payload on OSSIE-D has been released. UARX says additional customer spacecraft remain aboard, including hosted payloads such as Dawn Aerospace’s Docking and Fluidic Transfer Port. The company said satellites still on the vehicle will be released later, but it did not provide specific details about the affected customers or their schedules.
Before launch, OSSIE-D had been scheduled to deploy satellites seven and 30 days after launch. Some customers reported their own mission updates, including German nonprofit AMSAT-Deutschland, which flew three PocketQubes on the vehicle. AMSAT-DL said the deployment sequence began earlier than originally planned after the initial launch celebrations and preparations for subsequent activities were already underway.
Staggered deployment is one of the services an OTV can offer rideshare customers. Rather than separating every satellite at the same moment from a launch vehicle, an orbital transfer platform can hold spacecraft for later release. That can provide flexibility, but it also introduces additional operational complexity: the transfer vehicle itself must remain healthy, communicate with the ground and execute payload sequencing reliably.
What the episode means for UARX
For UARX, the maiden flight is an early test of both its hardware and its operations. The company has demonstrated that it could recover communication after a ground-interface issue, obtain spacecraft telemetry and verify that at least part of its deployment sequence worked as commanded. At the same time, the outage forced an unplanned response during the most sensitive phase of the mission.
The company’s next milestones will be the continued health of OSSIE-D and the later release of the payloads that remain on board. Those results will determine how much confidence customers can place in the platform’s ability to provide controlled, timed access to orbit rather than merely a one-time release service.
For the wider small-satellite market, the event is a reminder that ground systems are part of the spacecraft system. A configuration error beyond the vehicle can still interrupt command and telemetry links at a critical moment. UARX’s recovery shows why autonomous fault-handling and detailed onboard telemetry are increasingly important as companies fly more complex rideshare and transfer missions.
This article is based on reporting by SpaceNews. Read the original article.
Originally published on spacenews.com
