WEEKLY UPDATE FOR 25 MARCH 2005:
GRAVITY PROBE B MISSION STATUS AT A GLANCE
Item | Current Status |
Mission 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 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.8% |
Attitude & Translation Control (ATC) | X-axis attitude error: 173.5 marcs rms as of 3/24/05 |
Command & Data Handling (CDH) | B-side (backup) computer in control Multi-bit errors (MBE): 1 (on 3/18) Single-bit errors (SBE): 8 (daily average) |
Telescope Readout (TRE) | Nominal |
SQUID Readouts (SRE) | Nominal |
Gyro #1 rotor potential | -0.5 mV as of 3/21/05 |
Gyro #2 rotor potential | 9.4 mV as of 3/21/05V |
Gyro #4 rotor potential | -4.7 mV as of 3/21/05 |
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.
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.
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.The image to the right of this paragraph shows a screen capture from the ITF comparing the correct and incorrect values for a memory location from the spacecraft's computer.
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.
THE EINSTEIN EXHIBITION AT THE SKIRBALL CULTURAL CENTER IN LOS ANGELES
If you're going to be in Los Angeles anytime before 30 May 2005, and if you’re interested in Einstein’s life and work, the Einstein Exhibition at the Skirball Cultural Center (just north of the Getty Museum on Interstate 405) is the most comprehensive presentation ever mounted on the life and theories of Albert Einstein (1879-1955). It explores his legacy not only as a scientific genius who re-configured our concepts of space and time, but also as a complex man engaged in the social and political issues of his era. It examines the phenomenon of his fame and his enduring status as a global icon whose likeness has become virtually synonymous with genius.In this exhibit, you can examine Einstein's report card, inspect his FBI file, and enjoy his family photographs, love letters, and diary entries. Exhibition highlights include scientific manuscripts and original correspondence—including original handwritten pages from the 1912 manuscripts of the special theory of relativity and his 1939 letter to President Roosevelt about nuclear power—and a wealth of other documents from the Albert Einstein Archives at the Hebrew University of Jerusalem.
In addition to these displays of Einstein memorabilia, the exhibit also features a number of interactive components that help provide an understanding of Einstein's revolutionary theories. Furthermore, several “explainers,” identified by their red aprons, are on hand to discuss various aspects of the exhibit and to explain and demonstrate difficult concepts, such as time dilation and warped spacetime. At the end of the exhibit, you’ll find one of GP-B’s gyro rotors on display.
The Einstein exhibition was jointly organized by the American Museum of Natural History (AMNH), the Hebrew University of Jerusalem, and the Skirball Cultural Center. It was designed by the AMNH under the supervision of Dr. Michael Shara, curator of the exhibit and chairman of the museum’s Astrophysics Department. It opened in November 2002 at the AMNH in New York and then traveled to Chicago and Boston, spending about 8 months in each location. It will remain at its final U.S. stop at the Skirball Center in Los Angeles through 29 May 2005, after which time it will move permanently to the Hebrew University in Jerusalem.
Information about the Einstein exhibition is available on the Skirball Center Web site. If you can’t make it to Los Angeles, you can visit the AMNH’s virtual Einstein exhibit on the Web.
Drawings and photos: The diagram of the GP-B experiment created by GP-B Public Affairs Coordinator, Bob Kahn. The photos of the GP-B daily all-hands meeting, the Anomaly Room, and the Mission Operations Center were also taken by Bob Kahn. The screen capture from the ITF is courtesy of Lockheed Martin Corporation. The photos from the Einstein Exhibit are courtesy of the Skirball Cultural Center. Click on the thumbnails to view these images at full size.
MORE LINKS ON RECENT TOPICS
- Track the satellite in the sky
- Photo, video & and news links
- Build a paper model of the GP-B Spacecraft
- Following the mission online
- Our mailing list - receive the weekly highlights via email
- The GP-B Launch Companion in Adobe Acrobat PDF format. Please note: this file is 1.6 MB, so it may take awhile to download if you have a slow Internet connection.
Previous Highlight
Index of Highlights