CAPSTONE is now passing the orbit of the Moon on the way out towards Lagrange SEL1
Following Communications Recovery, NASA’s CAPSTONE Prepares for First ManeuverFollowing communications issues, mission teams for NASA’s Cislunar Autonomous Positioning System Technology Operations and Navigation Experiment (CAPSTONE) have re-established contact with the spacecraft through NASA’s Deep Space Network. Data received from CAPSTONE shows that the spacecraft is in good health and operated safely on its own while it was out of contact with Earth.Teams are preparing to carry out CAPSTONE’s first trajectory correction maneuver – which will more precisely target CAPSTONE’s transfer orbit to the Moon – as early as 11:30 a.m. EDT on July 7. As originally planned, CAPSTONE will arrive to its lunar orbit on Nov. 13. The CAPSTONE team is still actively working to fully establish the root cause of the issue. Ground-based testing suggests the issue was triggered during commissioning activities of the communications system. The team will continue to evaluate the data leading up to the communications issue and monitor CAPSTONE’s status. The mission team, led by Advanced Space, initially re-established contact with CAPSTONE at 9:26 a.m. EDT on July 6. The signal confirmed that CAPSTONE was in the expected location, as predicted based on data from CAPSTONE’s initial contacts on July 4. The team started recovery procedures and began receiving telemetry data from the spacecraft at 10:18 a.m. EDT. Author Sarah FrazierPosted on July 6, 2022 5:36 pm
A data visualization shows the antenna of the Deep Space Network. CAPSTONE is communicating with one of the Goldstone antenna.
Just dropped into mission control to check on Lunar Photon. We just past the moon and are now at 390,000km
Through the work over the last day, the team has high confidence that the issue has been cleared and through changes to the configuration and operations it will not happen again. As we finalize the review of this root cause analysis with appropriate parties, we will release more information.
Mission Team Determines Cause of Communications Issues for NASA’s CAPSTONEAfter a thorough review, teams have determined what led to CAPSTONE’s communications issue that began on July 4. During commissioning of NASA’s CAPSTONE (short for Cislunar Autonomous Positioning System Technology Operations and Navigation Experiment) spacecraft, the Deep Space Network team noted inconsistent ranging data. While investigating this, the spacecraft operations team attempted to access diagnostic data on the spacecraft’s radio and sent an improperly formatted command that made the radio inoperable. The spacecraft fault detection system should have immediately rebooted the radio but did not because of a fault in the spacecraft flight software. CAPSTONE’s autonomous flight software system eventually cleared the fault and brought the spacecraft back into communication with the ground, allowing the team to implement recovery procedures and begin commanding the spacecraft again. While CAPSTONE was out of contact with Earth, the spacecraft autonomously maintained its orientation to keep its antenna pointed towards Earth and allow the solar panels to keep its battery charged. CAPSTONE also used its thrusters to perform a standard maneuver to dump excess momentum from its reaction wheels, which are internal wheels that help the spacecraft rotate and point itself. The mission operations team conducted CAPSTONE’s first trajectory correction maneuver at approximately 11:30 a.m. EDT today. Teams are currently reviewing the data to ensure the maneuver was successful, and an update will be provided later. This maneuver will more precisely target the spacecraft’s transfer orbit to the Moon. Author Sarah FrazierPosted on July 7, 2022 1:18 pmCategories UncategorizedTags CAPSTONE, Cubesats, Gateway, Moon
While investigating this, the spacecraft operations team attempted to access diagnostic data on the spacecraft’s radio and sent an improperly formatted command that made the radio inoperable. The spacecraft fault detection system should have immediately rebooted the radio but did not because of a fault in the spacecraft flight software.
Great to hear they found the cause of the problem. Standard practise is to always verify any commands to be sent on a model of the spacecraft, before you send the commands. Sounds like this wasn't done properly.
Perhaps they then spent time commanding in the blind and perhaps waiting/hoping that additional fault protection would fire and restore radio operation- which is what appears to have happened.
...In my own experience, missions would have have sent that command on a testbed (usually a flatsat) BEFORE doing it in flight. I wonder if there is a high fidelity hardware in the loop simulator available for this mission where that might have been caught....
Is a [high fidelity hardware in the loop simulator] a standard for a cheap cubesat tho?