Hybrid GPS/Galileo Real Time
Software Receiver
Per-Ludvig Normark, Christian Sthlberg
NordNav Technologies
BIOGRAPHY
Per-Ludvig Normark is Chief Technical Officer at
NordNav Technologies. He received his M.Sc. in
Computer Science from Lule University of Technology.
And he has been working as a research engineer at the
Stanford University GPS laboratory. His interest is
focused on software receivers and high accuracy/integrity
GNSS implementations.
Christian Sthlberg, Signal Processing Engineer at
NordNav Technologies, has received a M.Sc. in
Computer Science from Lule University of Technology.
He is focusing on baseband processing of new GNSS
signals, efficient implementations and mapping of
algorithms onto programmable processors.
ABSTRACT
Galileo is designed to be interoperable but independent
from GPS. Interoperability means that user receiver
equipment should be able to take advantage of both
systems to increase accuracy, integrity, and overall
performance. Compatibility, on the other hand, implies
that the two systems should operate concurrently but
independently, with as little impact on each other as
possible. The inclusion of Galileo should not degrade
GPS standalone performance, and conversely GPS should
not impact Galileo processing. The interoperability,
despite frequency overlap, is accomplished through the
use of different signal structures and codes. The
frequency overlap, or essentially using the same carrier
frequency, greatly simplifies the radio frequency (RF)
design and reduces the cost for hybrid receivers; the same
antenna and front end can be used to receive signals from
both systems. The digital signal processing of the signals
will, however, differ.
This paper presents the design and implementation of a
hybrid software GPS/Galileo receiver, together with
testing and performance results using a GPS/Galileo
software intermediate frequency (IF) simulator.
INTRODUCTION
Software defined radio (SDR) is a concept for
transceivers in which the signal processing is
accomplished via a programmable general-purpose
microprocessor or digital signal processor (DSP), as
opposed to an application-specific integrated circuit
(ASIC).
A fully software Global Navigation Satellite System
(GNSS) receiver implementation holds many advantages
over traditional receiver designs. The most significant of
these advantages include the ability to do dynamic
reconfiguration; the ability to reuse hardware in system
design; and rapid design and prototyping cycles. The
complete list is quite extensive, and is an important factor
in light of upcoming expansions in GNSS service,
including not only Galileo but also the forthcoming
modernized GPS signals (Block IIR-M) and the Quasi-
Zenith Satellite System (QZSS).
Software GNSS receivers are a reality today and are
receiving market acceptance as a feasible alternative to
traditional hardware designs in certain applications. The
authors demonstrated one of the first fully real-time
software GPS receivers in 2000 [2] and have continued to
develop software receiver technology further at NordNav
Technologies. At present, a handful of research institutes
are developing real-time software receivers [4,5], with
efforts concentrating on multiple frequencies and wide
bandwidth processing. Many are using software receivers
as core tools in their research [7,8].
GALILEO AND GPS
Galileo and GPS interoperability means that hybrid
receivers will offer improved performance in several
ways compared to GPS- or Galileo-only receivers. The
availability of satellites (29 GPS and 27 Galileo) will
offer significant improvements in acquisition and tracking
in demanding environments such as cities, where satellites
are often blocked by buildings. Additionally, hybrid
receivers can select those subsets of visible satellites that
improve multipath performance for a given antenna
location. Integrity performance will also benefit from the
presence of the two independent systems.

GPS
GPS
Galileo
Figure 1 GPS and Galileo illustration in city
The civil GPS and Galileo L1 Open Service will operate
in the same frequency band (L1, 1572.42 MHz) and will
therefore greatly simplify the receiver design, since the
antenna and front end can be the same for both systems.
However the signal processing differs, which will require
changes to the receiver baseband processing. Figure 2
plots the spectrum of the GPS C/A code and the Galileo
BOC(1,1) at L1 frequency.
Figure 2 GPS C/A and Galileo BOC(1,1) in L1 band
GNSS SOFTWARE RECEIVERS
The ideal software radio, consisting of a single antenna,
analog-to-digital converter (ADC), and microprocessor, is
unrealistic today. Current technology does not allow for a
single hardware platform to process an arbitrarily wide
variety of existing radio frequency (RF) signals. The
ADC limits the bandwidth and dynamic range that can be
captured, and the processing elements (microprocessors,
DSPs, or gate arrays) cannot always meet the
computational requirements. Even if such a platform did
exist, it would not likely be cost-effective given current
technology.
However, for band limited signals, such as GPS/GNSS,
software receiver solutions are feasible. A software-based
implementation allows for high integration of GNSS
functionality with other systems/sensors, such as tightly
coupled navigation systems, and can also be upgraded to
take advantage of new ranging signals when such signals
become available.
Since GNSS signals are band limited, a traditional down
conversion front end can be used together with a proper
antenna this essentially overcomes the shortcomings in
the current state-of-the-art antenna and ADC technology
for software receivers. Ideally, the chosen downconverter
has the ability to select which RF band to translate (L1,
L2 or L5) and what bandwidth to capture (2-50 MHz).
Todays processing elements are capable of real-time
GPS/GNSS processing. A realizable software receiver for
GNSS signals with todays technology is illustrated in
Figure 3. This architecture is compatible with all known
front end architectures.
Antenna Microprocessor/DSP
Analog RF Front End
AGC
N
2
Digital
Digital IF
Pre Amp
(LNA)
Down
Converter
Analog IF A/D
Converter
Baseband
Channel 1
Reference Frequency
Oscillator Synthesizer Navigation Acquisition
Processing Tracking
Figure 3 A feasible commercial software GNSS
receiver architecture
The software receiver implementation discussed in this
paper has been designed to operate as a fully standalone
GPS receiver with the architecture described above.
IF SOFTWARE SIGNAL GENERATOR
Due to the early stage of the Galileo signal specification
(the interface control document (ICD) is not yet publicly
available), no signals in space or hardware signal
simulators are directly available for test and verification
of Galileo software receiver prototypes. To enable
functionality and performance testing of the Galileo
signal, an IF software signal generator was developed by
NordNav Technologies.
Figure 4 describes the architecture of the signal generator.
The signal generator consists of an API and a graphical
user interface that gives the user the ability to configure
the signals in a number of different ways. The user
decides the number of satellite signals that should be
generated. Each signal can be set to be either a GPS L1
signal or a Galileo L1 signal. The signal can also be
described with signal ID (PRN for GPS), approximate
C/No, carrier Doppler, and delays between different
signals. The data of the signal can also be specified. The
front end can be described by sampling frequency,
intermediate frequency, analog bandwith, and the number
of bits per sample. It is also possible to describe the
analog shape of the RF front end by specifying the taps of
an FIR filter. The generator can also produce signals that
contain enough navigation data to give a valid position
solution when used in a software receiver. This is done by
using GPS ephemeris to describe the satellites' positions
and specifying a time and a user position in the signal
generator. The delays and Doppler of the different signals
are then used to produce the valid position signal.
 Software Signal Generator
GUI
IF Signal Doppler Power Navigation
Noise Generator
Model Model Message
Signal Generator API Generator
AWGN N(0,1)

Galileo Signal Bandpass

Position Object Signal Description 1 Frontend Description
L1A/L1B/L1C FIR filter
Signal Description 2
Compute SVs SV id Description N
Signal Sampling Code/Carrier
XYZ Frequency Doppler
Doppler
SV id
Compute Time Intermediate Data modulation
Power
Doppler
SV id
Delays Frequency Hexaphase
Time Delay
Power
Doppler ADC bits modulation
Time Delay
Power Filter shape
Time Delay parameters

Software Signal Generator Signal Bandpass Signal Complete Signal

FIR filter
Combiner Tuner
Signal Generator

IF Signal Generator
Signal Combiner
S tot + n
Noise Generator Signal Adder
Signal Tuner N
S tot = S k
Quantizer CNo Meter
k =1

Hard Drive
Raw Signal Output Complete Signal Output

Figure 4 Architecture IF Signal Generator

The Software Signal Generator contains several sub
modules shown in Figure 5. Each of the signal
descriptions is applied to the IF Signal Generator block,
where a complete BOC(1,1) Galileo L1 signal is
generated including code/carrier Doppler and data
modulation. The amplitude of each signal is scaled such
that a desired power relation with respect to all signals is
achieved. Both the Doppler and power for a specific
signal are controlled by the selected model and the initial
values given in the signal description. The output from
this block is a sampled IF signal with a bandwidth
matched to the sampling frequency specified in the
description of the front end.
Figure 5 Submodules of the Signal Generator
NORDNAV R30 SOFTWARE RECEIVER
The NordNav R30 aims to bring all benefits of a real-time
software implementation into a high-end receiver. It is a
24-channel L1 software receiver system targeted for
research and development and testing and verification.
The entire signal processing load (acquisition, tracking
and navigation processing) is carried out on a single PC
microprocessor. For more details see [3]. Below is
summary of the R30.

The IF Signal Generator output is fed to the Signal

Combiner block where all generated IF signals are
combined and then filtered with an FIR bandpass filter
specified by the front end description. The specified filter
taps represent the desired parameterized analog shape of
the RF front end. The data is then scaled to an appropriate
amplitude and passed to the Signal Tuner, which adds
bandpass filtered Gaussian noise (using the same filter as
in the combiner) and quantizes the signal to the
configured number of bits. The resulting signal has the
desired C/N0. Since all underlying signals already have
correct power relations with respect to each other, it is
only necessary to tune one of the underlying signals. It is
also possible to generate noise-free signals with Signal
Generator. Figure 6 NordNav R30 software receiver

The receiver runs in two modes: 1) real-time mode or 2)

post process mode. In the real time mode, the number of
channels which can operate is limited only by
computational power.

The architecture is very modular and flexible, prepared

for extensions of new signal structures and multiple
antennas.
Antenna Microprocessor
USBv2
Data
Interface IF Samples
TCXO
IF Recorder
API
Multibit
User
Front End
Hard
App
Multibit
drives
Front End
Multibit
Front End
Multibit
Front End
Receiver GUI
Figure 7 NordNav R30 Architecture
Data interface and frontend
Figure 6 shows the L1 front end to the left in the picture.
A data interface based on USB2.0 has been developed to
transfer IF samples continuously from the front end into
the RAM of the PC. The R30 USB2.0 datainterface
supports up to 200 Mbit/s (25 MByte/seconds) of
continues transfer rate.
The L1 front end currently shipped with the R30 is based
upon a commercial ASIC downconverter. It provides
multibit IF sampling and allows external monitoring and
control of the automatic gain control (AGC) circuitry.
NordNav Front end specification
L1 frequency 1575.42 MHz
Sampling Frequency: 16.3676 MHz
Intermediate Frequency: 4.1304 MHz
Analog bandwidth 2.0 MHz
1, 2, or 4 bit sampling
External oscillator support
USB2.0 port
No need for external power (powered by PC
USB port)
Up to four front-end boards can be supported by the R30
receiver. Channels and correlators can be slaved to each
other in virtually any arrangement; this is ideal for
applications such as bistatic radar.
While processing data in real time, the R30 can also be
configured to continuously record multibit samples to the
hard drive for post-processing. File sizes are limited only
by available hard disk space. For example, using 4 bit
samples and a 16.3676 MHz sampling frequency results
in a data storage rate of ~8 MByte/s (1 minute of data is
about 470 MByte) which most PC hard drives and
external firewire drives can handle continuously. The R30
can also can be set up for Triggered Recording, in
which data logging begins when a predetermined event
occurs. Examples include a new satellite rising in the sky,
or the detection of an anomalous condition using
conventional signal quality monitoring (SQM) events
flagged by one or more correlator outputs. In any event,
the trigger causes the R30 to start recording samples to
Correlator Acqusition Acqusition the hard drive. This mode is expected to be particularly
Engine Loop API
Engine
useful for capturing the first Galileo satellite signals.
I&Q
Acqusition & Tracking
Rx
Tracking Loop API
Receiver processing
API Datadecode Measurement
All signal processing takes place on the PC processor.
Navigation
API Navigation The receiver has a very modular and flexible design and
SBAS Clock has support for a configurable sampling frequency of up
Rangecodes
Channel
Control
to 40 MHz and 16 bit IF samples (it can be extended to
support higher sampling frequencies).
Misc Tools
The receiver includes a GUI and also a well-documented
API for users who wish to integrate the receiver with
other applications.
Initialization
When the user has configured all parameters in the API or
GUI, such as acquisition and tracking loop, update rate,
the receiver tests or probes the current configuration on
the PC to estimate the runtime parameters. The receiver
determines how many acquisition bins can be performed
in parallel and how many channels can be correlated in
real time. Since a non real-time operating system is used
(Windows XP), overhead must be used in order to
compensate for slow response time. The performance
numbers below are given without overhead included.
Acquisition
A parallel acquisition engine is utilized to do a fast code
and Doppler search. The user can control how many
coherent integration periods are used and how large the
Doppler bins should be. As input the acquisition module
requires IF samples, a code sequence vector (for example
a C/A vector) and Doppler frequency bin to search. The
acquisition module computes and correlates all possible
code phases and returns an I and Q result for each code
phase step. The code is searched using a 0.125-chip
spacing.
On a 1.7 Ghz Pentium-M processor using 1 C/A code
period coherent time (1 ms), 1315 Doppler bins can be
searched per second with a resolution of 0.125 chip. This
is equivalent to approximately 21 000 correlators (10 500
I and Q pairs).
Tracking
The correlator engine takes as input raw IF samples, a
code vector, code frequency, code phase, carrier
frequency and carrier phase. It outputs I and Q
accumulations for each correlator and code period
(typically 1 ms for C/A). The standard correlator is a
early-late-prompt configuration, where the user can select
among predefined early-late chip spacings. It is also
possible to use multiple correlators: up to 32 correlator
pairs (I and Q) can be used per channel, and the spacing
for each correlator can be set by the user.
The tracking loops consist of a delay lock loop (DLL) for
tracking the code and a phase lock loop (PLL) to track the
carrier. The user can configure the loop bandwidth,
integration time, and what correlator pair to use for
tracking.
A separate API, called External Tracking Loop
Framework, has been developed for the user to implement
his own discriminators and tracking loop to control code
and carrier NCOs. The user follows a interface file (C
header file) and implements his own code. This is
compiled into a dynamic linked library (DLL). For each
channel and accumulation period, the receiver calls a
CloseLoop function in the DLL.
NordNav
R30 GUI
Visual C Framework
User implemented code - dll
NordNav R30 API Example implementation included
NordNav CloseLoops API
R30
Receiver
CloseLoops.dll
Figure 8 External Tracking Loop Framework
All correlator accumulations are passed on together with
current code and carrier frequencies and conventional
GNSS observables such as pseudorange, carrier phase,
and receiver position (and are updated at the resulting
measurement update rate).
This framework is very useful for implementing advanced
discriminators and loop structures for GPS and Galileo.
For example, it allows for aiding the loops with externally
derived Doppler information from an IMU [8].
Navigation filter
The R30's navigation engine is designed for integration
into user applications using the NordNav API. Least-
squares estimation techniques using pseudorange and
Doppler measurements are utilized to solve for position,
time, and velocity. Epoch-by-epoch least squares
estimation facilitates analysis of each epoch
independently. In addition, advanced fault detection
methods are used to identify erroneous measurements, for
example due to multipath signals, and remove them from
the estimation. The navigation API is designed to allow
users to implement their own estimation for specific
applications. This allows for hybrid GPS and Galileo
experimentation of the navigation solution.
Spectrum Monitoring and Signal Injection
The receiver has the functionality to inject simulated IF
samples into real-world collected GPS samples, as shown
in Figure 9. This functionality was originally developed in
order to investigate the new Galileo signals [6] and is
used for that purpose in this paper, but it also allows study
of the effects of interference signals on GPS signal
processing algorithms in a controlled way.
GPS Signal
Stored GPS
samples
Sample
Antenna Streamer Multiplication
factor
Front end A/D R30 Software
Receiver
Stored external
signal samples Signal Combiner
Example :
Simulated CW, Noise
Figure 9 Signal Injection of simulated jamming signal
Figure 10 shows the real-time spectrum plot in the
receiver GUI. In this example, a 15 dB CW tone, 500 kHz
off the L1 frequency, is simulated in Matlab and injected
into real GPS samples prior to receiver processing.
Figure 10 The GPS spectrum generated by the
receiver with a simulated 15 dB CW tone 500 KHz off
the downconverted L1 intermediate frequency
GALILEO EXTENSION TO R30
To support Galileo BOC(1,1), some additions were
needed in the NordNav R30 receiver.
The spreading codes used by the prototype Galileo
BOC(1,1) require new PRN codes to be generated (no
specifications is yet available). The PRN codes used in
the simulator and the receiver are for BOC(1,1) data and
pilot channel are truncated gold codes (4092 chips long)
and are similar to the ones used by GPS. The BOC
modulation scheme also requires a square wave generator
to be added.
In the acquisition module, because of the shape of the
BOC correlation peak, care must be taken so that the main
peak is used. This is not a problem in receivers that search
all code phases for each frequency bin simultaneously and
can identify the highest peak.
For optimal performance, new discriminator functions are
needed in the tracking module.
FRONT END BANDWIDTH BOC(1,1)
The analog bandwidth of the receiver front end will
determine how much of the signal energy can be captured.
Any bandwidth-related signal loss will be greater for
Galileo BOC(1,1) than for GPS C/A for a given front end,
because of the wider spectral shape of BOC(1,1).
Figure 11 shows theoretical signal loss vs. front end filter
bandwidth for both GPS C/A and Galileo BOC(1,1) using
an ideal filter (box filter shape). The x-marks in the plot
shows the correlation loss for a GPS C/A and a BOC(1,1)
signal after it has been filtered by the filter shown in
Figure 12. The filter is a 19-tap FIR filter designed to
resemble the real filter in the NordNav front end. The fact
that the correlation loss on the GPS signal is less than the
ideal filter is due to the front end of the R30 was
optimized for the GPS C/A signal, with a slight gain on
the C/A-code main lobe. For the same reason, the
correlation loss is slightly worse for the BOC(1,1) signal.
To accommodate the Galileo L1 signals, an analog
bandwidth of 4 MHz in the front end is sufficient. The
correlation loss will then be less than 1dB for both GPS
and Galileo without being specifically designed for either.
Figure 11 Signal loss vs. front end filter bandwidth
Figure 12 NordNav R30 front end filter replica
HYBRID GPS/GALILEO PROCESSING IN R30
Presently, no live Galileo signal in space exists.
Therefore, it was necessary to generate Galileo signals
using the NordNav IF Signal Generator to demonstrate a
hybrid Galileo/GPS processing with the NordNav R30
receiver. The full Galileo L1 signal was generated
including the BOC(1,1) data signal, the BOC(1,1) pilot
signal and the BOC(15,2.5) signal. The receiver only
tracked the BOC(1,1) data signal, however.
The GPS data was real data recorded with the NordNav
R30 receiver collected in Stockholm, Sweden. The
sampling frequency of the data is 16.3676 MHz and 4 bits
per sample.
Four different Galileo signals were generated with signal
IDs 1, 2, 3 and 4, with a carrier Doppler of -1500, 1500, 0
and 4500 Hz, respectively. The signals were generated
with 8 bits per sample. No noise was added. The front-
end filter was developed to be very similar to the
designated filter shape of the front end that was used to
record the GPS data file. Figure 13 shows the recorded
GPS files PSD plot and Figure 14 shows the PSD plot of
generated noise with the same front-end filter that was
used in the generation of the Galileo signals.
Figure 13 PSD plot of the real GPS file.
Figure 14 PSD plot of generated noise with the same
front end filter that was used in the generation of the
Galileo signals.
To combine the live GPS data file and the generated navigation data for Galileo will look like. As shown in the
Galileo signal, the Signal Injection feature of the figure, the Doppler frequency also has the correct value.
NordNav R30 was used. Figure 15 shows an overview of
the injection of the generated Galileo signal to the live
GPS signal [5].

Figure 15 Set up with live GPS signal and generated

Galileo signal
To be able to see the difference in the correlation peak
between GPS and Galileo signals, some channels were
configured to use multiple correlators as shown in figure
16.
Figure 17 Running the receiver with the first two
channels tracking the Galileo BOC(1,1) data signal
and four channels tracking GPS signals.
Figure 18 that shows the resulting correlation peaks of the
first six channels.. Channels 1-3 uses multiple correlators
with the set up shown in Figure 16, while channels 4-6
use a standard early, prompt, late correlator. Green
correlators indicates the tracking pair. Channels 1 and 2
show the peak of the BOC(1,1) signal which can be
compared to the normal peak of the GPS signal shown in
channel 3. Note that the figure shows the peak magnitude;
the side peaks of the BOC(1,1) signal are negative.

Figure 16 To be able to see the correlation peak of the

Galileo signal compared to the GPS signal a multi
correlator was used for some channels. The correlator
has one prompt correlator and then 7 equally spaced
early late correlation pairs.
The result of running the combined GPS and Galileo data
can be seen in figure 17. Channels 1 and 2 are used to
track the BOC(1,1) data signal and channels 3-6 is used to Figure 18 The correlation peak of the different signals.
track GPS signals. The GPS signals are tracked properly Channel 1 and 2 shows the BOC(1,1) peak while
and the position can be decoded as shown in the figure. channel 3 shows the GPS L1 peak, all with multiple
The Galileo signals are also in code lock, however no data correlators. Channel 4-6 shows the GPS L1 peak with
is decoded because of the lack of specification of how the the standard correlator.
Figure 19 shows the performance of the R30 software
correlator in various analog bandwidths in the front end
when computing early, late and prompt I and Q
correlators while tracking Galileo BOC(1,1) signals. The
sampling frequency is 2.5 times the bandwith to allow for
realistic filter implementations. For example 4 MHz
bandwitdh corresponds to 10 MHz sampling frequency.
This correlator is designed for flexibility and 16 bit
samples. It is not optimized for lowest processing load but
allows for real-time tracking of 15 channels GPS/Galileo
L1 signals from a front end sampling at a 10 MHz.
Nr channels with R30 correlator performance on a 3.2 GHz P4 Laptop
30
25
Nr Channels
20
15
10
5
2 3 4 5 6 7
filter bandwidth (MHz)
Figure 19 R30 software correlator tracking Galileo
signals versus different filter bandwidths.
CONCLUSIONS
Software GNSS receivers offer significant advantages
over traditional hardware designs due to their inherent
architectural flexibility. This paper describes a fully
software hybrid GNSS receiver capable of real time
acquisition and tracking of GPS C/A and Galileo
BOC(1,1) data channel and pilot channel.
In conjunction with the receiver, a software IF simulator
is also presented. This device simulates the GPS L1
constellation (C/A code) and Galileo L1 Open Service
signals, and is used together with live GPS data to verify
receiver performance in a hybrid signal environment. The
simulator enables full bit-true validation of the receiver's
Galileo Open Service performance even though no
Galileo satellites have yet been launched. The simulation
shows that software receivers are a feasible choice for
hybrid GPS/Galileo L1 applications.
GNSS software receivers are an emerging technology
enabling the creation of new applications. The continued
demand for more information and modernized radio
navigation systems, combined with the exponential
evolution of processing power may well see the extinction
of some application specific integrated circuits.
ACKNOWLEDGEMENT
Part of this work has been funded by the Swedish
National Space Board (SNSB) under the RyT 1 program
and we thank them very much for their support of this
work. Also great thanks to all the colleagues at NordNav
Technologies who has contributed to this work.
REFERENCES
[1] Akos, D., A Software Radio Approach to GNSS
Receiver Design, Ph.D. Dissertation, Ohio
University, 1997.
[2] Akos, D., Normark, P.-L., Hansson, A., Rosenlind,
A., Stahlberg, C., Svensson, A., Global Positioning
System Software Receiver (gpSrx) Implementation in
Low Cost/Power Programmable Processors,
Proceedings of ION NTM 2001, Long Beach, CA,
January 22-24, 2001, pp. 809-816.
[3] Normark, P-L., MacGougan, G., Stahlberg, C.,
GNSS Software Receivers a Disruptive
Technology, Proceedings of GNSS Symposium
8 9 10
2004, Tokyo, Japan, November 19, 2004.
[4] Pany, T., Frster, F., Eissfeller, B., Real-Time
Processing and Multipath Mitigation of High-
Bandwidth L1/L2 GPS Signals with a PC-based
Software Receiver, Proceedings of ION GNSS
2004, Long Beach, CA, September 21-24, 2004.
[5] Ledvina, B., Psiaki, M., Sheinfeld, D., Cerruti, A.,
Powell, S., Kinter, P., A Real-Time GPS Civilian
L1/L2 Software Receiver, Proceedings of ION
GNSS 2004, Long Beach, CA, September 21-24,
2004.
[6] Normark, P.-L., Sthlberg, C., Seco, G., Interference
Study Processing Live GPS L1 Data with Injected
Galileo L1 Data in a High-Performance GNSS
Software Receiver, ION GPS 2003, Portland, OR,
September 9-12, 2003.
[7] Manandhar, D., Shibasaki, R., Normark, P.-L., GPS
Signal Analysis Using LHCP/RHCP Antenna and
Software GPS Receiver, Proceedings of ION GNSS
2004, Long Beach, CA, September 21-24, 2004.
[8] Chiou, T.-Y., Alban, S., Atwater, S., Gautier J.,
Pullen, S., Enge, P., Akos, D., Gebre-Egziabher, D.,
and Pervan, B., Performance Analysis and
Experimental Validation of a Deeply Integrated
GPS/INS Receiver for JPALS Applications,
Proceedings of ION GNSS 2004, Long Beach, CA,
September 21-24, 2004.
[9] Kaplan, E., ed., Understanding GPS: Principles and
Applications, Artech House, ISBN: 0890067937,
March 1996.