November 2005 

NASA/CR‐2005‐213693

GPS Lessons Learned from the International  

Space Station, Space Shuttle and X‐38

John L. Goodman

United Space Alliance

Houston, Texas
The NASA Scientific and Technical Information Program Office ... in Profile 

Since its founding, NASA has been dedicated to the 

advancement of aeronautics and space science. The 

NASA Scientific and Technical Information (STI) 

Program Office plays a key part in helping NASA 

maintain this important role. 

The NASA STI Program Office is operated by 

Langley Research Center, the lead center for NASA’s 

scientific and technical information. The NASA STI 

Program Office provides access to the NASA STI 

Database, the largest collection of aeronautical and 

space science STI in the world. The STI Program 

Office is also NASA’s institutional mechanism for 

disseminating the results of its research and 

development activities. These results are published 

by NASA in the NASA STI Report Series, which 

includes the following report types: 

• TECHNICAL PUBLICATION. Reports of 

completed research or a major significant 

phase of research that present the results of 

NASA programs and include extensive data or 

theoretical analysis. Includes compilations of 

significant scientific and technical data and 

information deemed to be of continuing 

reference value. NASA counterpart of peerreviewed formal professional papers, but 

having less stringent limitations on 

manuscript length and extent of graphic 

presentations. 

• TECHNICAL MEMORANDUM. Scientific 

and technical findings that are preliminary or 

of specialized interest, e.g., quick release 

reports, working papers, and bibliographies 

that contain minimal annotation. Does not 

contain extensive analysis. 

• CONTRACTOR REPORT. Scientific and 

technical findings by NASA-sponsored 

contractors and grantees. 

• CONFERENCE PUBLICATION. Collected 

papers from scientific and technical 

conferences, symposia, seminars, or other 

meetings sponsored or co-sponsored by 

NASA. 

• SPECIAL PUBLICATION. Scientific, 

technical, or historical information from 

NASA programs, projects, and missions, 

often concerned with subjects having 

substantial public interest. 

• TECHNICAL TRANSLATION. Englishlanguage translations of foreign scientific 

and technical material pertinent to NASA’s 

mission. 

Specialized services that complement the STI 

Program Office’s diverse offerings include creating 

custom thesauri, building customized databases, 

organizing and publishing research results ... even 

providing videos. 

For more information about the NASA STI 

Program Office, see the following: 

• Access the NASA STI Program Home Page 

at http://www.sti.nasa.gov

• E-mail your question via the Internet: 

help@sti.nasa.gov 

• Fax your question to the NASA STI Help 

Desk at (301) 621-0134 

• Telephone the NASA STI Help Desk at 

(301) 621-0390 

• Write to: 

 NASA STI Help Desk 

 NASA Center for AeroSpace Information 

 7121 Standard Drive 

 Hanover, MD 21076-1320 
November 2005 

NASA/CR‐2005‐213693

GPS Lessons Learned from the International  

Space Station, Space Shuttle and X‐38

John L. Goodman

United Space Alliance

Houston, Texas

National Aeronautics and 

Space Administration 

Johnson Space Center 

Houston, Texas 77058 
Available from:

NASA Center for AeroSpace Information National Technical Information Service

7121 Standard Drive 5285 Port Royal Road

Hanover, MD 21076‐1320 Springfield, VA 22161

This report is also available in electronic form at http://ston.jsc.nasa.gov/collections/TRS
5 of 118

Table of Contents

1. Acronyms

2. Preface

3. Introduction

4. The Software Nature of Satellite Navigation

Threats to Integrity

Software Quality and GNSS Integrity

Computer Integration Versus Plug and Play

5. GPS Lessons Learned

Mission Impacts of GPS Problems

Define Realistic Schedule, Budget, and Requirements

Off-The-Shelf Versus Development

Working With Off-The-Shelf Items

Take Advantage Of Lessons Learned

Do Not Take Shortcuts With Process

Lab and Flight Testing

Provide the Vendor With As Much Data As Possible

Integrated Teams

The Challenge Of Being A New User

Documentation

Design Insight

Independent Verification and Validation

Orbit Determination Accuracy

COTS Box Outputs May Not Be Designed With Redundancy 

Management In Mind

Do Not Totally Rely On The Vendor For Navigation Expertise

Vulnerability to Space Radiation

The Challenge of Autonomous, On-Board Navigation

Navigation Conferences

6. International Space Station

ISS Space Integrated GPS/INS

Ground Testing and Shuttle Flight Tests of ISS SIGI

SIGI Flight Experience on the ISS

ISS Spacecraft Position Optimal Tracking (SPOT) Filter

SIGI Software and ISS Telemetry Changes

Other GPS Receivers on the ISS

9

13

15

17

17

17

19

21

22

23

24

26

28

28

30

34

35

38

39

40

42

43

45

45

46

46

47

49

49

51

51

53

54

55
6 of 118

Table of Contents Continued

7. The Space Shuttle and GPS

Overview of Space Shuttle Navigation System

Integrating GPS In A Loosely Coupled Architecture

The Tightly Coupled Option

State Replacement Chosen

Receiver Selection

GPS Antennas

Initial Flight Tests and Receiver Missionization

“Single String” TACAN Replacement Flight Tests

Status of Shuttle TACAN Replacement

Mission Control and On-Board, Operational Use of GPS By Flight Phase

Differential GPS and the Space Shuttle

8. Other GPS Receivers On The Space Shuttle

Relative GPS Demonstrations

Scientific Payload Support

Preparation for Future Autonomy Demonstration

9. Shuttle Space Integrated GPS/INS

Tightly Coupled Integration

Shuttle Space Integrated GPS/INS

Shuttle SIGI Ground and Flight Test Results

10. X-38/Crew Return Vehicle

V-201 Flight Test

X-38 Design

CRV GPS Unit

CRV SIGI Ground and Flight Testing

Resolving the SIGI Attitude Initialization Issue

V-201 SIGI Operations Concept

11. Rationale Behind a Notional Shuttle GPS Receiver Upgrade

Receiver Recovery

Loss of Service

New GPS Signals

Receiver Autonomous Integrity Monitoring and Satellite Based Augmentation

Shuttle Autoland Using Ground Based GPS Augmentation

Weather Minimums For Landings

Simplification of Shuttle Navigation Procedures

Precision Orbit Determination

Rendezvous and Proximity Operations

57

58

59

60

61

63

64

64

66

72

73

85

87

87

88

88

89

89

89

90

93

93

93

94

95

96

97

99

100

100

100

101

102

103

103

104

104
7 of 118

Table of Contents Concluded

Attitude Determination

GPS Metric Tracking For Range Safety

12. Summary

13. References

Figures

1. ISS GPS Antenna

2. ISS Antenna Array Location

3. Shuttle and TACAN Ground Station

4. Shuttle Single and Three String Architectures

5. Shuttle Receiver Selection Timeline

6. Location of Single String Antennas

7. Location of Three String Antennas

8. STS-88 GPS Velocity Noise

9. Geographic Distribution of Ionospheric Scintillation

10. Receiver Data From STS-110 Entry (April 2002)

11. GPS States Compared With Best Estimate of Trajectory During Entry

12. Use of Mission Control GPS Filter

13. Day of Rendezvous Profile

14. Entry Navigation Sensors

15. Mission Control Use of Single String GPS

16. Martin Marietta X-24A

17. X-38 V-132 Drop Test 

18. X-38 GPS Antenna and Camera Locations

19. X-38 Drop Test at Edwards Air Force Base

20. SIGI Testing at Dryden Flight Research Center

21. Advantages of a Modern GPS Receiver

22. Upcoming Enhancements to Global Navigation Satellite Systems

Tables

1. GPS Flights on the Shuttle and Shuttle Payloads

2. Lessons From Other Programs

3. Shuttle and Progress Missions Related to ISS SIGI

4. Operational Impacts of SIGI Induced ISS Computer Crash

5. Planned TACAN Phase-Out From Federal Radionavigation Plan

6. Legacy Space Shuttle Navigation Sensors

7. X-38 SIGI Flight Test Program on the Shuttle

105

105

107

109

49

50

57

62

63

65

65

68

69

70

71

76

79

81

83

93

94

94

95

96

99

101

21

29

51

52

57

59

95
8 of 118

This page intentionally left blank.
9 of 118

1. Acronyms

AERCam ‐ Autonomous Extravehicular

Robotic Camera

ATLAS ‐ Atmospheric Laboratory for

Applications and Science

ATV – Automated Transfer Vehicle

BET – Best Estimate of Trajectory

BFS – Back‐up Flight System

BIT – Built In Test

BITE – Built In Test Equipment

CANDOS ‐ Communications And Navigation

Demonstration On Shuttle

CHAMP ‐ CHAllenging Minisatellite Payload

COAS – Crew Optical Alignment Sight

COTS – Commercial Off The Shelf

CRISTA‐SPAS – CRyogenic Infrared

Spectrometers and Telescopes for

Atmospheric – Shuttle PAllet Satellite

CRV – Crew Return Vehicle

DART – Demonstration of Autonomous

Rendezvous Technology

DPS – Descent Propulsion System

DTO – Detailed Test Objective

EGI – Embedded GPS/INS

EGNOS ‐ European Geostationary Navigation

Overlay Service

FDIR – Fault Detection Identification and

Reconfiguration

FOM – Figure Of Merit

GANE – GPS Attitude and Navigation

Experiment

GDOP – Geometric Dilution of Precision

GEM – GPS Embedded Module

GFE – Government Furnished Equipment

GLONASS ‐ Global Navigation Satellite

System

GNC – Guidance, Navigation and Control

GNSS – Global Navigation Satellite Systems

GPC – General Purpose Computer

GPS – Global Positioning System

GRACE ‐ Gravity Recovery And Climate

Experiment

HAINS – High Accuracy Inertial Navigation

System

HHL – Hand Held Laser

HTV ‐ H‐II Transfer Vehicle

HUD – Heads Up Display

ICD – Interface Control Document
10 of 118

IMU – Inertial Measurement Unit

INS – Inertial Navigation System

ISS – International Space Station

IV&V – Independent Verification and

Validation

JSC – Johnson Space Center

JPALS ‐ Joint Precision Approach and Landing

System

KSC – Kennedy Space Center

LAAS – Local Area Augmentation System

LPT – Low Power Transceiver

MAGR/S – Miniaturized Airborne GPS

Receiver/Shuttle

MCS – Master Control Station

MLS – Microwave Landing System

MOD – Mission Operations Directorate

MOTS – Modified Off The Shelf

MSBLS – Microwave Scanning Beam Landing

System

OAST – Office of Aeronautics and Space

Technology

OMS‐2 – Orbital Maneuvering System 2

ORFEUS‐SPAS – Orbiting and Retrievable Far

and Extreme Ultraviolet Spectrometer

– Shuttle PAllet Satellite

PASS – Primary Avionics Software Subsystem

PRN ‐ Pseudorandom Noise Code

QA – Quality Assurance

RAIM – Receiver Autonomous Integrity

Monitoring

RLG – Ring Laser Gyro

RM – Redundancy Management

SA, S/A – Selective Availability

SEM‐E ‐ Standard Electronic Module, Format

“E”

SIGI – Space Integrated GPS/INS

SOAR ‐ SIGI Orbital Attitude Readiness

SPARTAN – Shuttle Pointed Autonomous

Tool for Astronomy

SPOT – Spacecraft Position Optimal Tracking

SRTM – Shuttle Radar Topography Mission

STS – Space Transportation System

TACAN – Tactical Air Control And

Navigation

TAL – Trans Atlantic Landing

TANS – Trimble Advanced Navigation System

TCS – Trajectory Control Sensor

TDRSS – Tracking and Data Relay Satellite

System
11 of 118

TSO ‐ Technical Standard Order

UAV ‐ Unmanned Aerial Vehicles

UHF – Ultra High Frequency

VHF – Very High Frequency

WAAS – Wide Area Augmentation System

WSF – Wake Shield Facility

X‐SAFT – X‐38 SIGI Atmospheric Flight Test

XSS – Experimental Spacecraft System
12 of 118

This page intentionally left blank.
13 of 118

2. Preface

This document is a collection of writings concerning the application of Global Positioning System (GPS)

technology to the International Space Station (ISS), Space Shuttle, and X‐38 vehicles.  An overview of how

GPS technology was applied is given for each vehicle, including rationale behind the integration

architecture, and rationale governing the use (or non‐use) of GPS data during flight.  For the convenience

of the reader, who may not be interested in specific details of the ISS, Shuttle and X‐38 applications, the

lessons learned chapter is at the beginning of the document.   Most of this material can be understood

without reading the sections specific to the ISS, Shuttle and X‐38.

These lessons were written mainly from the perspective of NASA and contractor personnel (both

technical and management) supporting the Mission Operations Directorate at the Johnson Space Center

(JSC).   Additional perspective on GPS integration experiences and lessons learned can be obtained by

contacting the JSC Aeroscience and Flight Mechanics Division, Code EG (Engineering Directorate).  

GPS has also been applied to space applications by other NASA centers (Goddard, Jet Propulsion Lab,

Marshall).    Personnel supporting GPS applications at these centers can also provide insight into

challenges associated with GPS integration.
14 of 118

This page intentionally left blank.
15 of 118

3. Introduction

In the early 1990s, use of Commercial or Modified Off The Shelf (COTS or MOTS) hardware and software

became a prominent theme in government and industry in order to reduce procurement, development

and integration costs.   At the same time, in an attempt to revitalize the U.S. space program, a “faster‐

better‐cheaper” approach to spacecraft development and mission execution was being stressed within

NASA.  

By the early 1990s, after over 20 years of development of the Global Positioning System, the GPS satellite

network and associated ground support infrastructure was nearing operational status.  GPS receivers for

scientific, commercial, consumer and military applications were entering the marketplace.    GPS was

anticipated to provide the revolutionary capability of precision navigation at low cost and at a minimum

amount of effort on the part of the user.    GPS receivers have the potential to provide cheaper, more

accurate and timelier state vectors than traditional ground tracking.  GPS is an enabling technology for

small satellites operated by organizations that cannot support an operations infrastructure.    To lower

spacecraft operating costs, there is a desire to build spacecraft that operate in a more autonomous fashion

and require fewer or no ground support personnel.

At this time, the NASA Johnson Space Center initiated a number of projects designed to leverage GPS

technology to meet the needs of current and future manned spacecraft.  Use of off‐the‐shelf GPS receivers

was believed to be the key to introducing low cost, precision navigation into human space flight, and to

reduce integration, certification, and maintenance costs.  These spacecraft included the Space Shuttle [1],

the ISS [2] and the X‐38 [2, 3], a prototype of a Crew Return Vehicle (CRV) for the ISS.   The receiver

integrated into the Space Shuttle avionics system was the Miniaturized Airborne GPS Receiver/Shuttle

(MAGR/S), while the ISS and X‐38 used the Space Integrated GPS/Inertial Navigation System (SIGI).  In

addition, a mission control software tool called the Spacecraft Position Optimal Tracking (SPOT) filter

was developed to process Shuttle and ISS GPS receiver data to provide more accurate orbit determination

for mission planning.   The use of GPS by the Shuttle, ISS and X‐38 is not as extensive as some might

expect, given the widespread use and success of GPS technology, and the availability of ~$100 receivers to

the general public.  The rationale behind the current planned use of GPS by the Shuttle and ISS Programs

is discussed along with some project history.

While the Shuttle and ISS integrations were successful (the X‐38 was canceled), more technical and project

management challenges were encountered than anticipated.  More GPS receiver software changes, host

vehicle flight software changes, and flight and ground testing were required than anticipated, which in

turn caused schedules to slip.

Two incidents involving GPS, one on the ISS and another on the Space Shuttle, had a profound effect on

the direction and execution of the GPS integrations.  During the STS‐91 (June 1998) flight of Discovery, a

GPS receiver software problem interacted in an unanticipated manner with existing Shuttle flight

computer software requirements which were deficient and resulted in a loss of communication with

Discovery for over an hour.
16 of 118

On the ISS in September of 2002, a GPS receiver software error not recognized in ground testing caused

an ISS computer system to go into a diagnostic mode.   The incident impacted the ISS in the following

ways:  transfer of attitude control from the U.S. segment control moment gyros to the Russian segment

thruster system; contingency attitude control using valuable and carefully managed propellant supplies;

labor intensive manual S band antenna pointing by Mission Control in Houston to maintain data and

voice communications; loss of Ku band data transmission capability; loss of micro‐gravity environment

due to attitude control thruster firings; and loss of a crew day of science operations.

Shuttle GPS receiver, Shuttle computer and ISS GPS receiver software changes were later made. Lab

testing and flight experience proved that the changes resolved the software problems.

GPS receiver procurement, pre‐flight testing, integration, numerous test flights in space and on aircraft,

data analysis, issue resolution, interaction with the GPS community (vendors, users and satellite

operations personnel), and participation in navigation industry conferences has provided Johnson Space

Center personnel with insight into the advantages and difficulties posed by GPS technology.    Many

observations and lessons learned from these projects may be useful for reducing risk in other GPS

implementations, and any project that concerns the infusion of software intensive technology.  

Future applications such as formation flying, elimination of ground tracking, autonomous operation and

automated orbital replenishment (rendezvous, proximity operations and docking) will place stringent

demands on GPS receivers.    Software quality, hardware reliability and orbit determination accuracy

requirements to support these applications will be more demanding than the capabilities of current,

Commercial‐Off‐The‐Shelf (COTS) based GPS units.  Lessons learned from experiences in the Shuttle, ISS

and X‐38 programs should be studied to mitigate risk in future programs that require highly accurate,

robust GPS navigation and GPS attitude determination to support automation and autonomy

requirements.
17 of 118

4. The Software Nature of Satellite Navigation

Threats to Integrity

Risks to GPS (or GNSS, Global Navigation Satellite Systems) integrity include radio‐frequency

interference (intentional or unintentional), spoofing, ionospheric and solar effects, user errors, multipath,

signal obscuration, antenna failure, failures in computers that interact with GNSS receivers, and

malfunctioning GNSS satellites or ground support systems [4].    The effects of on‐board satellite

equipment failures, or ground control segment induced anomalies, may affect users over a wide area.  

Spectrum sharing and the effects of new radio‐frequency technologies, such as Ultra Wide Band, are

important issues that must be resolved at the engineering, government policy and regulatory levels.  The

navigation industry and government agencies are actively researching the potential of GNSS integrity

threats and building systems (such as WAAS, LAAS, EGNOS) and procedures to detect, identify and

mitigate them [5].    Much research has been performed on receiver algorithms (such as Receiver

Autonomous Integrity Monitoring, or RAIM) to detect signal‐in‐space issues [6].  

These are not hypothetical threats.  On July 28, 2001, the failure of a rubidium clock on GPS satellite PRN

22 was detected by the WAAS, the U.S. Coast Guard and GPS receivers that were equipped with RAIM

algorithms [7].   A well‐publicized example of unintentional interference was noticed in Moss Landing

Harbor, California, in April of 2001.  Several months of investigation resulted in the identification of three

boat mounted, active UHF/VHF television antennas with preamplifiers, that were the source of the

interference [8].

Software Quality and GNSS Integrity

Over the last 40 years, integration of off‐the‐shelf systems had changed from being primarily hardware

integration to software integration.    This presents new challenges for users of off‐the‐shelf systems.  

Developers of such systems must compete in a market that demands short time‐to‐market and low

overhead.  This results in short development and test cycles, less rigorous requirements definition and

documentation, and a small group of programmers; and it can lead to a higher probability of software

errors.  Some products contain legacy code that may be decades old, and proper coding standards may

not have been adhered to.    Vendors often maintain a library of common software modules used in a

variety of products.    Cost and schedule concerns may lead the vendor, integrator, or user to judge a

software issue to be no impact and not fix it.  However, this can lead to propagation of software problems

throughout a product line, and it could negatively impact users whose applications of the product in

question are different from the original user.

Historically, navigation unit problems and failures in the legacy Shuttle navigation system tended to be of

a hardware nature.  However, most problems observed by JSC with GPS have concerned software.  GPS

receivers contain tens or hundreds of thousands of lines of code.  Code errors may not always manifest in

a predictable or easily observable manner and may lie dormant for years until the proper set of

__________
18 of 118

conditions permits them to become visible.  Software errors that do not manifest in an aircraft application

of a GPS receiver may be an impact in orbit, where vehicle dynamics, satellite visibility, and flight times

are very different.

Software is at the heart of the GNSS revolution.   Receivers, ground monitoring stations, augmentation

systems, GNSS satellites and associated constellation ground support equipment are software intensive.  

The computational capacity and amount of code possessed by GNSS receivers is approaching that of

aircraft flight management systems and flight control computers. Some current and many future GNSS

receivers will interface with multiple systems: GPS, Galileo, GLONASS, WAAS, LAAS, EGNOS and

various differential systems.  Multiple system interfaces will further increase the software complexity of

GNSS receivers.    With this revolutionary navigation capability has come increased potential for

performance anomalies due to software issues.

Receiver software problems can result in degraded navigation accuracy, or loss of navigation data for a

variable amount of time.    Most of the threats under examination by the navigation industry and

government agencies are external to GNSS receivers.   External monitoring, augmentation systems and

receiver based RAIM will protect against software failures external to the GNSS receiver, but will not

protect a user from a GNSS receiver software problem.  

Receiver failures are not always well documented and may not be noticed if a device is not continuously

monitored and data is not recorded and analyzed.  If a problem is noticed, the reports often tend to be

anecdotal in nature.  It is difficult to pin down the cause of many GNSS receiver issues (i.e., intentional or

unintentional radio‐frequency interference, multipath, signal obscuration, antenna failure, hardware

failure, receiver software failure, host computer hardware or software issues, operator error).  Users are

sometimes too quick to blame a receiver problem on a “bad” satellite or receiver software “bug,” when

the root cause is more likely a user error stemming from inadequate knowledge of receiver operation.

Engineers often underestimate the complexity of software, and overestimate the effectiveness of testing

[9].  Tasks in GNSS receivers are started and stopped based on priorities, and the ability to track GNSS

satellites.    Logic path execution in a receiver is dependant on the radio‐frequency environment,

introducing an element of randomness into what code is executed, and when.    A number of Shuttle

receiver problems identified during a GPS receiver code audit were deemed non‐credible due to the

number of conditions that had to occur within a tight timeframe. However, many of these issues later

manifested in Shuttle flights, sometimes more than once.   Receiver software modifications were made,

proven in lab testing and during Shuttle missions, and the Shuttle GPS system was certified for

operational use in August of 2002.  GNSS satellite signal generators used in lab testing cannot duplicate

the exact radio‐frequency environment encountered outside the lab.   Receiver software anomalies that

manifest in flight may not manifest in ground testing.  The Shuttle and ISS experience also indicates that

changes to receiver software can result in subtle, unintended changes in receiver performance.  

Changes in operating environment that come with a new application may invalidate assumptions made

during initial requirements definition, and result in software issues during testing and operation.  

Software development schedules driven by time to market pressures and a desire to lower overhead

__x__
19 of 118

costs (a small group of requirements developers and programmers, short development and test cycles)

negatively effect software quality. A recent study of stand‐alone TSO C‐129 certified GPS receivers

performed in the United Kingdom found that the probability of a receiver outage (loss of service) due to a

software problem was higher than a signal‐in‐space problem that RAIM is designed to detect and isolate

[10].    Data analyzed was collected during a total of 78,384.1 hours of receiver operation.    The study

concluded that more attention should be paid to characterizing GNSS receiver outage probability and

outage modes.  NASA’s experience with the Shuttle, ISS, and CRV GPS receivers supports these findings.

Computer Integration Versus Plug and Play

Many applications of GNSS receivers involve interfacing with other computer systems.  The concept of

“plug and play” assumes that no software or hardware changes are required during integration.  This is

not a safe assumption for many applications.  Different users may have different data and commanding

requirements, and may not be able to economically change the rest of the system to conform to available

receiver input and output.  Hardware changes for items such as mounting or electrical power may also

be required.  Interactions of receiver software and software in other parts of a system cannot be assessed

without testing and design insight, no matter how many applications already use the receiver in

question.  A “plug and play” integration assumption, which drives initial budget and schedule planning,

can easily result in schedule slips and cost increases due to unanticipated technical problems at the

component and system levels.  

Successful integration of computers requires knowledge, not just of the interfaces, but also of how the

data behind the interfaces are computed and behave under nominal and off‐nominal conditions.    An

integrator may have to negotiate legal agreements concerning access to proprietary documentation with a

vendor, so that information needed for integration is available. Integrator verification of interface

documentation in a laboratory environment is prudent.    System problems may result from the

inappropriate interaction between parts of a system, such as computers, rather than individual units.  The

root causes, manifestations and impacts of system components that behave in a dysfunctional manner are

difficult and sometimes impossible to predict.  
20 of 118

This page intentionally left blank.
21 of 118

5. GPS Lessons Learned

Since 1993 numerous flights of GPS receivers have been made on the Space Shuttle (Table 1) in support of

Shuttle navigation upgrades, testing for the International Space Station, X‐38, X‐33 and X‐34 programs,

relative GPS technology development, and various other payloads and projects.   In addition, GPS has

been in operational use on the ISS since April of 2002.    GPS units are flying on the Shuttle Training

Aircraft, and flew on X‐38 landing demonstration vehicles when dropped from the NASA B‐52B at

Edwards Air Force Base.  X‐38 GPS tests were also conducted on a NASA Beechcraft Beech 200 Super

King Air based at the NASA Dryden Research Center.  This experience base can be leveraged to mitigate

risk in new applications of GPS technology to space flight.

The Shuttle, ISS and X‐38 GPS projects encountered technical, schedule and budget problems that were

not anticipated.  GPS technology proved to be more difficult to apply than was anticipated in the early

1990s.  In spite of the challenges, the Shuttle and ISS GPS projects eventually resulted in certified GPS

receivers for operational use.

Unit Flown a

3M

MAGR

SIGI (GEM III)

TANS Vector

SIGI (Force 19)

SIGI (Force 19)

LN-100G (GEM III)

H-764G (GEM III)

TurboRogue

3M

Laben Tensor

TANS Quadrex

Actel

Blackjack

Low Power 

Transceiver

TANS Quadrex

TANS Vector

Flights b

61, 59, 68, 67, 69, 72, 77

79, 81, 82, 84, 85, 89, 91, 95, 88, 96, 103, 99, 101, 106, 92, 

97, 98, 102, 100, 104, 105, 108, 109, 110, 111, 112, 113, 107, 114

86, 89, 91, 95, 88, 96, 103

77 (GANE)

101 (SOAR), 106 (SOAR) 

100, 108

81, 86

84

69 (WSF-02)

69

80 (ORFEUS-SPAS 2), 84c

, 86c

80

51 & 80 (ORFEUS-SPAS 1 & 2)

99 (SRTM)

107 (CANDOS)

51, 56, 66 (ATLAS 3)

66 & 85 (CRISTA-SPAS 1 & 2), 72 (SPARTAN-206 OAST-Flyer)

Purpose

Space Shuttle

Navigation 

Upgrades

ISS Testing

X-38 Testing

X-33 & X-34

Support

Relative GPS

Test

ATV Relative

GPS Test

Other Payload 

Support or 

Technology

Demonstration

Table 1 - GPS Flights on the Shuttle and Shuttle Payloads (1993 to 2005)

a For Embedded GPS/INS units, the GPS receiver is in parenthesis.

b Payload names are in parenthesis. ATLAS 3, GANE, SOAR, SRTM and CANDOS remained on the orbiter, the 

others were deployed and retrieved. There may have been other GPS equipped payloads that are not listed. c A Motorola Viceroy receiver was on the Mir space station.
22 of 118

A number of lessons were learned during the requirements definition, integration, testing, certification,

and operational phases of these projects.  Consideration should be given to these lessons learned in any

future application of GPS to space vehicles.  

Perhaps the most important lesson concerned people’s perception of the maturity of GPS technology for

space applications.  The widespread success of GPS in myriad applications during the 1990s exceeded the

expectations of those in the military navigation arena that designed and developed the system in the

1970s and 1980s.  The success seen in terrestrial applications of GPS was anticipated to occur in space

applications, but more difficulty in the space applications was encountered than many expected.  

Optimism about the ease of application of GPS to space flight influenced budget, scheduling and project

planning, which led to problems at both the technical and project management levels as the projects

progressed.

A paper presented at a 1998 Institute of Navigation conference covered the status and future plans for

GPS on spacecraft. Part of the paper discussed reasons for difficulty encountered in development and use

of GPS receivers for space flight:

“While this technology holds great promise, its incorporation on spacecraft has been delayed for several reasons.

......... The tremendous success of the very lucrative terrestrial GPS market has, in fact, stifled the development of

spaceborne GPS receivers.  Companies with GPS expertise are more interested in the lucrative terrestrial‐based GPS

market. They are not interested in diverting their GPS talent on the relatively small space‐based market. This has

restricted the development of spaceborne receivers to meet the demands of future spacecraft requirements.” [11]

The paper went on to list the reasons why spaceborne GPS receivers have not matured as fast as receivers

for terrestrial applications: the perception that GPS technology is mature and requires no research and

development to fly in space; more lucrative GPS receiver market for terrestrial‐based applications;

differences between space‐based and ground‐based GPS reception; and the requirement for numerous

flight experiments to climb the technological stair steps [11].

Mission Impacts Of GPS Problems

Government and the navigation industry have devoted a considerable amount of effort to ensuring the

integrity and availability of satellite navigation to the user community to ensure safety [5].  However, the

negative impact of GPS receiver malfunctions is not limited to safety‐of‐flight applications such as the

Space Shuttle or commercial airliners.  GPS on the ISS is not safety critical, but frequent Mission Control

and crew intervention to resolve GPS receiver anomalies created additional work for crew and ground

personnel.   The September 2002 incident on the ISS also impacted science operations, and could have

posed a risk to crew and vehicle safety due to the communications problems that occurred.  In addition

to the operations costs incurred from handling GPS receiver anomalies, a significant amount of effort was

required to eventually resolve those anomalies.   The interaction of requirements deficiencies in a GPS

receiver and Shuttle computer software caused a one‐hour loss of communications with Discovery during

STS‐91, and drove the Shuttle Program to make significant changes to the Shuttle GPS project.
23 of 118

Receiver issues and a lack of design insight negatively impacted several relative GPS technology

demonstrations on the Shuttle [12‐15].  The GEOSAT Follow‐On (GFO) Altimetry Mission satellite (not a

part of the Shuttle Program) was to use a combination of on‐board GPS receivers and ground laser

tracking (using an on‐board corner cube reflector) to perform centimeter level orbit determination.  

However, GPS receiver issues forced the use of ground‐based lasers alone [16].

The criticality of GPS to the success of the Shuttle Radar Topography Mission (SRTM) on STS‐99

(February 2000) led to the inclusion of two Blackjack receivers in the Shuttle payload [17].  The Shuttle

MAGR/S was designated as a backup, and a second MAGR/S was carried to provide additional backup

capability.    Shuttle IMU and Mission Control processed Tracking and Data Relay Satellite System

(TDRSS) tracking data were also identified as backups.   While the Blackjack met a 60 cm positioning

requirement, the effort spent on backup orbit determination methods underscores the importance of GPS

to the success of a non‐safety critical science application.    GPS was also a critical part of the NASA

sponsored Demonstration of Autonomous Rendezvous Technology (DART) mission.  The DART vehicle

carried two different GPS receivers (each from a different vendor) to ensure state vector availability [18].*

Define Realistic Schedule, Budget, and Requirements

The phenomenal success of mass produced, low cost GPS technology in the 1990s is evidence that it can

be leveraged to provide more robust, economical and autonomous navigation for many different

applications.    This has led some to believe that applying GPS to spacecraft should be relatively

straightforward, and require little expenditure on development, modification and integration.    Many

potential users of GPS technology fail to realize the complexity of GPS receivers, since some units can fit

into a pocket and cost around $100.  Experience has proven that GPS integration on spacecraft is not so

straightforward.

Overly optimistic expectations of the budget and schedule required for integration are often not fulfilled.  

More technical issues were encountered than were anticipated, driving up costs and slipping delivery

schedules. Particular attention should be paid to how realistic the schedule is considering the complexity

and technical risk involved.  A study by the Aerospace Corporation of NASA projects that used a faster‐

better‐cheaper approach indicated that mission failures resulted from highly complex projects on short

development timelines [19‐21].  

Analysis at the start of a project should be conducted to determine risk to cost and schedule based on the

technology level, the maturity of the technology and the difference between the planned application and

the application for which the receiver was originally designed. Software complexity should also be

examined. Technical risk must be taken into account when defining budget and schedule. Failure to do so

can lead to cost and schedule problems [22].    Traditionally, navigation unit integration has revolved

around hardware integration and testing (such as shock, vibration, thermal, radiation).  However, with

the increasing use of embedded computers software development, maintenance, and testing must be

budgeted for as well.

* When this document was submitted for publication, the report of the DART Mishap Investigation Board had not

been publicly released.    See “NASA Announces DART Mishap Investigation Board Members,” NASA Press

Release 05‐105, April 22, 2005.
24 of 118

If extensive modifications and operation in a different environment are required, more testing will have

to be performed.  Provision for interim software versions should be provided in the budget.  The vendor

will have to be more involved than on “plug and play” integrations.  Understanding the design rationale

and original user requirements is important, and provision for discussing this with the vendor should be

included.  

Lessons learned from users of the same or similar products should be considered, particularly when

defining requirements for the COTS item.    “Loose” requirements may be easily met with little or no

budget impact.  However, they could permit problems to go unnoticed and unresolved and could impact

future use of the device.  Such requirements result in a “let’s see what we can get by with” attitude rather

than a “let’s do what is right for the application” approach.

Some GPS receivers used on NASA spacecraft have a specified rate of receiver resets to recover from

software anomalies of less than one per day [17].  Such a requirement, along with a maximum allowable

solution outage time, will help motivate a vendor to pursue software issues.

Off-The-Shelf Versus Development

Everything Is Not Plug and Play 

The fact that a unit is in mass production and is a proven product does not mean that its integration into

a different vehicle will be a simple, problem free “plug and play” project.   A difference in application

(such as aviation versus space flight) will result in the manifestation of software issues that may not have

appeared in the original application.  A unit is not likely to meet all requirements as is, and both software

and hardware modifications may be needed to meet mission unique requirements and interface with host

vehicle avionics, telemetry and power systems.  Even a receiver originally designed for space applications

may require changes to meet new requirements and resolve technical issues.

Changes Will Be Needed

Navigation and avionics units are becoming more software intensive, and the technical risk posed by

software is difficult to assess. While GPS receivers have the potential to provide spacecraft with an

autonomous precision orbit determination capability, most receivers do not contain navigation

algorithms needed for this [23].    In addition to software concerns, “terrestrial” and “atmospheric”

navigation units may have difficulty meeting hardware requirements for space flight in the areas of

loads, thermal, data interfaces, electrical power, weight and volume. The ever‐smaller size of electronics

makes them more vulnerable to space radiation; hence radiation hardening, which is expensive, may

have to be considered.  The Shuttle MAGR/S unit, which represented an early 1990s technology level, met

NASA space radiation requirements as built.  However, SIGI units required expensive modification to

meet radiation requirements.    The GPS receivers on the NASA Gravity Probe B spacecraft are another

example of modification of a receiver to meet unique mission requirements [24].
25 of 118

A Fixed Price Contract May Not Be Appropriate 

A fixed price contract may be appropriate if the intended application of the device is the same or very

similar to the application for which it was originally designed. In this case, little or no development work

is required.    However, if a unit is to be used in a flight environment that will necessitate significant

changes to the device, the program budget and schedule should be allocated as for a development

project.  Fixed price contracts can result in inflated vendor estimates for initial cost and can remove the

incentive to aggressively resolve technical issues.  Resolution of these issues may not be covered in the

budget defined at project start.   Modifying an existing GPS receiver, even one originally designed for

space, for use on an unmanned or manned spacecraft should be budgeted and scheduled as a

development project.

Building Your Own Receiver May Be An Option

For some scientific applications, commercially available receivers may not meet mission requirements

(accuracy, fully autonomous operations, special types of measurements, radiation exposure, size, power,

etc.).    Furthermore, such missions may have unique requirements that are difficult to meet with GPS

receivers whose software is proprietary. One such vehicle is the NASA Johnson Space Center Miniature

Autonomous Extravehicular Robotic Camera (Mini AERCam), a 7.5‐inch diameter robotic inspection

nanosatellite [25]. GPS vendors may be reluctant to support customization (i.e. a research and

development activity) of a small number of receivers, for which a market does not exist.  An example of

an in‐house scientific receiver is the Jet Propulsion Laboratory Blackjack, which has flown on ICESat

(2003), FedSat (2002), GRACE (2002), JASON‐1 (2001), SAC‐C (2000), CHAMP (2000), and SRTM/STS‐99

(2000) [26].  

Commercially available GPS receiver kits supply GPS chip sets and traditional GPS software functions

(signal processing, channel and data management, etc.) while allowing the user to add application

unique software.  Another advantage to kits is that the user has access to all software source code.

However, building and flight qualifying an in‐house receiver for space flight requires a high level of in‐

house GPS hardware and software expertise.    Required skills that are not in‐house may have to be

obtained via contractors.    Many projects may not have the schedule, budget, and technical resources

needed to custom build a GPS receiver.   Even if an off‐the‐shelf unit requires extensive modification,

such a path may be less expensive than a custom built receiver or adaptation of a commercial GPS

receiver kit.  For safety‐critical applications, such as the Space Shuttle, use of off‐the‐shelf units may be

more appropriate.  GPS vendors can leverage experience from a variety of safety critical government and

commercial programs.  Furthermore, some capabilities (such as ground or satellite based augmentation,

authorized operation, mitigating radio‐frequency interference, etc.) needed for receivers in safety critical

integrations may require expertise that may not exist outside of the vendors.    Vendor expertise and

experience is crucial to successful requirements definition, receiver modification, integration, testing,

anomaly resolution and certification of a safety critical receiver.
26 of 118

Working With Off-The-Shelf Items 

Recent analyses indicate that a lack of guidance on the application of COTS and faster‐better‐cheaper

principles leads to projects that exceed cost and schedule estimates, and in some cases causes project

failure [9, 10].    Some projects have failed or encountered significant problems since management and

technical personnel were told to use COTS, but were not given (or did not seek) guidance on how to

work with COTS, or determine if a COTS approach was even feasible.  While much material has been

published on the subject of COTS, much of it is highly theoretical.    Many managers and engineers

concerned with using COTS do not necessarily have the theoretical background to understand esoteric

treatments of COTS theory.    A key lesson from accident reports and experience papers reviewed by

Shuttle operations personnel is that one must understand how to properly define, select and integrate

COTS/MOTS components.    Policies governing COTS and faster‐better‐cheaper approaches must be

defined to permit clear and consistent application and to mitigate risk to budget and schedule [27‐35].  

Trade studies of COTS products involving “must meet,” “highly desirable,” and “nice to have”

requirements will help determine what product to choose, what requirements it must meet, and if a

custom approach should be taken instead.    Any addition to or relaxation of requirements must be

identified.  A need for new requirements may not become visible until testing and implementation of the

product is underway.    The impact of COTS driven hardware and software changes to an integrated

system must be assessed.   

COTS/MOTS Policy

A policy is needed to help prevent cost, schedule and technical difficulties from imperiling projects that

use off‐the‐shelf items [27‐37].  Criteria for determining whether a COTS approach can be taken must be

determined.  Of prime importance is defining the level of insight needed into vendor software, software

maintenance and certification processes.   Problems in COTS projects can arise when requirements are

levied on the product that the vendor did not originally intend for the unit to meet.  Using COTS may

mean either compromising requirements on the COTS unit or on the integrated system.  Whether or not

new requirements have to be applied to the unit is a critical decision. Unfortunately, new requirements

may not be recognized until the COTS product experiences difficulties in the testing and integration

phases of the project.

The Shuttle Program created COTS/MOTS software guidelines for varying levels of application criticality.

This recommended policy defines what considerations should be made before deciding to procure a

COTS/MOTS product.  The following should be examined based on the criticality (impact of failure on

safety of flight or mission success) of the application and product in question [38].

Certification Plan — How much of the vendors in‐house certification can be relied upon?    For critical

applications, additional testing will be needed if access to test results, source code and requirements

documents is not allowed.  Can the unit be certified to a level commensurate with the criticality of the

application?
27 of 118

Vendor Support — This should cover the certification process and the system life cycle.    The level of

support should be defined based on the criticality of the system.  Vendor support required for testing,

integration, and maintenance over the life cycle of the product must be defined.   If white box testing

(rather than black box testing) must be performed, design insight from the vendor will be required and

proprietary agreements must be negotiated.    The vendor may possess information on problems other

users have encountered, which will be useful during integration and over the life cycle of the product.  

An additional risk in using “off‐the‐shelf” units concerns the availability of the vendor.    Can a user

continue to use and maintain a product if the vendor goes out of business or stops producing and

supporting the product?

Product Reliability — Vendor development and certification processes for both hardware and software

should be examined.

Trade Studies — Trade studies and risk identification must be performed before committing to the use of a

particular unit and integration architecture.  Define “must meet,” “highly desirable” and “nice to have”

requirements.  Ability of the unit to meet those requirements, and at what cost, will be a major deciding

factor in the COTS decision.  Identify loss of operational and upgrade flexibility as well technical risks

and cost associated with the product.    Examine the impact of the product on the integrated system,

including hardware and software interface changes.  Compare the proposed COTS products to a custom

developed product.  Assess life expectancy of the product and it’s track record in the market place.

Risk Mitigation — Identify areas that increase risk, such as lack of support if the vendor goes out of

business or the product is no longer produced.  Ensuring vendor support over the product life cycle can

mitigate risk, along with gaining access to source code, design requirements, verification plans and test

results.  Off‐line simulations of the product should also be considered.  Can access be obtained to vendor

information on product issues discovered by other users?

Impact Of COTS Disappointments

The success of inexpensive and easily available GPS technology has led some to believe that applying

GPS technology is relatively straightforward, with low risk and low cost.    Not understanding the

complexity of GPS technology will lead to unrealistic budget, schedule, and technical success

expectations.    Assuming that “cheap and easy” terrestrial GPS means applying such technology to

spacecraft will be “cheap and easy” has prevented the maturation of GPS units for use on spacecraft [11].

New technology projects may encounter significant technical problems, budget overruns and schedule

slips due to unrealistic expectations that defined project budget and schedule.   These experiences may

cause both engineers and managers to become suspicious of the technology in question.  The political and

budgetary climate may demand a COTS solution, but problems using a certain technology can lead to

reluctance to work with that technology in the future, particularly in a COTS project.  The problem is not

with the technology but with the unrealistic expectations that were attached to the new or off‐the‐shelf

technology.  These unrealistic expectations arise from a failure to appropriately investigate and plan for

the use of a COTS product when defining schedule, budget, and requirements.  These expectations are

___
28 of 118

based on a lack of understanding about the original design and application of the product in question.  

COTS products are “proven” devices only when used in the applications for which they were originally

designed.   The vendors met the contractual obligations of the original customer.   The issue is not the

technology, or the use of a COTS product, but rather how that technology was applied to meet the needs

of the original customer.

Take Advantage Of Lessons Learned

When performing trade studies and risk assessments, previous users of the technology should be

consulted.  Independent consultants who have worked with a variety of units in different programs and

who do not have a stake in the choice of a particular unit are a good source of information.  Users and

consultants may possess valuable knowledge based on hands‐on experience that may not be available

from a vendor.    Consultants and other users can also provide valuable insight into the rationale and

requirements that governed the original design of the unit.    Taking advantage of such information

enhances identification of cost, schedule and technical risks, and can help an integrator and user

formulate more robust requirements.

Starting in the mid 1990s, Shuttle operations personnel working on GPS began reviewing reports from

accident investigations and spacecraft failures.  A number of reports have been published highlighting

the challenges of software development and analyzing failures of unmanned spacecraft, some of which

used COTS and a “faster‐better‐cheaper” approach [27, 37, 39‐50].    Some issues identified by those

reports are listed in Table 2.  

Do Not Take Shortcuts With Process

Process entails requirements definition, development of software, manufacture of hardware, verification,

validation, integration, testing (at both the component and system level), data analysis, issue resolution,

and certification by regulatory agencies.    Problems in process can manifest as technical issues at the

component or system level, user issues due to lack of understanding proper receiver or integrated system

operation, schedule slips and cost overruns.    Was the spurious active television antenna output that

caused the recent GPS interference incident in California [8] the result of a process problem with design

or manufacture?  Process problems can delay the fielding of augmentation and improved constellation

ground support systems that are needed to enhance navigation capabilities, and ensure integrity [51].  

It is difficult to assess the quality of software requirements and code development processes when they

are of a proprietary nature.  Most software is not written from scratch, but is reused and modified for

new applications.  Development of legacy code may not have adhered to coding standards as it evolved,

or been subjected to a robust process (requirements definition, code reviews, configuration management

of code and supporting documentation, unit testing, lab testing of the receiver and integrated system,

testing in the operational environment).  Processes should be designed to focus resources on areas where

the root cause of problems are frequently found.  For example, many root causes of software issues occur

during requirements definition and at hardware/software interfaces [52].
29 of 118

Table 2 - Lessons From Other Programs 

• Technical risks not identified and managed.

• Software development process not well 

defined, documented or understood.

• Contract consolidation led to corporate 

knowledge loss concerning critical systems.

• Lack of independent verification and 

validation.

• Inadequate communication between project 

participants.

• Lack of management involvement and 

oversight.

• Inadequate spacecraft monitoring and 

procedural errors by operators.

• Navigation equipment not well understood.

• Spacecraft operators not familiar with 

system design, operation and failure modes.

• Lack of a formal, disciplined process for 

documenting, advertising and resolving 

issues.

• Inadequate staffing and training.

• Legitimate issues ignored and attributed to 

resistance to a “new way” of doing business. 

• Frequent turnover of management and 

technical personnel.

• Issues ignored due to cost and schedule 

pressure.

• Roles and responsibilities not defined.

The requirements definition, verification and validation processes require special attention [53].    Most

software problems can be traced back to flaws in specifying requirements, not to coding errors [9, 54].  

Flaws in requirements specification result from incorrect assumptions about system operation or

unanticipated aspects of the operating environment.  Requirements should also specify how a component

or system should act under off‐nominal conditions.

Proper documentation of requirements, and requirements rationale, is important.  Much software in use

today is maintained by personnel who did not participate in the original development of the

requirements and code [52].  Lack of documentation and corporate knowledge loss can pose technical,

cost and schedule risk to projects that reuse existing software [55].*

A review [9] of seven recent aerospace accidents identified sixteen common factors: 1) overconfidence

and over reliance in digital automation; 2) not understanding the risks associated with software; 3)

confusing reliability and safety; 4) over relying on redundancy; 5) assuming that risk decreases over time;

6) ignoring early warning signs; 7) inadequate cognitive engineering; 8) inadequate specifications; 9)

flawed review process; 10) inadequate safety engineering; 11) violation of basic safety engineering

practices in the digital parts of the system; 12) software reuse without appropriate safety analysis; 13)

unnecessary complexity and software functions; 14) operational personnel not understanding

automation; 15) test and simulation environments that do not match the original environment; and 16)

deficiencies in safety‐related information collection and use.  Many of these factors may be classified as

problems with the processes used to develop, integrate and use devices and systems that contain

software, which includes GNSS receivers and associated support systems.

* John L. Goodman, Knowledge Capture and Management for Space Flight Systems, NASA Contractor Report

CR‐2005‐213692, October 2005.  Available at http://ntrs.nasa.gov/
30 of 118

However, robust processes can be expensive [52].  A rigorous and successful process, such as that used

for the Space Shuttle flight software, may not be economically viable for a vendor.  Controversy over cost

has surrounded the Federal Aviation Administration’s DO‐178B standards for avionics certification.  

Hiring and retaining skilled personnel to support these processes is challenging.

Use of new or off‐the‐shelf technology has the potential to lower development, integration, and life cycle

costs.  However, successful use of a technology in other applications and environments does not mean

that applying the technology in a new application or environment will be straightforward and low cost.  

Trade shows, conferences and industry magazines often do not highlight the technical and management

challenges encountered when applying a new technology.  The temptation to cut costs by cutting corners

during requirements formulation [56], product or technology selection, development, integration, testing

and certification should be avoided.  False and simplistic perceptions of the maturity or flexibility of a

technology can result in flawed processes that will increase technical, cost and schedule risk.    Well‐

defined processes, clear lines of technical and management authority, accountability, and specific goals

are required.    Technical and management issues must be meticulously documented in a manner that

provides visibility throughout the project.  Clear lines of communication are essential to enable project

members at both the organizational and individual levels to facilitate issue resolution.

Technical issues must be addressed early in a project, even in the presence of cost and schedule concerns.  

These issues can easily become show‐stoppers later in the integration.  Not addressing issues until late in

a project will drive up cost and shift schedules to the right.  Problems arising from cost and schedule slips

and failure to address issues can create adversarial relationships between project participants and the

vendor.

The data path from the receiver to the user needs to be completely and clearly defined.  This includes on‐

board and ground hardware and software, and associated requirements documents.    System

requirements owners should also be clearly identified.  New users of GPS data may experience difficulty

in elevating concerns through unfamiliar and complicated software and hardware configuration control

processes than encompass multiple spacecraft and ground systems.

Lab And Flight Testing

A number of spacecraft failures have resulted from a lack of comprehensive, end‐to‐end testing [9, 57].  A

limited amount of flight and ground testing to ensure that the unit meets specifications may not exercise

enough of the software to uncover software issues.  If the new application is different from that for which

the product was designed, and modifications have been made, the amount and scope of testing will have

to go beyond that needed to verify that the unit meets contract specifications.    Both off‐line and

integrated testing of interface software in units that interact with the COTS product are required.

The ISS, X‐38, and Shuttle GPS projects illustrated the need for thorough ground and flight‐testing.  The

level of testing required varies with the criticality of the application.  Sufficient resources and schedule

should be provided to permit the appropriate level of testing to be conducted early enough in a program

__
31 of 118

to catch performance issues so that they may be resolved in a timely manner.    If it can be afforded,

extensive testing of the complete system and provision for interim software versions is highly desirable.

Shuttle GPS – A Safety-Critical Application

The Shuttle GPS receivers are required for hypersonic, supersonic and subsonic flight and landing of an

~100 ton glider.  As such, receiver and overall avionics performance are safety critical and must be highly

reliable.  The Shuttle test program permitted extensive ground testing of the MAGR/S in a stand‐alone

configuration with a signal generator, and integrated with a ground duplicate of the Shuttle avionics

system. Multiple fly/fix/fly cycles of interim GPS receiver software versions were performed.  

Modifications of Shuttle flight computer software interfacing with the receiver were also identified and

proven in ground testing and Shuttle flights (Table 1, page 21) before MAGR/S certification.  

The Shuttle/GPS integration architecture allowed a single GPS receiver to be flown for data collection

while the baseline, certified legacy Shuttle navigation system operated.  Shuttle software that interfaced

with and processed MAGR/S data was exercised in flight.  This integration architecture permitted flight

evaluation of all hardware and software components of the GPS integration without requiring the use of

GPS for Shuttle navigation.

ISS GPS – A Non-Safety Critical Application

A non‐safety critical application may not warrant the same level of testing as a safety‐critical application.  

The ISS GPS receivers, whose data support antenna pointing, time determination and provide state

vectors to various users on the ISS, are not safety‐critical.  There are other methods of state determination

available, such as GPS/GLONASS receivers on the Russian segment of the ISS, Russian ground tracking,

and U.S. ground tracking.  However, significant mission impacts can occur due to malfunctions of GPS

receivers.  While these impacts may not always threaten safety of flight, they may increase operations

costs, drive extensive anomaly investigation and software changes, and prevent the accomplishment of

science and mission objectives.    However, dysfunctional interaction between a non‐safety critical GPS

receiver and safety–critical elements of an avionics system could pose a safety risk.  Even for non‐safety

applications, an appropriate level of GPS and overall system testing must be determined to avoid threats

to cost, schedule, and the achievement of mission objectives.

The Difficulty of GPS Testing

GPS receivers track and download data from multiple satellites. Signal strength, antenna obscuration,

radio‐frequency interference, and multipath can all effect the ability of a receiver to successfully perform

acquisition, tracking, measurement processing, and data collection tasks.  Software paths executed within

GPS receivers are highly influenced by the radio‐frequency environment.    Test flights in the flight

environment, as was accomplished with MAGR/S flights on Shuttle missions (Table 1, page 21), are the

best way to test a receiver.    Due to the integration architecture, these flights also exercised the same

Shuttle computer software (GPS quality checks, telemetry, commanding, receiver aiding data, etc.) that

would be supporting actual use of GPS after certification and TACAN replacement.    However, this is

expensive and may not be feasible in many applications.
32 of 118

Tests of the ISS and CRV SIGI units on the Shuttle (Table 1, page 21) were valuable, but they could not

subject the SIGI units to the exact radio‐frequency environment later encountered on the ISS.  Nor were

Shuttle flight tests of ISS SIGI able to exercise the complete GPS data path from the SIGI, through the ISS

avionics and telemetry system, to the users in Mission Control. The first time ISS SPOT developers noted

telemetry issues with SIGI data was after the SIGIs were operational on the ISS.    GPS receivers may

manifest performance problems after extended, continuous use (weeks or months) that may not manifest

on shorter test flights.    Some of the issues with the ISS SIGI unit could not have been caught during

laboratory or Shuttle flight tests.  While a non‐safety critical application such as ISS GPS may not warrant

the extensive test program that the safety‐critical Shuttle MAGR/S was subjected to, there is risk of late

discovery of performance issues that pose a risk to cost and schedule.

Lab Testing

Lab testing of GPS receivers is important for verifying data interfaces, commanding, basic functionality,

receiver performance under dispersed trajectory conditions, and the ability of the receiver to operate in

an integrated system.  While GPS signal generators are useful for subjecting receiver software to flight

dynamics, they cannot replicate the radio‐frequency environment encountered in flight.   Testing using

roof‐top antennas can also be useful, but cannot duplicate the flight dynamic or radio‐frequency

environments.  Testing must not be limited to basic tests to ensure that the unit meets published accuracy

and availability specifications.    Extensive testing of both the receiver and interfacing host vehicle

software using both nominal and off‐nominal inputs should be conducted.    Receiver anomalies will

appear in flight tests that may not manifest during lab testing [17, 58].    Conversely, some anomalies

found during lab testing may not occur in flight.

Command and data collection interfaces should be exhaustively examined in lab testing prior to more

expensive test flights. This will help ensure that interface and data collection problems do not occur

which could make it impossible to verify receiver performance during a flight. Software issues that do

not manifest in aviation applications due to a flight time of minutes or hours can manifest during a much

longer space flight.  For space applications, lab tests lasting many days or weeks should be conducted.  

Many software issues could have been found earlier in the Shuttle GPS project had a more thorough

ground test program been conducted.   A limited number of lab and flight tests to ensure that the box

“meets spec” will not exercise enough of the software to find issues.  This is particularly important for

safety of flight applications.    Vendors tend to perform the minimum amount of lab testing needed to

ensure that the unit meets contract specifications.  Vendors may not consider flight testing to be valid if

they do not trust the source of truth vectors.

Testing should also involve any hardware and software that interfaces with the unit.  Thorough off‐line

testing of the unit and proposed algorithms that will interface with it should be performed before

committing to specific integration architecture.    Once the integration has been performed, thorough

testing of navigation unit interaction with the rest of the avionics system is needed.
33 of 118

Early testing of the X‐38 SIGI and knowledge of CRV trajectory requirements enabled the cold start

attitude determination issue to be caught early, providing time to analyze the issue and develop an

alternate procedure using digital video cameras (see Chapter 10, page 93).

Allocate Sufficient Resources And Schedule For Testing

Software issues tend to be discovered sequentially.  Units containing complex software may not manifest

anomalies in the initial round of ground and flight tests.  This can lead to a false sense of security about

the maturity of a software version.    Enough rigorous ground and flight testing must be planned to

thoroughly exercise the software.    Schedule and budget should include interim software versions to

allow issues to be discovered and resolved before a production software load is scheduled for

certification.  A lack of comprehensive, end‐to‐end testing has resulted in a number of spacecraft failures

[9, 57].  

Adequate time and personnel must be set aside to analyze flight and ground test data.   If data is not

thoroughly analyzed in a timely manner, software issues will go unnoticed.  Lack of resources can even

lead to failure to analyze test data.  Performance issues arising late in the development and certification

cycle can negatively impact cost and schedule.

Produce, Test and Fly Interim Software Versions

GPS receivers tend to become more robust after use in multiple applications has allowed users to identify

and fix software anomalies.  Some anomalies may not be fixed, as a previous user has judged them to be

of no impact to the application in question.  However, these issues may be an impact to a subsequent user

of the same device.   Introduction of a GPS receiver into a new operating environment (such as going

from an aircraft to a spacecraft, or from a low Earth orbit application to a higher orbital altitude) can lead

to manifestation of software issues not seen before.  Differences in flight duration (aviation versus orbit,

hours versus days or weeks) can also determine which software issues will manifest.    For orbital

applications, lab tests that subject a receiver to orbital dynamics for days or weeks should be considered.

Interim software versions and multiple fly/fix/fly cycles (Table 1, page 21) were instrumental in resolving

Shuttle MAGR/S performance and Shuttle flight computer issues, and built confidence in the system

prior to certification for operational use in a safety critical application.  From September 1996 to February

2003, over 7,000 hours of “nominal performance” MAGR/S operating time was accumulated during

Shuttle missions.    The parallel integration architecture enabled the receiver to be flown in the actual

dynamic and radio‐frequency flight environment in a test mode, while interfaced with Shuttle flight

computers [1].

Instrumentation Port Data Is Needed During Flight and Ground Tests

Instrumentation port data provides invaluable insight into software behavior during periods of

questionable performance.  Vendor input should be solicited concerning what data to collect and how it

should be interpreted.  Instrumentation port data simplifies and speeds up the identification of software

problems.    Software on data collection platforms (such as laptop computers) must be fully tested,

________
34 of 118

documented and certified.  Clear and accurate procedures for laptop operation and troubleshooting are

needed.  Otherwise, it may be difficult to distinguish GPS receiver problems from problems with the data

collection computer.    Lack of instrumentation port data will lengthen the time needed to resolve a

software anomaly, and may even prevent its resolution.  Due to the June 1998 GPS receiver and Shuttle

software anomalies on STS‐91, a laptop computer was flown on many subsequent missions to collect

instrumentation port data.

Conduct Enough Test Flights Before Making Critical Decisions

Initial flights of the 3M receiver (pre‐production MAGR, Table 1, page 21, see also Chapter 7, page 57)

were very successful.    Later flights of the MAGR/S, along with ground testing and software audits,

uncovered many issues that had to be resolved before the MAGR/S could be certified for TACAN

replacement.  It is important not to be lulled into thinking problems are not out there based on a small

number of initial, successful test flights.  Numerous software issues were discovered during the STS‐91

flight in June of 1998, resulting in a three‐year delay of MAGR/S certification for operational use.  

However, the three TACAN units had already been removed from the orbiter Atlantis and three MAGR/S

had been installed.  The Shuttle Program had to remove three string MAGR/S and reinstall three string

TACAN in Atlantis.

Maintain Configuration Control Over Test Equipment And Procedures

Perceived anomalous navigation unit performance in the lab is more likely to be caused by improper test

equipment configuration and improper procedures, rather than software or hardware problems in the

receiver, signal generator, or GPS satellite problems.  A lack of accurate, documented test procedures can

make it difficult to duplicate questionable receiver performance in later tests.  This lengthens the amount

of time it takes to determine the cause of suspect behavior.    When trying to diagnose questionable

performance, an accurate record of what procedures were performed and the test equipment hardware

and software configuration is invaluable.  Software associated with lab simulations and data collection

for both lab and flight test applications should be accurately documented and verified.    A lack of

laboratory configuration control and documented operating procedures can result in a failure to discern

the difference between a unit problem, a test equipment problem, or a user error.

Provide The Vendor With As Much Data As Possible

Vendors often complain that users provide minimal data when a problem with a unit occurs.  Devices

containing software are complex computers whose performance depends on a variety of factors.    For

example, in the case of GPS, a plot illustrating questionable position and velocity performance is not

enough to permit a vendor to diagnose the true cause of an alleged anomaly.   The vendor should be

provided with as much digital data as possible, particularly channel and tracking parameters.  

Information on antenna location, hardware configuration and the procedures that were executed is also

helpful.  Vendors are busy and receive large numbers of inquiries from the user community.  Users who

suspect that a unit is malfunctioning should make a thorough investigation to determine if the alleged

performance is a user error before involving the vendor.
35 of 118

Integrated Teams

Communicate Early, Communicate Often

Participation by experienced personnel from various disciplines who possess sharp technical skills and

are motivated by lessons learned from past projects can facilitate development of robust and realistic

requirements, and enable issues to be noted early in the project.  Open and unrestricted communication

between all project participants (vendor, users, integrators, host vehicle systems specialists) is essential to

ensure that robust and accurate requirements are developed, issues are noted, and issues are resolved in

a timely fashion. Open communication creates a positive working environment and enables team

members to become educated on issues raised by various parties.

The success of the Mercury, Gemini, Apollo, Space Shuttle, and ISS spacecraft development and flight

programs was in part due to the existence of integrated teams, which freely communicated across

corporate and civil servant/contractor boundaries.    All participants had access to requirements and

source code for a variety of on‐board and ground systems, leading to a good understanding of system

requirements and technical difficulties.  This access facilitated accurate communication and timely issue

resolution.  Furthermore, the Mercury, Gemini and Apollo spacecraft were not nearly as complex as the

Space Shuttle, ISS (and future vehicles), and required a smaller number of specialists to design, test and

understand the systems.   The increasing complexity of aerospace vehicles requires more specialists to

assess the impacts of technical issues and modifications, which in turn necessitates effective and accurate

communication.  However, an environment of effective communication can be difficult to maintain over

the long term in a large program, as evidenced by the losses of Challenger and Columbia [59‐61].  All four

NASA JSC GPS projects demonstrated the need for a close working relationship between the integration,

user, and vendor personnel.  

The success‐oriented nature of project budgets and schedules sometimes restricts communication at the

technical level. Little or no money will be saved by a success‐oriented approach that limits

communication in an attempt to save money. Multiple layers of contractors cut down on communication

and should be avoided.  Concern about keeping management and technical discussions within the scope

of the contract are valid, but such concern should not restrict open discussion of issues that are within the

scope of the contract.    Frequent and open communication between personnel (technical and

management) is the key to catching and resolving problems early, lowering risk to cost and schedule, and

building positive working relationships among team members.  Trying to obtain design information in

the presence of firewalls wastes time and money.  Knowledge of product design and operation should

not be isolated to a select few.  Integration engineers must have access to testing facilities and data so they

can become familiar with box performance.  

Early MAGR/S project reviews focused on hardware modifications, with little attention paid to software.  

Most technical personnel were “fire walled” from the software missionization process and the vendor.  

No formal, program wide reviews of the GPS receiver software modifications were made.    The GPS

vendor and the Shuttle navigation (both operational and engineering, contractor and civil servant)

_______
36 of 118

personnel had minimal involvement in the missionization decisions made by the integrator.  As a result

of the GPS receiver and Shuttle flight computer anomalies that surfaced during STS‐91, the GPS vendor

was more fully integrated into the GPS project to enhance communication.  Weekly teleconferences were

established that included the vendor and all NASA and contractor organizations.  Face to face meetings

of all project participants were held at the Johnson Space Center three to four times a year.  Special teams

that crossed civil servant and contractor boundaries were formed to address specific technical and project

management challenges.

The Role of the User 

Users of the GPS receiver should be integrated into the project from the start, and work alongside

development, integration, and vendor personnel.    The user brings an operational and procedural

perspective to the project.    User input into the requirements process may prevent technical and

procedural issues from arising after the operations phase has begun.  Such issues may drive complicated

and time‐consuming work‐arounds, analysis, and new software development.    Receiver and systems

requirements that reflect user considerations are a key to reducing life cycle costs once the operations

phase has begun.

Personnel from the JSC Missions Operations Directorate (MOD), responsible for Mission Control

activities, mission design and planning, procedure and flight rules development, and astronaut training,

were closely involved in the MAGR/S integration effort.   MOD personnel participated in evaluation of

MAGR/S flight test data, development of performance requirements, development of software and crew

display requirements, anomaly investigation and anomaly resolution. User involvement throughout the

MAGR/S project was later credited as a factor in the project success, in spite of numerous technical

challenges.  Early user involvement in the MAGR/S project was also a factor in the success of the later

Shuttle SPOT project.

Vendor Involvement

Use of software intensive products in high‐visibility, high‐risk, and safety‐related applications requires a

higher level of vendor participation than other applications.  Unfortunately, many vendors have little or

no insight into how their products are integrated and used. Due to communication constraints imposed

by success oriented budgets and schedules, vendors are frequently not involved in the definition of

integration and software requirements.  The “throw a unit and an Interface Control Document over the

fence” approach can lead to cost and schedule problems. Vendor participation throughout the

integration, test and certification program is invaluable, particularly if the receiver is used in an

application for which it was not originally designed.    The vendor possesses insight into receiver

operation and design that is useful throughout a project.  Vendor assistance in host vehicle systems and

test requirements definition, receiver and integrated system anomaly resolution, procedure development,

and data analysis can reduce risk to cost and schedule over the life of a project.  Vendor support is more

effective if they are provided with as much data as possible, along with test and flight equipment

configurations and procedures that were executed.  Vendor personnel should be given opportunities to

learn about the application, as it may be different from previous applications of the receiver.    This

_______
37 of 118

knowledge may be useful in avoiding surprises due to use of a receiver in an application that it was not

originally required to operate in.  Fixed price contracts may limit or even prevent vendor participation.  

Such contracts pose high risk to cost and schedule.    If the receiver vendor is a subcontractor to a

navigation unit integrator, contracts should be written and budget provided to ensure that the vendor is

accessible.

What the Vendor Brings to the Table — Vendors possess valuable insight into a product through their

knowledge of the product; it’s original design requirements, and experience from previous applications

of the technology.    The vendor can be invaluable in reducing technical, cost and schedule risk by

providing assistance in areas such as addressing anomalies, resolving questions over technology

application, defining requirements (software, hardware, testing, integration).    Technical interchange

between both the vendor and user is required for risk mitigation.    Early vendor participation in

discussions on integration and architecture should be sought.  The vendor can provide sage advice based

on a detailed knowledge of unit operation.  The vendor may also identify concerns related to the use of

the product in a new environment.    New (i.e. the product was not originally designed for the

application), high risk, high visibility and safety critical integrations require more vendor involvement

than other projects.

Budget for Access to the Vendor — The GPS receiver is a critical part of the SIGI.  Unfortunately, due to cost

and schedule concerns, the user and SIGI manufacturer often had little or no opportunity to interact with

the GPS vendors in the Shuttle, ISS and CRV SIGI projects.  This made identification and resolution of

GPS performance issues difficult.    Contracts concerning integrated units should be written so that

vendors of critical, software intensive components can be involved and able to give advice and

information to the unit manufacturer, the integrator and the user.  

The Vendor and the Shuttle GPS Project — In hindsight, some aspects of the Shuttle GPS integration might

have been done differently had the vendor been involved earlier in the project.  The Shuttle software that

interfaced with the MAGR/S was designed with an inadequate understanding of the software behind the

interface definition.  This lack of receiver insight was one of the causes of the problems encountered on

STS‐91.    Initially, contact with the MAGR/S vendor was limited to a small group of personnel.  

Information obtained from the vendor was not passed on to other project participants, and the vendor

was not consulted enough on integration and performance issues. After STS‐91 the MAGR/S vendor was

fully integrated into the GPS project team.  Regular face‐to‐face contact between the vendor and Shuttle

engineers built positive personal relationships and established a team rather than an adversarial

environment.  Both the vendor and Shuttle Program engineers became familiar with each other’s work

cultures, which enabled them to work better together and provide appropriate support to each other.  

Interaction with project participants during weekly teleconferences and face‐to‐face meetings enabled the

vendor to understand concerns and various points of view expressed by project members, enabling them

to propose solutions that were agreeable to all parties.    The vendor also provided much needed

education to Shuttle engineers concerning the challenges of GPS receiver design and operation.
38 of 118

Enable The Vendor to Learn About Your Application — While vendors have valuable knowledge about unit

design, operation and performance in various applications, they may not fully understand the

implications of using their product in a new environment.  Vendor understanding of the new application

environment and user requirements is necessary to enable the vendor to supply the best possible support.  

In the case of the Shuttle GPS project, vendor interaction with Shuttle personnel enabled them to

ascertain how the Space Shuttle application differed from aviation users of their product.    Observing

Shuttle ascent and entry from Mission Control, flying landings in a Shuttle simulator, and participating in

MAGR/S testing at Space Shuttle Program facilities enabled the vendor to become familiar with the

Shuttle flight regime, crew and Mission Control procedures, flight rules, and aspects of Shuttle mission

design.    This facilitated better understanding of customer concerns and helped them identify

improvements to be made to the receiver.  The vendor provided advice that improved ground and flight‐

testing, issue identification, and issue resolution.  The vendor also became familiar with the strengths and

weaknesses of Shuttle Program GPS simulation facilities.  This enabled them to provide input to Shuttle

integration engineers concerning how best to perform receiver testing and verify functionality.

The Challenge Of Being A New User

In the mid 1990s, telemetry constraints and a complex ISS software requirements process prevented

orbital debris avoidance needs from being addressed in ISS GPS telemetry requirements definition.  The

ISS SPOT application was not conceived for several more years.  Likewise, the use of MAGR/S data for

the Shuttle SPOT application was not identified until about three years after flights of the MAGR/S and

associated Shuttle computer software had begun.  However, the development and testing of the Shuttle

SPOT application encountered far fewer technical difficulties than the ISS SPOT application.   This was

due to the differences between the development and test phases of the two projects.   

The safety‐critical MAGR/S project enjoyed extensive, full system testing in both laboratories and the

flight environment.  Associated Shuttle software and telemetry requirements were exhaustively reviewed

by all project participants (civil servant and contractor, engineering personnel, Mission Control and

mission design personnel) before the initiation of MAGR/S test flights on the Shuttle.  Furthermore, SPOT

processing of MAGR/S data for development purposes did not begin until several interim receiver

software versions had been produced and test flown. Vendor involvement ensured that project

participants understood MAGR/S data and operating characteristics.    MAGR/S software, originally

developed at government expense, had been made available to the Shuttle Program and was undergoing

an audit by the NASA IV&V contractor.  This also ensured that receiver performance and operation was

well understood.    While the MAGR/S was not ready for certification to support Shuttle TACAN

replacement, it had undergone enough testing to avoid major technical surprises during the Shuttle SPOT

development process.

New uses for GPS receiver data will most likely be identified that were not anticipated when the initial

spacecraft GPS and overall system requirements were written.    Requirements for components in the

integrated system (GPS receivers, interfacing on‐board avionics, on‐board and ground telemetry

processing) may not meet the needs of the new user.  Furthermore, systems integrators, software process

_
39 of 118

owners and operations personnel may not initially recognize the new user as a customer for the data.  

This may make it difficult to get priority and support for resolving issues, identifying requirements and

software changes, and getting changes approved and implemented. While it is not possible to forecast

with 100% accuracy what new uses for receiver data on a particular spacecraft may come up in the future,

experienced personnel should make an effort to identify output data and telemetry requirements that will

avoid problems experienced with past integrations.  New users of GPS data may experience difficulty in

elevating concerns through unfamiliar, poorly defined, and/or complicated software and hardware

configuration control processes that encompass multiple on‐board and ground systems.

Documentation

A lack of configuration‐controlled documentation can lead to incorrect knowledge about receiver or

signal generator design, operation and performance.    Inadequate understanding of unit design and

operation can also lead to misinterpretation of test results.    This makes problem resolution more

expensive.   A lack of accurate, detailed product documentation forces integrators to spend significant

amounts of lab time trying to get the unit to work properly.    Frequent consultations with the vendor

drives up project costs.

Keep Accurate Records

Detailed and accurate records of meetings, issues and issue disposition, design rationale, and testing

results should be maintained.  This enables project participants to be better informed on issues facing the

project and provides a record for the future.  An official issue list should be maintained, along with a list

of questions for the vendor and vendor responses.    Issue and question status and closure should be

recorded and periodically reviewed.

Identify And Resolve Legal Issues Concerning Proprietary Documentation

If a device contains proprietary software, legal arrangements must be made to permit inspection of

proprietary documentation.    Lack of access to proprietary documents can result in undetected issues.  

One such example was the telemetry bandwidth problem on the European Space Agency

Cassini/Huygens Titan probe.  Telemetry requirements for the Huygens data receiver on Cassini did not

include the effects of Doppler shift.    This issue was not discovered until a communications test was

performed while the probe was enroute to Saturn [42].  To compensate for the error, the trajectory was

changed to minimize the Doppler shift between Cassini and Huygens. This slipped the Huygens arrival

at Titan from November 2004 to January 2005.    Factors that contributed to the late discovery of the

problem were lack of access to proprietary documentation, no end‐to‐end system testing and a lack of

comprehensive project requirements.  
40 of 118

Interface Control Documentation (ICD)

If the integrator and user do not have access to software and software requirements, the ICD may be the

only written source of information on unit parameters.  Developers of software that will interface with

the unit must examine the ICD closely.  The ICD and the interfacing software must be compared to each

other throughout a project.  The ICD should also be compared to ground and test results to ensure that it

accurately reflects unit input, output and operation.    An inaccurate ICD will lead to software and

procedural issues that will have to be addressed before a system can be certified as operational.    An

accurate ICD is also needed for any data available in the lab (i.e. instrumentation port data) that might

not be available once the unit is integrated into an operational system.   This is critical in the test and

verification phase of a project.

Integrators should strive to understand operation of the software intensive devices as much as possible

before defining requirements for code that will perform interface functions.  Interfaces should be bullet

proofed since it may not be possible to account for all forms of anomalous unit behavior.

Short development schedules may result in changes to the ICD while host vehicle software requirements

are being defined and software is in development and test.  A disciplined process of checks must be in

place to ensure that the ICD and software requirements for units that interface with each other are

consistent.   Individuals who are knowledgeable in requirements for various interfacing units must be

able to communicate and be involved in any changes made to the ICD.

Design Insight

Design insight is required for high‐risk, safety‐related applications for the COTS integration to be

successful.  Users of COTS units usually have little or no insight into software design, design rationale,

and operation.  Available documentation may not contain accurate, pertinent information that would aid

an integrator in designing integration architecture, defining interface and software requirements, test and

operational procedures, and issue identification and resolution. A vendor supplied Interface Control

Document may not contain enough information to permit host system interface software requirements

creation.  Many devices, such as GPS receivers, contain legacy code, some of which may be one or more

decades old.  Vendor engineers may not have participated in the original development of the product.  

Over time, corporate knowledge loss concerning design rationale occurs due to retirements, employee

attrition, office clean‐ups, and corporate takeovers.  This will make it difficult for the vendor to answer

integrator and user questions.  Vendor answers to questions may be limited to “how” a device operates,

but not “why” it was designed to operate that way.  If a vendor is not forthcoming concerning design

insight, consultants and other users of the product may be able to provide information.

As much design information as can be obtained is invaluable for determining if a device is really suitable

for an application, and what hardware and software modifications are required for it to meet

requirements.    Lack of design insight makes this determination difficult. Issue identification, issue

resolution and procedure development are also hindered by lack of design insight.  Excessive amounts of

_
41 of 118

proprietary documentation and software also hinder the process, even if proprietary non‐disclosure

agreements are in effect. This can result in identification of serious technical issues late in the

development and test program, or after operational use has begun.  Lack of design insight can lead users

to attribute suspect performance to the unit or some other component of an integrated system, when the

real problem is a lack of user understanding of the device and how it should be operated.  During a space

mission, operators of both unmanned and manned spacecraft live by their data.    Wrong information

about system functionality can lead to making the wrong decisions when faced with a spacecraft

anomaly.  This can lead to loss of data, some vehicle capabilities [50] or even the spacecraft itself, as in the

1997 Lewis satellite incident [45].    Some form of knowledge capture and management should be

implemented by developers, users and integrators to ensure preservation of system knowledge that is

critical for resolving issues and examining proposed reuse of software and hardware in new

applications.*

The ISS Experience With SIGI Design Insight

The developers of the original Force 19 attitude determination software were not permitted to see the

Force 19 code that the attitude software would interface with, as it was proprietary.  Furthermore, NASA

JSC and contractor personnel responsible for integrating the SIGI into the ISS avionics system were not

permitted to see the attitude determination code, as it was also classified as proprietary.    These

restrictions complicated SIGI flight qualification, as well as resolution of SIGI issues once the units were

operating on the ISS.  This experience was one factor in the decision to develop and maintain a new set of

non‐proprietary attitude determination code owned by NASA (see Chapter 6, page 49).

The Shuttle Experience With MAGR/S Design Insight

For a flight critical application (i.e., the box is required to safely conclude the mission), a box will undergo

more modification than in other applications.   The user will also require more detailed knowledge of

navigation unit design and operation than users of non‐safety critical units.    The Shuttle Program

considers a box to be failed more quickly than an aviation user. Engineering and Mission Control

personnel must have a thorough understanding of receiver operation and data.  For manned space flight,

lack of design insight is a safety issue.  Due to the anomalies that occurred on STS‐91, MAGR/S software

requirements, the integration guide and source code (originally developed at government expense) were

made available to the Shuttle Program.   A formal “questions for the vendor” list was maintained and

answers were recorded.

The STS‐91 incident revealed that the Shuttle computer software that interfaced with the MAGR/S was

designed with an inadequate understanding of MAGR/S operation.    The Shuttle software was later

modified to handle known and unknown receiver anomalies.  Expanded vendor involvement after STS‐

91 brought much needed design insight to the project, which greatly aided issue identification and

resolution.  In hindsight, some aspects of the MAGR/S interface and integration might have been done

differently if the vendor had been involved when the Shuttle computer software requirements to support

GPS were initially defined.

* John L. Goodman, Knowledge Capture and Management for Space Flight Systems, NASA Contractor Report

CR‐2005‐213692, October 2005.  Available at http://ntrs.nasa.gov/
42 of 118

Insight into test equipment design and operation is critical.  Like vendors of GPS receivers, vendors of

test equipment may not understand the applications that their equipment supports.   Many issues that

arose during MAGR/S ground testing concerned GPS signal generators.  These issues had an impact on

test results, cost, and schedule.  Insight into GPS signal generator design and operation was a challenge

throughout the project.

Impact of Design Insight on Science Missions

Little or inaccurate design insight can complicate or prevent the use of GPS data in support of GPS

technology demonstrations and scientific missions.    Examples of this include GPS technology

demonstration payloads flown on the Shuttle.  During the relative GPS experiments conducted on STS‐69

and STS‐80, lack of insight into the 3M, TurboStar, Tensor and Quadrex receivers made integration, data

processing and data analysis more difficult.    In addition, lack of insight into algorithms (particularly

those associated with clock steering) made development of the laptop based relative GPS navigation filter

more challenging [12‐15].  

Independent Verification And Validation

If it can be afforded, Independent Verification And Validation (IV&V) is a valuable part of a high risk or

safety critical project.  Verification is the determination of whether or not an item meets the requirements

set for it.   Validation is the determination of whether or not an item meets its intended purpose in its

operating environment.  Validation is particularly important when an item or new technology is to be

used in an operating environment that it was not originally designed for.    The trend to use non‐

developmental item avionics containing proprietary software may prevent IV&V of software in some

safety critical applications.  This is an issue for applications that involve human safety and unmanned

applications requiring a high degree of autonomy.  

IV&V of software requirements and source code may reveal issues that did not arise during lab and

flight‐testing.  Guidelines should be created governing the scope of the audit.  Issues should be examined

to determine if they represent credible failure scenarios.  

The NASA IV&V contractor played a significant role in the MAGR/S project [62‐66].    Initial IV&V

involvement focused on the integration architecture, ground test, and flight test results.  After MAGR/S

certification was postponed in the wake of the STS‐91 incident (1998) and MAGR/S software (originally

developed for the Department of Defense at government expense) was made available to the Shuttle

Program, IV&V performed an audit of the software starting in 1999.   IV&V personnel possessed prior

experience with the MAGR on aircraft integrations.    The IV&V contractor played a valuable role in

identifying, assessing the criticality of, and assisting with the resolution of software issues.  The audit was

invaluable in the certification process, but should have been conducted much earlier in the project.  

Several hundred issues, of varying degrees of severity, were identified and dispositioned through the

IV&V analysis of the MAGR/S requirements and software.
43 of 118

Orbit Determination Accuracy

While accuracy of COTS navigation units may be sufficient in some cases to support low accuracy space

flight requirements, Shuttle flights of these units indicate that they are not appropriate for future

applications with more demanding orbit determination needs.  

Formation flying, elimination of ground tracking and orbital replenishment (rendezvous, proximity

operations and docking) will place stringent demands on orbit determination and relative navigation

accuracy [67].  Software quality, hardware reliability and orbit determination accuracy requirements to

support these applications will be more demanding than the capabilities of current GPS units.  

Autonomous, on‐board, real time navigation, relative navigation and burn targeting requires investment

in spacecraft navigation systems that will differ from atmospheric flight navigation systems.

Velocity Accuracy Is Important

Targeting algorithms that compute precise orbital adjustments to support activities such as (but not

limited to) formation flying, rendezvous, proximity operations and docking/grapple need accurate

velocity as well as position.  Such algorithms have to predict vehicle state vectors into the future over a

period of time that may range from minutes to weeks.   Even small velocity errors can result in large

position and velocity errors after a prediction using high fidelity integrators and environment models.  

How well a navigation unit state vector predicts into the future is a key question that potential users of a

unit must ask and address during flight and lab test evaluation.

Orbital Semi-Major Axis

A metric used to evaluate how well a state vector will predict is the semi‐major axis [68] accuracy.  

Orbital semi‐major axis is a function of position, velocity and energy (1).  It is also related to the period of

the orbit (2).  

Relative semi‐major axis accuracy is a good parameter for judging the accuracy of a relative GPS

algorithm for formation flying and rendezvous applications.

A recent journal article addresses the importance of semi‐major axis accuracy and the need for realistic

correlation between position and velocity [23].    This article was written in response to the poor

navigation performance observed on Shuttle flights of off‐the‐shelf GPS receivers and EGIs.

E

a

2

2

1 2

μ

μ

− = ⎥

⎥

⎦

⎤

⎢

⎢

⎣

⎡

= −

−

v

r

r

r

μ

π

3

2 a T

P =

(1)

(2)
44 of 118

Most Space Navigation Conference Papers Do Not Address High Accuracy Orbit 

Determination

Some papers appearing in the literature advocate geometrical, kinematic type position‐determination

techniques using GPS data.  The advent of all‐in‐view receivers supports this trend.  Such algorithms take

advantage of continuous, high rate GPS measurements and the improved measurement geometry

compared to ground based radar tracking.    From a software perspective, these algorithms are more

straightforward since complex environment models (such as gravity and drag) are not used.  While the

position and time data resulting from kinematic positioning algorithms are very accurate and meet the

requirements of some missions, this solves only half the problem for other users.  

Many papers discuss a range of space applications of GPS and the high‐position accuracy it offers, but

pay little or no attention to the need for accurate velocity and semi‐major axis estimation.    Numerical

results of algorithms designed to improve spacecraft navigation accuracy are exclusively focused on

position accuracy, with no mention of velocity and semi‐major axis errors.    Challenges in spaceborne

applications of GPS are often detailed, such as:

• Widening the Doppler shift window.

• Installing an orbit propagator to facilitate reacquisition after a GPS outage.

• Multipath

• GPS satellite visibility as a function of spacecraft attitude.

• GPS satellite visibility to antennas on spinning spacecraft.

• Increased number of satellites visible on‐orbit.

• Satellite visibility and signal strength for geostationary satellite applications.

• Modifying legacy navigation algorithms to accommodate higher orbital altitudes and velocities.

However, the need to improve navigation and filtering algorithms to enhance velocity and semi‐major

axis accuracy is rarely mentioned.  Lack of orbital and relative semi‐major axis accuracy data, along with

position and velocity correlation data, make it difficult to evaluate the usefulness of relative GPS

navigation studies and algorithms published in the literature.  Such data is required to assess navigation

accuracy impacts on targeting and guidance algorithms and perform propellant budgeting.

Receiver Specifications

Receivers have specifications for expected position and velocity accuracy under the best tracking

conditions.  Even receivers designed for space lack a semi‐major axis specification.  This, coupled with

the proprietary nature of receiver software, makes it difficult for potential users to determine how

suitable a receiver may be for a space application.

Navigation units that are needed to support advanced concepts (formation flying, rendezvous,

autonomous operation, limited ground support and infrastructure) require navigation algorithms that

reflect orbital mechanics.    While it is true that position, velocity and orbital parameter accuracy

requirements vary from program to program, this should not be used to justify a lack of appropriate

navigation algorithm missionization.
45 of 118

COTS Box Outputs May Not Be Designed With Redundancy Management In 

Mind

Most aircraft and missiles use only one GPS receiver, stand‐alone Inertial Navigation System (INS) or

Embedded GPS/INS (EGI).  Some vehicles (Space Shuttle, ISS, X‐33, X‐38) were designed to use multiple

navigation units for redundancy.    Redundancy Management (RM) schemes perform checks on box

outputs, such as dynamic parameters (position, velocity, attitude, rotational rate and accumulated sensed

velocity) and health status parameters (Built‐In Test/Built‐In Test Equipment, BIT/BITE).  Most BIT/BITE

indicators and self‐tests were designed to help ground personnel determine if a suspect unit should be

returned to the depot for maintenance.

Use of BIT/BITE indicators in RM algorithms requires that the integrator understand what the health

status indicators mean and how indications of a problem can affect navigation unit performance.  Care

must be taken when determining which parameters to monitor for assessing unit health.  A title of what

the indicator is in an interface control document does not tell the integrator the potential impact the

annunciated condition has on box performance.  This makes it difficult for the integrator to determine

which BIT/BITE indications should be used in the RM algorithm.    The RM scheme should be robust

enough to identify and deselect a questionable unit but not deselect a good unit.  BIT/BITE indicators in

navigation units evolve over long periods and have a heritage going back decades to previous products.  

Particular indicators are often added to help address certain problems encountered.    Over the years,

corporate knowledge loss results in a manufacturer no longer knowing why a particular indicator is

present in the output or what its significance is.  Of particular importance are what values performance

indicators (such as Figure of Merit) are initialized to after a unit power cycle or re‐initialization.

Unlike aircraft, the Space Shuttle performs BIT on navigation units during flight.  Mission Control must

understand how to interpret negative results.   Does a certain failure indication from BIT always mean

that the unit should not be used?  Could the unit continue to be used for navigation with no degradation

in performance?  Nuisance indicators need to be identified and ignored.  A BITE masking capability is

particularly useful.

While redundancy management is important, it is not a substitute for well‐documented and fully verified

software.

Do Not Totally Rely On The Vendor For Navigation Expertise 

Vendors can provide valuable information on the design, integration, and use of their products.  

However, they may not always fully understand the applications where their products are used.  Users

and integrators must maintain navigation expertise to conduct testing, resolve issues, avoid “false pulls”

of healthy units that are assumed to be malfunctioning [69], determine how best to integrate a unit, and

provide management with advice on what navigation products are suitable for an upgrade.  Navigation

vendors, who are doing business in a highly competitive market, do not want skilled technical personnel

__
46 of 118

tied to one project for periods of years.  The use of a COTS navigation product should not lead one to

believe that technical expertise can be “bought” as a COTS product.

Vulnerability to Space Radiation

Each succeeding generation of electronic devices, such as GPS receivers, use smaller and smaller

electronic components.  This may make modern GPS receivers more susceptible to space radiation upsets

than the legacy receivers.  The higher susceptibility of new receivers to radiation makes use of GPS prior

to and during safety‐critical flight phases (such as deorbit) questionable.  A modern receiver may require

expensive modification to meet reliability requirements, or the required reliability may have to be

lowered.

The Challenge Of Autonomous, On-Board Navigation

Autonomous operation of spacecraft systems has long been a desire to reduce operations costs.  

However, such a requirement poses high reliability requirements on system components.  Software safety

is an important consideration in any aerospace system [9, 40, 57].

Rather than being viewed as off‐the‐shelf, plug‐and‐play units, GPS receivers are complex computers that

interact with other complex computers.     The GPS and host vehicle computer incidents on Discovery

(June 1998) and ISS (September 2002) illustrate that GPS receivers and host vehicle computer systems can

interact in a dysfunctional manner with results that are vehicle wide and not anticipated.  Even a GPS

receiver in non‐safety‐critical functions could threaten safety of flight by affecting safety critical systems

such as flight computers and communications systems.    Non‐safety‐critical receivers may require an

extensive testing and certification process for an autonomous application, or the host vehicle avionics

system must be robust enough to survive known and postulated dysfunctional interaction between

system components, and recover to a safe state.

Roadblocks to achieving on‐board navigation autonomy include on‐board system capacity, cost, schedule

and technical complexity.  Trade‐studies may have to be conducted to determine the level of autonomy

that is commensurate with maturity of the technology, on‐board system capacity, and available schedule

and budget.  If the available GPS receivers do not meet orbit determination requirements as built, the

chosen receiver will either have to be modified, or additional orbit determination software placed on the

spacecraft.  The orbit determination function may even have to be performed on the ground.

One example of a trade‐off between on‐board complexity and autonomy is the Swedish Space

Corporation Odin aeronomy satellite, which is equipped with two GPS receivers.  To reduce on‐board

complexity, it was decided to perform precision orbit determination on the ground using down linked

GPS data, rather than on the satellite. The receivers require periodic re‐initializations, and commands are

sent from the ground to accomplish this [70].
47 of 118

It is important to carefully assess the maturity of a technology, even if there is potential that the

technology could enable autonomy and reduce development, integration, and life cycle costs.  A proven,

but initially more expensive solution, may save money in the long run.

Navigation Conferences

Receiver reliability and robustness is seldom addressed at navigation conferences.  Reports on new GNSS

applications and integrations rarely highlight the more mundane process problems that were

encountered when implementing and using GNSS technology.  Problems with hardware and software

procurement, software quality, lack of information on receiver design and operation, poor

communication between project participants, poor vendor support, cost and schedule problems, test

equipment issues, and inaccurate documentation are rarely mentioned in papers or keynote speeches, but

are often discussed informally by technical personnel outside conference forums.  Vendor feedback to the

user community is often missing.  The tendency to avoid mentioning problems makes it difficult, if not

impossible, for GNSS integrators and users to learn how other users and integrators overcame process

challenges to bring a project to a successful conclusion.

Conference agendas should include lessons learned sessions that facilitate discussion among users and

integrators.  Best practices cannot be identified and communicated if problems and their solutions are not

discussed.    There should be a willingness to discuss negative aspects of projects, including project

failures, while sticking to the facts and not assigning blame to individuals or organizations.  A vendor

feedback session, featuring a panel of vendor representatives, may allow users and integrators to become

aware of common problems observed by vendors from having worked with a large customer base.  

Vendor comments should not be limited to perceived obstacles to selling their products.   Tutorials on

process engineering (i.e., software development, testing, certification, device selection, integration, project

management) as applied to the navigation industry may be helpful to conference participants.
48 of 118

This page intentionally left blank.
49 of 118

6. International Space Station

In 1993, GPS was chosen over star trackers for ISS attitude determination.  Although star trackers had a

high state of technology readiness, it was believed that use of GPS for attitude determination would

lower development and integration costs.  GPS position, velocity, and time would be used by the ISS as

well.  

ISS Space Integrated GPS/INS

The Space Integrated GPS/Inertial Navigation System (SIGI) was a project to develop a common

spacecraft navigator for both manned and unmanned vehicles [2, 3, 71].  The Force 19 GPS receiver in the

SIGI was specifically developed for the ISS application.   The Force 19 attitude determination software

was developed by NASA and furnished to the GPS vendor as Government Furnished Equipment (GFE).  

The ISS SIGI came equipped with a strapdown Inertial Measurement Unit, although at the time there was

no ISS requirement for the strapdown accelerometer and ring laser gyro data.  Blended filter data from

the SIGI is not used.    Two SIGI units are located in the U.S. laboratory module Destiny.    Four GPS

antennas, each equipped with choke rings for multi‐path mitigation, are at the corners of a 1.5 by 3 meter

rectangle on the S0 truss (Figures 1 and 2) [2].

A Kalman filter was implemented in the SIGI for position and velocity determination in the presence of

Selective Availability (SA).    However, the deactivation of SA and technical issues with the filter has

driven the ISS Program to rely on the deterministic position and velocity solution from the Force 19.  

One hundred foot long cables connect the antenna assemblies to the SIGI units.  Double differencing was

used to cancel out cable biases than could not be determined before the hardware was brought to the ISS.  

x

Figure 1 – One of the four ISS GPS antenna and choke 

ring assemblies prior to launch. The assembly is 10.81 

inches wide.

NASA
50 of 118

Most of the attitudes flown by the ISS do not allow the GPS antenna boresights to be pointed along the

zenith direction [72, 73].  ISS SIGIs are provided with antenna pointing information to facilitate satellite

acquisition.

Figure 2 - Close up of ISS GPS antenna array location. This photograph was taken on STS-111 

following undocking over western Kazakhstan on June 15, 2002. Endeavour was conducting a flyaround of the ISS. The docking port is pointed along the velocity vector.

Shuttle 

Docking 

Port

GPS Antenna 

Array on S0 

Truss

Two SIGIs Located in 

Earth US Lab Module

Earth

Shuttle 

Docking 

Port

Two SIGIs

In Destiny

Lab

Four GPS

Antennas

On S0 Truss

NASA
51 of 118

Ground Testing and Shuttle Test Flights of ISS SIGI

Lab Tests

An array of flight qualification tests were conducted in ground facilities, using both GPS signal

generators and live sky antenna arrays.  Complex mathematical models were developed and lab testing

performed in an attempt to subject the SIGI to the multi‐path rich ISS radio‐frequency environment [2,

74].  However, lab testing could not exactly duplicate the ISS radio‐frequency environment.

Flight Tests 

Attitude determination algorithms used in the ISS SIGI were first tested in a TANS Vector GPS receiver

flown on STS‐77 (Endeavour, May 1996, Table 3) as a part of the GPS Attitude and Navigation Experiment

(GANE) [75, 76].  The GANE hardware was mounted in the payload bay.  ISS SIGIs were flown for data

collection in the SIGI Orbital Attitude Readiness (SOAR) experiment on two Shuttle missions, STS‐101

(Atlantis, May 2000) and STS‐106 (Atlantis, September 2000) to test position, velocity and attitude

determination [77].  SOAR used much of the GANE hardware, and was also in the payload bay.  Star

trackers collocated with the SOAR hardware provided a check on Force 19 attitude determination.  While

these flights did provide valuable on‐orbit data, they could not subject the SIGI to the exact multi‐path

and signal obscuration environment later encountered on ISS.

SIGI Flight Experience on the ISS

The two SIGI units arrived at the ISS when the Destiny module was delivered on assembly flight 5A (STS‐

98, Atlantis, February 2001).  GPS become operational on ISS after the S0 truss was installed on assembly

flight 8A (STS‐110, Atlantis, April 2002).  Actual use on the ISS was the first time the ISS SIGI was used

during extended (longer than a Shuttle mission) flight.

Table 3 - Shuttle and Progress Missions Related to ISS SIGI

Mission

77

101 (2A.2a)

106 (2A.2b)

98 (5A)

110 (8A)

14P

15P

Spacecraft

Endeavour

Atlantis 

Atlantis 

Atlantis 

Atlantis

Progress M-49

Progress M-50

Year

1996 

2000 

2000 

2001 

2002 

2004 

2004 

ISS GPS Objective

GANE GPS attitude test

SOAR SIGI testing

SOAR SIGI testing

SIGI delivery to ISS

GPS antenna array delivery

Deliver new SIGI software

Deliver SIGI loader cable

Primary Mission Objectives

SPARTAN deploy/retrieve, SPACEHAB

ISS resupply and outfitting

ISS resupply and outfitting

Deliver Destiny lab module

Deliver S0 truss & Mobile Transporter

ISS replenishment. Docked 5/27/04

ISS replenishment. Docked 8/14/04
52 of 118

Use of GPS by ISS

Force 19 deterministic position and velocity data must pass quality assurance checks and a selection filter

before they are incorporated into the ISS computer navigation solution.  The Force 19 deterministic state

vector must meet an orbit determination accuracy requirement of no greater than 1,000‐foot three‐sigma

semi‐major axis error to support Ku Band antenna pointing to TDRSS satellites.   GPS attitude data is

filtered in an ISS computer along with rate gyro data (not from the SIGI) to determine an attitude solution

that meets the ISS 0.5‐degree 3 sigma per axis attitude accuracy requirement.  While the SIGI and the ISS

attitude control system have met requirements for attitude, position, velocity, and time determination

accuracy, numerous technical issues surfaced that impacted solution availability.  Most of the issues were

discovered after ISS SIGI operations began in April of 2002.  Identification and recovery from many of

these problems required Mission Control and astronaut/cosmonaut intervention, which added additional

work to already complex ground and crew timelines.

Impact of One Force 19 Issue

On September 22, 2002, and again on the following day, a Force 19 software error not recognized in

ground testing occurred that caused the SIGI to emit a type of output to the ISS Guidance, Navigation

and Control (GNC) software that was not anticipated by system integrators.  The output caused ISS GNC

computers to go into a diagnostic mode, which resulted in the mission impacts listed in Table 4.  It was

known and documented that the ISS computer could not handle the output in question, but during the

integration and test phase, no evidence was noted that any avionics would supply that type of output to

the ISS computers.    The SIGI units were turned off for several weeks, until a software patch was

developed and applied to the ISS GNC software.    The patch enabled ISS computers to handle the

spurious output without interrupting normal operation.  Subsequent emissions of the spurious output by

the SIGIs were correctly handled by the ISS computers with no ill effects.

Table 4 - Operational Impacts of SIGI Induced ISS Computer Crash

• Transfer of attitude control from the U.S. Segment control moment gyros to the Russian segment 

thruster system

• Contingency attitude control using valuable and carefully managed propellant supplies

• Labor intensive manual S band antenna pointing by MCC Houston to maintain data and voice 

communications

• Loss of Ku band data transmission capability

• Loss of micro-gravity environment due to attitude control thruster firings

• Loss of a crew day of science operations 
53 of 118

Solution Availability 

Another issue was limited solution availability.  Due to non‐optimal antenna pointing, signal obscuration,

and the rich multi‐path environment, the GPS attitude determination function frequently has to solve for

integer ambiguities in carrier phase. Up to an hour may be spent solving for the ambiguities, and the

receiver will not output a position and velocity during these periods, the time and duration of which are

not predictable.  This feature of the unit was known before use on‐board the ISS began, and was judged

not to be an impact to the ISS antenna‐pointing requirement.    However, it was an impact to ground

processing of Force 19 data, which will be discussed in the next section.  No requirement was levied on

the unit for the maximum acceptable position, velocity or attitude outage.  

ISS Spacecraft Position Optimal Tracking (SPOT) Filter

Why Filter GPS States?

There were no requirements for the Force 19 to perform precision ISS orbit determination.  Ground radar

tracking of the ISS is only performed by Mission Control Houston to support Shuttle rendezvous.   

Although coherent S‐Band TDRSS transponders are carried by the ISS, there are currently no plans to

process TDRSS Doppler from ISS in Mission Control, as is done for the Shuttle.  Historically, continuous

tracking of the ISS by U. S. Strategic Command was the source of ISS orbit data used for ISS debris

avoidance efforts and mission planning conducted by Mission Control Houston.    A Mission Control

based GPS ground filter (ISS SPOT), similar to the one developed for the Shuttle MAGR/S data, was

developed to process Force 19 deterministic state vectors to provide high accuracy orbit determination to

support collision avoidance, orbit maintenance, rendezvous planning, and to augment ground radar

tracking in support of Shuttle rendezvous.

Processing SIGI Flight Test Data

Force 19 deterministic state vector data from flights of the ISS and X‐38 SIGIs on Shuttle missions STS‐101

SOAR (Table 3, page 51) and STS‐108 (Table 1, page 21) were processed by the ISS SPOT filter during

development.  The flight data was useful in developing and tuning the filtering algorithms.  However,

these test flights did not provide insight into Force 19 performance in the radio‐frequency environment of

the ISS, nor was Force 19 data processed by ISS telemetry software.

ISS SIGI Data and SPOT

Once the SIGI units were in operation aboard the ISS, Force 19 data was processed by the developmental

version of the ISS SPOT filter.   While the filter successfully performed orbit determination to a higher

level of accuracy than the Force 19, data problems severely limited the time spans over which orbit

determination could be performed.    Frequent loss of integer ambiguity solutions prevented Force 19

output of position and velocity estimates.    Furthermore, much of the required data was not time

homogeneous.  Even if the Force 19 was computing position and velocity data, variations in ISS telemetry

x
54 of 118

format content and low SIGI data priorities prevented acquisition of the input required for the ISS SPOT

filter.   The frequent lack of Force 19 position and velocity vectors caused the SPOT filter to converge

much more slowly, or even prevented orbit determination from occurring in the first place.   Lack of a

suitable and unambiguously defined Force 19 solution quality indicator complicated processing of Force

19 data by SPOT.

Most of the ISS SPOT development effort focused on a pre‐processor to weed out unacceptable Force 19

data before it reached the orbit determination filter.  Development of the pre‐processor required extensive

analysis of SIGI data and complicated the software development process, resulting in schedule problems.  

ISS SPOT has been certified for flight use, and will provide improved orbit estimates for mission planning

after a flight‐following period in Mission Control.

SIGI Software and ISS Telemetry Changes

Since April of 2002, SIGI performance has been continually assessed, and modifications to Force 19

receiver and SIGI input/output software were identified, developed, tested, and flight qualified.    In

addition, a new set of attitude determination code was developed, tested, and flight qualified, which

resolved many performance issues.  Due to the grounding of the Shuttles following the Columbia accident,

the new SIGI software and a laptop‐to‐SIGI software loader cable were sent to the ISS on two Progress

flights (Table 3, page 51) launched from the Baikonur Cosmodrome.

New Attitude Determination Software 

The NASA SIGI team at the Johnson Space Center developed the new code, which is government owned

and maintained, whereas the original Force 19 attitude determination software was developed by a

different NASA organization and became proprietary after delivery to the receiver vendor. The new

attitude determination software used a different method of integer ambiguity resolution and attitude

determination, which significantly increased attitude solution availability.

In response to the software issues encountered with the original attitude determination code, the software

development and testing process for the new code was significantly different.  All attitude determination

code and associated software development and testing tools were placed under strict configuration

management.    Coding standards were followed, code audits were performed, and modules were

exhaustively tested on a workstation using both nominal and off‐nominal input data.  All lines of code

and software paths were tested.    Built‐in error words were placed in the code, which greatly aided

software anomaly analysis once the new attitude determination software was placed in the Force 19.  In

addition, all developmental software versions were meticulously documented and saved for future

reference.  The software and test cases were completely documented, and the theoretical development of

and assumptions inherent in the new attitude determination algorithm were thoroughly documented.  

Since the new software is not vendor proprietary, NASA JSC SIGI and associated ISS contractor

personnel have complete access to requirements, source code and theoretical development

documentation.  This greatly aids verification and anomaly investigation efforts.
55 of 118

Initialization data was placed in the new attitude determination software to lower the amount of work

required by Mission Control personnel to recover the SIGI after a power cycle.  The capability to adjust

additional attitude determination algorithm parameters from Mission Control was also added.  Solution

of carrier phase integer ambiguities was decoupled from position and velocity determination, which

resolved the extended position and velocity outage issue.

New SIGI and Force 19 Software

Both the SIGI and Force 19 vendors resolved software and performance issues not associated with the

attitude determination function.    To improve ISS re‐boost maneuver monitoring and post‐burn orbit

determination by Mission Control Centers in Moscow and Houston, the SIGI and ISS GNC software has

been modified so that integrated acceleration from the SIGI strapdown IMUs can be incorporated into the

ISS GNC processing and downlisted to the ground.

ISS Telemetry Changes 

ISS SPOT developers identified several problems in Force 19 data that were due to ISS telemetry format

and content.  Several changes were made to telemetry requirements to ensure that the ISS SPOT input

data would be grouped together in the same data packets, were time homogenous, and would be present

in the telemetry stream when needed.

Other GPS Receivers On The ISS

For completeness, it should be pointed out that there are other GPS receivers on the ISS, which were not

test flown on the Space Shuttle.  Two ASN‐2401 navigation systems, containing ASN‐22 GPS/GLONASS

GPS cards, are in the Russian built Zvezda Service Module [78].   They supply navigation data for the

Russian segment of ISS.  Two Laben Tensor units will also be carried on the European built Automated   

Transfer Vehicle (ATV) to support automated rendezvous, in conjunction with the ASN‐2401 units on the

Service Module.   The ASN‐2401 units will be upgraded to support relative navigation before the ATV

flight operations begin.  Two SIGIs will be on the Japanese Experiment Module (JEM) and three on the

Japanese Transfer Vehicle (HTV) to support rendezvous.  The SIGIs contain Trimble Force 5 GPS cards.
56 of 118

This page intentionally left blank.
57 of 118

7. The Space Shuttle and GPS

In the 1970s, the Space Shuttle was designed with three TACAN units for use during the entry phase of

flight.  By the late 1970s, with the NAVSTAR GPS program promising a revolution in navigation, the use

of GPS on the Shuttle orbiters was studied [79].  The orbiters Discovery, Atlantis and Endeavour were all

manufactured in the 1980s with GPS antennae and associated wiring.  However, due to budget concerns

and the developmental nature of GPS, a GPS upgrade to the Shuttle system was not pursued.

Table 5 - Planned TACAN Phase-Out 

From The Federal Radionavigation Plan

Publication Date

1990

June 1993

May 1995

July 1997

December 1999

March 2002

?

Planned Start of 

TACAN Phase-Out

2000

2000

2000

2005

2008

2010

?

FRP

1990

1992

1994

1996

1999

2001

2005a

a The 2005 Federal Radionavigation Plan was 

not available at the time of publication. A

2003 Plan was not published.

In 1990, the introduction of GPS had led the

Department of Defense and the Federal Aviation

Administration to plan the phase out of TACAN

ground stations beginning in the year 2000 (Table 5).  

GPS promised better performance than TACAN and

reduced operating costs.    In response, then Shuttle

Program Manager (and former astronaut) Robert

Crippen initiated an effort to study the possibility of

replacing the three TACAN units on each orbiter

with three GPS receivers (Figure 3).

Figure 3 - Eventual phase-out of TACAN ground stations led NASA to 

upgrade a proven and highly successful Shuttle navigation system.
58 of 118

By 1996, the development of Embedded GPS/INS (or EGI) units employing strapdown inertial sensors

[80] motivated the Shuttle program to look at an eventual replacement of the previously mentioned stand

alone GPS (the TACAN replacement) and stable member, spinning mass gyro Kearfott High Accuracy

Inertial Navigation Systems (HAINS) Inertial Measurement Units (IMUs) with EGIs.    The use of

strapdown IMUs employing ring laser gyro (RLG) technology was identified as a potential source of cost

and schedule savings during orbiter pre‐launch processing.  

Both the TACAN replacement and GPS/IMU replacement efforts were conducted in parallel.    Studies

were performed to determine the best integration architecture.  Stand‐alone GPS units and EGIs had to be

integrated in a manner that did not compromise the integrity of an operational, certified navigation

system.   Once it was decided to tailor the GPS receiver requirements to TACAN replacement, studies

were conducted to determine if there were other applications for GPS during Shuttle flights.

Changes to the Shuttle General Purpose Computers (GPCs) to support both projects were identified.  GPS

and EGI hardware was selected; interface, software and hardware changes were identified and made.  

Both types of units were flown on a series of Shuttle missions for test and evaluation.  Modifications were

made to GPS and EGI software based on flight test results.

Overview Of Space Shuttle Navigation System

Navigation requirements for manned spacecraft are different than those for terrestrial aircraft, unmanned

Earth orbiting satellites and interplanetary probes [81, 82].  The guidance, navigation and flight control

system had to be designed to ensure safety of flight and mission success for ascent, orbit, rendezvous and

gliding entry to a runway landing in the presence of system failures.  For ascent and entry, a total of five

computers, running in parallel, can control the vehicle.    Four of the GPCs run what is known as the

Primary Flight Software Sub‐system (PASS) software.    The fifth runs Backup Flight Software (BFS).  

Different contractors coded PASS and BFS software.  The BFS contains a subset of the PASS functionality

to enable the vehicle to finish nominal ascent, an abort or landing in the event of a generic PASS software

failure.  While on orbit, only PASS software provides guidance, navigation and flight control functions.  

Multiple navigation sensors, command paths and power buses within the avionics system ensure

redundancy [83, 84].  Navigation sensors used in the “pre GPS era” are depicted in Table 6.

For HAINS IMUs, TACANs, barometric altimeters and MLS units, redundant measurements are passed

through Fault Detection, Identification and Reconfiguration (FDIR) algorithms [85].  Selection filters then

process data from units deemed to be good.    Selected measurements are then passed to the Shuttle

navigation software.  HAINS IMU data is used during all flight phases for attitude and sensed velocity

determination.    During entry, PASS and BFS Kalman filters process selected TACAN, IMU derived

altitude and barometric altimeter measurements.  Only the PASS Kalman filter processes selected MLS

data.  Selected radar altimeter data is provided for crew situational awareness, but is not incorporated

into the navigation solution.  
59 of 118

Ascent

• Three High Accuracy

Inertial Navigation

System Inertial 

Measurement Units

(HAINS IMUs)

• Ground based C & S

Band radar tracking 

• Three HAINS IMUs

• Two Star Trackers

• One Ku band

rendezvous radar

• One Crew Optical

Alignment Sight

(COAS)

• One Trajectory 

Control Sensor 

(TCS, a laser)

Entry

• Three HAINS IMUs

• Three TACANs

• Four Barometric

Altimeters

• Three Ku Band

Microwave Landing

System (MLS)

Receivers (on-board) 

plus ground equipment

• Two Radar Altimeters

• Ground based C & S

Band radar tracking.

• At least two TACAN

ground stations. 

• Two Hand Held 

Lasers (HHL)

• Two payload bay

television cameras 

with ranging ruler 

overlays

• Ground based C band

radar tracking

• Tracking And Data 

Relay Satellite 

System (TDRSS)

• S Band Doppler 

tracking 

Orbit and Rendezvous

Table 6 - Legacy Space Shuttle navigation sensors. GPS supplements TACAN in the “single string”

(one GPS) configuration. “Three string” GPS (three receivers) will replace the three TACAN units.

During rendezvous, a PASS Kalman filter processes on‐board radar, star tracker and Crew Optical

Alignment Sight (COAS) measurements.  TCS and HHL data are processed in Kalman filters residing in a

laptop computer for crew situational awareness.    Television monitors with ranging ruler overlays

provide range information to the crew during docking. The angle subtended by the target in the COAS is

also a back‐up source of range data.

Integrating GPS In A Loosely Coupled Architecture

A loosely coupled architecture using cascaded filters is a common way of upgrading existing navigation

systems with GPS.  This method of integration has been used on platforms such as the F‐16 [86], F‐117

[87], Conventional Air Launched Cruise Missile [88] and B‐2 [89].  

A cascaded filter approach involves using the position output of the GPS receiver as a measurement for a

Kalman filter in the host vehicle navigation system [86].  Position and velocity aiding data from the host

vehicle INS are fed back to the GPS receiver to improve signal acquisition and tracking performance.

However, the Kalman filter is derived under the assumption that measurements are not time correlated.  

This assumption is violated by processing the GPS position vector in the host vehicle Kalman filter.  Time

correlated measurements can lead to filter instability.    This problem has been avoided in many

applications by processing GPS position vectors at a low rate, such as no higher than every 15 seconds

[88].
60 of 118

One option considered was to process GPS position vectors as measurements in the PASS and BFS

Kalman filters, as is done in many military applications.

Another option studied was to convert GPS position into a TACAN measurement (known as “TACAN

transparency”).  This was an attempt to minimize or avoid changes to the PASS and BFS flight software

and input/output.    This would have resulted in a high rate cascaded filter implementation (TACAN

measurements are processed every 3.84 seconds).   A “transparent” approach would not have allowed

INS aiding to be supplied to the receiver from the GPC.  Crew displays required GPS receiver specific

controls and quality assessments, and GPS data needed to be sent to Mission Control for the flight

controllers.  For on‐orbit processing, a new Kalman filter would have to be created.  On‐orbit processing

of “pseudo TACAN” measurements could only have been performed within the line‐of‐sight of the

TACAN stations already in the flight software to support landing.

Neither of the loosely coupled, cascaded filter options were acceptable to the Shuttle Program.  

Processing GPS as a TACAN measurement or filtering the GPS position vector could not have been

evaluated in flight without actually incorporating the data into the navigation state.  Both of these options

would have required retuning the entry navigation Kalman filters in the PASS and BFS flight software.  A

new PASS flight software Kalman filter for the orbital phase of flight would have to be created.   Any

modifications to the existing filters for entry, or a new Kalman filter for orbit, would result in an extensive

flight software development and certification effort.

The Tightly Coupled Option

In a tightly coupled integration, processing actual GPS measurements (pseudorange, delta range) from a

GPS receiver in a host vehicle computer permits the navigation system designer to have more control

over the quality of the navigation solution, rather than having to rely on a receiver vendor’s proprietary

software.    Processing high rate, unfiltered GPS observables and inertial measurement unit data in a

central Kalman filter permits higher accuracy navigation and less vulnerability to GPS outages and

jamming.    This architecture enables rapid estimation of GPS receiver clock errors and inertial

measurement unit errors [86].  

Processing of GPS pseudoranges in the PASS and BFS flight software was also considered, but not

chosen.  Like the cascaded filter options discussed previously, it would have required modifications to

baseline entry navigation and a new Kalman filter for the on‐orbit phase.    Furthermore, there were

security concerns with sending corrected pseudoranges outside the keyed GPS receiver to the Shuttle

GPCs.  Uncorrected pseudoranges could be processed in the GPCs, but the entry and new orbit Kalman

filters would have to solve for the corruption due to Selective Availability.
61 of 118

State Replacement Chosen

After considering eight integration options, the Shuttle Program directed that GPS be integrated “in

parallel” with the existing baseline navigation on the orbiters.    A GPS state (position and velocity)

selected by the Shuttle flight software would overwrite the Shuttle flight software navigation state. “State

replacement” in the Shuttle navigation software was chosen over treating GPS as a sensor and filtering

the GPS measurements or state vector.  This architecture treats the GPS receiver as a complete navigation

system [1].  Any potential problems with cascaded Kalman filters would be avoided.  State replacement

could be implemented so that the same GPC flight software could be used for GPS processing during

both orbit and entry.    This was essentially the same integration architecture called for in a 1980 GPS

upgrade proposal for the Shuttle.

The Shuttle operates in a demanding flight environment with little margin for error. Shuttle software and

hardware undergo an extensive test and validation process. Technical issues that arise before or during a

flight can easily disrupt complex flight preparation schedules that span a period of years. The state

replacement architecture lowered potential impact on the existing Shuttle navigation software, flight

schedules and operations. GPS integration engineers also had to work within cost and schedule

constraints and a desire to minimize hardware modifications to the vehicles.

The integration architecture also allowed GPS receiver and Shuttle flight software GPS data collection to

occur in the flight environment before certification, while still using the proven legacy navigation aids

and Shuttle computer navigation algorithms [1].  This also permits operation of a “mixed fleet” of GPS

and TACAN hardware configurations with the same version of PASS and BFS flight software.  Due to the

schedule of orbiter overhaul periods, not all orbiters would be equipped with GPS units at the same time.  

Supported TACAN/GPS configurations are (Figure 4):

• Three TACANs for operational use and one GPS receiver (single string GPS) for data gathering (test

flights) or operational use.

• Three GPS units for operational use and no TACANs (three string GPS).

• Three TACANs and no GPS unit onboard.

It was believed that this approach would also make it easier to upgrade the Shuttle with more advanced

receivers, whereas the Kalman filtering of GPS measurements or vectors in the Shuttle GPCs might

require retuning the filters in the GPC.  Furthermore, if a receiver upgrade occurred, it was believed that

this approach would eliminate the need for detailed knowledge of the GPS receiver’s software.  

The GPS receivers are provided with position, velocity and attitude aiding from the Shuttle flight

software  (PASS, or BFS in the event of a PASS software failure).  One aiding state vector is propagated

for all three receivers, using selected IMU data from candidates that have been screened by a FDIR

algorithm.  The single aiding state is periodically reset with the Shuttle navigation state.
62 of 118

The PASS flight software subjects GPS state vectors to three Quality Assurance (QA) checks.   The QA

tests were designed so that retuning of the receiver Kalman filter, or changes to receiver residual edit tests

would not be necessary for the Shuttle missionization.

• A check of several receiver parameters, one of which is the Figure of Merit (FOM).  

• The current GPS state is compared with the receiver’s previous state propagated to the current time.  

• Comparison of the receiver states with each other.  

If criteria for any of the QA tests are violated, that receiver’s state is not a candidate for selection.  State

vectors from candidate GPS units are then processed in a selection filter.  The BFS flight software uses a

xx

FIGURE 4 - In the “single string” configuration, TACAN and GPS data may be processed 

concurrently. Microwave Landing System data takes priority over TACAN, GPS and 

barometric altimeter data.

“Single String” GPS Configuration

Shuttle

Computer

GPS Position

And Velocity

TACAN

Inertial

Measurement

Unit

Barometric

Altimeter

Aiding Data

Altitude

Range

And Bearing

Sensed Velocity

And Attitude Data

Microwave

Landing

System

Range,

Azimuth & 

Elevation

GPS 

Receiver

“Three String” GPS Configuration

Shuttle

Computer

GPS Position

And Velocity

Inertial

Measurement

Unit

Barometric

Altimeter

Aiding Data

Altitude

Sensed Velocity

And Attitude Data

Microwave

Landing

System

Range,

Azimuth & 

Elevation

GPS 

Receiver
63 of 118

simpler QA and selection scheme than PASS.  There are crew controls that allow these QA tests to be

bypassed, if necessary.

Once the QA checks are complete and a GPS state has been selected, there are two crew commanded

methods for incorporating the selected GPS state into navigation.    The first involves automatic

incorporation at a flight phase dependent rate, if the selected GPS state is within a tolerance of the current

navigation state.    The second method, called a “force,” ignores the comparison test with the current

navigation state and incorporates (forces) the selected GPS state into navigation.

Six years of test flights (1996 to 2002) have proven that the state replacement architecture was the right

choice. State replacement permitted the shuttle computers to conduct GPS QA tests and exercise the

selection filter without using GPS as a primary source of navigation data. It also allowed the team to

avoid modifying the legacy entry navigation Kalman filter, which has proven itself over 21 years (1981 to

2002) of operation. The Shuttle Program was able to fly one set of Shuttle software, regardless of the

TACAN and GPS hardware configuration, for as long as was needed, without committing to use GPS

operationally.

State replacement also enabled Mission Control to perform real‐time comparisons of the selected GPS

vector with the Shuttle navigation state, without incorporating GPS data into baseline navigation. This

additional insight will help assess the health of the onboard and ground‐based legacy navigation systems

and resolve dilemmas between legacy sensors. Had the team chosen the cascaded filter architecture, it

could have performed this assessment only in post flight simulations that processed selected position

vectors in the onboard entry Kalman filter.

Receiver Selection

During the early to mid 1990s, use of Commercial/Modified‐Off‐The‐Shelf hardware and software, and

the “faster‐better‐cheaper” approach, were being stressed within NASA [90].    Use of an off‐the‐shelf

receiver, and the success of GPS technology, was seen by some as the key to a quick, low cost Shuttle

upgrade.  For TACAN replacement, the Shuttle Program desired an off‐the‐shelf, in production military

unit designed for aircraft to take advantage of the existing production line and logistics base.  The Shuttle

Program also desired to be an authorized user of GPS, to take advantage of the jamming and spoofing

____

MAGR

Enters

Production

For Military

All-In-View 

Receivers 

Available

Originally 

Planned First 

Three String 

Flight

Original TACAN

Phase-Out Start

Year

1994 1996 1998 2000 2002 2004

2000

2005

2008

2010

2015

Figure 5 - Receiver Selection Driven By Year 2000 Need Date Planned TACAN Phase-Out Start

First 

MAGR

Flight on 

Shuttle

resistance provided by military GPS

units.   In addition, the Shuttle Program

wanted to benefit from software that

had been matured through development

and use by the Department of Defense.

A 1993 trade study selected a 5‐channel

aviation GPS receiver, the Miniaturized

Airborne GPS Receiver (MAGR), which

_
64 of 118

entered production in 1994 [91].    All‐in‐view military aviation receivers of this type did not become

available until the late 1990s (Figure 5). The receiver tracking loops were digital, rather than analogue,

and could be modified to obtain measurements and download data at orbital velocities through software

changes, rather than through changes to discrete electronic components, as was required with earlier

receivers.  The MAGR had several desirable capabilities, including authorized operation and the ability to

accept inertial aiding data from an Inertial Navigation System (INS).   A change to the receiver power

supply and input/output electronics card was required to make the receiver compatible with the orbiter

power system and data bus.  Radiation testing of the receiver at the Indiana University Cyclotron Facility

indicated that no hardware changes were required to meet radiation exposure requirements.

Existing space rated GPS receivers were not suitable for the Shuttle (i.e. didn’t accept inertial aiding from

an INS, too big and heavy for the Shuttle, not capable of authorized operation).

GPS Antennas

Each GPS receiver uses two antennas (Figures 6 and 7), which are mounted under the Shuttle thermal

protection system, which does not significantly attenuate the GPS signal.  The antennas provide direct

visibility of satellites in any attitude while on‐orbit or during entry. The signal from each antenna is

amplified by a pre‐amplifier, then is passed to a signal combiner to provide one input to the receiver.  

Antenna switching is not conducted.

The single string MAGR/S flown during the test phase has two antennas, one on the top and one on the

bottom of the crew compartment (GPS 2 in Figure 6).   Antennas and cables used for the single‐string

configuration were actually installed in the Shuttles Discovery, Atlantis, and Endeavour when they were

built in the 1980s.  For the three‐string configuration (Figure 6), antennas for GPS units 1 and 3 occupy the

former positions of TACAN antennas (Figure 7).

Initial Flight Tests And Receiver Missionization

The first flight of a GPS receiver on the Shuttle was on mission STS‐51 in September of 1993 [92].   A

Trimble TANS Quadrex was flown.  This experiment was not a part of the TACAN replacement project.  

The Quadrex was mounted in an overhead window on the flight deck.  Signal attenuation from the glass

and limited field of view severely impacted receiver performance.

The initial flight test program supporting TACAN replacement involved the 5 channel, Collins 3M

receiver.   The 3M was a pre‐production version of the Collins MAGR.    This series of flight tests was

intended to prove if a GPS receiver designed for terrestrial aircraft use could function on the Space

Shuttle with a minimum number of software changes.
65 of 118

GPS 2 

GPS 1 GPS 3 

GPS 1 

GPS 2

GPS 3 

GPS 2 

GPS 2 

GPS 1

GPS 3

Figure 6 – Three string GPS antenna configuration of Endeavour, circa 2005.

GPS 2 

GPS 2 

TACAN 1

TACAN 1

Figure 7 – Three string TACAN and single string GPS antenna configuration 

of Atlantis and Discovery, circa 2005. 

GPS 2 

GPS 2 

TACAN 3 TACAN 1 

TACAN 1 

TACAN 3

TACAN 2

TACAN 2 

INS aiding was supplied to the 3M by the BFS GPC during ascent and entry, while on‐orbit the receiver

was unaided and operated by a laptop computer.    Receiver state vectors and other 3M data were

recorded on the laptop.  The 3M was not keyed.  Since the purpose of the 3M flight tests was purely data

gathering, no navigation data was sent from the 3M receiver to the BFS GPC.  The Collins 3M unit flew

seven times (December, 1993 to May, 1996) on Endeavor (flights 61, 59, 68, 67, 69, 72 and 77) (Table 1, page

21, and Table 7, page 66).  Modifications were made to the 3M software between flights based on flight

test results.

Hardware and software missionization of the Collins production MAGR for TACAN replacement began

in 1995.    The version of the MAGR flown on the Shuttle is known as the MAGR/S (MAGR/Shuttle).  

Collins based MAGR/S software on military MAGR Link 008, with Link 009 and 010 modifications also

included.  Lessons learned from the 3M flights were also incorporated into the MAGR/S software.
66 of 118

“Single String” Tacan Replacement Flight Tests

A single MAGR/S unit (the “single string” configuration, one MAGR/S and three TACAN units) was

flown on each orbiter during the flight test and certification program for data collection (Table 7, Figure

7).  

On many flights, a laptop computer was used to record instrumentation port data, in addition to receiver

data normally transmitted to Mission Control during a mission.    This data greatly enhanced vendor

efforts to track down and resolve complex software issues in the GPS receiver. After every flight, the GPS

team examined fault logs.

MAGR/S data was available in “real time” to Mission Control personnel during ascent and entry.  More

flights followed as each orbiter in the fleet was equipped with a single MAGR/S receiver.  STS‐91 in June

of 1998 was the first flight during which GPS data was available “in real time” to Mission Control

personnel during the orbital phase of flight.  By the flight of Columbia on STS‐109 in 2002, all four orbiters

were flying with one MAGR/S receiver each, in the single string configuration.

From STS‐79 (September 1996) to STS‐107 (January/February 2003), the Shuttle Program has accumulated

~7,000 hours of MAGR nominal performance operating time from launch through landing.    In

comparison, ~100 hours of TACAN nominal performance operating time have been accumulated from

Mach 10 through landing from STS‐1 (April 1981) through STS‐113 (November/December 2002).

Shuttle Missions

61 

59, 68

67, 69

72, 77

79

81, 82, 84, 85

89, 88

91, 95

96, 103

101, 106 

92

99, 97

98, 104

102, 105

100, 108

110, 112

109

111, 113

107

114

GPS

Receiver

3M

MAGR/S

Year

1993

1994

1995

1996

1996

1997

1998

1999

2000

2001

2002

2003

2005

Orbiter

Endeavour

Endeavour

Endeavour

Endeavour

Endeavour

Endeavour

Endeavour

Discovery

Discovery

Atlantis

Discovery

Endeavour

Atlantis

Discovery

Endeavour

Atlantis

Columbia

Endeavour

Columbia

Discovery

Table 7 - Shuttle GPS Test Flights For TACAN Replacement
67 of 118

GPS Tests

Detailed Test Objectives (DTOs) were carried out during the single string flights.  These tests involved

astronaut execution of MAGR/S procedures.  Selected MAGR/S state vectors were incorporated into the

PASS and BFS flight software on several occasions while on orbit.  On STS‐103 (December 1999, before

the deactivation of Selective Availability), the MAGR/S was intentionally unkeyed prior to entry.   The

Shuttle is certified to land with the MAGR/S unkeyed.   Another DTO involved a late power‐on of the

MAGR/S just prior to entry on STS‐92 (October 2000).  This tested the ability of the MAGR/S to collect

ephemerides, download the daily key and establish four satellite navigation during entry.

Pre-Launch Ephemeris Collection

The launch pad multi‐path environment, obscuration of the lower antenna by the external tank, and non‐

optimal pointing of the upper antenna (boresight at the horizon) made pre‐launch ephemeris collection

difficult.  This became a serious concern, as GPS may be required to support an emergency landing soon

after launch.    Simulation studies indicated that four hours were needed to collect GPS satellite

ephemerides that would be needed for an emergency landing in Europe or North Africa.    As GPS is

powered on about five hours prior to launch, no changes were needed in the pre‐launch time line.

The team did not consider loading the receiver with ephemerides before liftoff using a data port and

laptop computer. It would have been difficult to fit such a procedure into an already‐crowded pre‐launch

timeline, and would have required orbiter hardware modifications to permit easy access to the GPS

receiver from the crew compartment and an ephemeris verification procedure.

Ascent Performance Results

For most of ascent, the Shuttle is in a heads down configuration.  The GPS antenna on top of the crew

compartment is facing the Earth, while the antenna below the crew compartment is facing the External

Tank.  In spite of the poor antenna visibility, enough GPS signals wrap around the External Tank and

orbiter to permit the MAGR/S to track three to four satellites most of the time.  However, the Geometric

Dilution Of Precision (GDOP) is high, which can result in large state errors.  On most flights, a roll to a

heads up attitude is performed at about 6 minutes into the flight.  This provides excellent GPS satellite

visibility to the antenna on top of the crew compartment.  Receiver tracking and performance during this

phase of ascent is usually exceptional.

On-Orbit Performance Results

While on‐orbit, noisy GPS velocity incidents (Figure 8) occurred that are consistent with the spatial (near

the geomagnetic equator) and temporal (early evening to early morning) characteristics of ionospheric

scintillation (Figure 9).    Analysis has indicated that the velocity anomaly is induced by ionospheric

scintillation of the phase of the GPS signals, which manifests in the delta‐range measurements.  Velocity

noise as high as 11 feet per second has been observed and noise periods have lasted up to 20 minutes.  

Velocity noise was judged not to be a constraint for operational use of GPS by the Shuttle [93, 94].
68 of 118

Mission Elapsed Time (days:hours:minutes)

6:15:30 6:15:50 6:16:10 6:16:30 6:16:50 6:17:10 6:17:30 6:17:50 6:18:10 6:18:30 6:18:50 6:19:10

Altitude Velocity Difference

Down-Track Velocity Difference

Cross-Track Velocity Difference

Feet/Second Feet/Second Feet/Second

Figure 8 - Comparison of GPS velocity with Shuttle on-board navigation velocity, illustrating ionospheric scintillation 

induced velocity noise periods on three consecutive orbits. Bias is due to error in Shuttle on-board navigation state.

latitude -15.5o

longitude -34.1o

8:40 pm local

latitude -7.6 o

longitude -51.7o

9:55 pm local

latitude 6.6o

longitude -65.1o

11:32 pm local

STS-88 GPS Velocity Noise (December 1998)

On‐orbit, GPS vectors did not permit orbit determination as accurate as that obtained with Mission

Control processing of TDRSS and ground radar tracking data.  This was expected, as the MAGR/S unit

was not modified to support high accuracy orbit determination.    Multi‐path and upper antenna

obscuration that occurs while the Shuttle is docked to the ISS degrades receiver performance, but it does

not pose an operational impact.  MAGR/S radiation testing conducted in 1997 indicated that no hardware

modifications were required.    To date, no on‐orbit anomalies have occurred that could be traced to

radiation effects.

Entry Performance Results

Receiver performance during the “blackout” or “plasma” region of entry was a concern (Figure 10).  

However, flights since 1993 have indicated that an inertially aided, five‐channel receiver can track from

one to five satellites during plasma, and a true “blackout” of GPS signals rarely occurs.  Frequent loss of

lock and reacquisition occur, along with less than optimal GPS satellite geometry.  GPS state vector errors

x
69 of 118

FIGURE 9 - Geographic distribution of ionospheric scintillation induced delta range noise for STS-99 

(February 2000), during the solar maximum. The geomagnetic equator and dip angle contours for ± 15 

and ± 45 degrees are indicated.

during this period were not excessive.  Lower antenna tracking can be impacted by plasma as high as

320,000 feet, and the lower antenna may not resume continuous tracking until about 185,000 feet.  The

most severe plasma period impacts the upper antenna, and typically begins around 285,000, when the

first roll maneuver occurs.  Continuous upper antenna tracking of satellites typically resumes between

220,000 feet and 200,000 feet.

The impacts of the plasma region on the MAGR/S are extended periods of less than four satellite tracking,

failed reacquisition attempts, incomplete data collection (i.e. ephemerides) and loss of delta range

measurements.  Less than optimum number of measurements and poor satellite geometry could result in

an increasingly inaccurate GPS state vector.  However, navigation errors during the plasma region have

so far not been excessive.  The orbiter can fly through this region without an update from GPS.

Roll maneuvers during entry outside the plasma region had little or no impact on receiver performance.

Figure 11 depicts legacy entry navigation and selected GPS average ±3 sigma position differences using a

post‐flight Best Estimate of Trajectory (BET) as the reference. The BET process blends Shuttle on‐board

data (IMU, MLS) with ground radar tracking, but does not include GPS data (GPS may be more accurate

than the BET). Legacy navigation data is from 49 recent Shuttle flights, while the GPS data used was from

x
70 of 118

Figure of Merit

Geometric Dilution of Precision

Less Than Four Satellite Tracking

Altitude (Thousands of Feet)

STS-110 Entry (April 2002)

Figure 10 - Receiver data from an altitude of 400,000 feet through landing. Figure of Merit (FOM) is the 

receiver’s estimate of it’s position accuracy. The Shuttle computers will not use GPS data if the FOM is 6 or 

greater. Geometric Dilution of Precision (GDOP) indicates how well the satellite geometry will enable the 

receiver to resolve navigation errors. The Less Than Four Satellite Tracking bit is “1” if less than four 

satellites are tracked. The plasma region for this flight was roughly from 260,000 feet to 210,000 feet. On 

most flights, FOM and GDOP typically have low values from the end of the plasma region through landing.

12 single‐string GPS test flights. The legacy navigation system, even at the 3‐sigma level, is well within

guidance constraints for maximum allowable navigation error. GPS is considerably more accurate than

the legacy entry navigation system. The 3‐sigma keyed receiver accuracy specifications for position are 31

meters horizontal and 36 meters vertical. The 3‐sigma velocity specification is 0.1 meters/second in both

the horizontal and vertical directions.  
71 of 118

Shuttle Software Changes 

Flight data from the MAGR/S as well as the GPC QA checks are examined both during and after

missions.  Flight tests and simulation results have driven changes to the MAGR/S software and PASS and

BFS flight software that processes MAGR/S data.

Flight experience also drove a change to the position and velocity vector‐aiding scheme used by the PASS

flight software.   The original design involved propagation of a separate aiding state for each receiver,

xxxx

Cross-Track

Altitude (kilo-feet)

Altitude (kilo-feet)

Altitude (kilo-feet)

Down-Track

Altitude

Feet Feet Feet

Legacy Nav System

Selected GPS

Maximum Allowable Nav Error

Figure 11 - Average ± 3-sigma position differences for entry legacy navigation and selected GPS using a post-flight 

Best Estimate of Trajectory (BET) as the reference. The BET includes ground radar and on-board (IMU and MLS) 

data, but does not include GPS data. Ground radar tracking begins between 160,000 and 150,000 feet, while MLS 

data processing begins around 17,000 feet. The gradual decrease in the BET versus GPS differences (particularly 

noticeable in down-track) is due to deceleration sensed by the IMUs, which improves BET accuracy. The plasma 

region (~270 to ~220 kilo-feet) has little impact on receiver accuracy. Guidance constraints (heavy lines) represent 

the maximum navigation error under which guidance can still fly the Shuttle to a runway. 

Legacy Nav Selected GPS

Legacy Nav Selected GPS

Legacy Nav Selected GPS

Drag Baro

TACAN

TACAN

MLS

MLS
72 of 118

with each propagator having an independent source of IMU data (i.e. an IMU is assigned to each

receiver).  Instead, one aiding state vector is propagated for all three receivers, using selected IMU data

from candidates that have been screened by a FDIR algorithm.    Instead of periodically resetting the

aiding states with each receiver’s own GPS state, the single aiding state is periodically reset with the

Shuttle navigation state.   The original design did not perform a sanity check on the GPS states used to

reset the aiding states in the PASS flight software.    Resetting the single aiding state with the Shuttle

navigation state takes advantage of protection provided by the GPS QA checks, the GPS state selection

process and the comparison of the selected GPS state with the current navigation state before GPS

incorporation.  The new aiding scheme also permits the ground to have more insight into and control

over the position and velocity aiding states sent to the receivers.

GPS Availability

The five channel MAGR/S uses four channels to obtain navigation measurements, and a fifth for

ephemeris collection and satellite acquisition.  New satellites needed to maintain track of an optimal set

of four are acquired sequentially.  Under difficult tracking conditions (multi‐path, antenna obscuration,

satellite line‐of‐sight off of the antenna gain pattern), multiple satellite switches could fail or be delayed,

resulting in less than optimal satellite geometry or less than four satellite tracking for extended periods of

time.    The receiverʹs estimate of its position accuracy could exceed a Shuttle computer GPS quality

assurance test limit, which would prevent the Shuttle computers from using position and velocity data

from that receiver.  A lack of GPS updates during entry could make it difficult for the Shuttle to reach the

runway [84].  

The Shuttle GPS team conducted an extensive simulation campaign using a GPS receiver, two GPS signal

generators (one for each antenna, upper and lower), and Shuttle entry trajectories, to determine whether

the GPS receiver could experience a loss‐of‐service for longer than 2.3 minutes between an altitude of

140,000 feet and touchdown on the runway. A failure of any of the tests to meet the loss‐of‐service limit

would have necessitated changes to the receiver to lower the probability of loss of service.  Simulation

results indicated that such changes were not required.

Status of Shuttle TACAN Replacement

Delay in Certification

The original flight of three string GPS (no TACANs) was planned for 1999.  However, due to the number

of GPS software issues encountered during flight and ground testing, and a slip in the TACAN

decommissioning date (Figure 5, page 63, and Table 5, page 57), certification of Shuttle GPS for

operational use was delayed by three years, from 1999 to 2002.  Additional receiver software versions,

laboratory test campaigns and Shuttle test flights were scheduled.    The project was reorganized to

enhance communication between project participants, and to improve identification, documentation and

resolution of issues.  The NASA independent verification and validation contractor audited the MAGR/S

software, which had been developed at government expense.   By March of 2002, all four orbiters had

flown with one MAGR/S receiver installed for data collection, and for use in contingencies defined in

Shuttle Program flight rules.
73 of 118

Certification Status

The MAGR/S and associated Shuttle computer software was certified for TACAN replacement in August

of 2002, over three years after the original target date.  Uses for the single MAGR/S receiver configuration

(Figures 4 and 6), in conjunction with TACAN, on each orbiter were identified, and the receiver and

associated Shuttle computer software was certified for these applications in December of 2002.  

TACAN Replacement on Endeavour

On October 23, 2003, the Shuttle Program approved the removal of the three TACAN units from

Endeavour, and the installation of two additional MAGR/S receivers, bringing Endeavour to the three‐

string GPS configuration (Figure 4, page 62, and Figure 6, page 65). Once Shuttle flights resume, a ramp‐

up of increasing single string GPS use on Discovery and Atlantis in conjunction with TACAN will be

performed (Figure 7).    These flights will lead to Endeavour flying the first all GPS, no TACAN flight,

which is expected to occur in 2006.

GPS On Discovery and Atlantis

Both Discovery and Atlantis are equipped with one GPS receiver and three TACAN units (Figure 4, page

62, and Figure 7, page 65). During entry, GPS data will be incorporated into the primary and backup

flight computers simultaneously with TACAN data.    Since the TACAN phase‐out initiation date has

slipped to 2010 (2001 Federal Radionavigation Plan), TACAN availability is not considered to be a

problem.    Contingent upon Shuttle Program direction, one or both of the orbiters may have their

TACANs removed and two MAGR/S receivers added as they cycle through the periodic Orbiter Major

Modification activity.

Mission Control And On-Board, Operational Use Of GPS By Flight Phase

The following sections give an overview of the current Shuttle navigation methodology.   How GPS states

will be used by the orbiter navigation system and Mission Control after MAGR/S certification is covered.  

Pre GPS Ground Tracking

Initially, the Shuttle Program required continuous tracking from 2 radars during ascent and entry, so that

Mission Control could determine the Shuttle state independently of the on‐board navigation system.  As

confidence was established in the on‐board system, the ascent/entry ground tracking requirement was

changed from mandatory to highly desirable.  

Prior to launch, if there are certain failures on the vehicle, radar tracking to support navigation is

required to meet Launch Constraint Criteria.   C Band (range and angles) and S Band (range, Doppler,

angles) radar data is processed in a Mission Control based Kalman filter.  The filter can process data from

one S Band and two C Band radars.
74 of 118

If the Shuttle is to rendezvous with a spacecraft already in orbit (a “ground up rendezvous,” such as with

the International Space Station or Hubble Space Telescope), Mission Control checks the cross track

velocity error after Main Engine Cut Off.   A state vector update may be required prior to the OMS‐2

maneuver for cross‐track velocity error greater than 6 feet/second.  The uplink would be based on ascent

ground tracking data processing.

Initially, S Band communication sites provided tracking (range, Doppler, angles) during the orbital phase

of flight, when the orbiter was visible.  As TDRSS satellites were launched, ground S Band use for orbit

was reduced.  When available, TDRSS provides near global communications coverage, but only Doppler

measurements due to the type of S Band transponder on the orbiter.

On‐orbit, both S Band TDRSS Doppler measurements; and C Band radar data (range and angles from a

number of tracking stations) are processed to estimate the orbiter’s state vector.  The on‐board navigation

state is usually allowed to grow in down‐track position error before a new state, based on radar and

TDRSS tracking, is uplinked.   For landing, the maximum allowable downtrack position error at Entry

Interface (400,000 feet) is 20 nautical miles.

TDRSS S Band Doppler tracking provides a good estimate of the orbital semi‐major axis (which reflects

both position and velocity).  C Band tracking resolves planar errors.  Radar geometry plays a large role in

determining the accuracy of ground‐based navigation.  On‐orbit, a weighted least squares algorithm is

used by Mission Control for orbit determination.

Ground‐up rendezvous flights require radar tracking of the target spacecraft.  Radar tracking begins from

18 to 24 hours prior to Shuttle launch.    Ground tracking of the target spacecraft continues through

docking (ISS) or grapple (Hubble Space Telescope).  If the orbiter deploys a scientific payload that is to be

retrieved later in the mission, ground tracking of the deployed spacecraft will be performed to facilitate

the rendezvous and grapple.

For entry and landing, Mission Control processes radar data in the previously mentioned Kalman filter

for independent assessment of onboard navigation systems.  Since Shuttle landings are planned for the

Kennedy Space Center (KSC), and radars are located there to support the Eastern Test Range, C Band and

S Band radar tracking is usually available.    C Band tracking is also usually available for landings at

Edwards Air Force Base, since NASA has radars at the Dryden facility.  However, range scheduling can

prevent entry tracking.  If there are certain failures in the on‐board or ground navigation systems, radar

tracking during entry becomes mandatory.  

During entry, radar normally becomes available in time for Mission Control to assess the TACAN units

and navigation state health prior to TACAN processing in the GPCs.  Mission Control can also perform

an emergency state uplink to the orbiter if navigation errors are excessive.
75 of 118

Post GPS Ground Tracking

After GPS certification, the Shuttle Program still considers radar tracking during ascent to be desirable,

but not required, unless there are navigation equipment failures on the vehicle.

Radar and TDRSS tracking will still be used during the orbital phase to support maneuver planning in

Mission Control.  The MAGR/S Kalman filter has not been tuned for orbital dynamics, since emphasis

was on a TACAN replacement and a Commercial‐Off‐The‐Shelf approach that minimized MAGR/S

modifications.  

Shuttle Spacecraft Position Optimal Tracking (SPOT) Filter 

The MAGR Kalman filter and navigation algorithms were designed so that the unit could be integrated

into a wide variety of atmospheric flight platforms without having to substantially modify the navigation

algorithms to support specific integrations [95].  Filter tuning assumes a worst case inertial measurement

unit and receiver clock.  The downside to this approach is that the receiver is not optimized for space

navigation.    It effectively provides a blended deterministic solution without accurate gravity or drag

modeling needed for accurate orbit determination. The performance of these algorithms is sufficient to

support TACAN replacement and Shuttle deorbit burns.  

However, MAGR/S velocity errors, and the resulting semi‐major axis errors, render the receiver incapable

of performing the high accuracy orbit determination currently performed with ground radar and TDRSS

tracking to support post‐insertion orbit assessment, orbit maneuver planning, debris avoidance analysis,

and rendezvous.  Poor orbital navigation performance of GPS receivers originally designed for terrestrial

use and the importance of semi‐major axis accuracy is covered by Carpenter and Schiesser [23].  

Although the MAGR/S was modified by the Shuttle Program to improve velocity accuracy on‐orbit, the

improvement was insufficient to facilitate precision orbit determination.

To take advantage of the near continuous availability of GPS state vectors from the Shuttle, a Mission

Control based filter, called Shuttle SPOT, was developed (Figure 12).  Shuttle SPOT processes MAGR/S

state vector data to provide an improved estimate of the orbit. MAGR/S data from Shuttle missions 88,

96, 99, 106 and 108 was used to tune and certify the filter.  Although a few technical issues arose, these

were resolved and the development and certification of SPOT for the Shuttle was relatively

straightforward.   The filter will be certified for use after a flight following and evaluation phase over

several Shuttle missions.

Near continuous availability of ground filtered GPS state vectors, in conjunction with radar and TDRSS

tracking, will allow more responsive mission planning.  Burns will be confirmed more rapidly than with

radar and TDRSS data alone.  If the orbiter is subjected to perturbations that are not modeled by Mission

Control, it can take 2 or 3 revolutions before enough ground and TDRSS tracking data is available to

quantify the impact on the orbiter state.  SPOT will permit much more rapid perturbation determination.
76 of 118

Ground radar tracking will be used on no‐TACAN flights as a backup to GPS.  TDRSS is also used for

telemetry and communications, thus the Doppler measurements will always be available for processing.  

However, radar and TDRSS will still be designated as backups to GPS, and Mission Control Center

personnel will maintain proficiency in C Band and S Band measurement processing.

Pre-GPS Ascent And Post Insertion

Navigation aids (TACANs, barometric altimeters, MLSs, radar altimeters) that would be used for an

emergency landing due to an ascent abort are powered on and self tests are run prior to the day of

launch.    The three HAINS IMUs are calibrated and aligned before liftoff.    Only HAINS IMU data

(accumulated sensed velocity, gimbal angles) are processed by PASS and BFS navigation during powered

flight [96].  No sensor measurements are processed by an on‐board Kalman filter.

Ascent And Post Insertion In The GPS Era

There is no change to the Shuttle baseline navigation (use of HAINS IMU data) for powered flight.  The

MAGR/S units will be turned on approximately 5 hours prior to liftoff.  This permits receivers to collect

ephemerides of satellites that will be over the Trans Atlantic Landing (TAL) sites at launch.  GPS states

___

Figure 12 - GPS vectors filtered by Mission Control will be used to 

support shuttle maneuver planning and debris avoidance.
77 of 118

are not used by the Shuttle navigation software during powered flight, but receiver aiding data is

supplied to the MAGR/S units by the GPCs.

After the GPS SPOT Filter is certified, it could be used as a source of post Main Engine Cut Off state

vector uplinks.  GPS vectors from the on‐board MAGR/S units would not be incorporated directly into

navigation.

GPS Metric Tracking For Range Safety

The Shuttle Program examined the use of GPS for Space Shuttle range safety metric tracking during

launch, to replace radars at the launch site.  Radar replacement would have required the addition of GPS

receivers, cables and antennas to the Solid Rocket Boosters and External Tank.    The orbiter GPS

receiver(s) could not be used as a source of range safety data, as they receive aiding data from the orbiter

avionics system and therefore are not an independent source of state vectors.  Even with a switch to GPS

metric tracking, C band radars would still be needed to support Space Shuttle operations.  Radar tracking

is highly desirable to support launch and emergency landings at the launch site soon after launch, to

backup the Shuttleʹs onboard navigation system.   Radar tracking is mandatory for landing if there are

navigation unit failures on the vehicle, and radar is needed to support orbit determination for

rendezvous flights.  In October of 2001, the Shuttle Program decided against a transition to GPS metric

tracking for Space Shuttle range safety, as GPS metric tracking integration costs exceeded ownership and

maintenance costs of launch site radars.

Pre-GPS Orbit Coast Navigation

During the orbit phase, the on‐board navigation state is monitored and maintained by Mission Control

via state vector uplinks.  A vent force may also be uplinked by Mission Control for use by the GPCs.  This

takes into account non‐propulsive forces acting on the orbiter that cannot be detected by the HAINS

IMUs, and reduces error growth in the on‐board state.  Vent values are based on flight history for specific

orbiter attitudes.  The orbiter state (and for a rendezvous, the target spacecraft state) determined from C

Band and S Band tracking are used by Mission Control for maneuver planning.

Alignment of the HAINS IMUs is periodically performed using star sightings [97].   Two star trackers

with near orthogonal lines of sight are located on the nose of the orbiters.  Data from star sightings can

also be used by Mission Control to determine IMU gyro biases.  The ground determined biases are then

uplinked for use in the Shuttle PASS flight software.  If the orbiter cannot maneuver to a star sighting

attitude due to excessive IMU misalignment, a rough alignment can be executed by a crew member

sighting on a star using the Heads Up Display (HUD) or the COAS. This would be followed by a precise

star alignment using the star trackers.

Orbit Coast Navigation In The GPS Era

Current plans call for two of the three MAGR/S receivers to be powered off for most of the orbit period.  

MAGR/S state vectors will periodically be taken into the PASS flight software to maintain the on‐board

___
78 of 118

navigation state accuracy at an acceptable level.  Ground and TDRSS tracking will remain the primary

source of state vectors for maneuver planning in Mission Control, until the GPS SPOT Filter is certified.

There is no provision for GPS attitude determination in the MAGR/S.  Star sightings will still be used for

precise HAINS IMU alignment.

Pre GPS Rendezvous

Successful rendezvous requires an accurate relative state for on‐board burn targeting and target track

attitude maintenance.  Relative velocity errors, in particular, are critical. However, ground tracking of the

orbiter and the target spacecraft is not accurate enough to guarantee a safe rendezvous within the

orbiter’s tight propellant budget.  An on‐board navigation system that provides an accurate relative state

is required.

Shuttle rendezvous is divided into two phases, ground targeted and on‐board targeted.  For the ground‐

targeted phase, the orbiter navigation state is determined by ground based radar and TDRSS tracking as

described previously.  Burns to be executed by the orbiter are computed by Mission Control (hence the

term “ground targeted”) and uplinked to the vehicle for execution by the crew.  The last ground targeted

burn is performed on the day of rendezvous, 40 nautical miles behind the target, at about orbital noon.  

During the on‐board targeted phase (Figure 13), relative sensor measurements are processed in a Kalman

filter in the PASS flight software [98].  The PASS software maintains an estimate of the target spacecraft

state (initially provided by Mission Control) and the filtered orbiter state in an inertial frame.    These

states are used to compute burn solutions using an onboard Lambert targeting algorithm [99].  

The star trackers used for IMU alignments are also used to process angular measurements of the

orbiter/target relative state.  This permits resolution of navigation errors normal to the star tracker line of

sight.  The star tracker pass begins shortly after the last ground‐targeted maneuver, and will resolve most

altitude and out‐of‐plane position errors.  Due to change in relative geometry, some down‐track position

error will be resolved at the end of the star tracker pass.   The end of the pass roughly coincides with

orbital sunset, and is followed by the first on‐board targeted maneuver.

Incorporation of Ku Band radar measurements begins at a range of 135,000 feet.  Range, range rate and

angular data are obtained from this point until a range of about 100 feet.  Five more on‐board targeted

burns are executed to control the orbiter’s approach to the target spacecraft.

At a range of approximately 8 nautical miles, there is another opportunity for a daylight star tracker pass,

in the event of a radar failure.  Due to the size and brightness of the ISS, optical tracking during orbital

daylight may not be possible for this pass.  A tracking light on the ISS facilitates processing of star tracker

data at night.   The ISS maneuvers to a night star tracker attitude at a predetermined time during the

rendezvous.    Such a failure occurred on STS‐92 (October 2000), forcing execution of an “angles only”

rendezvous.    The rendezvous and docking was successful, but with slightly higher propellant

consumption.
79 of 118

1. NC, last ground

targeted burn.

2. Start star tracker

3. End star tracker

4. NCC, first on-board

targeted burn. 

5. Start Radar

6. Ti Burn

7. Start star tracker

(for radar fail) 

8. MC-1 Burn

9. Sunset

10. End star tracker

for radar fail.

11. MC-2 Burn

12. Sunrise

13. MC-3 Burn

14. MC-4 Burn

15. Manual piloting

phase using radar, 

phase using radar, 

TCS & HHL.

+V Bar

+R Bar

40

30

20

-50 -100 -150 -200 -250

10

15

-10 -20 -30 -40 -50

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

Figure 13 - Day of rendezvous profile with burns and navigation activities indicated. Relative 

coordinate frame centered on the target spacecraft. “V Bar” is in the direction of target motion, 

“R Bar” is in the direction of the center of the Earth. 

10

10

15

- 10 - 20 -30 -40 50

6

7

8

9

10

11

12

13

14

15

Axes are in kilo-feet

NCC - Corrective Combination

Ti - Transition initiation

MC - Midcourse Correction

If both the radar and star trackers are failed, the COAS may be used manually by the crew to obtain

relative angular measurements.   COAS measurements have never been taken in flight due to a sensor

failure.    However, after the undocking from Mir on STS‐71 (Atlantis, June‐July 1995), COAS data was

processed as a test.

After the final on‐board targeted burn, at a range of about 2,000 feet, the manual piloting phase begins.  

Radar data continues to be incorporated into the orbiter navigation state during the manual phase, but

the primary source of relative navigation data for piloting comes from the Trajectory Control Sensor

(TCS).  TCS is a laser system mounted in the payload bay that provides relative range, range rate and

angular information.  TCS requires retro‐reflectors on the target vehicle.  Two Hand Held Laser (HHL)

range finders are also carried.  Both TCS and HHL can lock on to the target as far out as 5,000 feet.

A Kalman filter is used in the primary and backup laptop computers to process TCS measurements.  

HHL measurements are processed in the primary laptop, in a different Kalman filter than TCS.  

Television cameras in the payload bay, with ranging ruler overlays on the monitors, are used by the crew

as an additional range information source from 15 feet to docking.   Ku Band radar, TCS and HHL are

also used during undocking and fly‐around, when the orbiter leaves the ISS.
80 of 118

Shuttle Rendezvous In The GPS Era

Even if both spacecraft have GPS units, simple subtraction of state vectors does not provide an accurate

enough relative state for use in burn computation.    Use of such data could easily result in an unsafe

trajectory and an undesirable level of propellant consumption.

Development of the on‐board rendezvous navigation system for Apollo [99, 100] (on which the Shuttle

system was based) proved that rendezvous could be accomplished with high inertial state errors on both

vehicles, but low relative state errors [101].    High accuracy inertial states on both spacecraft are not

enough to permit accurate rendezvous navigation.

If GPS relative navigation were to be used for spacecraft rendezvous, identical GPS receivers on the target

and chaser vehicles would be required.  Processing of common satellite measurements from both vehicles

in one Kalman filter permits the cancellation of common errors and biases (such as ionospheric error and

Selective Availability) [102].  This in turn drives the need for a radio data link between the vehicles.  

The Space Shuttle Program had to preserve the capability to rendezvous with spacecraft that are not

equipped with GPS units, such as the Hubble Space Telescope.  The current suite of on‐board, relative

navigation sensors (radar, star trackers, lasers) provide relative states that are just as good as or better

than the level of accuracy possible with relative GPS.

Furthermore, the International Space Station requirements for GPS were limited to coarse orbit

determination to support pointing of antennas to the TDRSS satellites.  Obscuration of GPS signals by ISS

structure and multi‐path would pose a significant problem for relative GPS in close proximity to the

station.  The Shuttle Program currently has no plans to use relative GPS for rendezvous.  

Pre-GPS Deorbit

Currently, a state vector uplink is performed prior to the deorbit burn to both the PASS and BFS flight

software.  This uplink is based on Mission Control processing of ground radar C Band and TDRSS S Band

data.

Deorbit In The GPS Era

The current operations concept calls for the three MAGR/S units to be operating 6 hours prior to the

deorbit burn.  Selected MAGR/S data will be incorporated into the Shuttle navigation software prior to

the burn, replacing the uplink from Mission Control.  As with ascent and orbit insertion, MAGR/S data

will not be incorporated into navigation during powered flight.

Pre-GPS Entry Navigation

For most of entry, three independent navigation states are maintained in the PASS [103].    Each uses

accumulated, sensed velocity data from a different IMU to protect against IMU failures.  A selection filter

_
81 of 118

selects one navigation state (position and velocity) for use in the Kalman filter.  It is also passed on to

guidance, flight control and crew display functions.

The first navigation filter measurement to be processed is called “drag altitude.” Measurement

incorporation begins when the IMU sensed deceleration is greater than 11 ft/sec2 (Figure 14).  

Accumulated sensed delta velocity data from the IMUs are used to estimate atmospheric density.  A math

model of the atmosphere then provides a rough estimate of altitude.   Drag altitude measurements are

rather inaccurate, but are intended to bound error growth in the event of other navigation system

failures.

Kalman filter processing of selected TACAN range and bearing measurements begins at a range no

greater than 400 nautical miles from the runway and an altitude of roughly 140,000 feet (for a nominal

entry and landing).  TACAN bearing is not processed when the elevation angle of the slant range is 35

degrees or greater (cone of confusion).

Significant navigation errors during entry can exceed the ability of the guidance and flight control system

to fly the orbiter to the landing site.  A set of limits, called guidance constraints, defines the maximum

allowable state error.  In the event of a navigation error that exceeds the constraints, a correction to the

state vector can be uplinked directly to the PASS and BFS flight software or voiced to the crew for manual

entry.  The “delta state update,” which is based on radar tracking data, has never been executed in flight.

~ ~

Mach Number

18

14

10

6

4

2

1

22

0

25

~~

Altitude (Kilo-feet) 160

140

120

100

80

60

40

20

200

220

240

180

0

400

~

Range To Runway (Nautical Miles) 350

200

150

100

60

30

20

10

800

1200

1800

500

0

4300

~

GPS

Drag

Alt. = 82.5 kft.

Or Until Baro

Ground

Tracking

(Radar)

Alt. = 1500 ft.

TACAN

Radar

Altimeter

Baro

M = 2.5

M = 1.6

M = 1.1

Alt. = 500 ft.

MLS

Probes Deploy

M = 5

Calibrated at M = 3.5

Lock On

Drag = 11 ft./sec

Data Available

For Navigation

Data Used If

No MLS

Not Used

Figure 14 - Availability of navigation sensors and systems during entry. BFS does not process 

MLS, but processes TACAN and Baro all the way to landing. Radar altimeter data is for crew 

situational awareness only. Ground tracking (radar) data is used by Mission Control for 

independent assessment of onboard navigation systems. 
82 of 118

Barometric altimeter measurements are processed to control navigation errors in the vertical channel.  

Two barometric altimeter probes are deployed at Mach 5, and data becomes available for Mission Control

evaluation at Mach 3.5.  Each probe provides two independent measurements. Kalman filter processing

begins at Mach 2.5 and an altitude of about 85,000 feet.  Drag altitude processing ends once barometric

altimeter processing begins.  Barometric altimeter processing is inhibited between Mach 1.6 and Mach 1.1

(the Mach jump region).

PASS Kalman filter processing of MLS range, azimuth and elevation data usually begins at about 17,000

feet.   Once MLS is acquired, PASS stops processing TACAN and barometric altimeter data and shifts

from maintaining three state vectors to one state vector.  For a landing site not equipped with MLS, PASS

processing of TACAN stops at an altitude of 1,500 feet, and baro processing continues until 500 feet.  BFS

does not process MLS, and will process TACAN and baro data all the way to landing.

Selected radar altimeter data is available to the crew for situational awareness from 5,000 feet until

landing.  It is not processed in a Kalman filter, due to a lack of accurate terrain models for Shuttle landing

sites.

Emergency Use Of Uncertified, Single String GPS During Entry

During the flight test phase (prior to the August 2002 certification, only one MAGR/S on each orbiter),

flight rules were developed permitting use of selected MAGR/S state vectors under the following

emergency conditions:

• Use in place of a voice delta state uplink during entry.    Complexity of the voice delta state uplink

makes it more risky than incorporating uncertified GPS data.

• Avoid scenarios (low ceilings at landing, on‐board and/or ground station TACAN and MLS failures)

that could result in a high‐risk crew bailout and loss of vehicle.

• Enable Mission Control to resolve dilemmas between redundant navigation sensors (HAINS IMUs,

barometric altimeters, TACANs, MLSs).  This does not require incorporating GPS states into the Shuttle

navigation software (Figure 15).

During training simulations, Mission Control training supervisors regularly fail various systems on the

Shuttle to train flight controllers on anomaly recognition, resolution, and procedural work‐arounds.

Failing a navigation sensor involves either presenting the Shuttle computers with erroneous data that

prevents them from using the sensor or simply turning off the unit. Simulation experience in Mission

Control has proven that a single functioning GPS receiver greatly aids flight controllers in identifying and

isolating suspect legacy navigation units. Regularly failing the GPS receiver prevents flight controllers

from becoming too dependent on GPS for anomaly identification and resolution.
83 of 118

Entry Navigation In The GPS Era

For the first several operational flights, selected MAGR/S data will not be taken into the Shuttle

navigation software between the deorbit burn and the acquisition of ground radar tracking (around

140,000 feet, the TACAN acquisition altitude).    This will permit a comparison of MAGR/S data with

ground tracking before incorporation.  Once operational experience with the three string system has been

obtained, navigation system updates with GPS will resume after the deorbit burn and continue through

MLS acquisition (or landing if MLS is not available).  However, selected MAGR/S states do not have to be

continuously incorporated into Shuttle navigation to support entry and landing.  

Drag altitude measurements will still be processed to bound error growth in the event of GPS outages or

IMU failures.  It is expected that drag measurements will have little impact on the navigation state when

GPS is incorporated in the automatic mode.

Space Shuttle navigation software will continue to process barometric altimeter and MLS data (in the

PASS) after TACAN has been replaced by GPS.  Whenever selected barometric altimeter measurements

are available for processing by the PASS and BFS GPCs, they will also be processed by the MAGR/S

Kalman filter.  This allows the GPS units to determine the bias on the barometric measurements during

four satellite tracking.   In the event of less than four satellite tracking, calibrated barometric altimeter

measurements will help maintain accurate MAGR/S states.

GPS states will be an important source of data for Mission Control during emergency landings at sites

where there is no ground radar tracking capability.

Figure 15 - The Shuttle GPS single string (one GPS receiver) configuration greatly 

aids detection and isolation of suspect legacy navigation sensors by Mission Control.
84 of 118

During entry, Mission Control in Houston will have an open line to the GPS Master Control Station

(MCS) at Schriever Air Force Base, Colorado.    Mission Control will be informed of any GPS satellite

integrity issues that arise.  The crew has the ability to command the MAGR/S units not to track specified

GPS satellites for measurements.

Single-String GPS Use After Certification

The single GPS receivers on Discovery and Atlantis will be used as a navigation source during entry, but

TACAN data will continue to be processed.   This will enhance safety of flight and provide crew and

Mission Control personnel with operational experience and confidence building in GPS before the use of

three string GPS on Endeavour.    Post certification, single string use of GPS during entry has been

proposed as follows:

• Those scenarios listed under emergency use of uncertified, single‐string GPS.

• Use as an extra level of redundancy in case of TACAN navigation sensor and/or ground station failures

(TACAN, radar).

• Provide redundancy in the event of ground radar tracking station failures.

• Avoid early mission termination due to TACAN failures while on‐orbit.

• Source of vectors to support emergency deorbit.

• On‐board navigation updates on‐orbit, when not performing translational maneuvers or rendezvous.

• Permit a launch in the event of a navigation aid (TACAN, barometric altimeter, MLS) failure on the

pad.

The single‐string configuration also provides additional protection when using TACAN stations of

questionable calibration at emergency landing sites. TACAN stations used by the Shuttle for landings at

the Kennedy Space Center, Edwards Air Force Base, and Northrup Strip (New Mexico) are calibrated to

tighter NASA standards.  Emergency landings at other sites, in the United States and around the world,

require use of TACAN stations that have been calibrated to standards that are not as tight. Single‐string

GPS will provide more accurate navigation at these sites than TACAN, and it is the technique that

Mission Control prefers. TACAN will still be available in the event the Shuttle computers cannot use

single‐string GPS data.

Operational Ramp-Up to Single String Use During Entry

The operational ramp‐up to use of single string GPS during entry will occur over five flights starting after

the return to flight (Discovery, STS‐114, July‐August 2005).    The point on each flight at which GPS

incorporation will begin is defined:
85 of 118

1. GPS to BFS after radar acquisition (~140,000 feet, ~ Mach 6).

2. GPS to the BFS after the deorbit burn.

3. GPS to PASS after radar acquisition (~140,000 feet, ~ Mach 6).

4. GPS to PASS after the deorbit burn.

5. GPS to PASS and BFS after the deorbit burn.

Operational ramp‐up for single string use should be complete before the first flight of three‐string GPS

(no TACAN) on Endeavour.

Differential GPS and the Space Shuttle

Although the MAGR/S does have a differential GPS capability, there are currently no plans to replace

MLS with differential GPS.  Use of a MAGR/S to perform differential GPS, and replace the Microwave

Landing System, was discussed, but not pursued due to the continued viability of MLS, and the difficulty

of using the five‐channel receiver to support the differential application. Studies have shown that

differential GPS would provide little accuracy improvement over the current MLS system.

A differential GPS capability would have required adding Very High Frequency (VHF) antennas to the

orbiters, with adequate visibility to support landing, as is done with TACAN antennas.  After TACAN

replacement, the GPS antenna pairs would occupy two of the positions formerly occupied by TACAN

antenna pairs.  There are technical issues with placing omni‐directional VHF antennas under the thermal

protection tiles in spots formerly occupied by Ku Band MLS antennas. New antenna positions and

associated holes in the orbiter structure for cabling would have been required for the VHF antennas.  

Drilling more holes in the vehicle for antenna placement is not desirable.  
86 of 118

This page intentionally left blank.
87 of 118

8. Other GPS Receivers On The Space Shuttle

Several civilian GPS receivers have flown in the Shuttle payload bay in support of experiments and on

deployed payloads (Table 1, page 21).   

Relative GPS Demonstrations

Perhaps the most notable were relative GPS navigation experiments conducted on two Shuttle missions

that deployed and retrieved scientific payloads.  These experiments were intended to investigate the use

of GPS for spacecraft rendezvous.  One was conducted jointly with the European Space Agency as a risk

mitigation effort in support of the Automated Transfer Vehicle under development for the ISS Program.  

Flight results may be of importance to future development of relative GPS filters for rendezvous and

formation flying.

On STS‐69 (Endeavour, September 1995) [12, 14, 15] the Wake Shield Facility (WSF) free flyer had an Allen

Osborne TurboStar GPS receiver.  The orbiter Endeavour was equipped with the Collins five channel 3M.  

The Orbiting Retrievable Far and Extreme Ultraviolet Spectrometer Shuttle Pallet Satellite (ORFEUS‐

SPAS) payload deployed and later retrieved on STS‐80 (Columbia, November‐December 1996) was

equipped with Laben Tensor (nine channel) and Actel GPS receivers [13].   The source of orbiter data

during STS‐80 was a Trimble Advanced Navigation System (TANS) Quadrex (six channel) receiver.  

GPS pseudorange data from receivers on the deployed payloads and the orbiters were processed in

laptop computers on the Shuttle during the flight, and on the ground both during and post‐flight.  The

laptops contained Kalman filters that provided a relative navigation solution.

During the STS‐69 test, poor satellite visibility resulted in few periods where both receivers were tracking

a set of four common satellites needed for accurate relative navigation.  Although a power supply failure

in the TurboStar prevented relative navigation during the rendezvous, data was available from other

periods of WSF activity.  Lessons learned from STS‐69 data processing were applied to the STS‐80 relative

navigation experiment development [15].

On STS‐80, the SPAS attitude during the approach of the Shuttle was controlled so that GPS antennas on

both vehicles would see the same satellites.    This helped facilitate common tracking of at least four

satellites.    In‐flight and initial post‐flight results were less than satisfactory due to issues involving

receiver clock drift, frequent acceleration from Shuttle jet firings, unmodeled acceleration compensation,

residual edit thresholds and an error in the antenna to center of gravity offset computation.    Better

performance was obtained after the relative filter and measurement processing was modified after the

mission [13].    Relative position accuracy was comparable to Shuttle on‐board relative navigation

performance, but the relative velocity performance was poor compared to the Shuttle.    Processing of

carrier phase measurements would have improved relative GPS velocity.
88 of 118

Lack of insight into the 3M, TurboStar, Tensor and Quadrex GPS receivers made integration, data

processing and data analysis more difficult.    In addition, lack of insight into algorithms (particularly

those associated with clock steering) made development of the laptop based relative GPS navigation filter

more challenging.  

Scientific Payload Support

The flight of Endeavour on STS‐99 in February of 2000 carried the Shuttle Radar Topography Mission

(SRTM) payload.  Two Blackjack receivers (which were originally designed for space applications) on the

payload provided GPS data to be processed post‐flight to provide highly accurate positioning data [17].  

Due to the critical nature of the mission, Shuttle MAGR/S, TDRSS Doppler and Shuttle IMU data served

as an independent back‐up to the Blackjacks.  A spare MAGR/S was carried on the flight in a mid‐deck

locker and an in‐flight MAGR/S change‐out procedure was developed for the crew in the event that the

primary MAGR/S failed.  The Blackjack met the 60 cm position accuracy requirement needed for post‐

flight processing of SRTM data.

Preparation for Future Autonomy Demonstration

The Low Power Transceiver (LPT) flew in the cargo bay of Columbia on STS‐107 [104‐106].    A

collaborative effort between NASA and industry, the LPT demonstrated both GPS navigation and

communication capability through TDRSS and the Space Tracking and Data Network (STDN).    The

NASA Goddard developed GPS Enhanced Orbit Determination Experiment (GEODE) software [107] was

used in the LPT to provide high accuracy orbit determination.  Data was downlinked during the mission

for evaluation.    Future applications of the LPT include autonomous navigation, spacecraft

communication, range safety for space based ranges and satellite formation flying.
89 of 118

9. Shuttle Space Integrated GPS/INS

As GPS receivers became smaller, navigation system developers began envisioning the placement of GPS

receivers directly inside Inertial Navigation System (INS) units, which themselves contain an Inertial

Measurement Unit.   By 1995, Embedded GPS/Inertial Navigation System (or “Embedded GPS/INS” or

“EGI”) units entered production for atmospheric flight and terrestrial applications.   The EGI provides

cost, size and weight savings over previous navigation systems which consisted of separate avionics

boxes.  Since GPS data would not have to be sent outside the receiver to be processed, a central Kalman

filter could incorporate GPS measurements corrected for S/A effects, as well as other measurements

(barometric altimeter, Doppler radar, radar altimeter).  

Tightly Coupled Integration

The tightly coupled integration scheme of the EGI overcomes data latency issues with previous

architectures.    Less latency in aiding permits the carrier loops to be aided and speeds up satellite

acquisition.    The incorporation of all sensor measurements in one filter with high integration rates

provides a much more accurate solution than separate box architectures.  In addition, ground and flight

testing has shown that the tightly coupled EGI blended solution has far superior performance under less

than 4 satellite tracking conditions than a stand alone GPS receiver [86].  Since an aircraft or missile is

subjected to continuous specific force (due to thrust, lift and drag), the Kalman filter can obtain estimates

of sensor errors as maneuvering makes sensor errors visible to the filter through position and velocity

errors.  Continuous calibration of the inertial sensors permits an accurate position, velocity and attitude

solution during GPS outages (such as jamming).  This also allows manufacturers to use lower cost inertial

sensors.    The Kalman filter also permits alignment of inertial sensors much faster than INS systems

without GPS [108].  These factors, along with cost, size, power and weight savings made EGI units an

attractive alternative to legacy navigation systems consisting of multiple line replaceable units.  

Three test flights of EGIs were conducted to determine if such a device could be used in space with a

minimum number of software modifications (Table 1, page 21).  The first EGI unit to fly was the Litton

LN‐100G, with a Collins GEM III five channel SEM‐E form factor GPS receiver.  The GEM III contained

software modified for space use, based on GEM III Link 010, produced by Collins to support the Army

Tactical Missile System program.  The Litton EGI flew on missions STS‐81 (Atlantis, January 1997) and

STS‐86 (Atlantis, September‐October 1997) to provide data gathering for NASA’s X‐33 and X‐34 programs.  

A Honeywell H‐764G EGI, with the same type of GEM III receiver as was flown in the Litton unit, flew

on STS‐84 (Atlantis, May 1997).

Shuttle Space Integrated GPS/INS

In September of 1996, Honeywell was awarded a contract by NASA for the Space Integrated GPS/INS, or

SIGI.  SIGI was to be a common NASA navigator, based on the H‐764G EGI, to be used by both manned

and unmanned space vehicles [3].  The Shuttle version of SIGI, intended to replace the MAGR/S and the

HAINS IMU, contained the same Collins GEM III GPS receiver that was previously mentioned.  
90 of 118

Whereas the MAGR/S was integrated into the Shuttle avionics system as a “navigation system,” the

Shuttle SIGI was to be integrated as both a sensor and a navigator.  The SIGI blended state vector solution

was processed by the Shuttle PASS and BFS flight software using the same software used to process

MAGR/S data.    GPS receiver data and control commands were kept the same as MAGR/S.    This

integration concept was known as “MAGR/S transparency,” and minimized the amount of changes to the

Shuttle flight software.

The Shuttle flight software requires a source of IMU data (integrated attitude rates, change in

accumulated sensed velocity).  SIGI integrated attitude rates and change in accumulated sensed velocity

data were to be processed by the PASS and BFS computers as sensor data, in the same way that HAINS

IMU data were processed.  

The original inertial sensor integration concept was “HAINS IMU transparency,” an attempt to avoid

changes to the Shuttle flight software. The SIGI strapdown inertial instrument data was to be processed

within the SIGI to look like stable member HAINS IMU data, before being passed to the PASS and BFS

GPCs.  However, the transparency option would have made it impossible for Mission Control to identify

and take action on suspect gyros and accelerometers.  As a result, the HAINS IMU transparency option

was abandoned.   More changes were made to the SIGI software to support the Shuttle missionization

than were expected.

The stable members of the three HAINS IMUs are skewed with respect to each other, so that Mission

Control personnel can identify suspect gyros and accelerometers if only two HAINS IMUs are operating.  

With the strapdown configuration of the SIGIs, the axes of the inertial instruments in all three SIGI units

would be parallel, making it difficult for Mission Control to identify suspect inertial sensors if only two

SIGIs were operating.  Mounting the strap‐down SIGI units in a skewed configuration was not feasible;

therefore four SIGI units on each orbiter were needed.  As a result, plans were made to carry four SIGIs

on the orbiters, rather than three.  

Shuttle SIGI Ground and Flight Test Results

SIGI radiation testing resulted in the replacement of a static random access memory chip.  Shuttle SIGI

flew on Shuttle missions 86, 89, 91, 95, 88, 96 and 103 from September of 1997 to December of 1999.  A

cable splitter after the radio‐frequency combiner enabled the SIGI to use the same antennas, pre‐amps

and combiner as the MAGR/S.  SIGI commanding and data recording was conducted by a crew operated

laptop computer.    Numerous changes were made to SIGI software based on ground and flight test

results.  Closed loop lab testing of SIGI units using a signal generator that involved both the GPS and

IMU functions of the devices was challenging.  

During frequent flights of military aircraft the maneuvering, continuous specific force (engine thrust, lift

and drag) and processing of GPS measurements permits the EGI Kalman filter to accurately calibrate the

gyros and accelerometers.  While the SIGI strapdown IMU data was reliable, blended filter performance

was frequently questionable and much of the software modification effort was aimed at the blended

_____
91 of 118

filter.  The short periods of flight during which the shuttle experiences specific force (lift, thrust and drag)

while maneuvering (ascent and entry), coupled with months between flights rendered the reliability,

stability and quality of blended Kalman filter inertial sensor error estimates doubtful.  

For the Shuttle to get into a precise orbit the IMUs must be accurately aligned on the launch pad.  Stable

member HAINS IMUs are aligned by using the sensed Earth rotation and gravity direction. The platform

is oriented in various directions so that each of the accelerometers can calibrate against the gravity vector

and the gyros can calibrate against Earth rotation. With all of the advantages of a space missionized EGI,

preflight strapdown system alignment presented a challenge.    There were three opportunities at the

Kennedy Space Center to make observations when the vehicle was at different orientations: the Orbiter

Processing Facility, the Vehicle Assembly Building, and the launch pad.  The difference in orientation at

the three locations was not adequate to get a good separation of the alignment variables.  

Since the HAINS IMUs were projected to be operational through 2010, replacement of the HAINS IMUs

and MAGR/S units by SIGIs was deferred, and the project was placed on the shelf after the STS‐103 test

flight (Discovery, December 1999) was conducted.  
92 of 118

This page intentionally left blank.
93 of 118

10. X-38/Crew Return Vehicle

In the mid 1990s, NASA JSC began to develop the X‐38, a prototype of a proposed CRV for the

International Space Station.   The CRV was to provide an emergency return capability for the ISS crew in

the event of a medical or spacecraft emergency.   GPS was a key part of the X‐38 avionics system [2].  

Although the X‐38 project was canceled in the spring of 2002, much GPS work was performed and

important lessons were learned.  

V-201 Flight Test

At the time of project cancellation, the X‐38 team was preparing the V‐201 vehicle for an unmanned test

flight.  This test involved V‐201 deployment from the Shuttle payload bay using the Remote Manipulator

System, followed by execution of a deorbit, entry and landing profile.  V‐201 would have been equipped

with three SIGI units (to meet the one fault tolerant requirement).  The operational CRV (human rated),

which would have been taken to the ISS on a later Shuttle flight, was to have had four SIGIs (to meet the

two fault tolerant requirement).

X-38 Design

To lower development costs, the X‐38 used the same outer mold line as the Martin Marietta X‐24A lifting

body, which was tested from 1969 to 1971 (Figure 16) [109].  The lifting body had a higher lift to drag

ratio than a lifting capsule (such as Apollo, Soyuz, and Gemini), and therefore provided a less strenuous

entry (i.e. lower g forces), which is an important consideration when returning injured or sick

crewmembers from orbit.  A lifting body also provided more entry cross and downrange maneuvering

capability than a lifting capsule, which enhanced the ability of the CRV to quickly return a crew to an

appropriate landing site.   Rather than a high speed landing on a runway, as was done by the lifting

bodies tested at Edwards from 1963 to 1975, a 5,500‐square foot steerable parafoil was used (Figure 17).  

Elimination of runway landing also lowered development costs, and increased the number of possible

ground landing sites, which in turn reduced the time required to return crewmembers from the ISS [110]. NASA

Figure 16 - The Martin Marietta X-24A at 

Edwards Air Force Base, 1968. 
94 of 118

NASA/Tom Tschida

Figure 17 - X-38 prototype V-132 

during the fifth drop test at 

Edwards, March 2000. 

CRV GPS Unit

The X‐38 used the same type of SIGI unit and Force 19 GPS

receiver as the ISS, but some changes to the X‐38 SIGI

software were made later in the program.  However, unlike

the ISS SIGI, the strapdown IMU measurements and

blended filter data were required from the beginning.  

High accuracy IMU data was critical for performing guided

lifting entry at hypersonic velocities to achieve a precision

landing.    The Force 19 would provide the same position,

velocity and attitude data as was done for ISS. Leveraging

on the ISS GPS attitude development effort would lower

development and integration costs.    GPS attitude

determination was also believed to be a less costly solution

to the initial attitude determination problem than star

trackers, which would require modification to the X‐38

structure.  Four GPS antennas were placed on the top of the

X‐38 to support attitude determination (Figure 18).

Figure 18 - X-38 GPS antennas and camera bore sights for the proposed V-201 

unmanned test flight. Only camera bore sights in the plane of the figure are shown.

Five Upper 

Cameras

Two Lower 

Cameras

DPS

Four Upper GPS 

Antennas

Lower GPS 

Antenna

Entry Vehicle

Camera Bore Sight

GPS Antenna
95 of 118

CRV SIGI Ground and Flight Testing

Drop Tests

Test Flights on the Shuttle

The CRV SIGI flew in a data collection mode on two Shuttle missions (Table 7) [3]. A cable splitter after

the radio‐frequency combiner enabled the SIGI to use the same antennas, pre‐amps and combiner as the

Shuttle MAGR/S.  Attitude determination was not exercised.  Examination of GPS satellite tracking by the

MAGR/S and CRV SIGI units on Shuttle flights also led to the addition of the lower antenna on the X‐38

(Figure 18).  Having both upper and lower GPS antennas (as was done for the Shuttle MAGR/S receivers

and the legacy Shuttle TACAN units, Figures 6 and 7, page 65) facilitated successful tracking at all

attitudes on–orbit and during entry when not in the plasma region.

GPS signal tracking is subjected to a plasma region during entry.  On STS‐100, plasma effects impacted

Force 19 tracking starting at about 270,000 feet, and continuous tracking of four satellites ceased at

around 240,000 feet.   Continuous four‐satellite tracking did not resume again until about 130,000 feet.  

The inertially aided MAGR/S receiver performed much better.  For the follow‐on STS‐108 flight, the SIGI

was modified so that the Force 19 could use aiding data to help reestablish satellite tracking after plasma.  

As a result, continuous four satellite tracking was regained by an altitude of 210,000 feet [3].

Prototype X‐38 vehicles were dropped from a

NASA B‐52B at Edwards AFB to test the landing

guidance, navigation, control, and parafoil

systems (Figure 17) [110].  These vehicles used the

H‐764G EGI unit intended for atmospheric flight,

rather than the SIGI (space) version of the H‐764G

(Figure 19).  The EGI integration and operation on

the X‐38 was smoother than the CRV SIGI

integration, as the EGI was being used in an

atmospheric application, for which it was

originally designed.

Figure 19 - X-38 drop tests were conducted 

at Edwards Air Force Base.

NASA

Shuttle

Mission

100 (6A)

108 (UF-1)

Orbiter

Endeavour

Endeavour

Year

2001 

2001

Primary Mission

Installed ISS robotic arm 

Raffaello Multi-Purpose Logistics Module

ISS crew exchange

Raffaello Multi-Purpose Logistics Module

Table 7 - X-38 SIGI Flight Test Program on the Shuttle
96 of 118

Additional Testing

Resolving the SIGI Attitude Initialization Issue

Solving For Attitude

Requirements for the contingency departure from ISS scenario dictated that the CRV avionics system

must be able to solve for position, velocity, and attitude without a data transfer from Mission Control

(Houston or Moscow) or the ISS computers (i.e. a SIGI cold start must be performed).   To support a re‐

contact avoidance burn 22.5 minutes after departure from the ISS, cold start completion was needed soon

after separation.    Lab testing of the Force 19 indicated that it could provide position and velocity

relatively quickly after a cold start.  However, lab testing also revealed that the receiver could not always

provide GPS derived attitude under cold start conditions in time to support the re‐contact avoidance

burn, due to the time required to solve for carrier phase integer ambiguities.

Finding a Way to Compute Attitude Quickly

Alternate methods of SIGI attitude initialization were studied. One option involved adding

magnetometers to the CRV, but technical problems prevented this. A digital camera system had been

____

Figure 20 - NASA personnel conducted CRV 

SIGI tests in a Dryden Flight Research Center 

Beechcraft King Air.

NASA NASA

Issues observed    on    the    STS‐100    mission  

prompted testing of the CRV SIGI on a NASA

Beechcraft Beech 200 Super King Air at the

Dryden Flight Research Center (Figure 20).  

This was the X‐38 SIGI Atmospheric Flight

Test, or X‐SAFT.  Two CRV SIGIs were carried,

and one H‐764G EGI and one Ashtech Z‐12

differential GPS receiver were on‐board for

comparison with the SIGIs.  The first phase of

13 test flights (August‐October 2001) was

performed to assess position and velocity

determination.   For the second phase of 6 test

flights (February‐May 2002), four GPS antennas

were placed on the King Air to support attitude

determination tests.   The tests were useful for

comparing side‐by‐side performance of two

identical SIGI units (for redundancy

management architecture decisions), validation

of lab test equipment, and check‐out of

procedures, data collection and commanding

software.    The test flights were unable to

duplicate performance issues that occurred on‐

orbit during the Shuttle flights of CRV SIGI.
97 of 118

included in the CRV design to provide the crew with situational awareness during undocking and

separation from the ISS, until the CRV was clear of ISS structure, and could be adapted to perform an

initial attitude determination function.  This system was slated for testing on the X‐38 V‐201 test flight,

and software and procedure development was begun so that the optical attitude determination feature

could be tested on that flight.

The Camera System

Five cameras were to be mounted on the top of the Descent Propulsion System (DPS), and two on the

bottom (Figure 18).  Earth limb and nadir sightings, coupled with inertial rate data from the SIGIs, would

be used to compute an initial attitude estimate.    On the CRV, the crew could quickly perform the

sightings before or after separation from the ISS.    Attitude estimates produced by this method were

deemed accurate enough to support the collision avoidance burn. In addition, the attitude estimates

would speed up the Force 19 integer ambiguity resolution process, which would lead to more timely GPS

attitude determination.  

Camera Tests For V-201

For the unmanned V‐201 flight, Mission Control would perform the Earth limb and nadir sights on video

transmitted from the X‐38 to test the attitude determination algorithm.    Horizon sensors were also

mounted on the DPS of the V‐201 vehicle to cross check the digital camera attitude solution.

V-201 SIGI Operations Concept

For the unmanned V‐201 X‐38 test flight, the three CRV SIGIs were to be activated and checked out while

the X‐38 was still in the orbiter payload bay. The Shuttle onboard star trackers and the MAGR/S, along

with TDRSS and ground radar tracking were to be used to check SIGI attitude, position and velocity.

After deployment, X‐38 horizon sensors were to be used to check the GPS attitude computed by the

SIGIs.  GPS attitude determination was to be turned off before entry, and the SIGIs would continue to

determine attitude based on integrated rate measured by the SIGI strapdown IMUs. SIGIs were to

continue to perform position and velocity determination until landing.

A back‐up navigation function was designed into the X‐38 software in the event of SIGI problems.  Back‐

up navigation was to be initialized using a selected SIGI blended position and velocity vector.    SIGI

strapdown IMU sensed delta‐velocity data was to be continuously used to propagate the backup state

vector.  Starting at an altitude of ~80,000 feet (~Mach 2.5), barometric altitude data from the Flush Air

Data System was to be incorporated by backup navigation to control vertical position errors.   Backup

navigation could be reinitialized using a selected SIGI blended state vector if Mission Control personnel

deemed that errors in the backup state vector were excessive.
98 of 118

To support landing, a radar altimeter was to provide more accurate altitude than SIGI from 5,000 feet

through touch down.  Further definition of navigation architecture and procedures for the operational

CRV was to be made based on V‐201 flight results.
99 of 118

11. Rationale Behind a Notional Shuttle GPS Receiver Upgrade

Prior to the decision to retire the Shuttle by 2010, consideration was given to replacing the Space Shuttle’s

mid‐1990s vintage 5‐channel receiver with a more modern, all‐in‐view tracking receiver.   This chapter

details some of the ways advanced GPS technology could have been leveraged to improve Shuttle

navigation, and some reasons why advanced GPS technology would not have changed some aspects of

Shuttle navigation.

The current receiver represents an early 1990s technology level. Although it has flown on the Shuttle

since 1996, and been certified for use during flight, newer GPS units, GPS satellites and augmentation

systems are entering (or will soon enter) service with more advanced capabilities.    Some of these

capabilities could be leveraged to improve Shuttle navigation and safety, particularly if new automation

or autonomy requirements emerge (Figure 21).  A study would be required to determine which advanced

capabilities would provide benefit to the Shuttle Program.    Identification of candidate replacement

receivers would be contingent on when new satellite navigation capabilities are introduced, and when

receivers that take advantage of those new features are available.  This section discusses several ways in

which GPS could be applied to the Shuttle, but not all of the concepts mentioned are desirable for the

vehicle.

Legacy Sensors

Figure 21 - Legacy Navigation Sensors By Flight Phase, With Potential Advantages of a Modern Receiver. 

Modern GPS Receiver

Entry & Landing

• MLS Replacement

• Less Susceptible to Loss

of Service

• Facilitates Autoland

• Lower Minimum Ceilings 

• Improved Integrity

• Safer Emergency Landings

Orbit Relative Nav

• Possible Radar 

Replacement

Orbit Absolute Nav

• On-Board Precision 

Orbit Determination,

More Autonomy

Entry & Landing

• 3 TACAN & 1 

GPS or 3 GPS

• 3 IMUs

• 4 Baro Altimeters

• 3 MLS Receivers

• 2 Radar Altimeters

• Ground Based Radar

Orbit Relative Nav

• 2 Star Trackers

• Ku Band Radar

• Crew Optical Alignment Sight

• Trajectory Control Sensor Lidar

• Hand Held Lidar

• Closed Circuit TV Cameras

Orbit Absolute Nav

• 3 IMUs

• 2 Star Trackers

• Ground Radar

• TDRSS Satellite Tracking

• Legacy GPS Receiver

Ascent

• 3 IMUs

• Ground Radar
100 of 118

Receiver Recovery

Modern GPS receivers can track 12 or more GPS satellites at a time.    This greatly speeds up state

determination after a power cycle or receiver software reset, and reduces the likelihood that difficult

tracking conditions will result in unavailability of the GPS navigation solution.   This would provide a

performance improvement over the current five channel Shuttle GPS receiver.

Loss of Service

The five channel unit certified for use on the Shuttle uses four channels to obtain GPS measurements, and

a fifth for ephemeris collection, measurement collection for correction of ionospheric errors, tracking

channel calibration and satellite acquisition.  New satellites needed to maintain track of an optimal set of

four are acquired sequentially.    Under difficult tracking conditions (multi‐path, antenna obscuration,

satellite line‐of‐sight off of the antenna gain pattern), multiple satellite switches could fail or be delayed,

resulting in less than optimal satellite geometry or less than four satellite tracking for extended periods of

time.

In some cases during testing, the receiverʹs estimate of its position accuracy exceeded a Shuttle computer

GPS quality assurance test limit, which would have prevented the Shuttle computers from using position

and velocity data from that receiver.  The length of the GPS outages varied.  An extensive ground test

effort was conducted to ensure that loss of a GPS receiver during entry due to this condition would not

compromise safety of flight.

An all‐in‐view receiver (capable of tracking 12 or more satellites at a time) would be more capable of

providing a navigation solution under difficult tracking conditions.

New GPS Signals 

Current GPS satellites broadcast two military signals and one civilian signal, all of which can be tracked

by the Shuttle GPS receiver.  New GPS satellites, which will be launched in this decade, are the Block IIR‐

M and Block IIF series [111, 112].

In addition to the three legacy signals, the Block IIR‐M satellites will broadcast two new authorized user

signals, a new civil signal, and all signals will be broadcast at a higher power level than the previous GPS

satellites (Figure 22).  The Block IIF satellites, will broadcast those signals transmitted by the Block IIR‐M

vehicles, as well as a third civil signal to support safety‐of‐life applications, such as aircraft.  The current

Shuttle receiver will be able to track legacy signals transmitted by the Block IIR‐M and Block IIF satellites,

but a new GPS receiver will be required to take advantage of the additional signals and the improvement

they provide to navigation integrity.  Early in the next decade, the next generation GPS satellite, GPS III,

may be entering service.   This satellite and its new architecture may possess newer signals, enhanced

reliability and accuracy.
101 of 118

Receiver Autonomous Integrity Monitoring and Satellite Based Augmentation

The level of GPS navigation solution accuracy, availability and continuity are important.  In addition, the

integrity of the navigation solution, whether or not it can be trusted, is critical [113].  The integrity of the

GPS navigation solution is dependant on the on‐board GPS receiver, the GPS satellites and the GPS

ground support infrastructure.

Currently, the Shuttle Program is dependent on the GPS Master Control Station (MCS) for notification of

malfunctioning satellites.  If the MCS cannot set the satellite health bit or change the satellite GPS signal

to be non‐trackable, the MCS would pass word of the malfunctioning satellite to Mission Control.  Based

on Mission Control instructions, the crew would perform a data entry into a Shuttle computer display to

instruct the GPS receivers to ignore the unhealthy satellite.

The all‐in‐view tracking capability of modern receivers facilitates the use of Receiver Autonomous

Integrity Monitoring (RAIM), which detects anomalous GPS signals and identifies suspect GPS satellites,

facilitating exclusion of their measurements from state vector determination.  The availability of RAIM

would provide a level of protection against spurious GPS signals that is not available today with the

Shuttle’s five‐channel receiver.

While RAIM provides protection against suspect satellites, there may be times when a receiver is tracking

an insufficient number of GPS satellites with suitable geometry to support RAIM.    Satellite or ground

based augmentation using ground monitoring stations can provide a higher level of “real time” integrity

protection than a stand‐alone GPS receiver employing RAIM [113].

Figure 22 - Upcoming Enhancements to Global Navigation Satellite Systems

Space or Ground Based Augmentation

WAAS

• Satellite broadcast

• Enhances GPS accuracy & 

integrity in North American 

airspace

• Ranging, differential 

correction and integrity 

signals

• Supports take-off through 

CAT I approach

• Initial Operating Capability 

7/10/2003

• Final capability ~2008

EGNOS

• European equivalent 

of WAAS

• Monitors GPS, GLONASS 

& Galileo (future)

• Covers Europe, with possible

expansion to Africa

• Safety of life certified ~2006

Future WAAS/EGNOS 

Compatible Systems

• Japan 

• India

• Others

JPALS

• Ground or ship broadcast

• High accuracy & integrity

• CAT I, II & III all weather 

approaches

• Naval and land versions

under development

• Naval version will support

automated carrier landings

• Civilian version (LAAS)

under development

Satellites

GPS III

• Fifth generation GPS

• Architecture designed to 

support the long term

• Improved accuracy

& reliability

• New signals?

• First launch 2013?

Galileo

• European controlled

• 30 satellites

• Projected full 

operational 

capability ~2008

Block IIF Satellites

• L5 safety of 

life signal

• Longer lifetime

• First launch 2007?

Block IIR-M Satellites

• M code on L1 & L2

• Civil signal on L2

• Higher power

• First launch 2005
102 of 118

The U.S Wide Area Augmentation System (WAAS) and European Geostationary Navigation Overlay

Service (EGNOS), which are satellite based augmentation systems (the augmentation signals are

broadcast by satellites other than the GPS satellites), will provide GPS satellite integrity information to

those GPS receivers capable of receiving WAAS and EGNOS signals (Figure 22) [114].    WAAS and

EGNOS navigation payloads on geostationary satellites broadcast ranging, differential correction and

satellite integrity signals.    This will enable receivers to exclude satellites of questionable quality.    The

additional ranging signals will improve solution quality and availability.

WAAS covers most of North America with GPS corrections and integrity signals, while EGNOS

broadcasts GPS and Global Navigation Satellite System (GLONASS) related data to Europe.    EGNOS

could be expanded to cover Africa, and will eventually broadcast Galileo related data.  Other countries

such as Japan and India are considering building systems that perform the same function as, and are

compatible with, WAAS and EGNOS.

Receiver based RAIM and access to integrity data from satellite based GPS augmentation systems would

permit a modern GPS receiver to exclude a questionable satellite in an autonomous manner, more

quickly than can be done with the legacy five channel receiver.

Shuttle Autoland Using Ground Based GPS Augmentation

The Shuttle was designed with an autoland system, which has been upgraded over the years [115, 116].  

However, a completely automatic landing has never been attempted, and the capability is a back‐up

flying mode for contingencies.

The Shuttle’s MLS is an integral part of the Shuttle’s autoland capability.  It has been successfully used to

support piloted landings since the beginning of the Shuttle flight program in 1981 [117].  The Shuttle MLS

system is different than that used to support civil aviation, and is only available at six Shuttle landing

sites.*  The Shuttle has a much steeper glideslope than aircraft.  Over the long term, there are difficulties

in maintaining the legacy MLS on‐board and ground equipment. Multi‐path and coverage issues are also

of concern with MLS support for autoland.

If automated landings of either a crewed or uncrewed Shuttle are desirable in the future, use of a ground

based GPS augmentation system (augmentation signals are broadcast by a ground station) employing the

differential GPS concept may be preferable over MLS. A ground‐based augmentation system could

provide a navigation solution of sufficient accuracy and integrity, provide more operational flexibility in

landing site selection, and enhance safety margins.

* Within the Shuttle Program, the name Microwave Scanning Beam Landing System (MSBLS) is often used to

differentiate the Shuttle system from the civil and military aviation Microwave Landing System.
103 of 118

The military Joint Precision Approach and Landing System (JPALS)* will provide high accuracy, high

integrity differential GPS navigation to support precision landing in all weather conditions [5, 118‐123].  

Tests of a prototype JPALS system have already supported automated F/A‐18 carrier landings and

Unmanned Aerial Vehicle (UAV) tests [119, 121].    JPALS will play an important role in future UAV

operations [122].  One set of JPALS ground equipment could service all the runways at a landing site,

while the legacy MLS equipment has to be positioned at each runway.  This would ensure availability of

precision landing capability no matter which landing site runway was selected.  

Use of JPALS would require a new GPS receiver.  The legacy receiver was not required to, nor does it

support, precision landing using GPS augmentation.

Weather Minimums For Landings 

Use of an all‐in‐view receiver with JPALS and RAIM may also permit reduction of minimum ceilings,

and provide more safety margin for emergency landings, whether they are piloted or automated.

Simplification of Shuttle Navigation Procedures

A more capable and robust GPS receiver could lead to the simplification of Shuttle on‐board and Mission

Control navigation procedures.    However, any such simplification would have to be proceeded by an

extensive analysis of current procedures, program requirements and flight rules.    Furthermore, each

proposed change should be examined to determine if the payback in terms of life cycle costs and risk

reduction justifies the change.

The first measurement processed during entry is drag altitude, computed using Inertial Measurement

Unit data and an atmosphere model.  Drag altitude introduces an expected level of altitude error into the

Shuttle navigation state, but bounds altitude errors that are common to inertial navigation systems.  All‐

in‐view tracking, RAIM and satellite integrity signals from satellite‐based augmentation could eliminate

the need for drag altitude measurement processing.

A ground computed correction to the Shuttle on‐board navigation state, called a delta state update, is a

backup to the on‐board navigation system.  This capability requires two ground radars, a good Mission

Control solution of the Shuttle state vector, and a commanding capability to put the delta‐state into the

Shuttle computers.    Given the integrity functions available to more advanced GPS receivers (WAAS,

JPALS, RAIM, more signals), dependence on the delta state backup capability could conceivably be

reduced.

* A civilian equivalent, the Local Area Augmentation System (LAAS), is under development.
104 of 118

Barometric altimeters provide altitude measurements for Kalman filter processing by the Shuttle primary

and backup computers.    Given that barometric measurements help bound altitude errors at lower

altitudes and are more accurate than the previously mentioned drag altitude measurement, it is unlikely

that barometric altitude processing would be eliminated.  Such a measurement would still be desirable in

the event of one or more Shuttle systems problems that result in an unavailability of GPS data.  

Furthermore, the pitot tubes that provide the barometric altitude measurement also provide data from

which several parameters are derived for the orbiter’s flight control system.

Precision Orbit Determination

The Shuttle MAGR and ISS Force 19 GPS receivers did not have requirements to support precision orbit

determination.  While the existing filters in these receivers do meet requirements, flight results show they

are not capable of precision orbit determination [23].  This function is currently performed for the Shuttle

by Mission Control, and for the ISS by the U.S. Air Force Strategic Command and the Ballistics

Navigation System group at the Russian Mission Control in Korolev.  These solutions are used to support

maneuver planning and debris avoidance.    A Mission Control based filter, called SPOT (Spacecraft

Position Optimal Tracking) has been developed to perform precision orbit determination using MAGR

and Force 19 position vectors.  Consideration could be given to providing a precision orbit determination

capability on‐board the orbiters.  This could be done by placing a suitable filtering algorithm in either a

GPS receiver, or in a computer external to the receiver.  It may be easier to place the orbit determination

filter in a computer other than the GPS receiver.

Rendezvous and Proximity Operations

Application of relative GPS is being pursued by development efforts for the European Automated

Transfer Vehicle (ATV) and the Japanese H‐II Transfer Vehicle (HTV).    Similar application could be

considered for the Shuttle as a rendezvous radar replacement.  

The Shuttle has a requirement to rendezvous with vehicles that are not equipped with active relative

navigation aids such as relative GPS.   Any replacement of a current relative sensor with relative GPS

would have to be extensively studied to ensure that the Shuttle could still rendezvous with

navigationally passive targets.  

To support relative GPS for Shuttle rendezvous with the ISS, a new communications link between the ISS

and Shuttle may have to be created, with additional hardware and software added to both vehicles.  The

ISS may also need a new GPS receiver, modified to meet a relative GPS requirement.   The current ISS

receivers, and the Shuttle’s current GPS receiver, were not intended to meet a relative GPS requirement.

Relative GPS could conceivably replace the rendezvous radar and star trackers in their relative sensor

roles.    Such a replacement would permit similar navigation sensor redundancy (three GPS receivers

versus one radar) and eliminate the need for radar failure relative navigation procedures.  The Ku Band

__
105 of 118

antenna and associated electronics would still be required to support transmission of data and video via

the TDRSS network satellites.  In the event of a future communications system upgrade that replaces the

Ku Band hardware communications function, replacement of the Ku Band rendezvous function by

relative GPS would be desirable.  The star trackers used for relative optical measurements are also used

for IMU alignment, and would have to be retained in the event of a switch to relative GPS.

Accuracy, multi‐path, reliability, antenna obscuration and sensor measurement redundancy concerns in

close proximity to the ISS would prevent relative GPS from replacing the laser sensors currently in use to

support the close approach and docking phases.

A GPS receiver that is to be used for relative navigation would require extensive modification of

navigation and filtering algorithms.  If the receiver could not be modified, GPS measurements could be

passed to an on‐board computer that has navigation and filtering algorithms specifically designed to

support relative navigation during rendezvous and proximity operations.    Relative GPS is also more

complex than other relative sensors.   Given the complexity of the Shuttle and ISS GPS integrations, a

relative GPS integration effort should not be considered to be straightforward.

Attitude Determination

Research into GPS attitude determination has been extensive, and such an application has been

operational on the ISS since April 2002 [2].  However, for the Shuttle, GPS attitude determination is not

desirable.

Multiple antennas are required for GPS attitude determination, and the ISS experience has shown that

attitude solution quality is dependent on satellite visibility to the antenna array, which is a function of

vehicle attitude.  Mounting arrays on the Shuttle to ensure adequate visibility would be problematic.  The

Shuttle IMUs provide high accuracy attitude data during all phases of flight, at any attitude.  The units

are aligned using star trackers.  The high accuracy is needed to support safety critical ascent and entry,

where excessive attitude errors are not permissible.  GPS attitude determination may not be of sufficient

accuracy to replace the star trackers in the role of supplying attitude updates to the flight computers, for

the purpose of IMU alignment.  

GPS Metric Tracking For Range Safety

An effort to replace legacy ground radars with on‐board GPS receivers for range safety at U.S. launch

sites has been underway for some time.    Range safety tracking requires two independent sources of

tracking data. The Shuttle GPS receiver is integrated with the on‐board navigation, guidance and flight

control system.  This would preclude the use of a new Shuttle GPS receiver from being used to reduce

required ground tracking support during launch.  An additional GPS receiver, independent of the Shuttle

avionics system, would be required to meet range safety requirements for the Shuttle orbiters.  Ground

radar replacement for range safety would also require the addition of GPS receivers to the Solid Rocket

__
106 of 118

Boosters.  In addition to range safety, ground radar tracking is required to support Shuttle launch and

landings, which includes nominal and emergency landings at the Kennedy Space Center Shuttle runway.
107 of 118

12. Summary

In the early 1990s, GPS was viewed as an off‐the‐shelf technology that would permit a faster‐better‐

cheaper approach to upgrading vehicles and lowering development costs.    GPS technology has been

successfully integrated into the International Space Station and the Space Shuttle (the X‐38/CRV project

was canceled).    GPS provides more operational flexibility and better accuracy than legacy navigation

aids.  

However, the number of technical issues encountered exceeded the expectations held at the start of the

projects.  The amount of time, number of personnel, and effort required to resolve these technical issues

exceeded initial estimates.    GPS receivers are complex computers that interface with other complex

computers.  Treating a GPS integration with a spacecraft avionics system as a straightforward “plug and

play” project will lead to multiple technical, cost and schedule problems.  

Extensive testing of interim software versions and the integrated system should be performed, both in

the lab and the actual operating environment.  Computer interfaces, including GPS receivers, in safety‐

critical systems should be “bullet proofed” to protect against known and postulated forms of spurious

input.  Redundancy, RAIM, satellite and ground based augmentation and monitoring systems will not

protect against system level problems, receiver software problems, or user errors.  While it is a good idea

to equip GPS receivers with an autonomous reset feature (“ctrl‐alt‐delete”), the existence of such a feature

should not be used as an excuse to take shortcuts in software and system development and testing.  

Widespread acceptance, confidence in, and use of GPS technology should not lull the integration and

user community into thinking that problems cannot occur, particularly at the receiver level.   Research

and testing is needed to characterize receiver failures, and their probability of occurrence.

Integration and use of software intensive, off‐the‐shelf units into safety related applications for which

they were not originally designed requires vendor support and design insight above that required for

other off‐the‐shelf integrations.    Open communication among all participants and close relationships

with navigation unit vendors are required to ensure success.  

The process issues encountered by GPS vendors, integrators, users, and certification authorities are not

specific to the navigation industry.  The same issues occur throughout the computer industry, and are the

subject of research and discussion at computer industry conferences.  Interaction between the computer

software and the navigation industries may help overcome GPS software process problems.

Not all technical difficulties with new technology should be interpreted as being process problems (lack

of communication, inadequate requirements, insufficient testing).  Application of new and revolutionary

technology to new operating environments is a process of discovery.    The Columbia Accident

Investigation Board characterized the Shuttle as being a developmental vehicle with an operational

mission.  The NASA JSC experience with GPS in space indicates that it too is developmental in nature,

with an operational mission.
108 of 118

This page intentionally left blank.
109 of 118

13. References

[1] Peter M. Kachmar, William Chu, Peter Neirinckx, and Moises Montez, “U.S. Space Shuttle ‐ Integrated

GPS Navigation Capability,” Proceedings of the Institute of Navigation GPS‐93 Conference, Salt Lake City,

UT, September 22‐24, 1993, pages 313‐326.

[2] Susan F. Gomez, “Flying High – GPS on the International Space Station and Crew Return Vehicle,”

GPS World, Volume 13, Number 6, June 2002, pages 12‐20.

[3] E. Glenn Lightsey, Greg C. Blackburn and James E. Simpson, “Going Up: A GPS Receiver Adapts to

Space,” GPS World, Volume 11, Number 9, September 2000, pages 30‐34.

[4] The Volpe National Transportation Systems Center, Vulnerability Assessment of the U.S. Transportation

Infrastructure Relying on the Global Positioning System, final report prepared for the Office of the Secretary

of Transportation, August 29, 2001.

[5] Karen Van Dyke, Karl Kovach, John Lavrakas, and Brian Carroll, “Status Update on GPS Integrity

Failure Modes and Effects Analysis,” Proceedings of the Institute of Navigation 2004 National Technical

Meeting, Institute of Navigation, Fairfax, VA, 2004.

[6] RAIM: Requirements, Algorithms, and Performance, Global Positioning System: Papers Published in

NAVIGATION, Volume V, Institute of Navigation, Fairfax, VA, 1998.

[7] J. V. Langer, “Near‐Term Integrity Improvements for the GPS Operational Control Segment,”

Proceedings of Institute of Navigation GPS 2002 Conference, Portland, OR, September 24‐27, 2002.

[8] J. R. Clynch, et al., “The Hunt for FRI,” GPS World, Volume 14, Number 1, January 2003, pages 16‐22.

[9] Nancy G. Leveson, “The Role of Software in Spacecraft Accidents,” Journal of Spacecraft and Rockets,

AIAA, Vol. 41, No. 4, July‐August 2004, pages 564‐575.

[10] P. D. Nisner, and R. Johannessen, “Ten Million Data Points from TSO Approved Aviation GPS

Receivers ‐ Results of Analysis and Applications to Design and Use in Aviation,” Journal of the Institute of

Navigation, Vol. 47, No. 1, Spring 2000, pages 43‐50.

[11] F. H. Bauer, K. Hartman, and E. G. Lightsey, “Spaceborne GPS Current Status and Future Visions,”

Proceedings of Institute of Navigation GPS Conference, Institute of Navigation, Fairfax, VA, 1998, pages 1493‐

1508.

[12] J. Russell Carpenter and Robert H. Bishop, “Flight Data Results Of Estimate Fusion For Spacecraft

Rendezvous Navigation From Shuttle Mission STS‐69,” Space Flight Mechanics 1996, Volume 93 of

Advances In The Astronautical Sciences, Univelt Inc., 1996, pages 1257‐1276.
110 of 118

[13] E. Schiesser, J. P. Brazzel, J. R. Carpenter and H. D. Hinkel, “Results Of STS‐80 Relative GPS

Navigation Flight Experiment,” Space Flight Mechanics 1998, Volume 99 of Advances In The Astronautical

Sciences, Univelt Inc., 1998, pages 1317‐1333.

[14] C. Schroeder, B. E. Schutz and P. A. M. Abusali, “STS‐69 Relative Positioning GPS Experiment,” Space

Flight Mechanics 1996, Volume 93 of Advances In The Astronautical Sciences, Univelt Inc., 1996, pages

1239‐1255.

[15] Y. Park, J. Brazzel, R. Carpenter, H. Hinkel, and J. Newman, “Flight Test Results From Realtime

Relative GPS Flight Experiment On STS‐69,” Space Flight Mechanics 1996, Volume 93 of Advances In The

Astronautical Sciences, Univelt Inc., 1996, pages 1277‐1295.

[16] Changyin Zhao, C. K. Shum and Yuchan Yi, “Calibration Results of GFO,” International Workshop on

Satellite Altimetry, International Association of Geodesy Symposia, Vol. 126, Springer‐Verlag Berlin, 2003.

[17] Willy Bertiger, et al., “Precise Orbit Determination For The Shuttle Radar Topography Mission Using

A Next Generation Of GPS Receiver,” Proceedings Of ION GPS 2000, Nashville, TN, September 19‐22,

2000.

[18] Timothy E. Rumford, “Demonstration Of Autonomous Rendezvous Technology (DART) Project

Summary,” SPIE Space Systems Technology And Operations Conference, Orlando, FL, April 2003.

[19] D. Bearden, “A Complexity‐Based Risk Assessment of Low‐Cost Planetary Missions: When Is A

Mission Too Fast and Too Cheap?” 4th IAA International Conference on Low‐Cost Planetary Missions, The

Johns Hopkins University Applied Physics Laboratory, Laurel, MD, May 2‐5, 2000.

[20] M. Dornheim, “Aerospace Corporation Study Shows Limits Of Faster Better Cheaper,” Aviation Week

& Space Technology, Vol. 152, No. 24, June 12, 2000, pages 47‐49.

[21] Liam Sarsfield, The Cosmos on a Shoestring: Small Spacecraft for Space and Earth Science, MR‐864‐

OSTP, RAND, 1998.

[22] Theron R. Leishman and Dr. David A. Cook, “Risk Factor: Confronting the Risks That Impact

Software Project Success,” Crosstalk – The Journal of Defense Software Engineering, May 2004.

[23] J. Russell Carpenter and Emil R. Schiesser, “Semimajor Axis Knowledge and GPS Orbit

Determination,” Journal of the Institute of Navigation, Volume 48, Number 1, Spring 2001, pages 57‐68.

[24] P. Shestople, J. Li, A. Ndili, K. Schrock, “Gravity Probe B GPS Receivers,” Institute of Navigation GNSS

2004 Conference, Long Beach, CA, September 21‐24, 2004.

[25] S. Fredrickson, S. Duran and J. Mitchell, “Mini AERCam Inspection Robot for Human Space

Missions,” SPACE 2004 Conference, San Diego, CA, September 28‐30, 2004.
111 of 118

[26] Willy Bertiger, et al., “Instrument of Grace: GPS Augments Gravity Measurements,” GPS World,

Volume 14, Number 2, February 2003, pages 16‐28.

[27] Richard J. Adams and Suellen Eslinger, “Lessons Learned From Using COTS Software on Space

Systems,” Crosstalk ‐ The Journal Of Defense Software Engineering, June 2001.  

[28] Lisa Brownsword, David Carney and Tricia Oberndorf, “The Opportunities and Complexities of

Applying Commercial‐Off‐the‐Shelf Components,” Crosstalk ‐ The Journal Of Defense Software Engineering,

U.S. Department of Defense, April 1998.

[29] David J. Carney, and Patricia A. Oberndorf, “OSD  ‐ Commandments of COTS: In Search of the

Promised Land,” Crosstalk ‐ The Journal Of Defense Software Engineering, U.S. Department of Defense, May

1997.

[30] David Carney, Quotations From Chairman David – A Little Red Book Of Truths To Enlighten And Guide

On The Long March Toward The COTS Revolution, Carnegie Mellon University Software Engineering

Institute, Pittsburgh, PA, 1998.

[31] J. Dean and A. Gravel (editors), COTS‐Based Software Systems, Proceedings of the First International

Conference on COTS‐Based Software Systems (ICCBSS 2002), Orlando, FL, February 4‐6, 2002, Lecture Notes

in Computer Science Series, Volume 2255, Springer‐Verlag Heidelberg, Germany, 2002.

[32] Howard F. Lipson, Nancy R. Mead and Andrew P. Moore,  Can We Ever Build Survivable Systems from

COTS Components? CMU/SEI‐2001‐TN‐030.  Carnegie Mellon Software Engineering Institute, Pittsburgh,

PA, December 2001.

[33] B. Craig Meyers and Patricia Oberndorf, “Managing Software Acquisition: Open Systems and COTS

Products,” The SEI Series in Software Engineering, ISBN 0‐201‐70454‐4, Addison‐Wesley, Boston, MA, 2001.

[34] Patricia Oberndorf, COTS and Open Systems, Carnegie Mellon University Software Engineering

Institute, Pittsburgh, PA, February 1998.

[35] Patrick R. H. Place, Guidance on Commercial‐Based and Open Systems for Program Managers, Carnegie

Mellon Software Engineering Institute, CMU/SEI‐2001‐SR‐008, April 2001.

[36] Dr. Richard Bechtold, “Efficient and Effective Testing of Multiple COTS‐Intensive Systems,” Crosstalk

– The Journal of Defense Software Engineering, May 2004.

[37] Roberta L. Gross, Faster, Better, Cheaper: Policy, Strategic Planning, And Human Resource Alignment,

NASA Office Of The Inspector General, Report Number IG‐01‐009, March 13, 2001.

[38] “Commercial Off‐the‐Shelf (COTS), Modified Off‐the‐Shelf (MOTS) Software Policy, SSP Directive

No. 145,” dated April 16, 2001, in Space Shuttle Program Structure And Responsibilities, Book 2, Space Shuttle

Program Directives, NSTS 07700, NASA Johnson Space Center.
112 of 118

[39] Dr. Randall W. Jensen, “Lessons Learned From Another Failed Software Contract,” Crosstalk – The

Journal of Defense Software Engineering, September 2003.

[40] Brent Robertson and Eric Stoneking, “Satellite GN&C Anomaly Trends,” Guidance and Control 2003,

Advances in the Astronautical Sciences, Volume 113, Univelt, Inc., San Diego, CA, 2003, pages 531‐542.

[41] Michael W. Evans, Alex M. Abela, and Thomas Beltz, “Seven Characteristics of Dysfunctional

Software Projects,” Crosstalk – The Journal of Defense Software Engineering, April 2002.

[42] D.C.R. Link, et al., Huygens Communications Link Enquiry Board Report, December 20, 2000.

[43] Mars Climate Orbiter Mishap Investigation Board Phase I Report, NASA, November 10, 1999.

[44] Mars Climate Orbiter Mishap Investigation Board, Report on Project Management in NASA, March 13,

2000.

[45] Christine Anderson, et al., Lewis Spacecraft Mission Failure Investigation Board Final Report, February 12,

1998.

[46] William Anderson, et al., Army Workshop on Lessons Learned from Software Upgrade Programs, Carnegie

Mellon Software Engineering Institute, CMU/SEI‐2001‐SR‐021, November 2001.

[47] David A. Gaitros, “Common Errors in Large Software Development Projects,” Crosstalk – The Journal

of Defense Software Engineering, March 2004.

[48] Professor J.L. Lions, et al., ARIANE 5 Flight 501 Failure, Report by the Inquiry Board, Paris, July 19,

1996.

[49] Milstar Accident Investigation Board Report, United States Air Force, July 22, 1999.

[50] Professor Massimo Trella, et al., SOHO Mission Interruption Joint NASA/ESA Investigation Board Final

Report, August 31, 1998.

[51] General Accounting Office, National Airspace System: Persistent Problems in FAA’s New Navigation

System Highlight Need for Periodic Reevaluation, Report to the Chairman, Subcommittee on Transportation,

Committee on Appropriations, U.S. Senate, GAO/RCED/AIMD‐00‐130, June 2000.

[52] P. V. Bhansali, Perspectives on Safety‐Critical Software, Proceedings of the Australian Software

Engineering Conference (ASWEC’97), Sydney, Australia, September 28 – October 3, 1997.

[53] Dr. L. H. Rosenberg, et al., “Generating High Quality Requirements,” Proceedings of the AIAA Space

2001 Conference and Exposition,  American Institute of Aeronautics and Astronautics, Reston, VA, August

28 to 30, 2001.
113 of 118

[54] K. J. Hayhurst and C. M. Holloway, “Challenges in Software Aspects of Aerospace Systems,” 26th

Annual NASA Goddard Software Engineering Workshop, Greenbelt, MA, November 27 ‐ 29, 2001.

[55] D. A. Divis, “Washington View – A New Year’s Budget Resolutions,” GPS World, Volume 14,

Number 1, January 2003, pages 10‐12.

[56] Michael J. Hillelsohn, “Better Communication Through Better Requirements,” Software Performance

Systems,” Crosstalk – The Journal of Defense Software Engineering, April 2004.

[57] J. Steven Newman, “Failure‐Space: A Systems Engineering Look At 50 Space System Failures,” Acta

Astronautica, Elsevier Science Ltd, Volume 48, Numbers 5‐12, 2001, pages 517‐527.

[58] Jin H. Lee and Young K. Chang, “A Study On GPS Data Tracking Method For KOMPSAT Spacecraft

Orbit Control,” Proceedings of the 14th Annual AIAA/USU Conference On Small Satellites, Utah State

University, Logan, UT, 2000.

[59] Diane Vaughan, The Challenger Launch Decision, The University of Chicago Press, 1996.

[60] Presidential Commission on the Space Shuttle Challenger Accident, U.S. Government Printing Office,

Washington, DC, June 6, 1986.

[61] Columbia Accident Investigation Board Report, Volume I, U.S. Government Printing Office, Washington,

DC, August 2003.

[62] Michael A. Beims, and James B. Dabney, “Reliable Tailored‐COTS Via Independent Verification and

Validation,” NATO Symposium on Commercial Off‐The‐Shelf Products in Defense Applications, Brussels,

Belgium, April 3‐7, 2000.

[63] National Research Council, Independent Verification and Validation For Space Shuttle Flight Software,

National Academy Press , Washington, DC, 1992.

[64] National Research Council, An Assessment of Space Shuttle Flight Software Development Processes,

National Academy Press, Washington, DC, 1993.

[65] Dr. Linda H Rosenberg, “Verification and Validation    Implementation at NASA,” Crosstalk  ‐ The

Journal Of Defense Software Engineering, U.S. Department of Defense, May 2001.  

[66] Dr. Linda H. Rosenberg and Charles S. Vanek, “Independent Verification and Validation

Implementation at NASA,” 52nd International Astronautical Congress, Toulouse, France, October 1‐5, 2001.

[67] Craig A. McLaughlin, Chris Sabol, Aaron Swank, Richard D. Burns and K. Kim Luu, “Modeling

Relative Position, Relative Velocity, And Range Rate For Formation Flying,” Proceedings of the AIAA

Guidance and Control Conference, Montreal, Quebec, August 2001.
114 of 118

[68] David A. Vallado, Fundamentals of Astrodynamics and Applications, Second Edition, Kluwer Academic

Publishers, Boston, MA, 2001.

[69] Hardwick, Greg, “False Pull Prevention,” Proceedings of the 26th Joint Services Data Exchange and GPS

Users Conference, Oxnard, CA, Oct. 23‐26, 2000.

[70] Stefan Lundin, “Finding The Balance Between Autonomy On‐Board Versus Man‐Triggered Actions

From The Ground,” 53rd International Astronautical Congress, October 10‐19, 2002.

[71] Penny Saunders, “GPS on the International Space Station Alpha,” Proceedings of the 1995 National

Technical Meeting of the Institute of Navigation, Anaheim, CA, January 18‐29, 1995.

[72] E. G. Lightsey, C. Campbell, Jr., R. Carpenter, J. Simpson and G. Davis, “Design and Performance of

Space Algorithms for the GPS Receiver Used on International Space Station and Crew Return Vehicle,”

International Workshop on Aerospace Applications of the Global Positioning System, Breckenridge, CO, January

31 to February 2, 2000, pages 583‐593.

[73] Susan F. Gomez, “Attitude Determination and Attitude Dilution of Precision (ADOP) Results for

International Space Station Global Positioning System (GPS) Receiver,” Proceedings of ION GPS 2000, Salt

Lake City, UT, September 19‐22, 2000, pages 1995‐2002.

[74] James R. Pendergrass, Alfred J. Treder and Susan F. Gomez, “GPS‐Updated Attitude Determination

on ISS Despite Rich Multipath,” Proceedings of the AIAA Guidance, Navigation and Control Conference,

Denver, CO, August 14‐17, 2000.

[75] Penina Axelrad, “Post‐Processed Attitude and Baseline Estimation for the GPS Attitude and

Navigation Experiment (GANE),” Proceedings of the 53rd Annual Meeting of the Institute of Navigation,

Albuquerque, NM, June 30‐July 2, 1997.

[76] J. Russell Carpenter and R. M. Hain, “Precise Evaluation of Orbital GPS Attitude Determination on

the STS‐77 GPS Attitude and Navigation Experiment (GANE),” Proceedings of the Institute of Navigation

National Technical Meeting, Santa Monica, CA, January 1997, pages 387‐398.

[77] Jaeyong Um, and E. Glenn Lightsey, “GPS Attitude Determination for the SOAR Experiment,”

Journal of the Institute of Navigation, Volume 48, Number 3, Fall 2001, pages 181‐194.

[78] Vladimir Branets, Mikhail Mikhailov, Yuri Stishov, Sergey Klyushnikov and Sergey Filatchenkov,

“Soyuz ‐ Mir Orbital Flight GPS/GLONASS Experiment,” Proceedings of ION GPS 1999, September 14‐17,

1999, Nashville, TN, pages 2303‐2311.

[79] A. Van Leeuwen, E. Rosen and L. Carrier, “The Global Positioning System and Its Application In

Spacecraft Navigation,” Global Positioning System – Papers Published In Navigation, Volume 1, The Institute

Of Navigation, Washington, D.C., 1980, pages 204 – 221.
115 of 118

[80] Dr. George T. Schmidt, “GPS/INS Technology Trends For Military Systems,” Proceedings of the AIAA

Guidance, Navigation, and Control Conference, AIAA, New Orleans, LA, August 11‐13, 1997, pages 1018‐

1034.

[81] Peter M. Kachmar and Lincoln J. Wood, “Space Navigation Applications,” Journal Of The Institute Of

Navigation, Vol. 42, No. 1, Spring, 1995, pages 187‐234.

[82] Judy L. Miller, “Spacecraft Navigation Requirements,” Aerospace Navigation Systems, AGARD‐AG‐

331, NATO, June 1, 1995, pages 390‐405.

[83] John F. Hanaway, and Robert W. Moorehead, Space Shuttle Avionics System, National Aeronautics

and Space Administration, NASA SP‐504, 1989.  

[84] Proceedings of the Space Shuttle Technical Conference, NASA Conference Publication CP‐2342, Parts 1 &

2, NASA Johnson Space Center, Houston, TX, June 28‐30, 1983.

[85] J. R. Thibodeau and S. R. Bauer, “Redundancy Management Of The Space Shuttle Inertial

Measurement Units,” Proceedings of the AIAA 1982 Guidance And Control Conference, San Diego, CA,

August 9‐11, 1982.

[86] Zdzislaw H. Lewantowicz and Danny W. Keen, “Opportunities and Challenges In Avionics

Integration, INS/GPS  ‐ A Case Study,” AGARD Conference Proceedings 525, Integrated and Multi‐Function

Navigation, NATO, 1992.

[87] James E. Brown III, “Ring Laser Gyro/Global Positioning System Navigation Improvement Program

Plus,” Proceedings of the IEEE 1998 Position Location and Navigation Symposium, Palm Springs, CA, April 20‐

23, 1998, pages 30‐37.  

[88] John T. Nielson, “The Untold Story Of The CALCM: The Secret GPS Weapon Used In The Gulf War,”

GPS World, Vol. 6, No. 1, January 1995, pages 26‐32.

[89] Anthony S. Abbott and Douglas E. Atkinson, “B‐2 GPS Aided Munition and Targeting System,”

Proceedings of the ION 1997 National Technical Meeting, Long Beach, CA, January 14‐16, 1997, pages 779‐

789.

[90] H. E. McCurdy, Faster, Better, Cheaper: Low‐Cost Innovation in the U.S. Space Program, Johns Hopkins

University Press, Baltimore, MA, 2001.

[91] R. Hoech, R. Bartholomew, V. Moen and K. Grigg, “Design, Capabilities And Performance Of A

Miniaturized Airborne GPS Receiver For Space Applications,” Proceedings Of The IEEE Position Location

And Navigation Symposium, IEEE, New York, NY, 1994.
116 of 118

[92] P. E. Saunders, M. C. Robel, M. E. Aerni, D. N. Feuerstein, S. B. Lowery and C. E. Cohen, “The First

Flight Tests Of GPS On The Space Shuttle,” Proceedings of the ION National Technical Meeting, San Diego,

Calif., January 24‐26, 1994, pp. 657‐669.

[93] John L. Goodman and Leonard Kramer, “Scintillation Effects On Space Shuttle GPS Data,”

Proceedings of the ION 2001 National Technical Meeting, Long Beach, CA, January 22‐24, 2001.

[94] Leonard Kramer and John L. Goodman, “Ionospheric Instability Observed in Low Earth Orbit Using

Global Positioning System,” AIAA Journal of Spacecraft and Rockets, Vol. 42, No. 1, January‐February 2005,

pages 124‐131.

[95] R. L. Greenspan, “GPS and Inertial Integration,” Global Positioning System: Theory and Applications II,

edited by Bradford W. Parkinson and James J. Spilker, Volume 164 of the Progress in Astronautics and

Aeronautics Series, AIAA, Washington, D. C., 1996, pages 187‐220.

[96] R. L. McHenry, T. J. Brand, A. D. Long, B. F. Cockrell and J. R. Thibodeau, “Space Shuttle Ascent

Guidance, Navigation, and Control,” The Journal of the Astronautical Sciences, Volume XXVII, No. 1,

January‐March, 1979, pages 1‐38.

[97] F. E. Smith, M. E. Campbell, T. J. Blucker, C. E. Manry and I. Saulietis, “Shuttle Orbiter Stellar‐Inertial

Reference System,” Journal Of Guidance And Control, AIAA, Vol. 6, No. 6, Nov.‐Dec. 1983, pages 424‐431.

[98] Alan D. Wylie and Howard G. deVezin, “Onboard Rendezvous Navigation For The Space Shuttle,”

Proceedings of the 41st ION Annual Meeting, ION, Annapolis, MD, June 25‐27, 1985, pages 64‐72.

[99] Richard H. Battin, An Introduction To The Mathematics And Methods Of Astrodynamics, Revised Edition,

AIAA, Reston, VA, 1999.

[100] P. Kachmar, “Apollo and Space Shuttle On‐Board Navigation Systems: Application of Kalman

Filtering Techniques,” 58th Annual Meeting of the Institute of Navigation and CIGTF Guidance Test

Symposium, Institute of Navigation, Fairfax, VA, 2002.

[101] Eugene S. Muller and Peter M. Kachmar, “A New Approach To On‐Board Navigation,” Journal of

the Institute of Navigation, Vol. 18, No. 4, Winter 1971‐1972, pages 369‐385.

[102] Dr. Lubomyr V. Zyla, and Moises N. Montez, “Use of Two GPS Receivers In Order To Perform

Space Vehicle Orbital Rendezvous,” Proceedings of the Institute of Navigation GPS‐93 Conference, ION,

September 22, 1993, pages 301‐312.

[103] James J. Ewell, “Space Shuttle Entry Through Landing Navigation,” Proceedings of the Position

Location and Navigation Symposium, IEEE, Atlantic City, NJ, December 6‐9, 1982, pages 110‐117.
117 of 118

[104] Marc Harlacher, “The Low Power Transceiver (LPT) For Space Applications,” Proceedings of the

AIAA Space 2001 Conference and Exposition, Albuquerque, NM, August 28 to 30, 2001.

[105] S. Draganov, B. Veytsman and L. Haas, “Space Applications Algorithms and Initial Simulation

Results for the ITT Low‐Power Transceiver,” Institute of Navigation GPS/GNSS 2002 Conference, Portland,

OR, September 23‐24, 2002.

[106] L. Haas, C. Massey, and D. Baraban, “Navigation Flight Test Results from the Low Power

Transceiver Communications and Navigation Demonstration on Shuttle (CANDOS) Experiment,”

Institute of Navigation GPS/GNSS 2003 Conference, Portland, OR, September 9‐12, 2003.

[107] R. Hart, A. Long, and T. Lee, “Autonomous Navigation of the SSTI/Lewis Spacecraft Using the

Global Positioning System (GPS),” Proceedings of the Flight Mechanics Symposium 1997, NASA Conference

Publication 3345, May 19‐21, 1997, pages 123‐133.

[108] D. A. Tazartes and J. G. Mark, “Integration Of GPS Receivers Into Existing Inertial Navigation

Systems,” Journal Of The Institute Of Navigation, Volume 35, Number 1, Spring, 1988, pages 105‐119.

[109] R. Dale Reed, Wingless Flight – The Lifting Body Story, The University Press of Kentucky, Lexington,

KY, 2002.

[110] Ricardo Machin, Jenny Stein, and John Muratore, “An Overview Of The X‐38 Prototype Crew

Return Vehicle Development And Test Program,” 15th CEAS/AIAA Aerodynamic Decelerator Systems

Technology Conference, Toulouse, France, June 8‐11, 1999.

[111] M. Shaw, K. Sandhoo, and D. Turner, “Modernization of the Global Positioning System,” GPS

World, Volume 11, Number 9, September 2000, pages 36‐44.

[112] W. Marquis, “M Is For Modernization,” GPS World, Volume 12, Number 9, September 2001, pages

36‐42.

[113] P. Misra and S. Bednarz, “Navigation for Precision Approaches: Robust Integrity Monitoring Using

GPS+Galileo,” GPS World, Volume 15, Number 4, April 2004, pages 42‐49.

[114] K. Van Dyke, et al., “GPS Integrity Failure Modes and Effects Analysis,” Institute of Navigation 2003

National Technical Meeting, January 22‐24, 2003, Institute of Navigation, Fairfax, VA.

[115] L. B. McWhorter and H. G. Law, “Shuttle Autoland Status Summary,” AIAA Space Programs and

Technologies Conference, AIAA, Reston, VA, 1992.

[116] G. M. Tsikalas, “Space Shuttle Autoland Design,” AIAA Guidance and Control Conference, AIAA,

Reston, VA, 1982.
118 of 118

[117] M. C. Robel and P. L. Harton, “Microwave Scanning Beam Landing System Performance During

Shuttle Landings,” Proceedings of the IEEE National Telesystems Conference, IEEE, New York, NY, 1983.

[118] D. A. Stratton, “Certification and Operational Performance of GPS‐Based Landing Systems,”

Proceedings of the Institute of Navigation 2002 National Technical Meeting, Institute of Navigation, Fairfax,

VA, 2002, pages 507‐515.

[119] P. Sousa, L. Wellons, and G. Colby, “Results of Shipboard Relative GPS (SRGPS) Testing for the

Pegasus X‐47A Unmanned Combat Air Vehicle (UCAV),” Proceedings of the Institute of Navigation 59th

Annual Meeting, Institute of Navigation, Fairfax, VA, 2003.

[120] T. Katanik, et al., “Interoperability Between Civil LAAS and Military JPALS Precision Approach

and Landing Systems,” Proceedings of the Institute of Navigation GPS Conference, Institute of Navigation,

Fairfax, VA, 2001, pages 1179‐1189.

[121] J. Waters, P. Sousa, L. Wellons, G. Colby, and J. Weir, “Test Results of an F/A‐18 Automatic Carrier

Landing Using Shipboard Relative GPS,” 57th Annual Meeting of the Institute of Navigation, Institute of

Navigation, Fairfax, VA, 2001, pages 841‐851.

[122] J. Croft, “Pegasus: UCAVs Look Seaward,” Aerospace America, Vol. 41, No. 9, September 2003, pages

36‐42.

[123] B. Pervan, F. Chan, D. Gebre‐Egziabher, S. Pullen, P. Enge, and G. Colby, “Performance Analysis of

Carrier‐Phase DGPS Navigation for Shipboard Landing of Aircraft,” Journal of the Institute of Navigation,

Volume 50, Number 3, Fall 2003, Institute of Navigation, Fairfax, VA, pages 181‐191.
REPORT DOCUMENTATION PAGE Form Approved 

OMB No. 0704-0188 

Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and 

maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including 

suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, 

and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503. 

1. AGENCY USE ONLY (Leave Blank) 2. REPORT DATE 3. REPORT TYPE AND DATES COVERED 

 November 2005 NASA Contractor Report 

4. TITLE AND SUBTITLE 5. FUNDING NUMBERS

GPS Lessons Learned from the International Space Station, Space Shuttle and X-38 

6. AUTHOR(S) 

John Goodman 

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION 

REPORT NUMBERS

Lyndon B. Johnson Space Center 

Houston, Texas 77058 

S-969 

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSORING/MONITORING 

AGENCY REPORT NUMBER

National Aeronautics and Space Administration 

Washington, DC 20546-0001 

CR-2005-213693 

11. SUPPLEMENTARY NOTES 

 

12a. DISTRIBUTION/AVAILABILITY STATEMENT 12b. DISTRIBUTION CODE 

Available from the NASA Center for AeroSpace Information (CASI) 

7121 Standard 

Hanover, MD 21076-1320 Category: 03 

13. ABSTRACT (Maximum 200 words)

This document is a collection of writings concerning the application of Global Positioning System (GPS) technology to the 

International Space Station (ISS), Space Shuttle, and X-38 vehicles. An overview of how GPS technology was applied is given for 

each vehicle, including rationale behind the integration architecture, and rationale governing the use (or non-use) of GPS data during 

flight. 

14. SUBJECT TERMS 15. NUMBER OF 

PAGES 

16. PRICE CODE 

International Space Station, Space Shuttle, lessons learned, Space Shuttle, X-38 120 

17. SECURITY CLASSIFICATION 

OF REPORT 

18. SECURITY CLASSIFICATION 

 OF THIS PAGE

19. SECURITY CLASSIFICATION 

OF ABSTRACT

20. LIMITATION OF ABSTRACT 

Unclassified Unclassified Unclassified Unlimited 

Standard Form 298 (Rev Feb 89) (MS Word Mar 97) 

Prescribed by ANSI Std. 239-18 

298-102 

NSN 7540-01-280-5500