0% found this document useful (0 votes)
7 views7 pages

An Open GNSS Receiver Platform Architecture

The article discusses the development of an FPGA-based GNSS receiver architecture aimed at facilitating research into new receiver concepts and algorithms for current and upcoming GNSS standards. It outlines a three-stage approach to create a flexible platform that supports various signal processing solutions and enhances interoperability among GNSS systems. The platform is designed to allow researchers to work with real satellite signals, thus accelerating the development of next-generation navigation technologies.

Uploaded by

alonezero2426
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views7 pages

An Open GNSS Receiver Platform Architecture

The article discusses the development of an FPGA-based GNSS receiver architecture aimed at facilitating research into new receiver concepts and algorithms for current and upcoming GNSS standards. It outlines a three-stage approach to create a flexible platform that supports various signal processing solutions and enhances interoperability among GNSS systems. The platform is designed to allow researchers to work with real satellite signals, thus accelerating the development of next-generation navigation technologies.

Uploaded by

alonezero2426
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

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: {[Link], [Link]}@[Link] Tel: + 61 2 9358 7339; Fax: +61 2 9385 7942

Satellite Navigation and Positioning Group (SNAP), The University of New South Wales (UNSW)
e-mail: {[Link], [Link]}@[Link], kevin@[Link] Tel: + 61 2 9358 4182; Fax: +61 2 9313 7493

Received: 15 Nov 2004 / Accepted: 3 Feb 2005

Abstract. In this article we present the concept of a 1.1 Background


FPGA-based GPS receiver architecture with the aim of
providing a framework for investigating new receiver Although GPS is the only fully operational 'first genera-
architectures for current and upcoming GNSS standards. tion' Global Navigation Satellite System (GNSS), since
This development system facilitates researchers to prove the mid-1980s signals from the Russian Federation's
new receiver concepts using real signals, which nowa- Glonass system have also been available (Glonass, 2004).
days can only be simulated using tools such as Matlab. However, since 1995 Glonass has been starved of funding
One will be able to work with the satellites as soon as and the constellation has progressively degraded. Russia's
they are operational, rather than having to wait for the President has announced that the full Glonass system will
availability of commercial products. The system allows again be operational by 2008. In January 2004 India
individual development of signal processing solutions for signed a Memorandum of Understanding with Russia to
base-band processing. A soft-core processor implements collaborate on the Glonass refurbishment.
higher layer services that provide data to the user.
Europe is currently developing its own 'second genera-
tion' GNSS, known as Galileo (Galileo, 2004), for de-
Key words: GPS Receiver, GNSS, FPGA, Soft-Core ployment between 2006 and 2008. In 2003 China signed
Processor 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)
1 Introduction (SBAS, 2004) because they transmit extra signals that
certain receivers can decode and use (together with the
The Global Positioning System (GPS) is a satellite-based, global GNSS signals) to achieve improved positioning
all-weather, round-the-clock navigation system developed performance. To augment GPS for aviation users, the
by the U.S. Department of Defence. Since the early 1980s U.S. and Europe have deployed the Wide Area Augmen-
GPS has been available to the civilian community and is tation System (WAAS) and the European Geostationary
the most effective navigation and positioning system ever Navigation Overlay System (EGNOS) respectively
developed. Once a tool for experts and an exotic gadget (WAAS/EGNOS, 2004). Japan, India and China have
for nerds, it is rapidly becoming a commodity. Location- indicated that they too will develop regional SBAS by the
aware devices are an essential part of many ubiquitous end of this decade. The most advanced plans are Japan's
computing scenarios, and the recent mandate by the US Quasi-Zenith Satellite System (QZSS) (Petrovski, 2003), a
FCC (FCC, 2004) that all emergency calls from mobile constellation of 3 to 7 satellites that will broadcast GPS
phones must be locatable has increased the pressure on (and ultimately Galileo) signals from orbits optimised for
improving the technology. Satellite-navigation receivers East Asian.
will in the future be embedded in a large number of de- In the near to medium-term future the market for satellite
vices of widely different uses. 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- taining receiver status (e.g. tracking satellites) is usu-
duction in costs of GNSS receivers will support new ap- ally executed by a micro controller (µC) running
plication fields like indoor positioning for consumer de- special firmware.
vices. Besides the positioning data, these systems will
According to this structure, a generic receiver platform
support extra, low data rate channels. These channels can
should support interfaces to various RF front-ends, signal
be used to receive personalised information similar to a
processing hardware, and (µC supported) software layers
pager system, which prepares the ground for new services
for control processing and applications.
offering this information.

2.2 Configurability
1.2 Project Objectives
State of the art field programmable gate array devices
The aim of this project is to develop a platform for inves-
(FPGAs) such as Altera’s Stratix series provide high
tigating new algorithms and systems based on current and
computational capacities of up several million logic ele-
upcoming GNSS receiver standards. This platform could
ment equivalents (Stratix, 2004). Besides pure configur-
serve as a generic base for GNSS research that supports
able logic they also provide on-chip memory and DSP
research into signal processing issues, protocols and early
capabilities. Thus they are very well suited for complete
implementation of emerging standards:
system-on-chip solutions (SoC) without the need of sili-
• A reference and testbed environment to investi- con fabrication. Furthermore, FPGA vendors offer CPU
gate interoperability and standard compliance. cores integrated into the FPGA either as hard-core or
soft-core. While hard-core processors are optimally inte-
• An IP block readily accessible to industry part- grated into the FPGA fabric, soft-core processors allow a
ners for development of GNSS and GNSS-enhanced fine grain tailoring towards the design requirements by
devices. introducing caches and specialised instructions etc.
• Considering the wide range of next generation Following this strategy, baseband processing could be
GNSS signals a solution is required that support implemented by FPGA logic, supported by hardware
flexible hardware and software design. As an exam- macros, while control processing could be implemented
ple, a system that can incorporate extra processing by a soft-core processor such as Altera's NiosII. Thus an
power or tracking channels, as the need arises. FPGA device serves as the central processing element on
The article is structured as follows. Section 2 introduces this reconfigurable platform. It connects to RF front-ends
the requirements of such a platform concept. Section 3 as well as different communications interfaces (e.g.
explains project stages in more detail. Section 4 discusses TCP/IP, RS232, USB).
future investigations into improved GNSS receivers and
applications/products. Intermediate project results and a
conclusion finalises this article. 3 Approach

The general approach is to break the development process


2 Platform Reqirements into three stages. These stages relate to the migration of
the hardware platform from a Mitel Superstar receiver
2.1 Components towards the FPGA solution on a custom designed circuit
board. The stages are identified as:
In general a GNSS receiver consists of three major com- • Stage 1: SuperStar-NiosII;
ponents:
• Stage 2: GP2021_Emulator-NiosII and;
• RF front-end to receive GNSS signals and con-
verting into baseband: Since satellite signals are very • Stage 3: Custom GNSS Platform.
weak, the development of front-end components still The Mitel GPS Architect (sometimes referred to as
requires custom circuit design. Orion) has become some sort of standard GPS software
• Baseband processing to generate raw / pre- suite for the Zarlink chipsets. It was available as a devel-
processed data from received signals: It comprises opment kit with a licence allowing royalty free distribu-
strong digital signal processing either executed by tion of compiled binaries (GPSArch, 1997). The SNAP
custom hardware or a digital signal processor (DSP). Group purchased a kit in 1999. The GPS Architect has
been selected for testing purposes for the reasons men-
• Control processing to manage receiver activity tioned above. Altera's products 'Quartus' and the 'NiosII
and post-process data: Besides converting raw data IDE' are the primary tools used for programming the
into e.g. position velocity and time, tasks like main- FPGA and code generation (Altera, 2004).
Engel et al.: An Open GNSS Receiver Platform Architecture 65

3.1 Mitel GPS Architect 3.3 Stage 1: SuperStar-NiosII

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

JTAG

External Serial Flash


Interface

GP2015 Power
Front Supply
RF
End
Altera
Ethernet
Stratix
Interface
FPGA
GP2015
RF Front USB
End Interface

RAM
RS232
Interface

ROM
RS232
Oscillator
Interface

GP I/O

External Clock Switches,


LEDs, etc.

Fig. 1 Block Diagram of the Platform

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

GP2015
Front FPGA
End

(a) L1 only

GP2015
Front
End

FPGA
GP2015
Front
End

(b) L1 and L2

External External
RF Front Front End FPGA
End Interface

(c) Other Signals

Fig. 2 Signal Path Options

Providing flexibility in RF front-end choice facilitates 4 Further Development


access to the new signals as well as new designs as they
emerge. The custom board incorporates two GP2015 RF This project has the fundamental objectives of proving
front-ends, and a special header to accommodate an ex- the concept and developing a platform for future investi-
ternal RF front-end or any other extension board. This gations. Due to the configurable nature of FPGAs, there
arrangement potentially allows simultaneous reception of are many possibilities for investigation including:
multiple signals at different frequencies. Figure 2 illus-
trates some possible signal paths. • Baseband signal processing block design: This
design is not restricted to a GP2021 emulator, as
The clock signals for the on-board and external RF front- many design enhancements are possible. Ideas in-
end chips are driven from either a common temperature clude; improved tracking in weak signal and multi-
compensated oscillator or an external signal source via a path environments.
small coaxial connector. This allows the use of an op-
tional extra stable frequency source where required. In • DSP search engine: The Stratix FPGA device
both cases the clock signal is also connected to the FPGA has DSP blocks, which could be used to create a
phase locked loop circuitry to allow multi-phase clock search engine for signal acquisition and tracking,
generation within the device. particularly for weak signals.
68 Journal of Global Positioning Systems

• Develop the GPS Architect software for better 6 Conclusion


performance or specific functionality: The SNAP
Group has developed improvements and additions In this paper an approach of designing an FPGA based
such as better tracking algorithms, which could be GNSS receiver platform is described. The project has
implemented into the standard GPS Architect soft- been broken down into three stages so that particular
ware (Lee, 2003 and Mumford, 2003 and Satirapod, problems can be isolated and addressed at each stage. In
2003). A licence is required to develop applications Stage 1 the focus is on porting the GPS Architect soft-
using the GPS Architect software suite. However, ware to the NiosII processor architecture. Once the GPS
binaries developed by a licensed user can be distrib- Architect is running smoothly on the NiosII Development
uted without royalties. There may be a way of dis- Board with a GP2021 baseband processor and a GP2015
tributing core functionality as a binary API, allowing RF front-end attached, Stage 2 can be tackled. This stage
the development of particular critical sections such involves replacing the GP2021 with an FPGA baseband
as the tracking loops. signal processor emulating the main features of the
GP2021. Finally, the developed design can be ported to
• Replace the GPS Architect with another soft- the platform, a FPGA based prototyping board.
ware suite: for control, tracking and navigation solu-
tion functions on the NiosII processor. The OpenGPS The outcome of this project will be a development plat-
project (OpenGPS, 2004) is a possible candidate form for investigations into GNSS receiver designs for
here. current and future signals. It is the intention of this pro-
ject to foster research into improvements of existing GPS
• Raw data collection and packaging for PC receiver solutions, new GNSS signals and to help realis-
based soft receiver processing: The sign and magni- ing product ideas by providing a sophisticated hard-
tude data from the RF front-end can be collected and ware/software infrastructure.
packed up for transmission via Ethernet to a host PC
or stored onto USB media.
• Signal interference detection: The custom board References
is ideal for developing signal interference and jam-
ming detectors. Altera (2004): Altera Inc. – Homepage. Altera Inc.
[Link] .
Canalys (2004): EMEA mobile GPS navigation market races
5 Intermediate Results ahead. GPS market analysis, [Link]
2004/[Link] .
Stage 1 of this project is almost finished. All architecture EGNOS (2004): European Geostationary Navigation Overlay
dependant software parts (See Sec.3.3) are ported. Tests System (EGNOS). European Space Agency (ESA), http://
show the system is capable of tracking of at least 9 satel- [Link]/docs/egnos/estb/egnos_pro.htm .
lites and able to run more than 16 hours without failing. EvalBoard (2004): NiosII Development Kit - Stratix Edition.
This means a reference design is available which will be Altera Inc., [Link]
used to evaluate accuracy of the baseband processor emu- kit-nios_1S10.html .
lation, the main task of Stage 2.
FCC (2004): Wireless Enhanced 911 Rules (E911). US Federal
As for Stage 2, the development and testing of the initial Communications Commission (FCC), http:// [Link]/
designs for the baseband signal processor to emulate the 911/enhanced/ .
functionality of the GP2021 have begun. So far a single Galileo (2004): Galileo. European Space Agency (ESA),
channel correlator is under development. First simulation [Link] .
results and size estimates show that the design will fit
into a Stratix device and meet timing requirements. The Glonass (2004): GLONASS Satellite Navigation System. Rus-
sian Federation Ministry of Defence, [Link]
DSP blocks available within the Stratix device could be
[Link] .
optionally used and investigations are under way to
evaluate how their use may contribute to improve per- GP2021 (2001): GP2021 GPS 12-Channel Correlator. Zarlink
formance. Semiconductor Inc., Data Sheet (DS4077, Issue 3.2), April
2001.
The custom GNSS platform board is in the early stages of
GP2015 (2002): GP2015 Miniature GPS Receiver RF Front
development.
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- Petrovski I. (2003): QZSS - Japan's New Integrated Commu-
ment System. Zarlink Semiconductor Inc., Data Sheet nication and Positioning Service for Mobile Users.
(DS4605, Issue 2.5), March 1997. GPSWorld, 14(6):24-29.
Lee H.K.; Rizos C.; Jee, I.G. (2003): Design and analysis of SBAS (2004): Satellite Base Augmentation System (SBAS),
DGPS filters with consistent error covariance informa- Eurocontrol SBAS Project, [Link] pro-
tion. In Proceedings of 6th Intl. Symposium. on Satellite jects/sbas/ .
Navigation Technology Including Mobile Positioning and
Location Services, Melbourne, Australia, 22-25 July 2003, Satirapod C.; Khoonphool R.; Rizos C. (2003): Multipath
paper 47. mitigation of permanent GPS stations using wavelets.
Proceedings of 2003 Intl. Symposium. on GPS/GNSS, To-
Mumford P. (2003) Timing characteristics of the 1PPS output kyo, Japan, 15-18 Nov. 2003, 133-139.
pulse of three GPS receivers. In Proceedings of 6th Intl.
Symposium. on Satellite Navigation Technology Including WAAS (2004) Wide Area Augmentation System (WAAS), US
Mobile Positioning and Location Services, Melbourne, Federal Aviation Administration (FAA), [Link]
Australia, 22-25 July 2003, paper 45. Programs/WAAS/[Link] .

OpenGPS (2004): OpenGPS, [Link]


staff/gbeyerle/opengps/ .

You might also like