Hi,
Here is the Gravity Probe B Mission update.
#------------------------------------------------
==============================================
GRAVITY PROBE B MISSION UPDATE FOR 18 MARCH 2005
==============================================
GP-B STATUS AT A GLANCE (as of 3/17/05)
=============================
Mission Elapsed Time: 331 days (47 weeks/11.00 months)
Science Data Collection: 202 days (29 weeks/6.75 months)
Current Orbit #: 4,883 as of 2:00PM PST on 3/17/05
Spacecraft General Health: Good
Roll Rate: Normal at 0.7742 rpm (77.5 seconds per revolution)
Gyro Suspension System (GSS): All 4 gyros digitally suspended in science mode
Dewar Temperature: 1.80 kelvin, rising slowly
Global Positioning System (GPS) lock: Greater than 98.8%
Attitude & Translation Control (ATC): X-axis attitude error: 347.3 marcs rms
Y-axis attitude error: 353.4 marcs rms
Command & Data Handling (CDH): B-side (backup) computer in control
Multi-bit errors (MBE): 3 as of 3/17/05
Single-bit errors (SBE): 11 (daily avg.)
Telescope Readout (TRE): Nominal
SQUID Readouts (SRE): Nominal
Gyro #1 rotor potential: -0.1 mV
Gyro #2 rotor potential: +8.8 mV
Gyro #4 rotor potential: -5.1 mV
Gyro #3 Drag-free Status: Backup Drag-free mode (normal)
MISSION DIRECTOR'S SUMMARY
=======================
As of Mission Day 331, the Gravity Probe B vehicle and payload are in good health. All four gyros are digitally suspended in science mode. The spacecraft is flying drag-free around Gyro #3.
On Monday evening, 14 March 2005 at 11:38PM PST, the spacecraft's safemode system triggered another computer reboot--the second flight computer reboot within the past two weeks. Telemetry indicated that this most recent safemode response was activated when a memory checkout procedure detected at least three multi-bit errors (MBE's) within a 0.2 second interval in the B-side computer.
Since the switchover from the A-Side (main) computer two weeks ago, the spacecraft has remained in control of the B-Side (backup) flight computer. In this configuration, if a new series of MBEs occurs, the spacecraft does not automatically switch back to the A-side computer. Rather, the B-side computer reboots itself, and the mission operations team follows a pre-defined set of procedures to restore the normal systems configuration for science data collection-as was the case this past Tuesday and Wednesday.
In response to the reboot, the mission operations team uploaded and ran a set of pre-approved recovery commands on the B-side computer. The spacecraft's roll rate, which had automatically decreased during the reboot, was quickly restored to the science value of 0.7742 rpm. The team also sent commands to reboot the SQUID Readout Electronics (SRE) as part of the initial recovery response, prior to re-acquisition of the guide star and return to drag free flight. This accelerated the overall recovery process by a full day. We returned to drag-free operation on Gyro #3 at 5:34PM PST on Tuesday, less than 18 hours after the B-side reboot event. After several guide star search maneuvers Tuesday night, the guide star was successfully acquired at 4:41AM PST on Wednesday, 29 hours after the reboot event.
Because this is the second MBE-triggered event in a two-week period, we have changed the action response of the sequential MBE safemode test from "rebooting the B-side computer" to "stopping the mission timeline." We have made this configuration change because we believe that the reboot response overreacts to the reporting of sequential MBEs. This change will minimize unnecessary adverse impact to science data collection that occurs when the GP-B flight computer reboots. The cause of the last two safemode response activations is under investigation, and a fault tree is being developed to identify the root cause of these events.
Each time we experience a switchover or reboot of the on-board flight computer, a small amount of science data is lost. If the reboot events of the past two weeks have not placed any non-relativistic torques (forces) on the gyros, this small data loss will not have any significant effect on the outcome of the experiment. Analysis to determine whether this is the case is in progress.
MISSION NEWS -THE GP-B SAFEMODE SYSTEM & ANOMALY RESOLUTION PROCEDURES
========================================================
Consider the following: GP-B is a unique, once-in-a-lifetime experiment. Its payload, including the gyroscopes, SQUID readouts, telescope and other instrumentation took over four decades to develop. Once launched, the spacecraft is physically out of our hands, and typically, we only communicate with it about every two hours via scheduled telemetry passes. Thus, we entrust the on-board flight computer (and its backup) with the task of safeguarding the moment-to-moment health and well-being of this invaluable cargo. How does the GP-B flight computer accomplish this critically important task? The answer is the safemode subsystem.
Most autonomous spacecraft have some kind of safemode system on-board. In the case of GP-B, Safemode is an autonomous subsystem of the flight software in the GP-B spacecraft's on-board flight computers. The GP-B Safemode Subsystem is comprised of three parts:
1. Safemode Tests--Automatic checks for anomalies in hardware and software data.
2. Safemode Masks--Scheme for linking each safemode test with one or more safemode response sequences.
3. Safemode Responses--Pre-programmed command sequences that are activated automatically when a corresponding test fails to provide an expected result.
These tests and response commands are designed to safeguard various instruments and subsystems on the spacecraft and to automatically place those systems in a known and stable configuration when unexpected events occur.
For example, one of the tests in the GP-B Safemode Subsystem checks to ensure that the communications link between the on-board flight computer and the GP-B MOC here at Stanford is alive and active. The requirement for this test is that the flight computer must receive some command from the MOC at least once every 12 hours. If the flight computer does not receive a command within that time frame, we assume that normal telemetry is not working, and the pre-programmed response commands cause the computer to automatically reboot itself and then re-establish communication. This test is a variation of the "deadman" test used on high-speed bullet trains. To ensure that the train's engineer is alive and awake while the train is traveling at high speed, the engineer is required to press a button or switch at regular intervals. If the train does not receive the expected human input within each time interval, the train automatically throttles down and comes to a halt.
Not all of the tests and responses in the GP-B Safemode Subsystem are currently enabled. Some of the tests were specifically created for use during the launch and/or during the Initialization and Orbit Checkout (IOC) phase and are no longer needed during the science phase of the mission. Also, active tests and responses can be re-programmed if necessary. For example, the response commands for the safemode that triggered last Monday's computer reboot were changed this past week to simply stop the mission timeline, rather than rebooting the flight computer, as described in the mission director's summary above.
When anomalous events occur, automatic responses ensure that the spacecraft and its subsystems remain in a safe and stable condition. This enables our mission operations team to become aware of the issue on-board, identify and understand the root cause, and take appropriate action to restore normal operations. GP-B has a formal process, called "anomaly resolution," for dealing with unexpected situations that occur in orbit. This process was thoroughly tested and honed during a series of seven pre-flight simulations over the course of two years.
GP-B anomalous events are evaluated and classified into one of four categories:
1. Major Space Vehicle Anomalies--Anomalies that endanger the safety of the spacecraft and/or the payload. Response to these anomalies is time-critical.
2. Medium Space Vehicle Anomalies--Anomalies that do not endanger the safety of the space vehicle but may impact the execution of the planned timeline. Response to these anomalies is not time-critical if addressed within a 72-hour window.
3. Minor Space Vehicle Anomalies--Anomalies that do not endanger the safety of the space vehicle. These are low risk problems with the vehicle that are resolved by taking the appropriate corrective action.
4. Space Vehicle Observations--In addition to formal anomaly categories, the space vehicle may exhibit off-nominal or unexpected behavior that does not appear initially to be an operational or functional issue and does not violate any limits, but may warrant attention over time. Observation items may be elevated to an anomaly category if it is judged to be serious enough to warrant a high-priority investigation.
A special room in the GP-B Mission Operations, called the Anomaly Room, is the home of the GP-B Anomaly Review Board (ARB), a select group of senior GP-B team members from Stanford, NASA, and Lockheed Martin, who manage the troubleshooting of anomalies and observations. The Anomaly Room, which is located across the corridor from the GP-B MOC, contains a set of spacecraft status monitors, communications and teleconference equipment, computer and voice hookups, a documentation library, white boards, a computer projection system, and an oval discussion table.
Whenever an anomaly is in the process of being resolved, the Anomaly Room is staffed 24 hours a day, 7 days a week; at other times, it is staffed during normal working hours, with team members on call. When major events such as last week's computer reboot occur outside normal working hours, the Mission Director on duty activates the Anomaly Room and issues a series of pager and cell phone calls via computer, summoning key staff members on the ARB, along with a selected anomaly team, comprised of resident engineers and engineering specialists, to come in and work through the issue. The group uses a technique called "fault tree analysis" to evaluate and determine the root cause of unexpected events.
The GP-B Safemode Subsystem and anomaly resolution process have worked very well throughout the mission. Thus far, the ARB has successfully worked through more than 150 issues while the spacecraft has been in orbit. Most of these issues have been classed as observations or medium to minor anomalies. But a handful have been classified as major anomalies, including the B-Side computer switchover and the stuck-open valve problems with two micro thrusters early in the mission, as well as several subsequent computer and subsystem reboot problems due to radiation strikes. In each case, the established anomaly resolution process has enabled the team to identify the root causes and provide recovery procedures.
===================
PREVIOUS GP-B UPDATES
===================
If you wish to read any of our previous updates, our GP-B Web site includes a chronological archive of all the updates/highlights (with photos and drawings) that we have posted over the past 8 years:
http://einstein.stanford.edu/highlights/hlindexmain.html=============================
OTHER LINKS THAT MAY INTEREST YOU
=============================
Our GP-B Web site,
http://einstein.stanford.edu contains lots of information about the Gravity Probe B experiment, general relativity, and the amazing technologies that were developed to carry out this experiment.
Visual tour of the GP-B spacecraft and payload from our GP-B Web site:
http://einstein.stanford.edu/content/vehicle_tour/index.htmlPDF file containing a 1/20 scale, paper model of the GP-B spacecraft that you can download print out, and assemble:
http://einstein.stanford.edu/content/paper_model.
NASA's Marshall Space Flight Center also has a series of Web pages devoted to GP-B: (http://www.gravityprobeb.com )
Photo, taken through a telescope by Swiss physics teacher and amateur astronomer Stefano Sposetti, of GP-B spacecraft in orbit, passing near IM Pegasi: http://aida.astronomie.info/sposetti.
The Harvard-Smithsonian Center for Astrophysics (Cambridge) and York University (Toronto), with contributions from the Observatoire de Paris, have been studying the motions of the guide star, IM Pegasi for over a decade. To find out more, visit: http://www.yorku.ca/bartel/guidestar/
In addition, you'll find information in the Guide Star FAQ on our Web site: http://einstein.stanford.edu/content/faqs/faqs.html#guidestar and on pages 18-20 of the Gravity Probe B Launch Companion: http://einstein.stanford.edu/highlights/GP-B_Launch_Companion.pdf.
Track the GP-B satellite on the Web using NASA's Java-based J-Pass satellite tracking application at: http://science.nasa.gov/realtime/JPass/ Also, you can track the GP-B satellite on Personal Digital Assistants (PDAs) using either the Palm OS or Pocket PC operating systems with software from Big Fat Tail Productions: http://www.bigfattail.com.
The Einstein Exhibition at the Skirball Cultural Center in Los Angeles through May 2005: Information about the Einstein exhibition is available on the Skirball Center Web site: http://www.skirball.org/index.asp?s=exhibit&p=einstein.asp. If you can't make it to Los Angeles, you can visit the AMNH's virtual Einstein exhibit on the Web at: http://www.skirball.org/exhibit/amnh_frame.html.
==========================
ABOUT THE GPB-UPDATE EMAIL LIST
==========================
The email distribution list for this GP-B Weekly Highlights update is maintained on the Stanford University email lists server.
To subscribe to this list, send an email message to "majordomo@lists.Stanford.edu" with the command "subscribe gpb-update" in the body of the message (not in the Subject line).
You can unsubscribe at any time by sending an email message to "majordomo@lists.Stanford.edu" with the command, "unsubscribe gpb-update" in the body of the message (not in the Subject line.)
--
**********************************
NASA - Stanford - Lockheed Martin
Gravity Probe B Program
"Testing Einstein's Universe"
http://einstein.stanford.edu
Bob Kahn
Public Affairs Coordinator
Phone: 650-723-2540
Fax: 650-723-3494
Email: kahn@relgyro.stanford.edu
**********************************
#--------------------------------------------------------
Regards,
LelandJ
