GNSS
coordinates


An open GNSS receiver platform architecture

Jan 2006 | Comments Off on An open GNSS receiver platform architecture

 
The aim of the project is to develop a platform for supporting GNSS research and provide an accessible IP block
   

In early 2004 a plan was hatched to develop a Global Navigation Satellite System (GNSS) receiver based around Field Programmable Gate Array (FPGA) technology as a platform to support research in this fi eld. A joint project was set up between the School of Surveying and Spatial Information Systems (SISS) at the University of New South Wales and the National ICT Australia (NICTA), and soon after a small team was established. The team consisted of Kevin Parkinson, a post-graduate student at SISS with experience in FPGA and circuit board design, Frank Engel, a researcher with NICTA with software, Real Time Operating Systems (RTOS) and VHDL design knowledge and me, Peter Mumford from the SISS GNSS research group. At the end of the project we hoped to have an L1 GPS receiver running on a custom circuit board with the baseband processor and navigation solution processor running on an FPGA chip. The project is coming to an end now, and in this article, I will describe our design path, what has been achieved to date and then some potential research areas, but fi rst a little background.

Background

The Global Positioning System (GPS) is the only fully operational GNSS,
but with the Russian Federation’s Glonass System being refurbished (with the help of India) and the European’s Galileo, there may be three operational systems by 2008. In addition, there are Space Based Augmentation Systems (SBAS), Wide Area Augmentation Systems (WAAS), Japan’s Quasi-Zenith Satellite System (QZSS) and other signals that will become, or are already available to GNSS receivers. To enable research with so many new signals, a fl exible platform is required that can respond to the requirements of the signals without waiting for Application Specifi c Integrated Circuit (ASIC) chips to become available. FPGA technology is a natural choice to host the baseband and application processors due to their inherent design fl exibility, the maturity of the chips and development tools, good performance and reasonable price. Getting fl exibility in the Radio Frequency (RF) front end is a bit more diffi cult.

In the near to medium-term future the market for satellite navigation technology is expected to continue to experience major growth (Canalys, 2004). The ability to integrate GNSS functionality into a device by hosting the baseband processor on an existing FPGA chip may provide an opportunity to lower costs, as well as providing a degree of future-proofi ng. In addition, the relative ease of creating special GNSS attributes in an FPGA may lead to novel applications or solve particular problems.

The aim of the project is to develop a platform for supporting GNSS research and provide an accessible IP block. To explain the content of this platform, I will fi rst describe the three major components of a generic GNSS receiver, they are:

1) The RF front-end for receiving GNSS signals and converting it down into an Intermediate Frequency (IF) sampled baseband signal.

2) The baseband processor (sometimes called the correlator block) that
provides data for acquiring and tracking the signal, and measurements for calculating the position/time solution.

3) A micro-processor that runs software to control the baseband processor, and compute and communicate the position/time solution.

The first component generally requires special circuitry, although single
chip GPS receivers have recently become available. Components 2 and 3 typically reside in the same ASIC, but can likewise be hosted in the one FPGA chip as FPGA vendors offer CPU cores (as well as memory and DSP capabilities) integrated into the chips.

The Mitel GPS Architect

The Mitel GPS Architect (sometimes referred to as Orion) software was designed to help Mitel sell GPS chips by providing reference software in
the form of a development kit. The original software runs on an ARM60 processor, with a Zarlink GP2021 (Zarlink, 2001) baseband processor and GP2010 or GP2015 RF front end. In 2003 I ported the code to the Sigtec MG5001 GPS receiver. This receiver has a Zarlink GP4020 chip with an ARM7 core and GP2015 RF front end. The GP4020 has the same correlator design as the GP2021. It seemed a natural progression to port the GPS Architect to Altera’s NiosII processor.

Altera Tools

The FPGA vendor Altera provides a logic development tool called “Quartus” and a software development tool, the “NiosII IDE” for the

pic1

NiosII soft-core processor. Quartus contains the “SOPC Builder” used for generating Nios core FPGA design fi les. The NiosII development tools provide a Hardware Abstraction Layer (HAL) and an Application Programming Interface (API) that incorporates the Newlib ANSI C embedded library. Altera has a range of development boards available, these are very convenient for getting projects up and running quickly. The Statix development board is used for the fi rst task of this project.

Design Approach

The approach we have taken is to break the development process into three main tasks. These tasks are identifi ed as “SuperStar_ NIOS”, “FPGA_baseband” and the “Custom GNSS Platform” and are described below.

SuperStar-NIOS

This fi rst task involved porting the Mitel GPS Architect software to the NiosII processor. To set up the hardware for working on the port, we hacked into a Superstar receiver and removed the ARM60 and memory chips. We then connected the GP2021 address, data and control lines to a header onto an Altera Nios Development Board. Figure 1 shows what it looked like.

There are signifi cant differences between the NiosII and ARM7 architectures and instruction sets, as well as differences in the

pic2

development tools and embedded libraries. The main effort in porting the software concentrated around the RTOS, serial port communication and hardware initialization. The GPS Architect 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 was completely rewritten for the NiosII processor. Some ‘glue logic’ was required to connect the Nios processor to the GP2021 baseband processor. After some debugging we obtained the correct position/time solution. However, the hardware arrangement was quite noisy, and the position solution revealed some evidence of this, however in most respects the receiver performed much like the Signav receiver running the GPS Architect.

FPGA_baseband

The second task was to develop a baseband processor design in VHDL logic. The Zarlink 2021 was used as an architectural model to get things
rolling. The code was developed and functionally debugged with ModelSim. Once the design was complete a testbench was built to inject a sampled GPS signal into the design and look for correlation peaks. The sampled signal fi le consisted of a few milliseconds of sign and magnitude raw IF data generated by Data Fusion software. The simulation typically took several days to run, and we eventually found the correlation peaks we where looking for.

 
–~~~~~~~~~~~~–

Custom GNSS platform

The third task was to develop a custom designed circuit board and then port the GPS Architect software to it. The board is shown in fi gure 4, it has an Altera CycloneII FPGA device and a Zarlink 2015 RF frontend. For IO there is an Ethernet port, two RS232 serial ports and a JTAG programming / debugging port. There is sram and flash memory as well as a confi guration controller and serial fl ash. There are expansion headers, a real time clock, a three axis accelerometer, leds, switches and sma connectors.

The board was designed for very low noise to keep interference with the sensitive RF front end down. It can be seen in fi gure 5 that the IF output of the 2015 RF chip is free from interference spikes.

pic3
pic4

A single channel baseband processor has been built on this board to test the correlation functions and tune the tracking loops. Correlation peaks have been obtained from signals injected from a Spirent GPS simulator. Figure 6 shows a correlation plot, on the xaxis is the code delay (in half-chips) over two carrier doppler bins, and on the y-axis is the correlation power.

Shortly, we will fi nish working on the tracking loops and then the GPS Architect is pretty much ready to run on the custom GNSS board. There
will be a debugging and testing stage over the next few months, followed by the publishing of our results. We also have an improved baseband processor written in Verilog ready to replace the VHDL version.

The infl exibility of the RF front end was eluded to earlier in this article. The custom board has only an L1 (1575MHz) front end. Due to passband fi ltering and available chips, it is diffi cult to make a front end that covers more bands. Our solution was to provide a header and some sma

pic5
pic6

clock connectors to allow a daughter board to be attached later for access to other signals. Daughter boards can be built to suite the Galileo and new GPS signals once the RF chips are available.

Further Development

Due to the confi gurable nature of FPGA’s, there are many possibilities for research using this platform including:

• Baseband signal processing design: improved tracking in weak signal and    multi-path environments.

• Investigating new signals.

• DSP search engine: for signal acquisition and tracking, particularly for    weak signals.

• Develop the GPS Architect software for better performance or specifi c    functionality.

• Replace the GPS Architect.

• Raw data collection and packaging for PC based soft receiver processing.

• Signal interference (jamming) detection.

• Ultra-tight INS integration.

Conclusion

The project is heading towards completion. We have the FPGA GNSS circuit board running a single channel baseband processor, tracking a GPS satellite. We have the GPS Architect software ready to run on the NiosII processor. We hope to complete testing and report our results in early 2006. We hope that our work will then be of value to the GNSS research community.

References

FCC (2004) Wireless Enhanced
911 Rules (E911), US Federal
Communications Commission (FCC),
http:// www.fcc.gov/911/enhanced/

WAAS (2004) Wide Area
Augmentation System (WAAS),
US Federal Aviation Administration
(FAA), http://gps.faa.gov/
Programs/WAAS/waas.htm

Altera (2004) Stratix Device –
– Product Brief, Altera Inc.,
http://www.altera.com/products/
devices/dev-index.jsp

EGNOS (2004) European
Geostationary Navigation Overlay
System (EGNOS), European Space
Agency (ESA), http://esamultimedia.
esa.int/docs/egnos/estb/egnos_pro.htm

SBAS (2004) Satellite Base
Augmentation System (SBAS),
Eurocontrol SBAS Project, http://
www.eurocontrol.fr/projects/sbas/

GLONASS (2004) GLONASS
Satellite Navigation System, Russian
Federation Ministry of Defense,
http://www.glonass-center.ru

Canalys (2004) EMEA mobile GPS
navigation market races ahead,
GPS market analysis, http://www.
canalys.com/pr/2004/r2004093.htm

Galileo (2004) Galileo, European
Space Agency (ESA), http://www.
esa.int/esaNA/galileo.html

Petrovski I (2003) QZSS – Japan’s
New Integrated Communication
and Positioning Service for Mobile
Users, GPSWorld, 14(6):24-29

Zarlink (2001) GP2021 GPS
12-Channel Correlator, Zarlink
Semiconductor Inc. http://
www.zarlink.com/product_
profi les/gp2021.htm

 

Peter Mumford

Research Assistant, School of Surveying and
Spatial Information Systems, University of New South
Wales, Sydney Australia.
p.mumford@unsw.edu.au
   

Kevin Parkinson

Design Engineer, Currently completing a Master of
Engineering degree at the University of New South Wales
with the Satellite Navigation and Positioning Group.
   

Frank Engel

Senior Engineer, Philips
Semiconductors
Dresden, Germany
   
     
 
My coordinates
EDITORIAL
 
His Coordinates
Steve Berglund
 
News
INDUSTRYGPSGIS  | GALILEO UPDATE
 
Mark your calendar
May 09 TO DECEMBER 2009

«Previous 1 2View All| Next»

Pages: 1 2

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...