Page 1
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.
Page 2
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
Page 3
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
Page 4
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
Page 5
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
Page 6
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
Page 7
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
Page 8
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
Page 9
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
Page 10
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
Page 11
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)
Page 12
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.