An open GNSS receiver platform architecture

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

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

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.