GP-B Post-Flight Analysis—Final Report - Gravity Probe B - Stanford ...

Because this is the second MBE-triggered event in a two-week period,we have changed the action response of the sequential MBE safemodetest from “rebooting the B-side computer” to “stopping the missiontimeline.” We have made this configuration change because we believethat the reboot response overreacts to the reporting of sequentialMBEs. This change will minimize unnecessary adverse impact toscience data collection that occurs when the GP-B flight computerreboots. The cause of the last two safemode response activations isunder investigation, and a fault tree is being developed to identify theroot cause of these events.Each time we experience a switchover or reboot of the on-board flightcomputer, a small amount of science data is lost. If the reboot events ofthe past two weeks have not placed any non-relativistic torques(forces) on the gyros, this small data loss will not have any significanteffect on the outcome of the experiment. Analysis to determinewhether this is the case is in progress.25 MARCH 2005—GRAVITY PROBE B MISSIONUPDATEMission Elapsed Time: 339 days (48 weeks/11.25 months)Science Data Collection: 210 days (30 weeks/7.00 months)Current Orbit #: 5,004 as of 5:00 PM PSTSpacecraft General Health: GoodRoll Rate: Normal at 0.7742 rpm (77.5 seconds per revolution)Dewar Temperature: 1.82 kelvin, holding steadyCommand & Data Handling (CDH): B-side (backup) computer incontrol, Multi-bit errors (MBE): 1 (on 3/18), Single-bit errors (SBE): 8(daily average)Once again last Friday, 18 March 2005 at 7:20AM PST, as thespacecraft was passing over the western edge of the South AtlanticAnomaly (SAA), the B-Side flight computer, which has beencontrolling the spacecraft for the past three weeks, suffered a multi-biterror (MBE) and rebooted. Although last week's reboot was triggeredby an MBE, it was a different situation from the reboots of theprevious two weeks. In the previous two weeks, multiple multi-biterrors occurring within a 0.2 second interval caused a safemode test tofail, which then triggered the reboot response. After the reboot lastMonday, we re-programmed the multiple MBE safemode response tobe less sensitive, and the reboot last Friday was not triggered by afailure of this safemode test. Rather, it was apparently triggered by anMBE striking a critical memory location in the B-side flight controlcomputer, causing the computer to “hang.” A reboot command wasthen executed automatically when a “watchdog timer” in thecomputer's interface module expired without receiving an expectedsignal from the computer. For a more detailed explanation of the flightcomputer's error detection system, see this week's GP-B Mission Newsbelow.Because of the reboot, the vehicle roll rate automatically decreasedfrom its normal level of 0.77 rpm to 0.66 rpm, and the telescopebecame unlocked from the guide star, IM Pegasi. However, thespacecraft's Attitude and Translation Control system (ATC) kept thespacecraft and telescope pointed to within 3,000 arcseconds of theguide star using the on-board navigational control gyroscopes.Our mission operations team quickly swung into action, preparing aset of pre-planned recovery commands. The team uploaded thesecommands to the spacecraft, and they were executed at 3:20PM PSTon Friday. The team then commanded the spacecraft to return todrag-free operation at 7:30 PM-just 12 hours after the flight computerreboot. The guide star was re-captured at 8:40 PM on Friday evening,concluding a swift and flawless execution of the recovery procedure.On Saturday, the team sent real-time commands to optimize theattitude control performance, including enabling both roll and ratefilters, powering on the A-side navigation control gyro, and enablingthe science dither (an error reduction technique). We also switchedback to the A-side (main) navigation control gyroscopes, and byWednesday, 23 March, the spacecraft's ATC pointing performancehad improved to the pre-anomaly level. Finally, the team reprogrammeda section of the ACT’s stored commands, so that in theevent of a future computer reboot, the vehicle will not roll down. Thisshould result in better pointing accuracy during the anomaly periodand faster recovery.Last Friday's reboot anomaly presented yet another challenge to ourmission operations team—a challenge that they faced and overcamewith professionalism and teamwork. Congratulations to the team fortheir continued outstanding performance.Gravity Probe B — Post Flight Analysis • Final Report March 2007 499