Hi,

Here is the report on Gravity Probe B Mission.

#------------------------------

=============================================
GRAVITY PROBE B MISSION UPDATE FOR 25 MARCH 2005
==============================================

GP-B STATUS AT A GLANCE
=============================
Mission Elapsed Time: 339 days (48 weeks/11.25 months)
Science Data Collection: 210 days (29 weeks/6.75 months)
Current Orbit #: 5,004 as of 5:00PM PST
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.82 kelvin, holding steady
Global Positioning System (GPS) lock: Greater than 98.7%
Attitude & Translation Control (ATC): X-axis attitude error: 173.5 marcs rms (as of 3/24)
Y-axis attitude error: 229.9 marcs rms (as of 3/24)
Command & Data Handling (CDH): B-side (backup) computer in control
Multi-bit errors (MBE): 1 (on 3/18)
Single-bit errors (SBE): 8 (daily avg.)
Telescope Readout (TRE): Nominal
SQUID Readouts (SRE): Nominal
Gyro #1 rotor potential: 0.5 mV (as of 3/21)
Gyro #2 rotor potential: 9.4 mV (as of 3/21)
Gyro #4 rotor potential: -4.7 mV (as of 3/21)
Gyro #3 Drag-free Status: Backup Drag-free mode (normal)

MISSION DIRECTOR'S SUMMARY





=======================
As of Mission Day 339, 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.
Once again last Friday, 18 March 2005 at 7:20AM PST, as the spacecraft was passing over the western edge of the South Atlantic Anomaly (SAA), the B-Side flight computer, which has been controlling the spacecraft for the past three weeks, suffered a multi-bit error (MBE) and rebooted. Although last week's reboot was triggered by an MBE, it was a different situation from the reboots of the previous two weeks. In the previous two weeks, multiple multi-bit errors occurring within a 0.2 second interval caused a safemode test to fail, which then triggered the reboot response. After the reboot last Monday, we re-programmed the multiple MBE safemode response to be less sensitive, and the reboot last Friday was not triggered by a failure of this safemode test. Rather, it was apparently triggered by an MBE striking a critical memory location in the B-side flight control computer, causing the computer to "hang." A reboot command was then executed automatically when a "watchdog timer" in the computer's interface module expired without receiving an expected signal from the computer. For a more detailed explanation of the flight computer's error detection system, see this week's GP-B Mission News below.

Because of the reboot, the vehicle roll rate automatically decreased from its normal level of 0.77 rpm to 0.66 rpm, and the telescope became unlocked from the guide star, IM Pegasi. However, the spacecraft's Attitude and Translation Control system (ATC) kept the spacecraft and telescope pointed to within 3,000 arcseconds of the guide star using the on-board navigational control gyroscopes.

Our mission operations team quickly swung into action, preparing a set of pre-planned recovery commands. The team uploaded these commands to the spacecraft, and they were executed at 3:20PM PST on Friday. The team then commanded the spacecraft to return to drag-free operation at 7:30 PM-just 12 hours after the flight computer reboot. 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 the attitude control performance, including enabling both roll and rate filters, powering on the A-side navigation control gyro, and enabling the science dither (an error reduction technique). We also switched back to the A-side (main) navigation control gyroscopes, and by Wednesday, 23 March, the spacecraft's ATC pointing performance had improved to the pre-anomaly level. Finally, the team re-programmed a section of the ATC's stored commands, so that in the event of a future computer reboot, the vehicle will not roll down. This should result in better pointing accuracy during the anomaly period and faster recovery.

Last Friday's reboot anomaly presented yet another challenge to our mission operations team--a challenge that they faced and overcame with professionalism and teamwork. Congratulations to the team for their continued outstanding performance.

MISSION NEWS--DETECTEING AND CORRECTING COMPUTER MEMORY ERRORS IN ORBIT
==========================================================
The computer and electronics systems on-board every spacecraft must undergo special "ruggedization" preparations to ensure that they will function properly in the harsh environment of outer space. GP-B's on-board computers and other electronics systems are no exception. For example, the components must be radiation-hardened and housed in heavy-duty aluminum or equivalent cases. Furthermore, the firmware (built-in hardware-level programming) must include error detection and correction processes that enable the electronic components to recover from the effects of solar radiation bombardment and other space hazards. Following is a brief description of GP-B's on-board computers and the techniques used to detect and correct single and multi-bit errors.

GP-B has several computers on-board the spacecraft. The main flight computer and its twin backup are called the CCCA (Command & Control Computer Assembly). These computers were assembled for GP-B by the Southwest Research Institute. They use approximately 10-year old IBM RS6000 Central Processing Units (CPUs), with 4 MB of radiation-hardened RAM memory. These computers, along with ruggedized power supplies are encased in sturdy aluminum boxes, with sides up to 1/4" thick.

In addition to the A-side (main) and B-Side (backup) flight computers, the GP-B spacecraft has two other special-purpose computers--one for the Gyro Suspension System (GSS) and one for the SQUID Readout Electronics (SRE). Each of these specialized computers contains 3 MB of radiation-hardened RAM memory and custom circuit boards designed and built here at Stanford University. Because of the custom circuit boards, these computers are housed in special aluminum boxes that were also built at Stanford.

The RAM memory in these computers is protected by Error Detection and Correction logic (EDAC), built into the computer's firmware. Specifically, the type of EDAC logic used is called SECDED, which stands for "Single Error Correction, Dual Error Detection." Here's how it works. For every 64 bits of RAM in the computer's memory, another 8 bits are reserved for EDAC. This produces a unique 64-bit "checksum" value for each RAM location. A firmware process called "memory scrubbing" runs continually in the background, validating the checksums for the entire bank of RAM memory locations every 2.5 seconds.
If the EDAC detects an error in which only one single bit is incorrect--a "single-bit error (SBE)--in a memory location checksum value, it sends an interrupt signal to the CPU, and the CPU automatically fixes the error by writing the correct value back into that memory location. However, if the EDAC detects an error involving more than one bit--a "multi-bit" error (MBE)---it generates a different type of interrupt signal causing the CPU to store the address of the bad memory location in a table that is transmitted to our mission operations center (MOC) during each telemetry communications pass.

Whenever the computer engineers on our operations team discover the presence of one or more MBEs, they immediately look up the use of that memory location in a map of the computer's memory. If that location is in an area of memory that is not currently being used, the MBE is said to be "benign." In fact, most of the MBEs we've seen thus far in the mission have occurred in benign memory locations. In this case, one of the computer engineers travels to the Integrated Test Facility (ITF) at Lockheed Martin Corporation's Palo Alto office, about 15 minutes away from the GP-B MOC, to determine what value was supposed to be contained in that memory location. The ITF is a very sophisticated flight simulator that maintains a ground-based replica of all the systems running on the spacecraft. Once the engineer determines the correct value of a bad memory location in the spacecraft's computer, he creates a set of commands that are manually sent to the spacecraft during a telemetry pass to patch the bad location with the correct value. An excerpt of a printout from the ITF comparing the correct and incorrect values for a memory location from the spacecraft's computer is shown in this week's highlights on our Web site.

On the other hand, if the engineer determines that the MBE is located in an active part of the computer's memory--a location containing a command that the CPU will be executing--he can have the mission operations team manually issue a command to the flight computer to stop the currently executing timeline of instructions until the bad memory location can be patched. However, there is one scenario in which an MBE in a critical part of memory can be missed by the EDAC systemŠ.
The 2.5 seconds that it takes the EDAC to scrub the entire memory may seem like a very short time in human terms, but an RS6000 CPU can execute a great many instructions in that time frame. Because the CPU is executing instructions while EDAC memory scrubbing is in process, it is possible for the CPU to access a memory location that was, say, struck by a stray proton from the sun near the SAA region of the Earth, before the EDAC system detected the error. And, if that memory location contains a corrupted instruction that the CPU tries to execute, it can cause the CPU to hang or crash. Communications hardware in the interface box connected to the computer includes a so-called "watchdog timer." This is basically a failsafe mechanism that, like the deadman switch on a bullet train, awaits a signal from the CPU at regular intervals. If the watchdog timer expires without receiving a signal, it automatically triggers a reboot of the computer.

By a process of elimination, the GP-B Anomaly Review Team has concluded that this is probably what happened last Friday. The flight computer maintains a history of completed instructions up to within one second of executing an instruction in a bad memory location. However, once the watchdog timer expires and the computer reboots, this history is lost. Thus, the occurrence of such an event can only be deduced by eliminating other possible causes.

===================
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.html


* PDF 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