Journal of Global Positioning Systems (2004)
Vol. 3, No. 1-2: 63-69
An Open GNSS Receiver Platform Architecture
Frank Engel†, Peter Mumford‡, Kevin Parkinson‡, Chris Rizos‡, Gernot Heiser†
† Embedded Real-Time and Operating Systems Program (ERTOS), National ICT Australia (NICTA)
e-mail: {frank.engel, gernot.heiser}@nicta.com.au Tel: + 61 2 9358 7339; Fax: [phone]
‡ Satellite Navigation and Positioning Group (SNAP), The University of New South Wales (UNSW)
e-mail: {p.mumford, c.rizos}@unsw.edu.au, [e-mail] Tel: + 61 2 9358 4182; Fax: [phone]
Received: 15 Nov 2004 / Accepted: 3 Feb 2005
Abstract. In this article we present the concept of a
FPGA-based GPS receiver architecture with the aim of
providing a framework for investigating new receiver
architectures for current and upcoming GNSS standards.
This development system facilitates researchers to prove
new receiver concepts using real signals, which nowa-
days can only be simulated using tools such as Matlab.
One will be able to work with the satellites as soon as
they are operational, rather than having to wait for the
availability of commercial products. The system allows
individual development of signal processing solutions for
base-band processing. A soft-core processor implements
higher layer services that provide data to the user.
Key words: GPS Receiver, GNSS, FPGA, Soft-Core
Processor
1 Introduction
The Global Positioning System (GPS) is a satellite-based,
all-weather, round-the-clock navigation system developed
by the U.S. Department of Defence. Since the early 1980s
GPS has been available to the civilian community and is
the most effective navigation and positioning system ever
developed. Once a tool for experts and an exotic gadget
for nerds, it is rapidly becoming a commodity. Location-
aware devices are an essential part of many ubiquitous
computing scenarios, and the recent mandate by the US
FCC (FCC, 2004) that all emergency calls from mobile
phones must be locatable has increased the pressure on
improving the technology. Satellite-navigation receivers
will in the future be embedded in a large number of de-
vices of widely different uses.
1.1 Background
Although GPS is the only fully operational 'first genera-
tion' Global Navigation Satellite System (GNSS), since
the mid-1980s signals from the Russian Federation's
Glonass system have also been available (Glonass, 2004).
However, since 1995 Glonass has been starved of funding
and the constellation has progressively degraded. Russia's
President has announced that the full Glonass system will
again be operational by 2008. In January 2004 India
signed a Memorandum of Understanding with Russia to
collaborate on the Glonass refurbishment.
Europe is currently developing its own 'second genera-
tion' GNSS, known as Galileo (Galileo, 2004), for de-
ployment between 2006 and 2008. In 2003 China signed
onto the Galileo program.
There are a number of additional satellite systems in op-
eration today, or to be soon available that complement
GPS, Glonass and Galileo. These systems are generically
referred to as Space Based Augmentation Systems (SBAS)
(SBAS, 2004) because they transmit extra signals that
certain receivers can decode and use (together with the
global GNSS signals) to achieve improved positioning
performance. To augment GPS for aviation users, the
U.S. and Europe have deployed the Wide Area Augmen-
tation System (WAAS) and the European Geostationary
Navigation Overlay System (EGNOS) respectively
(WAAS/EGNOS, 2004). Japan, India and China have
indicated that they too will develop regional SBAS by the
end of this decade. The most advanced plans are Japan's
Quasi-Zenith Satellite System (QZSS) (Petrovski, 2003), a
constellation of 3 to 7 satellites that will broadcast GPS
(and ultimately Galileo) signals from orbits optimised for
East Asian.
In the near to medium-term future the market for satellite
navigation technology is expected to continue to experi-
ence major growth (Canalys, 2004). The greater availabil-

64 Journal of Global Positioning Systems
ity of signals from these upcoming systems and the re-
duction in costs of GNSS receivers will support new ap-
plication fields like indoor positioning for consumer de-
vices. Besides the positioning data, these systems will
support extra, low data rate channels. These channels can
be used to receive personalised information similar to a
pager system, which prepares the ground for new services
offering this information.
1.2 Project Objectives
The aim of this project is to develop a platform for inves-
tigating new algorithms and systems based on current and
upcoming GNSS receiver standards. This platform could
serve as a generic base for GNSS research that supports
research into signal processing issues, protocols and early
implementation of emerging standards:
• A reference and testbed environment to investi-
gate interoperability and standard compliance.
• An IP block readily accessible to industry part-
ners for development of GNSS and GNSS-enhanced
devices.
• Considering the wide range of next generation
GNSS signals a solution is required that support
flexible hardware and software design. As an exam-
ple, a system that can incorporate extra processing
power or tracking channels, as the need arises.
The article is structured as follows. Section 2 introduces
the requirements of such a platform concept. Section 3
explains project stages in more detail. Section 4 discusses
future investigations into improved GNSS receivers and
applications/products. Intermediate project results and a
conclusion finalises this article.
2 Platform Reqirements
2.1 Components
In general a GNSS receiver consists of three major com-
ponents:
• RF front-end to receive GNSS signals and con-
verting into baseband: Since satellite signals are very
weak, the development of front-end components still
requires custom circuit design.
• Baseband processing to generate raw / pre-
processed data from received signals: It comprises
strong digital signal processing either executed by
custom hardware or a digital signal processor (DSP).
• Control processing to manage receiver activity
and post-process data: Besides converting raw data
into e.g. position velocity and time, tasks like main-
taining receiver status (e.g. tracking satellites) is usu-
ally executed by a micro controller (µC) running
special firmware.
According to this structure, a generic receiver platform
should support interfaces to various RF front-ends, signal
processing hardware, and (µC supported) software layers
for control processing and applications.
2.2 Configurability
State of the art field programmable gate array devices
(FPGAs) such as Altera’s Stratix series provide high
computational capacities of up several million logic ele-
ment equivalents (Stratix, 2004). Besides pure configur-
able logic they also provide on-chip memory and DSP
capabilities. Thus they are very well suited for complete
system-on-chip solutions (SoC) without the need of sili-
con fabrication. Furthermore, FPGA vendors offer CPU
cores integrated into the FPGA either as hard-core or
soft-core. While hard-core processors are optimally inte-
grated into the FPGA fabric, soft-core processors allow a
fine grain tailoring towards the design requirements by
introducing caches and specialised instructions etc.
Following this strategy, baseband processing could be
implemented by FPGA logic, supported by hardware
macros, while control processing could be implemented
by a soft-core processor such as Altera's NiosII. Thus an
FPGA device serves as the central processing element on
this reconfigurable platform. It connects to RF front-ends
as well as different communications interfaces (e.g.
TCP/IP, RS232, USB).
3 Approach
The general approach is to break the development process
into three stages. These stages relate to the migration of
the hardware platform from a Mitel Superstar receiver
towards the FPGA solution on a custom designed circuit
board. The stages are identified as:
• Stage 1: SuperStar-NiosII;
• Stage 2: GP2021_Emulator-NiosII and;
• Stage 3: Custom GNSS Platform.
The Mitel GPS Architect (sometimes referred to as
Orion) has become some sort of standard GPS software
suite for the Zarlink chipsets. It was available as a devel-
opment kit with a licence allowing royalty free distribu-
tion of compiled binaries (GPSArch, 1997). The SNAP
Group purchased a kit in 1999. The GPS Architect has
been selected for testing purposes for the reasons men-
tioned above. Altera's products 'Quartus' and the 'NiosII
IDE' are the primary tools used for programming the
FPGA and code generation (Altera, 2004).

Engel et al.: An Open GNSS Receiver Platform Architecture 65
3.1 Mitel GPS Architect
The original Mitel GPS Architect software was designed
to run on an ARM60 processor, with a Mitel (now Zar-
link) GP2021 (GP2021, 2001) baseband processor and
GP2010 or GP2015 RF front end (GP2015, 2002). Ver-
sion 6.17 of the GPS Architect code was ported to the
Sigtec MG5001 GPS receiver in 2003. This receiver has a
Zarlink GP4020 chip with an ARM7 core and GP2015
RF front end (GP4020, 2002). The GP4020 has the same
correlator design as the GP2021. This version of the GPS
Architect software was selected for porting to the NiosII
embedded processor.
There are significant differences between the NiosII and
ARM7 architectures and instruction sets, as well as dif-
ferences in the development tools and embedded librar-
ies. Addressing these differences, getting familiar with
the new tools and creating interfaces to hardware such as
the baseband signal processing (or correlator) block, con-
stitutes the bulk of the porting effort. Although, only a
few changes to the application software are required, sys-
tem initialisation, the Real Time Operating System
(RTOS), chipset interfacing and serial port communica-
tion require significant changes to the code base since
those parts are highly architecture related.
3.2 Altera Tools
Altera provides Quartus, a tool for the generation of
FPGA designs and the NiosII IDE for the generation of
code to run on the NiosII soft-core processor. Quartus
contains the 'SOPC Builder' used for generating NiosII
core FPGA design files (Altera, 2004). The NiosII devel-
opment tools provide the Hardware Abstraction Layer
(HAL) Application Programming Interface (API) that
incorporates the Newlib ANSI C embedded library. In
addition, the HAL provides some UNIX-style functions.
This provides a higher level of abstraction than the ARM
tools, facilitating the removal of the GPS Architect's
booting, initialization and interrupt assembler code, as
well as most of the serial port communication code. Al-
tera also provide a development board with a Stratix
FPGA device and associated memory and I/O facilities
called the 'NiosII Development Board - Stratix Edition'
(EvalBoard, 2004). This is a very convenient platform to
get projects up and running quickly. It is used for Stage 1,
and Stage 2.
3.3 Stage 1: SuperStar-NiosII
The first stage involves porting the GPS Architect soft-
ware to a NiosII processor connected to an existing
GP2021/GP2015 hardware platform. To do this, a "hack"
is performed into a Superstar receiver to effectively re-
place the ARM60 with a NiosII processor. This is
achieved by removing the ARM60 and memory chips and
connecting the GP2021 address, data and some control
lines to a header on the NiosII Development Board.
RT-Exec Code
The GPS Architect software has a minimal RTOS closely
integrated with the rest of the code. The task-switching
core of this RTOS is coded in assembler, and this is com-
pletely rewritten for the NiosII processor.
SuperStar-Interface
An interface to read and write to the GP2021 baseband
signal processor and other registers is required, as these
are not memory-mapped registers as in the GP4020 case.
This 'glue logic' is realised in the FPGA as a small VHDL
module connected between dedicated parallel I/O ports
on the NiosII and the data, address and control lines of
the GP2021. Read and write functions provided by the
HAL API are used to send and receive serial data via the
NiosII UART's.
3.4 Stage 2: GP2021_Emulator-NiosII
The second stage is to replace the external GP2021 base-
band signal processor by an FPGA baseband processor in
the Stratix device. The FPGA baseband processor is de-
signed as a GP2021 emulator such that the code devel-
oped in Stage 1 can be reused with changes required to
the SuperStar-Interface only. For this stage, only the RF
front-end chip GP2015 of the SuperStar receiver is used.
The sampled signals (sign and magnitude) from the
GP2015 are connected to FPGA pins and these signals
are routed internally to the FPGA baseband processor.
GP2021 Emulator
In order to emulate the GP2021 silicon inside the FPGA,
a separate baseband processor is being developed to pro-
vide all of the functions as expected by the ported soft-
ware. This block will replace the GP2021 baseband proc-
essing functions using internal FPGA connections to the
NiosII core via an on-chip Avalon Bus. These functions,

66 Journal of Global Positioning Systems
Fig. 1 Block Diagram of the Platform
such as the multi-phase clock generator, time base gen-
erator, numerically controlled oscillators, correlator mod-
ules etc. are developed in HDL to initially have identical
functionality to the GP2021. The system clock and RF
signal connections from the GP2015 GPS RF front-end
chip to the baseband processor are still required from the
SuperStar receiver board.
Obviously not all of the GP2021 functions need to be
emulated, given that the chip was originally designed as a
multi-purpose chip to support other microprocessor inter-
face schemes, and also Glonass signals. Improvements in
the core baseband processing functions of the GP2021
will come later as the design diverges from the ported
software in Stage 3 of the development. While Glonass
signal processing capability is possible within the FPGA,
support for this may be considered in the future because
at the moment the different RF front-end structure is not
easily accessible.
3.5 Stage 3: Custom GNSS Platform
In Stage 3, SuperStar receiver and NiosII Development
Board are replaced with a custom designed board shown
in Figure 1. This board has all the regular features such as
I/O, memory, status LED’s and switches, an Altera
Stratix device, headers for expansion and multiple RF
front-ends. In fact it has many similarities to the NiosII
Development Board. This will help facilitate the move
from Stage 2.
The board has two RS232 serial ports along with Ethernet
10/100 and a USB port. The UART components for the
serial ports are instantiated into the FPGA as peripherals
connected to the on-chip Avalon Bus, while both the
Ethernet and USB functions are provided by external
chips connected to the FPGA to become peripherals ac-
cessible in the NiosII address space.
Switches,
LEDs, etc.
RS232
Interface
RS232
Interface
USB
Interface
Ethernet
Interface
Power
Supply
Serial Flash
External
Interface
GP I/O
External Clock
Oscillator
Altera
Stratix
FPGA
RF
RF
JTAG
GP2015
Front
End
GP2015
Front
End
ROM
RAM

Engel et al.: An Open GNSS Receiver Platform Architecture 67
Fig. 2 Signal Path Options
Providing flexibility in RF front-end choice facilitates
access to the new signals as well as new designs as they
emerge. The custom board incorporates two GP2015 RF
front-ends, and a special header to accommodate an ex-
ternal RF front-end or any other extension board. This
arrangement potentially allows simultaneous reception of
multiple signals at different frequencies. Figure 2 illus-
trates some possible signal paths.
The clock signals for the on-board and external RF front-
end chips are driven from either a common temperature
compensated oscillator or an external signal source via a
small coaxial connector. This allows the use of an op-
tional extra stable frequency source where required. In
both cases the clock signal is also connected to the FPGA
phase locked loop circuitry to allow multi-phase clock
generation within the device.
4 Further Development
This project has the fundamental objectives of proving
the concept and developing a platform for future investi-
gations. Due to the configurable nature of FPGAs, there
are many possibilities for investigation including:
• Baseband signal processing block design: This
design is not restricted to a GP2021 emulator, as
many design enhancements are possible. Ideas in-
clude; improved tracking in weak signal and multi-
path environments.
• DSP search engine: The Stratix FPGA device
has DSP blocks, which could be used to create a
search engine for signal acquisition and tracking,
particularly for weak signals.
(a) L1 only
FPGA
GP2015
Front
End
(c) Other Signals
External
Front End
Interface
FPGA
External
RF Front
End
(b) L1 and L2
GP2015
Front
End
GP2015
Front
End
FPGA

68 Journal of Global Positioning Systems
• Develop the GPS Architect software for better
performance or specific functionality: The SNAP
Group has developed improvements and additions
such as better tracking algorithms, which could be
implemented into the standard GPS Architect soft-
ware (Lee, 2003 and Mumford, 2003 and Satirapod,
2003). A licence is required to develop applications
using the GPS Architect software suite. However,
binaries developed by a licensed user can be distrib-
uted without royalties. There may be a way of dis-
tributing core functionality as a binary API, allowing
the development of particular critical sections such
as the tracking loops.
• Replace the GPS Architect with another soft-
ware suite: for control, tracking and navigation solu-
tion functions on the NiosII processor. The OpenGPS
project (OpenGPS, 2004) is a possible candidate
here.
• Raw data collection and packaging for PC
based soft receiver processing: The sign and magni-
tude data from the RF front-end can be collected and
packed up for transmission via Ethernet to a host PC
or stored onto USB media.
• Signal interference detection: The custom board
is ideal for developing signal interference and jam-
ming detectors.
5 Intermediate Results
Stage 1 of this project is almost finished. All architecture
dependant software parts (See Sec.3.3) are ported. Tests
show the system is capable of tracking of at least 9 satel-
lites and able to run more than 16 hours without failing.
This means a reference design is available which will be
used to evaluate accuracy of the baseband processor emu-
lation, the main task of Stage 2.
As for Stage 2, the development and testing of the initial
designs for the baseband signal processor to emulate the
functionality of the GP2021 have begun. So far a single
channel correlator is under development. First simulation
results and size estimates show that the design will fit
into a Stratix device and meet timing requirements. The
DSP blocks available within the Stratix device could be
optionally used and investigations are under way to
evaluate how their use may contribute to improve per-
formance.
The custom GNSS platform board is in the early stages of
development.
6 Conclusion
In this paper an approach of designing an FPGA based
GNSS receiver platform is described. The project has
been broken down into three stages so that particular
problems can be isolated and addressed at each stage. In
Stage 1 the focus is on porting the GPS Architect soft-
ware to the NiosII processor architecture. Once the GPS
Architect is running smoothly on the NiosII Development
Board with a GP2021 baseband processor and a GP2015
RF front-end attached, Stage 2 can be tackled. This stage
involves replacing the GP2021 with an FPGA baseband
signal processor emulating the main features of the
GP2021. Finally, the developed design can be ported to
the platform, a FPGA based prototyping board.
The outcome of this project will be a development plat-
form for investigations into GNSS receiver designs for
current and future signals. It is the intention of this pro-
ject to foster research into improvements of existing GPS
receiver solutions, new GNSS signals and to help realis-
ing product ideas by providing a sophisticated hard-
ware/software infrastructure.
References
Altera (2004): Altera Inc. – Homepage. Altera Inc.
http://www.altera.com .
Canalys (2004): EMEA mobile GPS navigation market races
ahead. GPS market analysis, http://www.canalys.com/pr/
2004/r2004093.htm .
EGNOS (2004): European Geostationary Navigation Overlay
System (EGNOS). European Space Agency (ESA), http://
esamultimedia.esa.int/docs/egnos/estb/egnos_pro.htm .
EvalBoard (2004): NiosII Development Kit - Stratix Edition.
Altera Inc., http://www.altera.com/products/devkits/altera/
kit-nios_1S10.html .
FCC (2004): Wireless Enhanced 911 Rules (E911). US Federal
Communications Commission (FCC), http:// www.fcc.gov/
911/enhanced/ .
Galileo (2004): Galileo. European Space Agency (ESA),
http://www.esa.int/esaNA/galileo.html .
Glonass (2004): GLONASS Satellite Navigation System. Rus-
sian Federation Ministry of Defence, http://www.glonass-
center.ru .
GP2021 (2001): GP2021 GPS 12-Channel Correlator. Zarlink
Semiconductor Inc., Data Sheet (DS4077, Issue 3.2), April
2001.
GP2015 (2002): GP2015 Miniature GPS Receiver RF Front
End. Zarlink Semiconductor Inc., Data Sheet (DS4374, Is-
sue 3.1), Feb. 2002.
GP4020 (2002): GP4020 GPS Receiver Baseband Processor.
Zarlink Semiconductor Inc., Data Sheet (DS5134, Issue
4.4), May 2002.

Engel et al.: An Open GNSS Receiver Platform Architecture 69
GPSArch (1997): GPS Architect - 12 Channel GPS Develop-
ment System. Zarlink Semiconductor Inc., Data Sheet
(DS4605, Issue 2.5), March 1997.
Lee H.K.; Rizos C.; Jee, I.G. (2003): Design and analysis of
DGPS filters with consistent error covariance informa-
tion. In Proceedings of 6th Intl. Symposium. on Satellite
Navigation Technology Including Mobile Positioning and
Location Services, Melbourne, Australia, 22-25 July 2003,
paper 47.
Mumford P. (2003) Timing characteristics of the 1PPS output
pulse of three GPS receivers. In Proceedings of 6th Intl.
Symposium. on Satellite Navigation Technology Including
Mobile Positioning and Location Services, Melbourne,
Australia, 22-25 July 2003, paper 45.
OpenGPS (2004): OpenGPS, http://www.gfz-potsdam.de/pb1/
staff/gbeyerle/opengps/ .
Petrovski I. (2003): QZSS - Japan's New Integrated Commu-
nication and Positioning Service for Mobile Users.
GPSWorld, 14(6):24-29.
SBAS (2004): Satellite Base Augmentation System (SBAS),
Eurocontrol SBAS Project, http://www.eurocontrol.fr/ pro-
jects/sbas/ .
Satirapod C.; Khoonphool R.; Rizos C. (2003): Multipath
mitigation of permanent GPS stations using wavelets.
Proceedings of 2003 Intl. Symposium. on GPS/GNSS, To-
kyo, Japan, 15-18 Nov. 2003, 133-139.
WAAS (2004) Wide Area Augmentation System (WAAS), US
Federal Aviation Administration (FAA), http://gps.faa.gov/
Programs/WAAS/waas.htm .