Aquarius Firmware for UNSW Namuru GPS Receivers

International Global Navigation Satellite Systems Society IGNSS Symposium 2011

University of New South Wales, Sydney, NSW, Australia

15 – 17 November 2011

Aquarius Firmware for UNSW Namuru GPS Receivers

Eamonn P. Glennon

School of Surveying and SIS, UNSW, Australia [email protected]

Peter J. Mumford

School of Surveying and SIS, UNSW, Australia [email protected]

Kevin Parkinson

General Dynamics Corporation, Albany, New Zealand [email protected]

ABSTRACT

UNSW is well known for its work in the development of FPGA based GPS

receivers. However, a hardware platform without suitable firmware severely

limits the application of that hardware and for the Namuru, the only

available firmware has been the GPS Architect and the GPL-GPS.

Unfortunately, both of these firmware suites have their limitations and it is

for this reason that the Aquarius firmware suite has been created.

This paper describes the Aquarius firmware suite, highlighting some unique

features that have been included in the design. One such feature is the use of

a GPS receiver driver layer to hide aspects of the frequency plan and

correlator architecture, thereby assisting in adapting the firmware as new RF

front ends become available or changes to the FPGA hardware are applied in

order to enhance the hardware operation. A second such feature is the

inclusion of specific code to assist in running release or acceptance testing

without the need for external test control software. Other aspects of the

firmware design are also described, including a short overview of the

features provided by the firmware. Finally, test results showing the

performance of the receiver are also provided.

KEYWORDS: GPS, receiver, firmware, FPGA.  

1. INTRODUCTION

The School of Surveying and Spatial Information Systems (SSIS) at the University of New

South Wales (UNSW) has been long recognised as one of the leading research organisations

in the field of Global Positioning System (GPS) and Global Navigation Satellite System

(GNSS) navigation and signal processing. However, like many research organisations in this

area, it faces the problem that many of the interesting GNSS problems that require research

attention relate to the internal operation of the GNSS receivers themselves. Unfortunately,

access to the internal operation of the receivers is rarely available, which makes performing

the research difficult.

One solution to this problem is for the research organisations to build their own GNSS

receivers, but this option is usually denied because most GNSS receiver companies that

supply the chipsets or completed receiver boards also supply the associated firmware as a

precompiled binary image. For a GNSS chipset supplier, the supply of firmware is often

mandatory as the complexity of the required firmware is often beyond the developmental

capabilities of the system integrators who purchase the products. It also allows the GNSS

chipset supplier to guarantee that the acceptable performance of the system as a whole.

Because the companies supply full receiver systems to their customers, it is generally not

necessary for them to publish the datasheets that describe the baseband correlator, which is

the component that represents a significant portion of the engineering cost. This has the

effect of preventing third parties from purchasing the chipsets and creating their own

firmware, with the added benefit of preventing competitors gleaning important product details

from an examination of the datasheets. Given that the GPS market is highly competitive and

that rationalisation of the market is likely to continue, there is no reason to expect any change

in this situation.

A far more widely adopted solution that has been employed by many universities is to make

use of software defined radio (SDR) receivers. One half of this approach is the use of GNSS

IF data capture equipment, such as the Ettus Research USRP products, the Racelogic LabSat

GPS/Glonass record and playback devices or the discontinued NordNav receivers. The other

half of the solution is to process the captured signals using a software receiver, with the

MATLAB based Kai-Borre software receiver being an excellent example (Borre et al., 2007).

Unfortunately this approach is significantly constrained by the size of the IF data and the

limited processing speed of a software correlator. Real-time processing of IF data is also

possible, although requires the use of custom software tailored to a powerful processor (high

end desktop or laptop) and specially developed hardware.

In contrast to these solutions, in 2004 UNSW decided to pursue an alternative approach

making use of field programmable gate arrays (FPGAs) (Engel et al., 2004; Mumford et al.,

2006). Such devices, which can be considered to be flexible application-specific integrated-

circuits (ASICs), allow many of the benefits of a fully commercial GNNS receiver to be

obtained. This follows because the FPGA can be considered to be equivalent to the GNSS

specific ASIC that it generally replaces. Indeed, commercial GNSS receiver companies often

make use of FPGAs to prototype their digital designs before committing to costly prototyping

at semiconductor fabrication plants. The problem of lack of access to the ASIC datasheets is

eliminated because the research organisation takes on the task of implementing the digital

baseband design itself and therefore defines the functionality itself. This has the effect of

increasing the cost for each individual receiver, although the research organisation can

perform this baseband implementation using the relatively low cost tools that accompany the

FPGA design flow. The receiver may also have higher power consumption due to the use of

FPGA technology. Changes are also easily applied to the FPGA, so that in some ways the

design can be considered an SDR if the FPGA Verilog or VHDL design code is considered as

firmware. However, as was the case for standard SDR, it is still necessary to create a

firmware suite that performs the functions necessary to implement a full GNSS receiver using

the available hardware platform.

Section 2 of this paper introduces the Namuru hardware platforms and describes the firmware

solutions that were available before the development of the Aquarius firmware. Design

requirements and features of Aquarius are described in Section 3, while Section 4 includes

some preliminary results obtained with a beta version of the firmware.

2. NAMURU GPS RECEIVERS

2.1 Namuru V2 Hardware

Although development of the first Namuru hardware, the Namuru V1, was started in 2004, it

is the more recent Namuru V2R4 that has found widespread use. This device, which at the

time of writing is still available for purchase, is a very flexible receiver that has been

successfully used for a wide variety of research. Part of the reason for this success is that the

receiver employs a powerful Cyclone II EP2C50 FPGA with 50,518 logic elements, 129 M4K

RAM blocks, 85 embedded multipliers, 4 PLLs and 294 user IO pins. This represents more

than sufficient capacity to include a full NIOS-2 soft-core, at least 12 hardware correlator

channels each capable of generating in-phase and quadrature samples at several different code

phase taps and UART functionality for serial communications. FPGA configuration data and

receiver firmware is stored within a 64 Mb serial flash memory, while 64 MB of SDRAM has

been included for firmware and other uses. Unlike many receiver designs, the Namuru V2R4

provides two radio frequency (RF) front ends that allow the use of two different antennas. An

L2 to L1 mixer also offers the possibility of tracking L2 signals using one of the L1 front

ends, albeit at a reduced input bandwidth. The board also includes a battery-backed memory

for the non-volatile storage of receiver information such as almanac, ephemeris, ionospheric

corrections, UTC corrections, a previous position fix and receiver configuration parameters.

The backup battery is used to power an on-board real time clock that permits warm or hot

starts to be performed as necessary. A USB2 interface is also available on each board, which

may be used for the output of high data-rate debugging information or the streaming of IF

data captured from the RF front ends. In addition to these standard features, the board may be

optionally loaded with a MEMs IMU and high-speed analogue to digital converter for

research into low cost GPS/INS integration.

2.2 Namuru V3.2 and Future Hardware

The Namuru V3.2 is the first of two planned upgrades for the Namuru GPS receiver platform;

with the receiver being a smaller, lower power and cut-back version of the Namuru V2R4 and

designed for integration into a cubesat. To meet the challenging environment of space, the

Altera SRAM based FPGA has been replaced with 2 Actel flash based FPGAs. One of the

Actel parts is a SmartFusion A2F500 device with a built in ARM Cortex M3 processor, 512

kB of parallel Flash memory, 64 kB of SRAM, a myriad of microcontroller type peripherals

and an FPGA fabric with 11,520 VersaTiles. An Actel ProASIC3E FPGA with 38,400

VersaTiles has also been included in order to ensure that sufficient FPGA logic is available

for larger digital designs. As has been the case with all Namuru designs to date, a GP2015

RF front end has also been used in order to minimise the developmental risk. Some other

features of the Namuru V3.2 include the ability to use a voltage-controlled temperature

compensated crystal oscillator (VC-TCXO) or oven controlled crystal oscillator (OCXO)

instead of a standard TCXO. This will permit the receiver to discipline the local oscillator,

thereby eliminating saw-tooth errors on the output timing pulse (Shmaliy et al., 2007). The

design also includes latch-up detection circuitry and RS422 connections, with the later being

required for integration onto the cubesat platform.

Although the Namuru V3.2 has a high degree of functional equivalence to the Namuru V2R4,

the processor change from the NIOS-2 to the ARM Cortex M3 and the change from Altera to

Actel FPGAs mean that a complex design porting process between the two designs has been

necessary.

In addition to the Namuru V3.2, a Namuru V3.3 is also planned. However, with the Namuru

V3.2 having just gone through its first iteration, the full details on the V3.3 have yet to be

determined. It is envisaged that the design will include a Cyclone IV FPGA, SRAM memory

for run-time program and data storage, a serial Flash for FPGA and firmware load-time

storage. The receiver will also incorporate newer RF designs capable of tracking wideband

L1 signals, GLONASS signals and other modernised GNSS signals in the L2 and L5 bands.

This will allow the implementation of a true system-of-systems GNSS receiver.

2.3 Existing Firmware Solutions

When the Namuru V1 hardware was first developed, there were two options for the provision

of navigation capable firmware for the device. The first was to port the GP2015/GP2021

reference software sold by GEC Plessey Semiconductor as part of their GPS Builder and GPS

Architect development kit (GEC Plessey Semiconductors, 1997). This software was designed

to demonstrate to customers the basic operation of a GPS receiver using the GP2015/GP2021

GPS chipset, but did not offer the high performance that was typically available with OEM

boards that were commonly available at the time. As such, the firmware offered a reasonable

level of reliability and performance associated with the maturity of a product that had been on

the market for several years, but did require that a customer purchase a GPS Builder or GPS

Architect from GEC Plessey Semiconductor. Because UNSW had previously purchased one

of these kits and the Altera Cyclone II GPS correlator was designed to be compatible with the

GP2021, a decision was made to use the GPS Architect as the baseline for the Namuru code.

This turned out to be a good decision and the Namuru V1 made a successful debut.

Unfortunately, use of the GPS Architect came with several severe drawbacks. One was that

when GEC Plessey Semiconductor (now Zarlink Semiconductor) decided to exit the GPS

market, the GPS Architect development kit was left orphaned. With the kit no longer

available for purchase and the software never placed into the public domain, the question of

whether it was acceptable to supply the software to third parties was unclear. A second

difficulty was that the software was only intended as a demonstration platform and as such,

GEC Plessey did not continue development of the software once the basic functionality was

provided. Standard algorithms such as carrier smoothing of pseudoranges and the provision

of carrier phase output that essential for the implementation of real-time kinematic (RTK)

positioning were never included either. The outcome of both of these factors has meant that

maintenance of the Namuru port of the GPS Architect has been limited to changes necessary

to keep the build operating with newer versions of the Altera toolset, but nothing else.

The second option that was available for providing firmware for the Namuru receivers was to

use the GPL-GPS codebase (Greenberg, 2005; Kelley et al., 2002). However, when Namuru

was first designed, this codebase was very much in it’s infancy and it did not have the

maturity for inclusion in a new product. Furthermore, GPL-GPS also suffered from some of

the algorithmic deficiencies of the GPS Architect because it too was developed in order to

demonstrate the principals of GPS. Nonetheless, GPL-GPS was been ported to the Namuru,

although unfortunately the port was not maintained and upgrades to the Quartus toolset mean

that the code-base can no longer be compiled. Part of the difficulty with regard to the code-

base also stems from the use of the eCOS real time operating system by the GPL-GPS, which

has marginal support for the NIOS-2 processor employed by Namuru.

3. AQUARIUS FIRMWARE

3.1 Motivation

Glennon commenced work on the Aquarius firmware in mid 2006 during his PhD studies

when he was first provided with a Namuru V1 receiver by UNSW. Recognising the

difficulties inherent in using the GPS Architect and having extensive experience in the

development of GPS receiver firmware obtained through his work at SigNav Pty Ltd, it was

natural for him to work on a better solution. This development had a number of aims.

The first aim was to develop a GPS receiver firmware framework that would permit the

firmware to be portable across several different chipsets, each with its own unique frequency

plan and baseband correlator implementation. This requirement was derived from the

observation that each time a new GPS chipset was targeted for firmware development, a

massive engineering exercise was required in order to port the firmware from the previous

receiver to the new one. Part of the reason for these difficulties was that each chipset

generally has its own set of magic numbers that relating to frequency plan and baseband

correlator implementation. The plan was to hide this complexity through the creation of a

GPS driver software layer in which interactions with the GPS baseband chip were all dealt

with using a defined application programming interface (API). High levels of firmware, such

as the code implementing the tracking and measurement functions would then use this API,

safe in the knowledge that API would remain unchanged. Each new chipset would then be

provided with its own GPS driver that would be selected at compile time.

A second aim of the development was to provide a firmware suite that would offer improved

performance compared to the GPS Architect and OS-GPS, whilst being free of the licensing

uncertainties present in the Architect codebase. Finally, having written the firmware it was

relatively easy to introduce the features necessary to test the DPIC cross-correlation

mitigation technique that was developed as part of Glennon’s PhD work, which was the

ultimate justification for the work. Demonstrating DPIC required modification to the

baseband correlator as well as additional firmware needed to allow direct user control of the

correlators and the output of data for display to the user.

3.2 Language

The Aquarius GPS firmware is written entirely in ANSI C. C was chosen over C++ because

many of the algorithms required of a GPS receiver do not necessarily require the use of object

oriented techniques, the processors employed for embedded GPS receivers are usually small

microcontrollers for which C compilers are always available, and C is generally more

efficient than C++, being a simpler language. On the NIOS-2 32-bit soft-core processor, the

total memory usage for both the program and data amounts to 417 kB, although a smaller

footprint may be achieved on a processor having a higher code density, such as an ARM

processor running 16-bit Thumb code. The software also includes extensive comments that

describe why various design decisions have been made, as well as the purpose of each

function and the use of many of the variables employed within the firmware.

3.3 Firmware Directory Structure

GPS receivers are complex systems and the firmware required to run inside a receiver is

equally complex. One way to reduce the level of complexity is to decompose the firmware

into several subsystems, each of which can then be understood without having a detailed

knowledge of the other subsystems. From an organisational perspective, Aquarius performs

such a decomposition by first grouping source code and header files into related directories,

so that related code is located in the same subdirectory, as described below.

a) The ‘Rtos’ directory contains all of the firmware related to the implementation of the

real time operating system (RTOS).

b) The ‘GpsTrk’ directory contains the low level GPS driver firmware used to control the

GPS correlation baseband, the pre-correlation integration and counting of samples, the

acquisition, reacquisition and tracking of GPS signals and the making of GPS

observations.

c) The ‘UserIF’ directory contains the functions required to implement the serial port

messaging processes that are common to all GPS receiver devices. This includes

command-processing functions to extract and upload data from each NMEA input

command, report processing to collect and output NMEA messages to the serial port

output process and UART related routines. The module implementing the storage

and restoration of data from non-volatile memory is also located here.

d) The ‘Timing’ subdirectory contains functions related to the maintenance of time inside

the receiver. These functions include routines that allow slewing and adjustment of

the measurement instant, output of a one pulse per second (1PPS), functions to convert

between calendar and GPS time, functions to operate on GPS time quantities, modules

to interact with the real time clock (RTC) and to implement I2C communications, as

required for communications with the RTC.

e) The ‘NavData’ directory contains the code necessary to convert the 20 ms coherently

integrated samples received from each GPS satellite into navigation messages, verify

the integrity of the navigation messages and to extract and upload the navigation

message data to the receiver database. This process also allows the time to be

extracted from the navigation message.

f) The ‘SvDb’ directory contains the module that manages the satellite and receiver

databases, as well containing functions related to selection of satellites by the receiver

and allocation of those satellites to hardware channels. Information received from

GPS navigation messages, the user or calculated by the receiver itself is loaded into

the database using functions specific to each data type. Similarly, information

required by the report processing or any of the tasks may be retrieved from the

database using a matching retrieval function. In addition, several miscellaneous

functions related to the calculation of reference satellite position, velocity and

acceleration using the ephemeris or almanac, the extrapolation of these reference

positions using Taylor series expansions, and the calculation of satellite range and

range-rate vectors are located here. Finally, the directory also includes functions to

calculate ionospheric and tropospheric corrections.

g) The ‘PVTNav’ directory contains the module used to perform the position, velocity

and time navigation by the receiver. This includes a simple 4 state position and clock

offset/time Kalman filter and a 4 state velocity and clock drift Kalman filter, and

matrix/vector routines used to run the Kalman filter.

h) The ‘Testing’ directory contains support for built in release testing of the receiver

firmware. This feature was added in order to automate the testing of receiver

performance parameters such as hot, warm and cold time-to-first-fix (TTFF), as well

as re-acquisition times given particular periods of obscuration. TTFF testing is

supported by including a task that once enabled, allows the receiver to automatically

restart after recording results in non-volatile memory. Reacquisition testing is

supported by monitoring the tracking status of each channel after obscuring and

restoring signal visibility by adjusting the detection threshold. 

3.4 Firmware Task Structure

The second method used to manage the operation and complexity of the firmware is to make

use of the features provided by the RTOS. Like most other GPS firmware suites, Aquarius

makes ample use of the ability to run different priority tasks whose operation is triggered

when required. As is to be expected, the decomposition into tasks is related to the

decomposition of the source code into subdirectories, although the source code for several

tasks may often be found within the same directory. Table 1 provides an indication of the

various tasks and interrupts that are run on the receiver.

In general, time-critical and higher frequency tasks are assigned higher priorities; with the

‘PreDSPTask’ having the highest priority because it is required to process the 1-ms dump

samples that are received from the hardware correlator. Employing multiple tasks each

running at different priorities also allows the processing load experienced by the receiver

processor to be managed. For example, rather than running the tracking loops at a 1 kHz rate,

the tracking process has been split into two distinct tasks. ‘PreDSPTask’ has the highest

priority of the two tasks and it is responsible for performing those processes that must be run

at a 1 kHz rate to match the 1 kHz output sample rate from the correlator baseband processor.

This includes receiving each of the dump samples, maintaining a count of the samples

received, maintaining a software ‘time-of-transmission’ quantity for each channel and

Task Priority Remark

TestTask1 240 Test task – optional task

PreDSPTask 195 Performs pre-integration & sample counting

TrackerTask 190 Tracking, reacquisition & acquisition

RtcTask 187 Update & maintain RTC

MsmtTask 185 Make observations & upload measurements

BufferBitsTask 175 Convert I&Q samples to bits and buffer

ExtractTask 170 Extract navigation message & decode data

ReportTask 150 Transmit serial port reports

CmdTask 150 Process input serial port commands

AutoTest 120 Perform automatic TTFF & reacquisition tests

TestTask3 100 Test task – optional task

PVTFixTask 15 Perform navigation solutions

SvDbTask 10 Calculate SV reference position, velocity & acceleration

SvSlctTask 10 Select satellites and allocate to hardware channels

ISR Remark

CorrelatorISR n/a Measurement TIC and sample poll ACCUM_INT

TimerISR n/a 1 ms RTOS timer

Table 1. Aquarius Tasks and Interrupts

adjusting the samples for correct bit alignment. However, as it is not necessary that the actual

tracking loops be run at a 1 kHz rate, ‘PreDSPTask’ also performs some pre-detection

integration and buffers the output samples so that a lower priority, lower frequency

‘TrackerTask’ task that runs at 250 Hz may be employed for the tracking process.

In much the same way, data bit extraction and navigation message extraction and decoding

are run at even lower priorities. This follows because new navigation message bits only occur

every 20 ms (excluding SBAS message bits that occur every 2 ms) and it takes 300 bits before

a full subframe of navigation message data is accumulated. However, when a full navigation

message has been accumulated it may take a substantial amount of processing to extract the

required data from the message, and this processing must not be allowed to delay the higher

priority tasks. Similarly, the measurement task runs every 0.1 seconds (10 Hz), although

carrier smoothing is employed to allow the output measurement period to be reduced to 1

second (1 Hz). This means that the PVT navigation filter runs at a rate of 1 Hz, which is

necessary because this presents a very computationally expensive process.

3.5 GPS Driver API

As previously explained, one difficulty faced by an embedded GNSS firmware engineer is

that every GNSS chipset is different. Aquarius addresses this difficulty by creating a software

layer that lies between the GPS receiver chipset, defined by the GPS front end and its

associated baseband correlator, and the GPS receiver firmware that uses this chipset to

perform a navigation solution. The software layer is implemented in terms of an Application

Programming Interface that provides functions that must be called to control the correlator, as

well as associated interrupt service routines (ISRs) that responds to baseband correlator

interrupts. GPS correlator basebands typically provide two interrupts to indicate that integrate

and dump and measurement values are ready to be read from the correlator. Generally, each

hardware channel provides several in-phase and quadrature integrate and dump values every

millisecond, while measurements are output at a user selectable period, such as 100 ms. Some

of the functions provided by the API are given in Table 2.

The GPS driver module also defines standard measures for the integer representation of code

phase (scaled chips) and code and carrier frequencies (scaled Hertz), as well as structures

defining the various fields necessary to represent an observation made on a particular channel

at the measurement instant. Another structure containing an array of such observations then

describes the measurement made by the receiver at the measurement instant. The

implementation in Aquarius also tries to minimize the use of floating-point arithmetic within

the GPS driver. This is done in order to ensure that the code operates at maximum efficiency

by eliminating the calls to software routines that are used to implement floating-point

whenever floating-point hardware is not available. This is often the case for low cost GPS

receivers that are implemented using 16 or 32-bit microcontrollers or digital signal

processors.

3.6 Serial Port Commands and Reports

GPS receivers have traditionally employed serial port commands and reports that are received

and transmitted using a universal asynchronous receiver transmitter (UART). Aquarius is no

exception to this tradition and supports many of the sentences defined by the National Marine

NMEA standard 0183 (National Marine Electronics Association, 2002). A full description is

beyond the scope of a paper such as this, although it suffices to say that commonly used

sentences such as GGA, GSA, GRS, GSV, ZDA, VTG and ALM are supported. Proprietary

messages are also used to allow full measurements (including 1-Hz carrier phase), ephemeris,

UTC and ionospheric corrections to be extracted or provided to the receiver, as well as

providing receiver configuration and tuning parameters.

4. SELECTED TEST RESULTS

Because Aquarius was developed on a part time basis starting in 2006, it is only recently that

it has gained a sufficient level of reliability for systematic testing to be considered. Before

this, the testing was limited to informal bench testing carried out using live signals, as was

appropriate for the validation of basic functionality and the introduction of new and useful

features. The sections that follow describe several recent test results.

Function Name Purpose

GetNominalClockFreq Return clock frequency (Hz) used for measurement period

GetNominalIFFreq Return nominal IF frequency (Hz)

SetMeasurementPeriodHW Set measurement period (clock cycles)

GetIQSamples Return channel IQ samples

GetSampleCount Return sample count for most recent IQ sample

NormaliseCodePhase Return normalised codephase given unwrapped codephase

GetFingerSpacing Return separation between adjacent code phase taps

GetFingerSeparation Return separation between specified code phase taps

GetFingerCount Return number of code phase taps per channel

SetCarrierFreq Set carrier frequency (scaled Hz) for channel

GetCarrierFreq Return carrier frequency (scaled Hz) for channel

AdjustCarrierPhase Not used

GetCarrierPhaseAdjust Not used

SetCodeFreq Set code frequency (scaled Hz) for channel

AdjustCodePhase Adjust code phase by increment (scaled chips) for channel

GetCodePhaseAdjust Return recent code phase adjustment (scaled chips) for channel

GetCodePhase Return most recently latched code phase (scaled chips) for channel

GPSDriverReset Reset GPS driver

SetPrn Set PRN code for channel

GetPrn Return PRN code for channel

SetHwEpochOffset Set offset to convert HW epoch count to SV time-of-transmission

GetHwEpochOffset Return offset converting epoch count to SV time-of-transmission

GetHwEpochModulo Return HW epoch count modulo limit

AdjustHwEpochCount Adjust HW epoch count registers for channel

GetCorrelatorObs Return correlator observation for channel

EnableChannel Enable hardware for channel

DisableChannel Disable hardware for channel

EnableCorrelator Enable entire baseband correlator

InitGpsDriver Initialise GPS driver module

GetHwMeasurementCount Return instant measure of hardware measurement counter register

SetNoise Set noise variance and standard deviation (1 ms) for channel

GetNoise Return noise standard deviation (1 ms) for channel

Table 2: Functions provided by GPS driver API

4.1 Simulator Static Test Result

A useful test for establishing the correct implementation of measurement and navigation

algorithms is to test the GPS receiver using a hardware GPS-simulator, such as a Spirent

STR6560. Using such equipment, the user has full control over the position, velocity and

time of the receiver, the satellites used in the navigation solution, the type of errors introduced

by the ionosphere and troposphere and the signal levels of the satellites to be used to generate

the observations. The correct application of ionospheric and tropospheric corrections can be

easily established by checking the calculated values against the truth data available from the

simulator, although lack of any bias or drift in the final navigation output may also instil

confidence if the receiver applied corrections cancel the simulator generated errors. Such a

test was performed using the Aquarius firmware, with the simulator setup for a static receiver

at latitude, longitude and altitude coordinates (S35°, E141°, 80 m), strong signal levels in

excess of 45 dBHz and ionospheric and tropospheric errors given by the standard Klobuchar

and Stanag models. The result from this test is shown in Figure 1 and shows a bias of (0.46,-

0.32,-1.55) and standard deviations of (0.4,0.4,1.0) meters in the east, north and up directions,

with occasional outliers of up to 4 meters.

4.2 Simulator Carrier Phase Real-Time-Kinematic Test Result

Carrier phase (CPH) real-time kinematic (RTK) performance may be verified using a Spirent

STR6560. For this test, a scenario where the receiver moves in a circle of radius 1 meter

(centre N0°, E0°, 0 m) and at a slow speed is employed, with the simulator outputting RTCM

differential corrections for a base-station located at the centre of the circle. Receiver

transmitted OBS, EPH, ION and UTC sentences are captured once navigation has

commenced and converted to RINEX. RTCM differential corrections are also captured from

the simulator base-station and converted to RINEX using the ‘rtkconv.exe’ utility provided by

the open source RTKLib software package (Takasu & Yasuda, 2009). RTK precision post-

processing navigation is then performed using the two RINEX files post-processed using the

RTKLib ‘rtkpost.exe’ utility. The result of this test is shown in Figure 2. The orange dots

refer to the locations where a “float ambiguities” solution has been performed, while the

green dots refer to the locations where the integer ambiguities have been fixed and an “integer

ambiguities” solution has been performed. It is clear that a good RTK solution has been

achieved once fixed integers have been determined and locked-into the solution process and

that the carrier phase measurements produced by the receiver are therefore acceptable.

Figure 1: Simulator static test

Figure 2: Simulator carrier-phase RTK test

4.3 Live Testing

Live testing has also been performed. However, as the live tests have been run over longer

periods of time with signals of varying signal strength and subject to the usual error sources,

there is more scope for firmware bugs to manifest themselves. Results of a static live tests

performed on 25-October 2011 at UNSW are shown in Figure 3.

For the most part, the results are not too bad, although occasional measurement problems do

mar the result somewhat. Correction of these difficulties will require improved tuning for the

tracking algorithms, improving the sensitivity of the receiver and the use of better criteria

when deciding whether or not a particular observation should be marked acceptable or use.

Unfortunately, correcting errors such as this that occur infrequently is notoriously difficult

and it could take quite some time before they are resolved. For the results shown above, the

latitude, longitude and altitude standard deviations are 2.39, 2.68 and 5.3 m, the circular error

probable (CEP) is 2.74 m and the 2D-RMS metric is 7.195 m, although in calculating these

values it has been assumed that there are no biases in the mean solution.

5. CONCLUSIONS

This paper has described a new firmware suite that has been created for the Namuru FPGA

based GPS receivers developed by the School of Surveying and SIS and General Dynamics

Corporation (of New Zealand). Starting with a brief summary of the Namuru receivers and

the firmware employed during the receivers early development, the need for new firmware

was made apparent. Some implementation details of the firmware were provided, as well as a

selection of code phase and carrier phase navigation results. These results show that correct

operation of the basic receiver operation has been achieved.

Current and future work will involve fixing firmware bugs and making further improvements

to the receiver, including improvements to the static accuracy and improving the carrier phase

performance of the receiver. It will also be necessary to improve the receiver sensitivity, as

well as making changes necessary to allow the firmware to be used in future versions of

Namuru, such as Namuru V3.2 and Namuru V3.3. Namuru V3.2 uses a different processor

and FPGA, but is otherwise similar to the Namuru V2R4. Namuru V3.3 will differ from

Namuru V2R4 in that different RF front ends that are capable of tracking L2, L5 or

30 20 10 0 10 20 30

5

0

5

10

15

20

25

30

35

40

45

Namuru/Aquarius Horizontal Scatter (m)

E W (m)N

S (

m)

Figure 3: Live position scatter (21-Oct-2011)

GLONASS in addition to L1 are envisaged, as are upgrades to the FPGA from a Cyclone II to

a Cyclone IV FPGA.

ACKNOWLEDGEMENTS

The Aquarius firmware development work was partially funded by ARC Discovery Grant

DP1093982 (Preparing for the Next Generation Global Navigation Satellite System Era:

Developing and Testing New User and Reference Station Receiver Designs) and the ASRP

‘SAR Formation Flying’ grant. The Namuru V3.2 GPS receiver hardware development and

associated Aquarius porting activity was funded by the Biarri Project.

REFERENCES

Borre K, Akos DM, Bertelsen N, Rinder P, Jensen SH. (2007), A Software-Defined GPS and

Galileo Receiver: A Single-Frequency Approach, Birkhauser.

Engel F, Heiser G, Mumford PJ, Parkinson KJ, Rizos C. (2004), An Open GNSS Receiver

Platform Architecture: GNSS 2004, Sydney.

GEC Plessey Semiconductors. (1997), GPS Architect 12 Channel GPS Development System:

DS4605-2.5.

Greenberg A. (2005), Open Source Software for Commercial Off-The-Shelf GPS Receivers,

Portland State University.

Kelley C, Barnes J, Cheng J. (2002), OpenSource GPS Open source Software for Learning

about GPS: ION2002, Portland, OR.

Mumford PJ, Parkinson KJ, Dempster AG. (2006), The Namuru Open GNSS Research

Receiver: 19'th Int. Tech. Meeting of the Satellite Division of the U.S. Inst. of

Navigation, Fort Worth, TX, pp. 2847-2855.

National Marine Electronics Association. (2002), NMEA 0183: Standard for Interfacing

Electronic Devices: Version 3.01. NMEA.

Shmaliy YS, Ibarra-Manzano O, Arceo-Miquel L, Munoz-Diaz J. (2007). Analysis of

Sawtooth Noise in the Timing SynPaQ III GPS Sensor. Sensors & Transducers

Journal, 79, 1151-1156.

Takasu S, Yasuda A. (2009), Development of the low-cost RTK-GPS receiver with an open

source program RTKLIB: International Symposium on GPS/GNSS,, Juju, Korea.