Recurve Satellite

Demonstrating adaptive radio frequency system capability from LEO, evaluating mesh network behavior across multiple nodes to route data wherever it needs to go.

The Recurve satellite propels CubeSat technology forward by demonstrating adaptive radio frequency system capability from Low Earth Orbit, evaluating mesh network behavior across multiple nodes to route data wherever it needs to go.

Recurve is the latest in several low-cost CubeSats designed, built and operated entirely in house at the Space Vehicles Directorate located on Kirtland AFB.

The spacecraft will validate a cognitive RF system able to perform in-situ, adaptive decision-making.

In addition, Recurve will evaluate mesh network behavior across multiple nodes in multi-domain applications, bringing information to wherever the warfighter is located.

Recurve only survived on orbit for about two months. In that time, it was highly effective: the team and systems worked quickly and effectively to perform spacecraft commissioning, and payload operations, which led to data collection to achieve mission goals. But still, the mission only lasted two months. Other SSP missions, with more challenged implementations and less system testing, had survived on-orbit generally greater than six months (note that none historically had system wide component environmental characterization; some had vendor specific component characterization). Admittedly, the SSP team was a bit surprised and unhappy with this outcome even though the mission was fully successful (and even hit some stretch goal items). Why, if the implementation and operations were generally very smooth, did the system not last?

Globalstar satellite communication beacons indicated that vehicle successfully exited Separation mode; that was the end of alignment with the optimal scenario. The vehicle began losing power, indicated by the battery voltage decreasing, even in illumination. The cause was that the solar panel did not successfully deploy. After the 35th pass, a beacon came in with substantial voltage on the wing solar panels and temperature increases on the inner side of the panels. This telemetry indicated that the panels deployed! The team was able to utilize the high downlink rate to catch up on telemetry over the next few passes, verifying a deployed panel state based on both power and IMU telemetry.

Recurve launched on July 2, at which time the downlink experimentation license was not granted. This was a calculated risk taken by AFRL assuming that the spacecraft lifetime would be long enough to wait until licensing was given and still perform the experiment. Frequency licensing for spacecraft-to-ground downlink was granted on August 9, 2022, 38 days following launch. On the evening of August 9, at 2313 local, the team communicated over the experimental frequencies just 12 hours after approval was granted during the very first window of opportunity. Over the course of the next three weeks, the team would complete 70 experiments with the payload leading to mission success prior to end-of-life (as described in later sections). While the spacecraft had a limited lifetime, which was experimentally even shorter due to licensing trials, the operations team met full mission success through smart design decisions and operations planning.

The last successful command/control pass with Recurve occurred the morning (~1000 UTC) of August 29, 2022. Recurve’s last successful Globalstar beacon was in the afternoon (~1500 UTC) of the 29th. All statuses were considered within nominal bounds. The lack of communication was first noted during the first expected payload pass around 2100 UTC. Due to automation of passes, specific scheduling of antenna with providers, and the expected inconsistency of beacon receipt, no communication attempts were made with Recurve prior to the payload pass. As this behavior persisted and included all forms of communication, it became clear there was a significant fault occurring.

Further interrogation of flight data for the days preceding loss of contact found that the flight computer current consumption showed several distinct increase. Because flight computer current may vary significantly based on load (the nominal, narrow spikes seen in the power data), this telemetry point is harder to check with automated logic or circuitry. However, the upward trend is readily apparent to a human. Unfortunately, this telemetry point was not consistently watched. At this point in the mission, the operators were focused on payload operations, not persistent detailed review of bus telemetry. Discussion of the power consumption profile with experts on space electronics concluded that the observed behavior was very consistent with a single event latch-up. The flight computer was still functioning correctly so the on-board fault logic, which is focused on execution faults, did not trigger. All these data hint that the flight computer failed, and it was probably caused by radiation. 

• CTIM FD
• GPX-2
• Gunsmoke-L
• MISR-B
• NACHOS 2
• Recurve
• Slingshot-1