12.07.2015 Views

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

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

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

SHOW MORE
SHOW LESS
  • No tags were found...

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

and velocity values erroneously calculated by the <strong>GP</strong>S receiver. The cross product of the position and velocitysolution calculated by the receiver resulted in a value with of 3e19. The magnitude function takes the root sumsquared, 3e192 = 9e38 which exceeded a short float range of 1.7014e+038 (2^127). Typically all divisions,squares etc. are protected in the ATC code, but multiplications are not. The result caused a stack overflow,which in turn caused the safemode activation. The erroneous position and velocity solution was caused by poorgeometry of the <strong>GP</strong>S constellation. The operational solution was to increase the exception counter.13.4.7.4 Channel Alignment Issues Due to Computer Memory ErrorsOn two occasions, August 12 th , 2004 (Observation 102) and Jan 10 th , 2005 (Observation 135), telemetryindicated that a <strong>GP</strong>S error flag, channel alignment error, had toggled to the true state, indicating a problem withthe receiver. A detailed analysis of <strong>GP</strong>S solutions ruled out an actual error state, suggesting that the error bitflipped as a result of a single bit or multi-bit event. While rebooting the receiver would have cleared the error, inboth cases the decision was made to leave the receiver as is. In both instances, the receiver was eventuallyrebooted as part of other vehicle operations.13.4.7.5 Switch to B-Side <strong>GP</strong>S ReceiverThe last observation regards the switch to the B-side receiver. Since the <strong>GP</strong>S receivers are not cross strapped,when the vehicle switched from the A-side to the B-side on March 13, 2005, the <strong>GP</strong>S subsystem switched fromthe A-side to the B-side components as well. While the average percent lock by the B-side components is onlyslightly less than the A-side average (95% vs 98%), Figure 13-43 clearly shows that the day-to-day values varygreatly. Figure 13-43 also shows the percentage of <strong>GP</strong>S solutions used by the orbit determination group tocalculate the <strong>GP</strong>-B orbit also dropped after the switch to the B-side hardware. The decrease in usable points isdue to the increase in “stale” data—data from a previous solution still in the <strong>GP</strong>S memory buffer. When thereceiver is locked and outputting valid <strong>GP</strong>S solutions, stale data is overwritten by new data. Stale data shouldonly occurs when the receiver is reacquiring the <strong>GP</strong>S constellation. Analysis of the solution quality indextelemetry shows that the SQI is slightly, but consistently, higher on the B-side than on the A-side receiver, anobservation consistent with the decrease in percent lock seen. Further insight is gleaned by observing that jitterin the clock bias is higher on the B-side. The most likely hypothesis is that the difference is caused by slightdifferences in the performance of the <strong>GP</strong>S internal oscillators, used to track time between successive PVTsolutions. While only a detailed analysis of the <strong>GP</strong>S internal oscillators can verify the root cause, availabletelemetry is consistent with this hypothesis. Pre-launch sanity testing did not reveal performance differencesbetween the two oscillators.388 March 2007 Chapter 13 — Other Payload Subsystems Analyses

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!