A Labview-Based Assisted GPS Receiver Development, Simulation and Testing Platform

Arpine Soghoyan, Grant Huang, Jayanthi Narisetty, David Akopian The University of Texas at San Antonio

BIOGRAPHIES
Arpine Soghoyan - received her B.Sc./M.Sc. degrees in Radiophysics and Electronics department of the Yerevan State University, and M.Sc. in Computer and Information Science at the American University of Armenia. Currently she is a Ph.D. student in Electrical Engineering at the University of Texas at San Antonio. Her research focuses on Software Defined Radio and GPS receivers. Grant Huang - received his M.Sc. degree from the University of Texas at San Antonio (UTSA) in 2009 and is currently a Ph.D. student in the Department of Electrical and Computer Engineering (ECE) at UTSA. His research interests include satellite/wireless channel modeling, Assisted-GPS/GNSS (A-GPS/GNSS) and remote experimentation systems. Jayanthi Narisetty - received her BS degree in Electronics and Communications from Jawaharlal Nehru Technological University (JNTU), Hyderabad, India in 2009 and is currently pursuing her MS degree in Electrical Engineering at The University of Texas at San Antonio. Her current research interest includes Assisted GPS (A-GPS) Simulator Support for different wireless devices. David Akopian is an Associate Professor at the University of Texas at San Antonio (UTSA). He joined UTSA in 2003 where he founded Software Communication and Navigation Systems Laboratory. He received the M.Sc. degree in radio-electronics from the Moscow Institute of Physics and Technology in 1987 and Ph.D. degree in Electrical Engineering from the Tampere University of Technology (TUT), Finland, EU, in 1997. From 1999 to 2003 he was a Senior Engineer and Specialist with Nokia Corporation. Prior to joining Nokia in 1999 he was a member of teaching and research staff of TUT. His current research interests include digital signal processing algorithms for communication and navigation receivers, positioning methods and mobile applications.

in strong signal conditions, their operation in many urban and indoor applications is not robust or even impossible due to strong distortions. The research community continuously explores new ideas and methods in an effort to design less costly, faster and more sensitive receivers. State-of-the-art receivers should be flexible to perform multimode tasks tailored to various conditions. The developers need reference receivers, associated Software Development Kits (SDKs), development platforms, simulators and testbeds to accelerate and facilitate their research. This paper presents such an integrated environment to reduce the development cycle and conveniently simulate and test receivers. The proposed testbed includes GPS signal simulator (transmitter) from National Instruments (NI) and several modules developed by authors for Labview, a development environment from NI. These are channel simulation module, a GPS software defined receiver, and Assisted GPS (A-GPS) support. The paper also describes the integration of hardware accelerators such as Field Programmable Gate Arrays (FPGAs) and Digital Signal Processors (DSPs). Receiver modules can be implemented in C/C++ or using Labview library components.

1. INTRODUCTION
The US Global Positioning System (GPS) and other existing and emerging Global Navigation Satellite Systems (GNSS) enable more and more civil and military applications as the accuracy and coverage of the receivers steadily improve [1],[2]. While GNSS systems perform very well in strong signal conditions, their operation in many urban and indoor applications is not robust or even impossible due to weak signals and strong distortions. The research community continuously explores new ideas and methods in an effort to design less costly, faster and more sensitive receivers. With higher receiver requirements one should address more complicated phenomena and typically state-of-the-art receivers should be flexible to perform multimode tasks for a processing tailored to various conditions. The developers need reference receivers, associated SDKs, development platforms, simulators and testbeds to accelerate and facilitate their research. To have high performance multimode receivers in the weak signal environments massive correlators are used. But as described in [3], in past few years there has been

ABSTRACT
The US Global Positioning System (GPS) and other existing and emerging Global Navigation Satellite Systems (GNSS) enable more and more civil and military applications as the accuracy and coverage of the receivers steadily improve. While GNSS systems perform very well

24th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland OR, September 19-23, 2011

1982

an evolution from hardware massive correlators and accelerators to Software Defined Radio (SDR) where real-time correlators, tracking loops, and navigation calculation are all implemented in software or using general purpose accelerators such as FPGA and DSP peripherals. Fig. 1 shows cost and host Central Processing Unit (CPU) usage for different hardware software configuration [4]. Software GNSS receivers require fewer hardware components and offer greater flexibility compared to traditional receivers whose correlators and accumulators are implemented in dedicated Application Specific Integrated Circuits (ASIC) technology.

reconfigurable and the performance can be compared to that of ASIC receivers. Although hardware-based implementations require longer development cycles and additional hardware-software interfacing efforts, FPGAs and DSPs are compromise solutions with well developed available support which facilitates development. Examples of FPGA based GNSS receivers can be found in [10],[11]. DSP is hardware that is specifically optimized for the efficient execution of common signal processing tasks. Unlike ASICs, DSPs are not as efficient in terms of speed and power consumption. But they are characterized by their flexibility and ease of programming relative to the FPGA. Examples of the high sensitive GNSS receivers using DSPs are receivers in [12],[13]. In comparison with FPGAs, DSP-based solution might be slower but still allow for high throughput correlator implementations with shorter development cycle. Another technology which improves GPS/GNSS receiver operation is Assisted GPS/GNSS (A-GPS/A-GNSS) [1],[2],[15],[16]. In this approach wireless channels are sued to deliver aiding data to receivers which they would normally have to receive and demodulate from weak GPS satellite signals. Assisted technology improves sensitivity and operational coverage of receivers. A-GPS and its hybrids are considered best global positioning technologies nowadays for wireless devices; as a result AGPS is standardized for all wireless networks [15],[16].

Figure 1. An example of various hardware/software configurations in a commercial receiver product line [4].

Examples of SDR are gpsSrx receiver [5] and NavX-NSR [6], and for the open source PC based GNSS SDR systems there are examples described in [7],[8]. Proprietary or open source toolkits are also developed by incorporating new components in existing GNSS receiver solutions. Examples of toolkits range from Matlab-based [9] receiver solutions [7] to C/C++ based open source [7] and commercial systems [4],[6]. Employing programmable hardware like FPGAs and DSPs provides additional acceleration capabilities.

Thus GPS/GNSS receivers continuously evolve by progressively replacing conventional algorithms and implementation platforms for faster operation and development. In our previous work [17] it was mentioned that major challenges of advanced receiver development, especially in academia, are the system development complexity, long development cycle, RF Front-End and hardware accelerator interfaces for real-time processing, and an access to end-to-end development and testing platforms. As a solution environment or platform for the fast receiver development, prototyping, simulation and testing,

Table 1. Advanced development-testing toolkit to facilitate research and dissemination [17] Components x An integrated platform using popular NI RF/PXI equipment, NI GPS simulator and Labview software to facilitate algorithm research and performance analysis x Labview algorithmic libraries: conventional receiver algorithms; Advanced algorithms; Advanced A-GPS support Benefits x Low-cost real-time processing platform with available RF Front-end interfaces and rich algorithmic libraries x Dataflow and/or C/C++ programming, available profiling tools to estimate performances, built-in user interface design and visualization tools x Easy access to RF and I/Q sampled signals from NI Labview-based GPS simulator x UTSA SUPL standard-based A-GPS support x Build-in compilers for target platforms such as DSP processors and FPGAs

Algorithms and architecture can still be completely

including A-GPS operation mode, National Instruments

24th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland OR, September 19-23, 2011

1983

(NI) [18] Labview platform is chosen. This paper is an extension of [17] where it was reported that Labview is an attractive alternative for GNSS receiver research as it facilitates software receiver design, and interfaces with RF Front-Ends. In this paper we demonstrate that GPS receiver can be implemented using hybrid softwarehardware solutions by employing FPGA and DSP accelerators from a Labview-based platform. A dedicated Labview A-GPS support is also developed to generate assistance data for available satellites. The support is created to provide aiding data both to a handheld device and also a laptop PC where the GNSS receiver from [17] is located. Advanced channel model is also developed and integrated with the NI GPS Simulator Toolkit. It is based on Urban Three-State Fade Model (UTSFM) [19] and allows for various user-defined channel conditions. The model mixes properly statistical profile generators with the parameters identified through measurement campaign data collection and analysis. An assessment of the modules is performed using profiling tools and analysis. The paper is organized as follows. Section 2 summarizes the overall GPS system architecture with hardware/software components included. Section 3 overviews the GPS Simulator as an integrated part of the signal transmitter in the Section 4 describes the channel model embedded in Labview environment. Section 5 proceeds with the GPS Receiver overview. Section 6 is a summary of the hardware peripherals such as FPGA and DSP target compilation support in Labview environment. Section 7 finalizes the system architecture overview with the A-GPS support. In Section 8 the conclusion of the overall paper is given.

The proposed testbed exploits all the mentioned strengths of Labview platform. The system architecture for the real-time GPS receiver in Labview environment has been first presented in [17]. Fig. 2 illustrates an enhanced version of the system which supports Assisted GPS operation, channel model integration, and FPGA/DSP accelerators. The transmitters RF Front-End consists of antenna and NI PXIe-5673 RF Vector Signal Generator (VSG) which can be configured to generate various GNSS signals. The GPS signal is generated using Labview-based NI GPS Simulation Toolkit [18]. Then an advanced channel model module is integrated with the simulator in Labview similar to [19],[22],[23]. Such a model is designed to replicate signal distortions due to noise, multipath, diffraction, reflection, and scatterings. Receiver RF FrontEnd consists of antenna, a variable gain amplifier (variable gain up to 30dB) [24] and NI PXIe-5663RF Vector Signal Analyzer (VSA). It is connected to a computer running Labview-based software defined GPS receiver. Optional hardware DSP/FPGA peripherals are accessible through Labview interfaces. A-GPS support exploits simulator data to generate assistance.

3. GPS SIGNAL SIMULATOR TRANSMITTER

The NI GPS Simulation Toolkit [18] along with NI 5673 VSG is enabling the generation of one to twelve satellite signals with a waveform duration of up to 12.5 minutes (25 frames) which is the duration of an entire navigation message. The main features of the GPS Simulation Toolkit are the following: - Generation 24 hours of up to 12 satellite C/A codes. - Power adjustment levels of each satellite based on the testing specifications. - Direct streaming generation with either of those o Wide Area Augmentation System (WAAS) o Trajectory scripts o On the fly parameters o Stored file - Use the stream of a simulated signal along with the NI RF vector signal generator for a reliable and lowcost GPS testing. The simulator requires ephemeris and almanac data file inputs for the baseband signal generation sampled at 1.5MS/sec (IQ interleaved integer 16 data type). These files contain satellite orbit parameters and related information which are used to estimate satellite locations, trajectories, and health for a specific date and time [2],[25]. The almanac and ephemeris file types, content and location is described in [26],[27]. The conventional L1 civilian GPS signal is a direct sequence spread spectrum (DSSS) signal consisting of a

2. GPS SYSTEM ARCHITECTURE

Table 1 summarizes the benefits for choosing Labview environment as a GPS receiver development platform as described by authors in [17]. NI Labview provides hundreds of built-in libraries for advanced development, analysis and data visualization. It is convenient for fast algorithm prototyping and testing, comparative studies, real-time performance evaluation and dissemination. Labview has integrated interfaces to various hardware peripherals. It also supports multithreading and multicore programming which is useful for real-time applications. These advantages have been already used in other radio-communication systems [20],[21]. The algorithms in Labview can be implemented using Labview library modules, Mathscript nodes using Matlab scripts for fast prototyping, the nodes can also use C/C++ language for fast processing, and finally some operations can run on hardware accelerators such as DSP and FPGA peripherals.

24th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland OR, September 19-23, 2011

1984

Host Server (PC) NI Labview (2010)

NI 5673 RF Vector Signal Generator NI 5611 I/Q Modulator NI 5450 AWG NI 5652 LO Source Preamplifier VGLCDLA30

Client (Laptop)

Channel

NI Labview (2010)
NI 5663 RF Vector Signal Analyzer NI 5601 RF Down converter NI 5622 IF Digitizer NI 5652 LO Source

GPS Simulator Toolkit 2.0

GPS Receiver

Labview DSP Target

Labview FPGA Target

SUPL Server
Assistance Data Generation (ASN1) Network

SUPL Agent
1. Java2ME

PER Encoding/Decoding

PER Encoding/Decoding 2. SUPL Messages (See Fig.3)

Figure 2. Integrated Receiver Architecture with Hardware Front-End, A-GPS Support, Labview DSP and Labview FPGA Targets

multiplication of a sinusoidal carrier at 1.57542 GHz, a binary phase shift keying (BPSK) navigation signal at 50Hz, and BPSK modulated spreading pseudorandom code signal (PRN) at 1.023 Mchips/sec. The spreading sequence is called the C/A (coarse acquisition) code. The generated signal is transmitted through a channel described below.

4. CHANNEL MODELING
Originally GPS was designed for open sky operations. With more sophistication GPS receivers operate in urban and indoor areas where signal propagation are more challenging because of signal blockage, multipath, other fading phenomena due to reflection, diffraction and scattering.

Integration of channel models is quite straightforward in Labview. As an example, a channel model, Urban ThreeState Fade Model (UTSFM) [19] with several additional multipath echoes is integrated with NIs GPS simulator prior to RF signal generation using NI PXIe 5673 VSG as shown in Fig. 3. The model is based on the combination of three types of distributions Rayleigh, Loo and Rician. Different combinations of distributions are used depending on the satellite elevation angles and userdefined environments such as urban, rural, etc. Thus the probability density function (PDF) of the fading profile [19] is a combination of three components:

f Q  C f Rician Q   S f Loo Q   B f Rayleigh Q  , where

C , S , B are weights such that C  S  B 1 .

Figure 3. Channel model integrated in NIs GPS simulator with NI PXIe 5673 RFSG (VSG) hardware support

Fig. 4 shows Labview-based channel implementation with user-defined C , S , B converted to percentages. Labview libraries include noise generators which are conveniently used for the implementation. We currently expand this model for automatic injection of elevation angles from the simulator. Multiple echoes can be also defined. Other than thermal noise additional wideband noise can be injected.

24th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland OR, September 19-23, 2011

198

Sampled signal from RF Front-End (NI PXIe-5663RF VSA) is the input to Labview-based SDR. Conventional GPS/GNSS receiver technology is well-described in the literature [2],[3]. The Labview-based receiver operation is described in [17] and is reviewed here for the convenience. It includes conventional and advanced modules. The ultimate goal of a GPS receiver is to provide position, velocity, and time information. For that receivers measure range, range-rate, and demodulate navigation data. Range and range-rate measurements are extracted by synchronizing locally generated replicas of the code with the received signal. This synchronization is performed in frequency by estimating Doppler modulation, and in time, by aligning the signal and replica and estimating their relative shift called code-phase. The synchronization is typically performed in two phases: acquisition (coarse) and tracking (fine). These two modules constitute a baseband processing stage. After the synchronization navigation data are simply obtained through sinusoidal carrier and PRN code wipe-off. Navigation data contain time stamps which along with code phases are used to estimate ranges to satellites. Navigation data also contain orbital parameters, ephemeris and almanac, which are used to find satellite positions provided time. These parameters can be alternatively received using assistance from wireless networks as described later in the paper. Satellite positions serve as beacon locations for trilateration using ranges. Acquisition & Tracking The first stage of baseband signal processing is acquisition of a satellite. It is a two dimensional search process in which receiver replicates code and residual carrier modulation matching those to the received signal. Conventional receivers achieve acquisition by searching over a predicted time-frequency uncertainty zone. Multiple possible signal replicas are generated and correlated with received signal to find a match and thus to identify input signal parameters. A statistical test is
Tracking General Purpose Processor

Figure 4. Clustered IQ constellation (a) GPS signal with channel conditions; (b) Pure GPS signal

Fig. 5(a) shows received BPSK signal constellation with white noise and a channel condition (multipath and mixed distribution fading profile), while Fig. 5(b) shows signal constellation with white noise only.

Figure 5. User interface of an advanced channel model simulator integrated with the NI GPS Simulator Toolkit

5. GPS RECEIVER
Radio Front end

GNSS radio front end

Buffer

Code Tracking Navigation Processing Carrier Tracking User Interface

Acquisition Figure 6. Software GPS/GNSS receiver architecture

24th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland OR, September 19-23, 2011

198

applied to the correlation results to determine if a signal acquisition has been reached or not. If it has been, the acquisition is terminated and the receiver starts the tracking stage for that satellite; if not, the search continues and moves to the next code-phase/frequency option. There are different correlation implementation methods. For example, for acceleration convolutional theorem can be used by using Fast Fourier Transform (FFT) to correlate received and replica signals for all relative shifts at once, as convolution in time domain is multiplication in frequency (FFT) domain [7].

adjust replica residual carrier frequency. Typically filters are used to smooth discriminator outputs and avoid DLL/PLL loop overreactions.
Early

Figure 7. Block correlator for acquisition, coherent integration length is N2 code periods (N1 N2 samples for N1

In the tracking stage, the residual code and carrier shifts are estimated using correlators, discriminators and a feedback loop to adaptively reduce signal misalignment. The approach is similar to acquisition in the sense of finding the parameters of received signal by generating exact replica and matching two signals using correlators. The difference is significantly reduced total search space but finer synchronization. The code tracking loop called delay lock loop (DLL) and a carrier tracking loop called phase/frequency locked loop (PLL/FLL) are used for consecutive fine alignment of received and replicated signals. The DLL loop aligns the incoming signal with the local PRN replica for code-phase estimation. In the conventional systems several replicas are used with shifted relative phases, e.g. three replicas early, prompt and late with a code-phase spacing of 1/2 chip are used by slightly shifting code replicas. The correlation outputs are fed into a discriminator which defines relative shift of received signal with respect to the prompt replica. Then the feedback from the discriminator is used to adjust the code phases of local replicas. The alignment of the received signal with three correlators estimates the code phase errors. In PLL/FLL [2] the output of the prompt correlator connects to the discriminator of carrier loop with the phase estimation between I and Q components. PLL loop consecutively estimates phase mismatch and adjusts the locally generated residual carrier replica to minimize Q component. Phase changes indicate a presence of a residual sinusoidal modulation, and the PLL discriminator estimates this presence and instructs to
24th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland OR, September 19-23, 2011

Figure 8. Block correlator structure for tracking. An example with three replica sequences; sub-sum combining

Advanced correlators Both acquisition and tracking algorithms use correlators to synchronize the incoming signal with the local replica. Typically there is an elementwise multiplication of the received samples with the samples of each replica and eventually the products are integrated for the final result. So called block correlators are implemented to reduce the computational loads performing shared computations. Examples of state-of-the-art block correlators are [28] for acquisition (Fig. 7), and [29] for the tracking (Fig. 8). The block correlators for acquisition efficiently perform a parallel joint search in three dimensions: code phase, Doppler frequency, satellite number, using e.g. FFT. In [29] many frequency search steps are implemented through iterations in frequency domain, a long FFT is computed once, while shorter inverse FFTs are computed for each Doppler frequency and satellite. The tracking block-correlator concept [30] implements several correlators jointly in time domain. Early-LatePrompt replica sequences are transformed to a set of addresses pointing to a set registers which accumulate partial correlations. Each incoming sample is added to a register as referred by the address array. Then these partial sums are combined as shown in Fig. 8. The acceleration is achieved by only one addition per sample

198

for all three correlators plus a controlled overhead due to partial correlation integration. Overhead is not significant for three correlators. The tracking loop iterations are modified to make use of block correlator concept. The DLL discriminator outputs estimate the misalignment of incoming signal with the prompt code. As replicas are fixed the code phase adjustments are performed by aligning the received code front edge with the front edge of the prompt replica code. Considering received signal as an array of data, one should shift a pointer to the start of the C/A code back and forth [31]. These block correlators use only additions which results in essential computational savings. Fig. 8 shows the combined carrier and code tracking loop.

Manage memory, first in first out (FIFO) buffers, clocks, and I/O in the Labview project

In addition, later versions of Labview FPGA Module introduced a new feature called IP Integration Node which creates a communication between Labview FPGA and third-party existing HDL. This node also automatically creates a simulation model for the IP. Once IP node is configured it is used like any other Labview node with inputs and outputs. The Labview FPGA Module extends Labview with development tools for NI and third party FPGA targets.

6. ACCELERATORS
Labview FPGA Support In the past, FPGA technology was only available to engineers with a deep understanding of digital hardware design. The rise of high-level design tools, however, is changing the rules of FPGA programming, with new technologies that convert graphical block diagrams or even C code into digital hardware circuitry. NI Labview has created Labview FPGA Module [32] that synthesizes FPGA hardware with its graphical development environment. Synthesis is the process of translating highlevel programming languages into true hardware implementations. For any given piece of synthesizable code there is a corresponding circuit schematic that describes how logic blocks should be wired together. The Labview FPGA Module adds additional logic around every block diagram function before sending final schematic to the compiler. This block diagram approach to FPGA is well-suited for an intuitive depiction of the inherent parallelism and data flow that FPGAs provide aiming to create FPGA-based measurement and control hardware, independent of the prior knowledge of hardware description languages (HDL). Fig.9 visualizes digital logic on hardware in Labview enviroment. On the left it is shown the for loop structure with logic operations such as OR, NOR, AND and their corresponding locations on the FPGA logic blocks. Labview FPGA provides: x Support for hardware targets including both PCI/PXI boards and modular stand-alone systems x More than 100 FPGA IP blocks for quick development x Built-in I/O direct memory access (DMA) provides fast communication with a host system x Create logic that can execute in one cycle of 40Mhz, 80MHz, or faster clocks

 Figure 9. Labview data flow in FPGA digital logic [32] FPGA targets identified in the Labview Project Explorer include FPGA programmable I/O nodes to acquire, process, transfer and output signals using the FPGA. This can be done either using simulating I/O on a development computer or in a real time mode using various hardware targets. Supported Labview FPGA hardware targets are Virtex-II 1000, Virtex-II 3000, Spartan-3 1000, Spartan-3 2000, Virtex-5 LX30, Virtex-5 LX50, Virtex-5 LX85, and Virtex-5 LX110 [32]. Labview FPGA is tested for the advanced block correlator and acquisition algorithms described in earlier sections. The following software components are installed and used for the application development [32]. x x x x Labview Real-Time Module (2010 Service Pack 1) Labview FPGA Module (2010 Service Pack 1) NI-Reconfigurable Input/Output (NI-RIO) Driver (3.6) Xilinx Compilation Tools (11.5)

When targeting the FPGA Device, Labview accesses I/O from the device and executes the VI logic on the Windows development computer. In this mode, debugging tools are also available in Labview.

24th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland OR, September 19-23, 2011

1988

There are two ways to work with Labview FPGA module; use existing Labview FPGA code blocks or incorporate external HDL code into Labview environment using IP integration code. To integrate, e.g.; Verilog code, Labview FPGA project should be created running on the development computer in the simulation mode followed by these steps: 1. Verilog code is compiled or synthesized to .ngc file by using Xilinx ISE simulator tools. One should be very careful with the version of Xilinx compilation tools. The compiler used for .ngc synthesis file generation and the version of Xilinx compilation tools of Labview FPGA Environment installed must be same. Otherwise it is not possible to generate the IP node. 2. Mapping-The Xilinx compilation tools divide the application logic of Netlist from .ngc file between the physical building block on the FPGA target specified. 3. Placing and Routing-The compiler assigns the logic to physical building blocks on the FPGA and routes the connections between the logic blocks to meet the space or timing constraints of the compilation. 4. Generating bitstream-The compiler creates binary data that Labview saves inside a bitfile. 5. Bitfile creation the saved file is programmed on to the Labview FPGA VI. Once the IP node is in the Labview FPGA application the appropriate settings to define inputs and outputs should be initialized according to the example given in [32]. In Fig. 10 a single cycle timed loop is shown where there is an IP integration node implementing advanced block correlator algorithm according to the input IQ signal and the address array as described previously.

FPGA is capable of implementing GNSS receiver related tasks thus in our case study coherent integration of one millisecond of signal is used and also the number of the acquired satellites is set to be one. The rest of the implementation is done according to the description in Section 7 giving similar correlation peak result as shown in Fig. 18(a).

Figure 11. FPGA project explorer in Labview environment

For the algorithm implementation the Labview project was created (Fig. 11). The target compilation is chosen to be done on the Development Computer. The application is developed on the FPGA target and called by the host .vi called Test 1024 FFT(Host).vi. The Labview block diagram of FPGA-based FFT implementation for the used advanced acquisition algorithm is given in Fig. 12. As an example, the incoming IQ signal is sampled at 1.024MHz sampling rate and provided to the FFT FPGA module. Once the result is obtained it is passed to a FIFO buffer (named Spectrum of Signal) which will be then read on the host application for further processing.

Figure 12. FFT of the incoming signal implemented in Labview FPGA Figure 10. Advanced Block Correlator algorithm called in Labview using IP Integration Node

The host application then can be benchmarked or profiled using Labview Profiling Tools. Labview DSP Support Similar to Labview FPGA module NI created also a Labview DSP module to accelerate various digital signal

For the advanced acquisition algorithm implementation another advantage of Labview FPGA module is used; which is to directly use the Labview functional blocks. This experiment was done just to prove that Labview
24th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland OR, September 19-23, 2011

1989

algorithm implemented on the Labview environment only and the result shows the improvement of using hardware component incorporated with Labview platform (Table 2).

Figure 13. DSP project explorer in Labview environment

processing algorithms. Examples of supported targets currently include Texas Instruments C6711, C6713 DSKs, and a simplistic NIs SPEEDY-33 board [33]. Like with Labview FPGA, Labview DSP identifies the available hardware I/O points from the supported hardware in the Project Explorer and it can easily switch between existing DSP targets. DSP module also allows deploying and running the application in the standalone mode. As a user friendly graphical programming language Labview makes it easier to build DSP systems with fast application prototyping and deployment. It also allows creating reusable subvis; a blocks of code with input(s) and output(s). As a data flow graphical programming language Labview environment embedded with DSP module provides hands on experimental learning environment for novice users, and self documenting, easy maintainable environment for professionals. The same advanced acquisition algorithm was tested on the DSP board. For this case study the NI SPEEDY-33 is chosen for its simplicity as an example (more advanced DSP implementation results will be provided in future). With the onboard analog and digital I/O, NI SPEEDY-33 provides several options to build DSP applications including speech analysis, processing and communication. This target is used with Labview DSP Module, which makes developing applications intuitive through its block diagram approach. Its dual-power options facilitate building standalone applications that need to be deployed without a PC. Due to the limited memory capability of this board in this paper the single satellite acquisition algorithm with 1.024 MHz input sampling rate and 1ms length of coherent integration was tested and benchmarked in real-time on a SPEEDY 33 DSP. Like for the previous case here again the Labview Project was created with the target selected to be SPEEDY 33 as shown in Fig.13. The target requirement platform is selected to be Labview 8.6 version. The DSP hardware/software installation is done according to [33]. Similarly a portion of the acquisition code implementing the FFT on the DSP module is depicted in the Fig.14. The performance analysis for the advanced acquisition algorithm using DSP target is compared to the same
24th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland OR, September 19-23, 2011

Figure 14. Acquisition algorithm implementation fragment in Labview environment Table 2. Performance estimation of FFT based Correlation for 1024 samples using Labview Profiling Tools Platform NI Labview NI Labview with SPEEDY 33 DSP Target Time (seconds) 0.034 0.025

7. A-GPS SUPPORT
The dedicated Labview-based A-GPS support is integrated with NIs GPS simulator. The simulator generates signal using ephemeris and almanac orbital parameters for all the selected satellites. These navigation data are transformed to binary formats to generate satellite signals. Proposed A-GPS support encapsulates these binary data into an assistance data which are communicated by an assistance server to receivers. In this paper only four assistances are delivered to the receiver: ephemeris, almanac, reference position and reference time. Reference location and time are generated using userdefined deviations from time and location used by the GPS simulator to generate satellite signals. The process follows the guidelines of Secure User Plane Location (SUPL) [16] which defines the assistance delivery format and communication between the user (client) and SUPL server. SUPL is the Internet Protocol (IP)-based network service to deliver information through a User Plane bearer between a SUPL Enabled Terminal (SET) (e.g. mobile devices) and a SUPL Location Platform (SLP) (e.g. AGPS servers) for wireless communications developed by OMA [14].

1990

In our implementation the GPS simulator is co-located with the A-GPS SUPL server (e.g. SLP). The server receives assistance data in Abstract Syntax Notation One

the SET as the reference location (e.g. Base Station) shown in Fig.15 between the SET and the SLP since Gateway Mobile Location Centre (GMLC) cannot be

Figure 15 A block diagram of experimental setup for testing A-GPS support

(ASN.1) format [34] from the Labview-based GPS simulator and delivers it to the SET. The assistance data (ephemeris and almanac parameters) are generated by extracting navigation bits which are obtained by GPS simulator for RF signal generation using VSG hardware. These generated assistance data are according to Radio Resource Location Protocol (RRLP) [35] and delivered through the RRLP Payload wrapped in the SUPL message [36] ,[37]. Fig. 15 provides general setup. A PC with Intel(R) Core i5 CPU M580, 2.67GHz (4CPUs), 3510MB RAM, Windows XP Professional OS is used as a GPS simulator and A-GPS generation platform. NI Labview 2010 version is used as a development environment along with GPS Simulation Toolkit 2.0. Microsoft Visual Studio 2008 Team Suite is used for creating dynamic linked library (dll) to communicate with Labview. Performance evaluation of the overall system in Labview environment is done based on [18]. Software Implementation of Client/Server Communication in Java Environment: In [38] and [39], the assistance data in ASN.1 format [34] for a single satellite is generated according to the SUPL architecture using Hypertext Transfer Protocol (HTTP) connections through sockets between the web server (Apache Tomcat web server) and the mobile device running on a Java ME [36] platform. In the SUPL architecture, SUPL messages are encapsulated as data packages through sockets with user-defined location of

accessed in the simulation experiment. GMLC is a network element to search the geographic location of the base station tower and transmit the coarse location (longitude and latitude) of the SET to the SLP. In the real world, the SET (client) provides its coarse position, location ID (cell ID, IP address, or MAC ID), to the SLP (server) for requesting assistance data. Once the location ID of the SET has been verified by the SLP, the SLP communicates with GMLC for the coarse location of the SET. Fig.15 illustrates the experimental scenario that assistance data is delivering for 8 satellites from the Labview-based A-GPS simulator with the SET-based, performed position computation on the handset, following the SUPL structure with Transmission Control Protocol (TCP)/IP connections between the SLP (Java server application) and the SET (the mobile device and the laptop). The TCP is a connection-based, reliable, ordered delivery of stream of bytes from a client application on one computer to a server application on another computer via the Internet. There are five messages going back and forth between the SET and the SLP in the SUPL architecture as shown in Fig.3. The SLP sends the SET requested message (SUPLSTART), which contains the user position technology, preference method and position protocol in order to connect an IP network. Once the SLP listens to the requested message, the SLP returns the SUPLRESPONSE in ASN.1 format including the sessionID and the positioning method to the SET as a respond message. After initiating the communication link, the SET asks for the assistance data from the SLP by sending

24th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland OR, September 19-23, 2011

1991

SUPLPOSINIT message consisting of supported positioning methods and associated positioning protocol to the SLP. Then, the assistance message (SUPLPOS) is delivered to the SET by enclosing it through the RRLP protocol. As long as the SET receives the orbital assistance message (SUPLPOS), it proceeds with the calculation of the coarse position based on the estimated assistance data from the SLP. Once the position calculation is complete, the SLP informs the SET to end the IP connection by sending SUPLEND message for releasing resources related to the location session. Server Implementation: The server application implements the significant feature of the SLP which is to transfer location information to the SET upon request. As mentioned earlier, the NI Labview A-GPS Simulator which resides in the same PC as SUPL Server generates all the files in ASN.1 format required in the SUPL information exchange session between the SLP and the SET. These files are periodically updated and stored on the server system. In java environment, the java.net.ServerSocket class is used to listen for client requests on the specific port (port 9999 in our case).
1. try { 2. serverSocket = new ServerSocket(9999); 3. } catch (IOException e) { 4. System.out.println("Failed to listen); }

message is given to Unaligned PER decoder which converts data from stream to a string. The decoded message is stored as a file on the server. This procedure is carried out for each file that the server receives from the client.
1. suplstart.ulp.ULP_PDU decodedmsg=null; 2. try { 3. Coder coder = 4. Suplstart.getPERUnalignedCoder(); 5. ByteArrayInputStream source = 6. new ByteArrayInputStream(SUPLSTART); 7. decodedmsg= 8. (suplstart.ulp.ULP_PDU)coder.decode 9. (source,new suplstart.ulp.ULP_PDU()); 10. } catch (Exception e) { 11. System.out.println("Decode Failed: " + 1 e);}

When the server replies to the message exchange initiation with the SUPLRESPONSE message, a similar process takes place at the client side. The Unaligned PER encoding/decoding at both client and server side is made possible by including OSS NOKALVATM API [38] and by importing the following packages into application resource bundle.
1. import com.oss.asn1.*; 2. import com.oss.metadata.*; 3. import com.oss.util.*; 4. import com.oss.validator;

The server invokes the accept() method of the ServerSocket class, which waits until a client connects to the server on the mentioned port. When a connection is requested and successfully established, the accept() method returns a reference to the new socket on the server through which communication with the client is possible.
1. Socket socket = null; 2. try { 3. socket = serverSocket.accept(); 4. } catch (IOException e) { 5. System.out.println("Accept failed: 9999"); }

In the final step of SUPL message exchange session, the server sends eight SUPLPOS messages corresponding to assistance data of eight satellites generated by the NI Labview A-GPS Simulator. These assistance data help the client to calculate its position. The server then ends the session by closing all connections after being prompted by the clients SUPLEND message.
1. os.close(); 2. is.close(); 3. serverSocket.close(); 4. socket.close();

After establishing the client-server connection, they can now communicate by writing to and reading from the socket using I/O streams. The client's OutputStream is connected to the server's InputStream, and the client's InputStream is connected to the server's OutputStream.
1. os = socket.openOutputStream(); os.write(); 2. is = socket.openInputStream(); is.read();

Client Implementation: It is known that the SET can be a Mobile Station (MS) in GSM technology or a User Equipment (UE) in UMTS or a PC over an IP-based technology [16]. For variety test environments, two types of client applications (e.g. PC and mobile device) have been developed. First is a pure Java Client Application to be tested on a PC while another is a Java ME Client application to be tested on a mobile device. For a mobile application, the OSS NOKALVATM ASN.1 TO JAVA COMPILER is used to compile the ASN.1 modules to java classes with the -microedition option to be included in the application resource bundle while for standard J2SE application the same compiler is

Since the SUPL architecture in our implementation is SET initiated, the SET initiates the information exchange by streaming the PER encoded SUPLSTART message using write() method on the instance of DataOutputStream class and sends over the TCP socket connection. The Server application reads the clients message using the read() method on the instance of DataInputStream class. The received SUPLSTART

24th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland OR, September 19-23, 2011

1992

used without the microedition option. Also, the Java ME application is built with ossmicro.jar (OSS NOKALVATM API for J2ME) while pure java application is built with oss.jar (for standard J2SE). Java Standard Edition provides the java.net.Socket class through which the client PC can communicate with the server PC. While the server listens to the client on a specific port, the client instantiates a Socket object, specifying the server name, and port number to connect to. The constructor of the Socket class attempts to connect the client to the specified server and port number. Once the communication is established, the client now has a Socket object and it is able to communicate with the server.
1. try { 2. socket = new Socket("10.3.12.77", 9999); 3. } catch (IOException e) { 4. System.out.println("Failed to connect 5.server); }

8. encoding = sink.toByteArray(); 9.} catch (Exception e) { 10. System.out.println("Encode Failed: " + .e);}

The mobile application is created, compiled and deployed onto the Java enabled cell phone in the NetBeans Integrated Development Environment IDE [40]. When the user launches the mobile application from the phone memory, exchange of messages takes place and as a final message the mobile device receives eight SUPLPOS messages from the server. The orbital assistance data from a single satellite with A-GPS support has been demonstrated on the mobile device, E72 Nokia mobile phone, as an example shown in Fig.16.

In Java ME application, the Connector class is the core of Generic Connection framework. Different types of communication can be created by the same static method open() defined in Connector class with different parameters. The connection could be file I/O, serial port communication, datagram connection, stream connection or a HTTP connection depending on the string parameter passed to the method. Such design makes Java ME implementation very flexible in supporting new devices and products. The connection is made with the server as shown below: 1.StreamConnection socket = null; 2. try { String server="10.3.12.77"; 3. String port = "801"; 4. String name="socket://"+server +":"+port; 5. socket =(StreamConnection)Connector.open 6. (name, Connector.READ_WRITE); 7. } catch (Exception ex) { 8. System.out.println(Connection failed+ex); } As the SUPL architecture in our implementation is SET initiated, the client initially PER encodes SUPLSTART message using the encode method() provided by the Coder class of OSS NOKALVATM standard API. This encoded message is written to the OutputStream through write() method and sent over the TCP socket connection to the server.
1.byte[] encoding = null; 2.try {suplstart.ulp.ULP_PDU SUPLSTART = 3.suplstart.ulp.ULP.myULP_PDU; 4.Coder coder = Suplstart.getPERUnalignedCoder(); 5.ByteArrayOutputStream sink = new 6.ByteArrayOutputStream(); 7. coder.encode(SUPLSTART, sink);

Figure 16: Fragment of ephemeris data in SUPLPOS message corresponding to one of satellites as an example received from server.

Labview GPS/GNSS Receiver Testing with A-GPS Support In [17] an implementation of the GPS/GNSS receiver using MS Visual Studio C++ dll block was done proving that Labview is not adding any overhead on the performance of the same receiver operating on the MS Visual Studio C++ platform. In addition to that receiver here the authors add the A-GPS support transferred to the laptop PC from the Host server described in Fig.2. The test is conducted using the modified version of the application from the Labview example package called RFSA Acquire Continuous IQ.vi. Here the incoming signal is of integer 16 IQ interleaved format which then is transferred to integer 8 for faster receiver processing. The settings chosen for the signal acquisition are the following; the IQ sampling rate is 4.092MS/s, the reference power level is -80dBm, the GPS carrier signal frequency is 1.57542GHz, and the number of samples to read per each block of the received signal is 81840. Without A-GPS support there was a need to collect 36 seconds of signal which is sufficient for decoding a navigation message for position calculation. But with AGPS support we already have the almanac and ephemeris

24th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland OR, September 19-23, 2011

1993

sinusoids are multiplied to the input signal to wipe-off the carrier. The resulting samples are accumulated into 8 partial correlations (subsums). Figure 18(c) illustrates the navigation message decoded in the tracking stage. The navigation databits and measurements are passed to position computation module. In this implementation a conventional least squares positioning algorithm is used [2].

8. CONCLUSION
Figure 17. The actual location of the user with determined set of locations.

information decoded thus we can proceed to the position calculation almost immediately. In Fig. 17 it is shown the actual location of the user and the detected location according to the A-GPS supported receiver position calculation. The acquisition is performed first. In our case study coherent integrations of 8ms of signal are used. This

The paper describes an integrated Labview-based platform for GPS/GNSS receiver development and testing using simulators and A-GPS support. It is described how to include channel models, delegate computing tasks to FPGA and DSP peripherals. Assisted GPS operation is demonstrated for two types of client sets; A-GPS support for mobile device and laptop PC. Advanced signal processing algorithms are also tested on FPGA and DSP target platforms.

(c) (b) (a) Figure 18. (a) Acquisition result of a single satellite using Labview Visualization Tools. (b) The signal strengths and PRNs of the acquired satellites. (c) Bits of the navigation message for a single satellite

allows determining the availability of the visible satellites with their code-phases and frequencies. The PRN code replicas for 32 satellite codes are stored in a 2D array for a faster access. The correlation result will provide a 2D search over all Doppler frequencies and code phases and whenever there is a match between incoming signal and the local replica there will be a peak like the one shown in Figure 18(a). The signal strengths for all detected satellites are given in Fig 18(b). So once the outputs of the acquisition stage are available we can proceed to the tracking algorithm. The tracking algorithm implemented in the paper is working for the sampling rate of 4.092 MHz. For the advanced tracking these samples are further integrated to reduce the sampling rate to 2.046MHz. To avoid real time generation of the carrier wave a fixed sinusoid array is created for generating various Doppler modulation compensating sinusoids through the saved sinusoid decimations and cyclic array reading. The generated
24th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland OR, September 19-23, 2011

9. REFERENCES
[1] N. Agarwal et al, Algorithms for GPS operation indoors and downtown, GPS Solutions. 2002, Springler-Verlag Heidelberg, Vol. 6, No. 3, pp. 149160. [2] P. Misra, P. Enge. Global Positioning System, Signals, Measurements, and Performance. GangaJamuna Press, Lincoln, MA. 2001. [3] D. Akos, The role of Global Navigation Satellite System (GNSS) software radios in embedded systems, GPS Solutions, 2003, Springler-Verlag, Vol. 7, No. 1: pp.1-4. [4] Fastrax GPS receivers and SDKs. www.fastrax.com, (Access: Sep 13, 2011). [5] Akos, D. M., Normark, P., Hansson, A., Rosenlind, A., Stahlberg, C., and Svensson, F., Global Positioning System Software Receiver (gpSrx)

1994

Implementation in Low Cost/Power Programmable Processors, Proc. 2001 ION GPS Conf., Salt Lake City, UT, Sept. 2001, pp. 2851-2858. [6] G. Heinrichs, M. Restle, C. Dreischer, T. Pany, NavX- NSR A Novel Galileo/GPS Navigation Software Receiver, ION GNSS International Technical Meeting of the Satellite Division, Fort Worth, TX, Sept. 25-28, 2007, pp. 1329-1334. [7] K. Borre, D. M. Akos, N. Bertelsen, P. Rinder, S.H. Jensen. A Software-Defined GPS and Galileo Receiver: A Single-Frequency Approach. Birkhauser Boston. 2006. [8] Open source GPS software radio - GPS-SDR, multithreaded enabled C++ application. www.gpssdr.com/wiki/gps-sdr (Access: Sep 14, 2010). [9] Matlab from Mathworks at www.mathworks.com. [10] A.G. Quinchia, C. Ferrer. A Low-Cost GPS&INS Integrated System Based on a FPGA Platform, Localization and GNSS (ICL-GNSS), International Conference, Tampere, Finland, June 29-30, 2011, pp. 152 157. [11] T. E. Humphreys, M. L. Psiaki, P. M. Kintner, Jr., B. M. Ledvina. GNSS Receiver Implementation on a DSP: Status, Challenges, and Prospects, ION GNSS Conference , Fort Worth, TX, Sept. 26-29, 2006, pp.1-13 [12] G. Girau, A. Tomatis, F. Dovis, P. Mulassano. Efficient Software Defined Radio Implementations of GNSS Receivers, Circuits and Systems, ISCAS 2007. IEEE International Symposium, New Orleans, LA, May 2007, pp.1733 - 1736. [13] E. Cetin, I. Kale, R. Morling. Analysis and compensation of RF impairments for next generation multimode GNSS receivers, Proceedings of the IEEE International Symposium on Circuits and Systems IEEE, New Orleans, LA, May 2007, pp. 1729-1732. [14] Open Mobile Alliance. UserPlane Location Protocol v1.0, Open Mobile Alliance_, OMA-TSSUPL-V1_0, 2007. http://www.openmobilealliance.org/. [15] Wireless E911 location accuracy requirements: FCC mandate for Docket 94-102. http://www.fcc.gov/e911. (Access: Sep 14, 2011). [16] Yilin Zhao, Standardization of Mobile Phone Positioning for 3G Systems, IEEE Communications Magazine, July 2002, pp. 109-116. [17] D. Akopian, A. Soghoyan, S. Chayapathi, GVS Raju, A Flexible Labview-based GNSS Receiver Development and Testing Platform, ION-ITM-2011 Conference, San Diego, CA, Jan. 24-26, 2011, pp. 1270-1280 [18] Labview, RF Signal analyzers and generators from National Instruments, www.ni.com (Access: Sep 14, 2011). [19] Ma, Changlin, Jee, Gyu-In, MacGougan, Glenn, Lachapelle, Grard, Bloebaum, S., Cox, G., Garin,

L., Shewfelt, J., "GPS Signal Degradation Modeling," Proceedings of the 14th International Technical Meeting of the Satellite Division of The Institute of Navigation (ION GPS 2001), Salt Lake City, UT, September 2001, pp. 882-893. [20] Developing an OFDM Transmitter and Receiver System Using LabWindows/CVI and PXI http://sine.ni.com/cs/app/doc/p/id/cs-12714 (Access: Sep 14, 2011). [21] Prototyping Algorithms for Next-Generation Radio Astronomy Receivers Using PXI-Based Instruments and High-Speed Streaming http://sine.ni.com/cs/app/doc/p/id/cs-12972 [22] Simulating multipath, Spirent Communications plc, Paignton, Devon, U.K., Application Note DAN004TM, Issue 1-00. [23] G. Huang, A. Soghoyan, D. Akopian, P. Chen, A. Samant, A Land Mobile Channel Modeling in LabVIEW, IEEE SMC, San Antonio, TX, 2009, pp. 4575-4580. [24] GPS Networking http://gpsnetworking.com/standardline-amplifiers.asp (Access: Sep 14, 2011) [25] E.D. Kaplan. Understanding GPS: Principles and Applications. Boston: Artech House, 1996. [26] Almanac information (the navigation center of excellence) http://navcen.uscg.gov/gps/alamanacs.htm (Access: Sep 14, 2011) [27] Ephemeris information (NASA Goddard Space Flight Center) http://cddis.gsfc.nasa.gov/gnss_datasum.html#brdc (Access: Sep 14, 2011). [28] M. Braasch, A.J. Van Dierendonck, GPS Receiver Architectures and Measurments, Prcoeeding of the IEEE, Jan 1999, Vol.87, No. 1, pp. 48-64. [29] D. Akopian, "Fast FFT based GPS satellite acquisition methods," Proceedings of IEE, Vol. 152, No. 4, pp. 277-286, 2005. Initial version presented at ION-GPS-2001 Conference, Sep. 11-14, 2001, Salt Lake City, UT. [30] P. K. Sagiraju, P. Kashyap, D. Akopian, Block correlator for tracking GPS/GNSS Signals, IONGNSS-2008 Conference, Sep. 16-19, Savannah, GE, 2008, pp. 229-235. [31] L. Winternitz, M. Moreau, G. J. Boegner Jr. and S. Sirotzky, Navigator GPS Receiver for Fast Acquisition and Weak Signal Space Applications, ION GNSS 2004, Sep 21-24, 2004, Long Beach, CA, pp. 1013-1026. [32] NI Labview FPGA,http://www.ni.com/fpga/ http://zone.ni.com/devzone/cda/tut/p/id/10015 (Access: Sep. 17, 2011) [33] NI Labview DSP http://www.ni.com/pdf/manuals/371581c.pdf (Access: Sep. 17, 2011)

24th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland OR, September 19-23, 2011

199

[34] UniGone ASN.1 Solutions, http://www.unigone.com/en/solutions/asn1 (Access: Sep 14, 2011) [35] 3GPP TS 44.031 Third Generation Partnership Project; Technical Specification Group GSM/EDGE Radio Access Network; Location Services (LCS); Mobile Station (MS) - Serving Mobile Location Centre (SMLC) Radio Resource LCS Protocol (RRLP), 2010. [36] Java ME Programming Guidehttp://developer.att.com/developer (Access: Sep 14, 2011) [37] OSS Nokalva at www.oss.com (Access: Sep 14, 2011) [38] S.N. Chayapathy, A.Kumar, P.Kashyap, D.Akopian, A. Samant,A SUPL-based A-GPS Simulator Support for Indoor Positioning, Proc. of the 22nd Int. Technical Meeting of The Satellite Division of the Institute of Navigation (ION GNSS), Savannah, GE, 22-25 Sep 2009, pp. 503-515. [39] M. C. Sundaramurthy, S. N. Chayapathy, A. Kumar, D. Akopian, Wi-Fi assistance to SUPL-based

Assisted-GPS simulators for indoor positioning, IEEE CCNC, Las Vegas, NV, Jan. 2011, pp. 918922. [40] Oracle corporation (1996), Netbeans Docs & Support, http://netbeans.org/ (Access: Sep 14, 2011) [41] A. Suleiman, D. Kinjarapu, D. Akopian, Reconfigurable Correlator Accelerators for Software GPS Receivers, ION GNSS, Portland, OR, Sept. 2011

ACKNOWLEDGMENTS
Authors would like to express gratitude to Dushyanth Kinjarapu for his efforts in the development of the block correlator algorithm [41] integrated in the Labview environment. Travel to the ION GNSS 2011 Conference is made possible by a grant from the Valero Energy Corp.

24th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland OR, September 19-23, 2011

199