GNSS-SDRLIB: An Open-Source and Real-
Time GNSS Software Defined Radio Library
Taro Suzuki, Nobuaki Kubo, Tokyo University of Marine Science and Technology, Tokyo, Japan
BIOGRAPHIES
Taro Suzuki is a JSPS (Japan Society for the Promotion of
Sciences) postdoctoral fellow at Tokyo University of
Marine Science and Technology, Japan. He received his
B.S., M.S., and Ph.D. in Engineering from Waseda
University in 2007, 2009, and 2012 respectively. His
current research interests include the GNSS precise
positioning for vehicles integrated with inertial navigation
and image sensors in urban environments. He is also
developing the multipath mitigation techniques by the
multipath simulation using 3D city models and the open
source GPS software receiver. He also develops an open
source software GNSS receiver library.
Nobuaki Kubo received his Master’s degree of Electrical
Engineering in 1998 from Hokkaido University. He
received his doctorate in Engineering from University of
Tokyo in 2005. He resided at Stanford University in 2008
as a visiting scholar. He is now an associate professor at
the Tokyo University of Marine Science and Technology
in the area of GPS/GNSS systems. His current interests
are high accuracy automobile navigation using RTK and
multipath mitigation techniques.
ABSTRACT
Global navigation satellite system (GNSS) is rapidly
gaining in popularity because of their wide range of
current and potential applications. As a result, GNSS
software receivers, which are based on software-defined
radio (SDR), have attracted significant attention in recent
years. Software GNSS receivers are widely recognized
and used because of their configuration flexibility and
ease of use in GNSS research. Many GNSS (or GPS)
software receiver projects have been undertaken by
researchers and companies. In particular, some are being
developed as open-source projects. However, the current
open-source GNSS receivers support a few specified
front-ends for real-time processing and partly support
multi-GNSS or do not support multi-frequency signals.
We have developed a novel open-source and real-time
processing capable GNSS software receiver, called
GNSS-SDRLIB. GNSS-SDRLIB is a very simple and
easy-to-use GNSS signal processing tool written in C, and
it consists of several application programs written in
C++/CLI. GNSS-SDRLIB provides GNSS signal
acquisition, tracking, pseudorange generation, navigation
message decoding, and spectrum analysis functions for
GNSS signal processing, which is required for position
computation. For real-time positioning, GNSS-SDRLIB
supports many commercially available front-ends. In
addition, it supports any recorded intermediate-frequency
(IF) data obtained by any front-end for post-processing. It
can output the observation data such as the pseudorange,
carrier phase, Doppler, and carrier-to-noise density (CN0)
in the RINEX or RTCM format. GNSS-SDRLIB can be
used with a conventional hardware receiver if a front-end
device and laptop computer are prepared.
We carried out tests to evaluate the performance of
GNSS-SDRLIB and developed actual applications. Based
on a static positioning test with multi-GNSS constellation,
we determined the receiver positions within 2 m using
multi-GNSS L1 pseudoranges generated by GNSS-
SDRLIB. We expect it to be widely used for research and
educational purposes to learn GNSS signal processing.
1. INTRODUCTION
Global navigation satellite system (GNSS) is rapidly
gaining in popularity because of their wide range of
current and potential applications. The availability and
accuracy of satellite positioning are anticipated to
improve because of the presence of various positioning
satellites such as the United States’ GPS, Russia’s
GLONASS, Europe’s GALILEO, China’s BeiDou, and
Japan’s QZSS. These positioning satellites broadcast
many new signals at multiple frequencies; for example,
China issued an interface control document (ICD) for the
BeiDou navigation system at the end of 2012 [1], and
many consumer GNSS chip companies have started to
support the BeiDou B1 signal. Further, QZSS has been
broadcasting the new L1C and LEX (L-band experiment)
signals to improve the accuracy of GNSS positioning [2].
The actual positioning accuracy performance with these
new signals must be evaluated and confirmed in GNSS
receivers. In addition, processing methods such as for
signal acquisition, decoding new navigation messages,
and signal tracking algorithms especially designed for
modern signals also need to be developed and verified
when we use new GNSS signals. On the other hand, in the
GNSS research field, advanced GNSS applications such
 Antenna
Analog
Digital
IF
IF
LNA ADC
Acquisition
Local
Oscillator
Front-End
Fig. 1. Configuration of software GNSS receivers.
as for signal interference and spoofing detection, GNSS
multipath mitigation based on a beam forming technique,
and the ultra-tight integration of GNSS with multiple
sensors have attracted researchers. In these applications, it
is difficult to develop new algorithms using only
conventional commercial GNSS receivers because we
must modify and reconfigure the basic technologies of the
GNSS receivers.
Thus, GNSS software receivers, which are based on
software-defined radio (SDR), have attracted significant
attention in recent years [3-11]. Software GNSS receivers
are widely recognized and used because of their
configuration flexibility and ease of use in GNSS research.
They can also analyze the new GNSS signals, which are
not supported by the currently available commercial
GNSS receivers because all the signal processing
algorithms can be changed and modified as desired in the
case of the software receivers. Figure 1 shows the
configuration of a general GNSS software receiver. A
software GNSS receiver consists of two blocks: the front-
end block, which down-converts and digitalizes the
incoming signal into digitalized intermediate frequency
(IF) data, and the baseband processing block. In the
baseband processing block, the down-converted and
digitalized GNSS signal is processed in order to provide
GNSS observation data such as pseudoranges and
navigation data for obtaining position solutions. First, a
digitalized GNSS signal that contains the GNSS ranging
code is detected in the acquisition step using the
correlation with the local replica code. Then, if a specified
GNSS signal is acquired, the carrier frequency of the
signal and the code phase are maintained in the tracking
step. Finally, when a navigation message is decoded, the
position can be estimated using the pseudorange, satellite
location, and clock correction data from the navigation
message. In software GNSS receivers, this baseband
processing is performed using software on a general-
purpose processer instead of using hardware.
Many front-ends, which can convert a radio frequency
(RF) signal into a digitally sampled IF, are on the market
today; some of these are designed to capture GNSS
signals and are widely available [24-31]. In the case of
using software for the baseband processing, the barrier to
Carrier Frequency Code and Carrier
Code Phase Measurements
Signal Signal PVT PVT
Tracking Estimation
Navigation Decoding
Baseband Processing
its dissemination was the heavy computational burden.
However, CPU power is increasing; hence, it has become
possible to develop practical software-based GPS
receivers. The first GNSS software receiver based on the
SDR technology was proposed in [3]. It expanded the
horizons of GPS software receivers for many researchers.
Several studies related to software GPS receivers have
been published to date [3-12]. The book written by Tsui
[4] provided much information about the implementation
of software GPS receivers. In 2007, [5] provided Matlab
implementations of a complete GPS receiver, which
lowered the entry level for users to develop original
software receivers.
Currently, many GNSS (or GPS) software receiver
projects are being undertaken by researchers and
companies. In particular, some of these are being
developed as open-source projects [12-17]. Moreover, an
open-source GNSS software receiver offers many
advantages in terms of customization and usability. Open-
source receivers also provide great benefits for many
users from the perspectives of education and the
development of advanced GNSS software receiver
applications. For example, both GPS-SDR [16] and
GNSS-SDR [17] are well-known open-source software
receivers written in C++. GPS-SDR supports real-time
processing with GPS L1CA code. GNSS-SDR (which is
under active development in 2014) supports multi-GNSS
L1 signals (GPS L1CA and Galileo E1 codes) for real-
time positioning [11]. These projects are considerably
useful and powerful tools for researchers. However, they
only support a few specific front-ends for real-time
processing and partly support multi-GNSSs or do not
support multi-frequency signals. Real-time processing for
multiple systems and multiple frequencies is still a
challenge in the development of an open-source software
receiver. We have developed a novel open-source and
real-time processing capable GNSS software receiver,
called GNSS-SDRLIB [18]. GNSS-SDRLIB is a very
simple and easy-to-use GNSS signal processing tool
written in C, and it contains a GUI application written in
C++/CLI to easily analyze real-time GNSS signals. It is
released under the GNU general public license (GPL)
version 3; we can share and modify the source code for
any purpose. In this paper, we describe the architecture
and functions of GNSS-SDRLIB and analyze its time positioning, the output of position solutions and
positioning performance using a consumer-ready front- observation data in a common format will provide
end and general purpose computer. benefits for users in terms of usability. GNSS-SDRLIB
supports the output of GNSS observation data in the latest
The remainder of the paper contains the following. In RINEX 3.02 format, which supports all the GNSS
Section 2, the architecture and functions of the proposed satellites such as the BeiDou observation data.
GNSS software receiver are described. Section 2 also Furthermore, GNSS-SDRLIB can output an RTCM 3.2
describes the method used to process a GNSS signal in multi-signal message (MSM) for real-time processing.
the software in order to generate the GNSS observation Because of these functions, the software GNSS receiver
data. Positioning tests and an advanced application of the can be used like commercial hardware GNSS receivers.
proposed software are described in Section 3. Then, we
discuss the performance analysis of GNSS-SDRLIB. (3) Real-time processing and multi-GNSS support
Section 4 describes the plans to add new functions to the There are few open-source GNSS receivers that can be
proposed software. Finally, the conclusions of the paper used for real-time positioning with commercially
can be found in Section 5. available front-ends. In order to get real-time position
solutions using a GNSS front-end, an interface between a
computer and front-end must be implemented. Typical
2. ARCHITECTURE AND FUNCTIONS
commercially available front-ends provide interfaces
through USB or Ethernet buses in order to send
2.1. GNSS-SDRLIB overview
digitalized IF data to a computer. However, the transfer
A general GNSS software receiver performs all of the
data size exceeds tens of megabytes per second
baseband signal processing using software on a general
(depending on the sampling frequency and bit resolution)
purpose computer. Some open-source software GNSS
and the protocol (format) is also dependent on the GNSS
receiver projects already exist. Therefore, a differentiation
front-end. The interface function and transfer control of
strategy is important to attract GNSS researchers to the
the specified GNSS front-end must be implemented on
GNSS software receiver field. We consider the following
the software GNSS receiver side. GNSS-SDRLIB
points to be important characteristics of GNSS-SDRLIB.
supports many commercially available front-ends, and we
verified the real-time processing performance with these
(1) Cooperation with RTKLIB [19, 20]
front-ends. In addition, GNSS-SDRLIB fully supports
RTKLIB is an open source software package written in C
multi-GNSS constellations such as GPS, GLONASS,
for GNSS data analysis and distributed under a BSD 2-
Galileo, BeiDou, and QZSS L1 signals in real-time
Clause license. RTKLIB provides many powerful API
positioning. Almost all other open-source software
functions that are needed in GNSS data analysis,
receivers only partly support multi-GNSS signals. This is
including read and write functions for the commonly used
an advantage compared with other software receivers.
RINEX and RTCM formats and position computation
based on single point positioning, differential GNSS (D-
Figure 2 shows the configuration of GNSS-SDRLIB.
GNSS), real-time kinematic GNSS (RTK-GNSS), and
GNSS-SDRLIB consists of the source code for the
precise point positioning (PPP). It also includes GUI
baseband processing and other libraries. GNSS-SDRLIB
applications such as a real-time positioning application
uses RTKLIB [19] to read and write in the RINEX and
with a GNSS receiver (RTKNAVI) and an application for
RTCM formats, a fast Fourier transform (FFT) library
visualizing the current GNSS status and position solutions
[21] for parallel signal acquisition, and a forward error
(RTKPLOT). We merged RTKLIB into the GNSS-
correction (FEC) library [22] for decoding navigation
SDRLIB project and used RTKLIB API functions as
messages inside the software. These libraries are released
much as possible. Using RTKLIB made it possible to
under the open-source license. A real-time position
focus on developing the baseband signal processing in
solution can be computed through RTKNAVI (RTKLIB
GNSS-SDRLIB. Hence, the most important code related
GUI application) using the TCP/IP connection in the
to a software receiver can be simple, compact, and
RTCM MSM format. The observation data can be stored
readable.
in the RINEX format for post-processing purposes. The
signal acquisition results and correlation outputs can be
(2) Output of observation data in common format
visualized using GNUPLOT, which is a portable
Almost all open-source GNSS software receivers can
command-line driven graphing tool [23]. A spectrum
output position solutions and GNSS observation data
analysis function is also provided through GNUPLOT. It
(pseudorange, carrier phase, etc.) in their original formats.
can be used to confirm the front-end performance and
Only GNSS-SDR [16] supports the output of a RINEX
check the incoming signal. These visualization functions
file, which is commonly used in hardware GNSS
can be used for checking the signal processing status,
receivers for post-processing purposes. However, it does
analyzing the signal quality, monitoring a multipath signal,
not support the RTCM format, which can be used in real-
etc.
time data transfer. If we use the software receiver for real-
 GNSS-SDRLIB Table 1. Specifications of GNSS-SDRLIB.
RTCM
GNSS RCV MSM RTKNAVI Software
Front end stereo.h stereo.lib TCP/IP GNU GPLv3
RTKPLOT License
IF data sdr.h ・Position computation
sdrplot.c sdrmain.c ・Display solution
Programming
sdrcmn.c C (GUI is written in C++/CLI)
FEC language
…
fec.h
fec.lib RTKLIB Obs. and Platform Windows 7,8 32/64 bit, Linux (Ubuntu 64 bit)
Nav. data
GNUPLOT rtklib.h RINEX
Pipe
FFT rtkcmn.c
FILE Hardware NSL STEREO, SiGe GN3S Sampler v2, SiGe GN3S
・Display acquisition ・Generation of support Sampler v3, RTL-SDR dongle, Nuand BladeRF
result, correlation output fftw.h rinex.c RINEX navigation
, and spectrum analysis fftw.lib … and observation file
Code generation: all existing GNSS signals
Multi-GNSS
Fig.2. Configuration of GNSS-SDRLIB. support
Positioning: GPS L1CA, GLONASS G1, Galileo E1,
BeiDou B1, QZSS L1CA

Navigation GPS L1 (LNAV), GLONASS Nav., Galileo E1B

The specifications of GNSS-SDRLIB are listed in Table 1. data (I/NAV), BeiDou B1(D1/D2 NAV)
The features of GNSS-SDRLIB are described as follows:
Decoding
SBAS L1 message (for DGPS), QZSS L1-SAIF (for
special
(1) GNSS-SDRLIB provides GNSS signal acquisition, DGPS), QZSS LEX message (for PPP)
message
tracking, pseudorange generation, navigation message
decoding, and spectrum analysis functions for GNSS Output RINEX (file), RTCM-MSM (TCP/IP)
signal processing, which is required for position
computation. All of the source code was exclusively
developed from scratch. GNSS-SDRLIB is very simple,
easy to use, and easy to port to other projects.

(2) The generation of all the existing GNSS ranging codes

such as GPS/QZSS L1CA, L1C, L2C, and L5, RTL-SDR dongle Nuand bladeRF
GLONASS G1 and G2, Galileo E1, E5a, and E5b,
BeiDou B1I and B2I, and QZSS LEX are supported. We
can evaluate and analyze new GNSS signals using GNSS-
SDRLIB.

(3) GNSS-SDRLIB works in both the Windows and

Linux environments. In the case of real-time processing, it
requires a large amount of computational power for signal
processing. However, we use the SIMD operations (SSE2,
AVX, and AVX2) to speed up the computations; thus, a
laptop PC with Intel Core i5/i7 is capable of real-time
signal processing.
(4) GNSS-SDRLIB supports the decoding of special
navigation messages, satellite-based augmentation system
(SBAS) L1 messages, QZSS L1-SAIF messages for D-
GPS, and QZSS LEX messages for real-time PPP.
The algorithms of the GNSS software receiver can be
easily modified based on the desired requirements. The
function described in this section will be expanded in the
future developments.
2.2. GNSS front-ends
There are several commercially available RF front-ends
that convert RF signals into digitalized IF signals for
baseband processing. GNSS-SDRLIB supports many
commercially available front-ends for real-time
processing, as shown in Figure 3.
SiGe GN3S Sampler v2/v3 NSL Stereo
Fig.3. Commercially available front-ends supported by GNSS-
SDRLIB.
For example, DVB-T USB dongles [24] based on the
Realtek RTL2832U chip is widely used as an ultra-cheap
($10~20) SDR front-end in SDR communities. This type
of front-end is called RTL-SDR, and the driver and
library of RTL-SDR are provided in order to obtain IF
data through this device. The maximum sample rate of
RTL-SDR is about 2.4 million samples per second
without lost samples. This means that up to 2.4 MHz of
the radio spectrum can be captured at once. However, this
bandwidth limitation is not suitable for GNSS receivers.
In addition, the positioning performance using RTL-SDR
is not good because of poor oscillator stability and
accuracy [32]. The SiGe GN3S Sampler v2 and v3 based
on the SiGe 4120 GPS chip [25, 26] provide a data stream
with a sampling frequency of up to 16.3676 MHz and a
bandwidth up to 4.4 MHz. The GLONASS and BeiDou
L1 signals cannot be received because they are designed
to capture the GPS L1 signal (1575.42 MHz) as a GPS
front-end. However, the positioning accuracy
performance using these front-ends is quite good. The
bladeRF [27] is an open-source SDR transceiver; it is
capable of receiving and transmitting RF signals. The
sampling rate can be set up to 40 MHz, and 12-bit full
duplex quadrature samples are obtained via a USB 3.0
interface. NSL Stereo [28] has two front-ends based on
the Maxim MAX2769 RF chip [29] and Maxim MAX212
RF chip. This means that it is capable of capturing dual
frequency bands simultaneously. Stereo makes it possible
to configure a bandwidth and sampling frequency of up to
40 MHz. MAX2769 is designed to capture a GNSS L1
signal (1550~1610 MHz), and MAX2112 can be
configured to capture a GNSS L-band signal (925~2175
MHz). Therefore, this front-end is suitable for capturing
multi-GNSS signals.
GNSS-SDRLIB also supports any recorded IF data stored
in a file using any front-end for post-processing. In the
future, we plan to support additional commercially
available RF front-ends for real-time processing.
2.3. Baseband processing
In the baseband processing, the signals digitalized by the
GNSS front-ends are processed for position computation
in the software. Figure 4 shows the signal processing flow
of GNSS-SDRLIB during the baseband processing. First,
the specified replica code is generated for the acquisition
and tracking of the incoming signal. Then, the digitalized
IF data from a front-end or file is correlated with the local
replica code in the frequency domain using FFT to
acquire the signal. If the signal is acquired in the
acquisition step, the code phase and carrier frequency can
be estimated. In the tracking step, the code phase and
carrier frequency are maintained using the carrier
frequency locked loop (FLL), phase locked loop (PLL),
and delay locked loop (DLL) based on the signal
correlator outputs. The output of the tracking result
contains the GNSS navigation messages. When the
navigation message bits are synchronized, the navigation
message is decoded. The pseudorange is generated using
the code phase information and time information
contained in the navigation message. Finally, the position
solution can be computed using the front-end and GNSS
software receiver.
A. Signal acquisition
The acquisition of GNSS signals in the acquisition step
includes a two-dimensional search in the Doppler
frequencies and the code phases based on the correlation
with the local replica code and received signal. In general,
traditional hardware receivers perform the correlation to
acquire GNSS signals in the time domain. Instead, the
parallel code correlation is suitable for software receivers
based on the FFT technique. This is well-known as the
circular correlation algorithm [4]. Here, x(t) is denoted as
the ranging code in the signal, and c() is denoted as the
GNSS L1 signal Replica code generation
IF data Acquisition
Initial Code Phase Doppler Freq.
Front-end
Tracking
PLL/FLL DLL
Doppler Freq. Code Phase
Nav. Data Synchronization
Navigation Message Bits
Nav. Data Decode
Pseudorange Computation
RINEX Output
Fig. 4. Signal processing flow of GNSS-SDRLIB during baseband
processing.
circulating moving local code replica. The output of the
correlator in the frequency domain is expressed as
follows:
( ) { ( )} { ( )} (1)
where fFFT{.} denotes the FFT function, and f *FFT{.}
denotes the complex conjugate FFT function. Here,
fIFFT{.} denotes the inverse FFT (IFFT). The correlation
output in the time domain y(t) is calculated using the
following equation:
( ) { ( )} (2)
The input digitalized samples may contain a bit transition
caused by the navigation data or secondary code. In this
situation, the correlation amplitude is decreased from its
ideal value. GNSS-SDRLIB uses the double-length zero-
padding FFT [33, 34] for the circular correlation in order
to get the perfect correlation outputs. A double-length
code replica is generated for the double-length zero-
padding FFT. Hence, the computational cost is almost
doubled. The correlation outputs are integrated using non-
coherent integration to improve the signal-to-noise ratio.
Then, a simple threshold test is performed to determine
whether or not the GNSS signal exists.
The FFT performance is dependent on the library used to
implement the FFT algorithm. GNSS-SDRLIB uses the
FFTW library [21] for the FFT in the parallel circular
correlation algorithm. FFTW is already optimized using
the SIMD technology. In addition, the FFT is performed
in parallel threads to speed up the calculations. Figure 5
shows the result of the signal acquisition in GNSS-
 GPS PRN19 GPS PRN19 BeiDou PRN8

Fig.5. Result of signal acquisition in GNSS-SDRLIB.

Fig.6. Multiple correlator outputs of GPS L1CA and BeiDou B1I
SDRLIB. The two-dimensional search results are signals in GNSS-SDRLIB.
visualized using GNUPLOT in order to check whether the
signal is acquired. It can be seen that a unique peak exists
where IP and QP are the prompt correlator outputs.
at the specified Doppler frequency and code phase.
The signal correlation computation in the tracking step
B. Signal acquisition
has the heaviest computational burden in the GNSS
In the signal tracking step, the carrier frequency and code
software receiver. All the correlation computations of all
phase of the incoming signal must be maintained. In order
the channels must be finished within 1 ms when we track
to estimate and keep the code phase, DLLs based on early,
the GPS L1CA code in real time. We use the SIMD
prompt, and late correlators are commonly used to
operation (SSE2 and AVX2) to speed up the
estimate and feedback the code phase error. Here, we use
computations. The SIMD instructions can be executed in
multi-correlators for research purposes such as monitoring
parallel, and it can also increase the speed of the
and mitigating multipath error. However, we use the
calculations. The latest Intel CPUs (after Haswell) support
traditional E-P-L correlator for the signal tracking. The
AVX2 instructions. The computational speed becomes 16
default number of correlators in GNSS-SDRLIB is 13,
times faster than that without using AVX2 in an ideal
and the early and late correlator space is 0.5 chip. The
situation. Figure 6 shows the multiple correlator outputs
number of correlators is changeable as desired, but the
of GPS L1CA and BeiDou B1I signals in the tracking step.
computational burden must be considered in the case of
The circular markers indicate the correlation points. The
real-time processing. We use a second-order DLL with
blue markers indicate early, prompt, and late correlators.
the aid of the carrier frequency from the FLL/PLL in the
The sampling frequency is 20 million samples per second
code tracking [35]. The DLL discriminator DDLL used in
in this experiment.
GNSS-SDRLIB is expressed as follows:
C. Decoding navigation message
√ √ GNSS-SDRLIB supports GPS/QZSS L1CA, GLONASS
(3) G1, Galileo E1, and BeiDou B1I signals. All of the
√ √
navigation data broadcast in these signals must be
decoded in real time to obtain GNSS position solutions.
where IE, IL, QE, and QL are the early and late correlator The time information, satellite orbits, and clock correction
outputs. To track the carrier frequency and carrier phase, parameter (ephemerides) contained in the GNSS
the second-order PLL with the first-order FLL [35] are navigation message are needed for positioning. The
used in the software. The discriminators of the FLL and structures of the sets of navigation data are completely
PLL are expressed as follows: different in the different satellite systems. Thus, the
( )
individual decoding processes must be implemented in
(4) software GNSS receivers.

(5) GNSS-SDRLIB can decode a GPS LNAV message in

L1CA code, GLONASS navigation message in G1 code,
Galileo I/NAV in E1B code, and BeiDou G1, and G2
( ) (6) NAV in BeiDou B1I code. A Galileo I/NAV message is
totally different from other navigation messages because
 Antenna

NSL STEREO Laptop PC

Fig.7. Setup of test for real-time positioning accuracy with multi-

GNSS.

Fig.8. Fish-eye image captured at antenna position.

it is encoded with a 1/2 convolutional code. The Fano and
Viterbi decoders are often used to decode convolutional
code. GNSS-SDRLIB uses the Viterbi decoder, which is
implemented in the FEC library [22] in order to decode
Galileo I/NAV data. In the case of BeiDou navigation
data, there are two types of navigation data, called D1 and
D2 NAV. D1 NAV is broadcast from medium earth orbit
(MEO) satellites and inclined geosynchronous satellite
orbit (IGSO) satellites. D2 NAV is broadcast from
geostationary earth orbit (GEO) satellites. GNSS-
SDRLIB can decode both D1 and D2 NAV data to
compute a position using BeiDou satellites. The decoded
navigation messages can be output in a RINEX navigation
file or through TCP/IP in RTCM formats for the position
computation.

3. EVALUATIONS

3.1. Real-time positioning accuracy with multi-GNSS

We carried out some tests to evaluate the GNSS-SDRLIB
performance and developed actual applications. First, we
describe the evaluation of the real-time positioning with
multi-GNSS using GNSS-SDRLIB and a commercially
available front-end. The test setup is shown in Figure 7.
We used an NSL Stereo front-end to capture multi-GNSS
signals, a GNSS antenna (Trimble, Zephyr 2), and a
laptop PC (Intel® Core™ i7-3635QM, 4 GB) that
included GNSS-SDRLIB for the real-time processing.
The GNSS antenna was installed on the rooftop of a
building within the campus of the Tokyo University of
Marine Science and Technology, Japan. Figure 8 shows a
fish-eye image captured at the antenna position in this test.
As can be seen, the test environment was an open-sky
environment. Figure 9 shows the sky plot of the
constellation of GNSS satellites during the test. GPS,
GLONASS, Galileo, BeiDou, and QZSS satellites were
available. However, NSL Stereo can only capture dual-
frequency signals. Hence, we evaluated the GPS, Galileo,
BeiDou, and QZSS constellation with the maximum
number of satellites. In this test, the position dilution of
precision (PDOP) value was 0.7.
Fig.9. Sky plot of constellation of GNSS satellites.
The processing window of the proposed software receiver
during the real-time positioning test is shown in Figure 10.
A total of 26 satellites could be acquired and tracked
during the experiments. Multi-GNSS observation data
were generated in real time and transmitted to RTKNAV,
which is one of the RTKLIB applications used for real-
time positioning, to compute the position solutions. In this
experiment, GPS, Galileo, BeiDou, and QZSS L1
pseudoranges were used to compute the location in the
single point positioning mode. The horizontal positioning
accuracy of the single point positioning with multi-GNSS
constellations is illustrated in Figure 11. The positioning
errors in the east, north, and up directions are illustrated in
Figure 12. The standard deviations (SDs) in the east,
north, and up directions were 0.52, 0.65, and 1.50 m,
respectively. The results of this experiment verified that
the positioning performance of the proposed GNSS-
SDRLIB was not very different from those of hardware
commercial receivers.
 Fig.10. Processing window of GNSS-SDRLIB during real-time positioning test.

Position solutions
East
North error [m]

North
Up

East error [m]

Fig. 11. Horizontal position error in static test with multi-GNSS. Fig. 12. Time-series position errors in static test with multi-GNSS.
.
3.2. PPP by QZSS LEX message
We also developed a PPP based on the QZSS MADOCA- NSL STEREO
LEX message, which has been broadcast from April 2013
[2], using the GNSS-SDRLIB. The message contained in
the LEX signal is designed to provide a multi-GNSS
satellite clock and ephemeris correction for correcting the PC
GNSS positioning error via the QZSS satellite in real time.
Unfortunately, the LEX signal cannot be received, and its
message cannot be decoded for PPP using the currently
available commercial GNSS receivers. We developed a Antenna
QZSS LEX message decoder using GNSS-SDRLIB. The JAVAD DELTA

LEX signal uses CSK modulation [2]. The CSK

Fig.13. M Test setup for PPP by QZSS LEX message.
modulation shifts the phase of the LEX code by the
number of chips indicated in the 8-bit encoded message
50 100
symbol. In our previous work, we developed a novel
technique for decoding the MADOCA-LEX message

Elevation angle [deg]

using a software GNSS receiver without the use of an
LEX signal tracking loop. However, we did use the

C/N0 [dB]
conventional L1CA signal broadcast simultaneously from 40 50
the QZSS [37].

We conducted a static test for over 18 h to evaluate the

performance of the LEX decoder and the actual accuracy
of the real-time PPP. The test setup is shown in Figure 13. 30 0
0 2 4 6 8 10 12 14 16 18
We used a dual-frequency GNSS receiver (Javad (a) LEX carrier-to-noise-density
DELTA-G3T) in addition to the above-mentioned 20 100
experimental equipment to obtain the dual-frequency
Number of decode error

Elevation angle [deg]

observation required in the PPP processing. The GNSS 15 80

antenna was also installed at the same location.

10 60

Figure 14(a) shows the relationship between the QZSS 5 40

elevation angle and LEX carrier-to-noise density obtained
by the GNSS-SDRLIB. Figure 14(b) shows the 0 20
relationship between the QZSS elevation angle and
number of decoded symbol errors. The LEX message was -5
0 2 4 6 8 10 12 14 16 18
0
correctly decoded over many hours using the GNSS- Elipsed time [hour]
SDRLIB. The CN0 and number of decoded symbol errors (b) Number of decode error
were associated with the elevation angle. However, the
Fig.14. Relationship between QZSS elevation angle and number of
QZSS LEX message contained the Reed–Solomon error decoded symbol errors.
correction code. The decoded frame error could be
reduced because the Reed–Solomon code can correct a
maximum of 16 symbol errors. The horizontal positioning
errors of the single point positioning (red dots) and PPP
with the MADOCA-LEX message (green dots) are
illustrated in Figure 15. It should be noted that PPP
requires the convergence time to accurately estimate the
user position. In this test, the position solutions in the first
North error [m]

hour were ignored in the evaluation. The horizontal root

mean square (RMS) error of the position solution was
1.93 m using GPS single point positioning. In contrast,
the horizontal RMS error improved to 5.0 cm when using
QZSS MADOCA-LEX PPP. Thus, the proposed software
receiver could stably track and decode the QZSS LEX
Single point positioning
signal, and the application using the real-time software PPP with LEX message
GNSS receiver (PPP with the MADOCA-LEX message)
realized centimeter-class positioning in real time using East error [m]
only the information broadcast from satellites.
Fig.15. Horizontal position error in PPP with MADOCA-LEX.
3.3. Real-time processing performance
We evaluated the real-time processing performance of
GNSS-SDRLIB. The computational performance of a
software receiver is an important issue because of its
heavy computational burden. In general, hardware GNSS
receivers are more efficient in terms of the computational
load because they are specially designed for GNSS signal
processing. GNSS-SDRLIB uses the SIMD instructions
and multi-thread implementation in order to improve the
performance. However, the heaviest computational power
is required in the tracking step. Thus, we evaluated the
relationships between the CPU loads and available
number of channels in the tracking phase. To determine
the best performance, we used a high-performance
desktop computer (Intel® Core™ i7-3770, 16 GB). The
SSE2 instructions were enabled in the signal correlator
functions, and the front-end sampling rate was 20 million
samples per second. Figure 16 shows the relationship
between the CPU load and number of channels of the
software receiver. In the case of using the conventional E-
P-L correlator and GPS L1CA code, GNSS-SDRLIB
worked with 46 channels in the real-time processing. It
could be verified that GNSS-SDRLIB had sufficient
performance to analyze a multi-GNSS constellation in the
real-time processing.
IV. FUTURE PLANS
GNSS-SDRLIB is still under active development. We
have plans to add new functions and improve the
performance of GNSS-SDRLIB. The future development
plans are as follows:
(1) Additional front-end support
We are considering supporting universal software radio
peripheral (USRP) front-ends [30], which are commonly
used in the SDR community. Although this will not be
only for GNSS front-ends, many GNSS researchers
develop real-time GNSS software receivers using this
device. Further, we will focus on open hardware GNSS
front-ends. An open hardware front-end has many
benefits for users, just as with open source receivers.
GNSS Firehose [31] is being developed as an open
hardware project. It has three RF front-ends and can
record triple-frequency observables from multi-GNSS
satellites. It is still under development. However, GNSS-
SDRLIB will support it in the future.
(2) Multi-frequency signal support
GNSS-SDRLIB already supports all the existing L1
ranging codes for GNSS satellites. However, the
generation of multi-frequency observables is still a
challenge in an open-source GNSS software receiver. We
will support new signals designed for civilian use,
including L2C, L5, and L1C, to evaluate dual-frequency
GNSS software receivers.
80
70
60
CPU Load [%]
50
40
30
20
3 correlators (E-P-L)
10
13 correlators
0
10 15 20 25 30 35 40 45 50
Number of channels
Fig.16. Relationship between CPU load and number of channels of
GNSS-SDRLIB in real-time processing.
(3) Real-time kinematic (RTK)-GNSS support
RTK-GNSS uses pseudoranges and carrier phase data to
find integer ambiguity resolutions to obtain centimeter-
level position accuracy. In general, this requires “survey-
grade” GNSS receivers, which can output high-quality
carrier phase measurements. RTK-GNSS is still a
challenge in the field of GNSS software receivers. We
will first try to develop an L1 RTK-GNSS. Then, we will
develop dual-frequency RTK-GNSS-capable software
receivers.
VI. CONCLUSION
In this paper, we described a novel open-source and real-
time processing-capable GNSS software receiver, called
GNSS-SDRLIB. GNSS-SDRLIB is a very simple and
easy-to-use GNSS signal processing tool written in
C/C++/CLI, and it consists of several application
programs. GNSS-SDRLIB provides GNSS signal
acquisition, tracking, pseudorange generation, navigation
message decoding, and spectrum analysis functions for
GNSS signal processing, which is required for position
computation. The architecture, configuration, and
characteristics of GNSS-SDRLIB were described in this
paper. GNSS-SDRLIB supports many commercially
available front-ends, and we verified the real-time
processing performance with these front-ends. In addition,
it fully supports multi-GNSS constellations such as GPS,
GLONASS, Galileo, BeiDou, and QZSS L1 signals, in
real-time positioning.
From the results of a positioning test, we confirmed that
GNSS-SDRLIB has sufficient performance to analyze a
multi-GNSS constellation using real-time processing.
GNSS-SDRLIB is released under the GPL v3, and we
expect it to be widely used for research and educational
purposes to learn GNSS signal processing and develop
GNSS algorithms and applications. Further, we expect
that the performance and ability of GNSS-SDRLIB will
be considerably improved by future developments.
ACKNOWLEDGMENTS
This work was supported by Grant-in-Aid for Japan
Society for the Promotion of Science (JSPS) Fellows.
REFERENCES
[1] CSNO, BeiDou Navigation Satellite System Signal In
Space Interface Control Document Open Service Signal,
Version 2.0, China Satellite Navigation Office, 26
December 2013
[2] Japan Aerospace Exploration Agency, “Quazi-Zenith
Satellite System Navigation Service, Interface
Specification for QZSS (IS-QZSS) Version 1.5”
Technical report, 2013.
[3] D. Akos, A Software Radio Approach to Global
Navigation Satellite System Receiver Design, Ph.D. thesis,
College of Engineering and Technology, Ohio University,
Aug. 1997.
[10] Y.-H. Chen, J.-C.Juang, D. S. De Lorenzo, J. Seo, S.
Lo, P. Enge, D. M. Akos, "Real-Time Dual-Frequency
(L1/L5) GPS/WAAS Software Receiver," Proceedings of
the 24th International Technical Meeting of The Satellite
Division of the Institute of Navigation (ION GNSS 2011),
Portland, OR, September 2011, pp. 767-774.
[11] C. Fern´andez–Prades, J. Arribas, P. Closas, C.
Avil´es, and L. Esteve, “GNSS-SDR: An open source tool
for researchers and developers,” in Proc. of the ION
GNSS 2011 Conference, Portland, Oregon, Sept. 2011.
[12] “OpenSourceGPS,”
http://sourceforge.net/projects/osgps/, (accessed
September 22, 2014)
[13] “SoftGNSS,” http://ccar.colorado.edu/gnss/,
(accessed September 22, 2014)
[14] “FastGPS,” http://sourceforge.net/projects/fastgps/,
(accessed September 22, 2014)
[15] “GPS-SDR,” https://code.google.com/p/gnsssdr/:
(accessed September 22, 2014)

[4] J. Bao-Yen Tsui, Fundamentals of Global Positioning [16] “GPS-SDR,” https://github.com/gps-sdr, (accessed
System Receivers. A Software Approach, John Wiley & September 22, 2014).
Sons, Inc., Hoboken, NJ, 2nd edition, 2005.
[17] “GNSS-SDR,” https://github.com/gps-sdr, (accessed
[5] K. Borre, D. M. Akos, N. Bertelsen, P. Rinder, and S. September 22, 2014)
H. Jensen, A Software–Defined GPS and Galileo
Receiver. A Single–Frequency Approach, Applied and [18] “GNSS-SDRLIB,”
Numerical Harmonic Analysis. Birkh¨auser, Boston, MA, http://www.taroz.net/gnsssdrlib_e.html, (accessed
2007. September 22, 2014)

[6] V. Chakravarthy, J. Tsui, D. Lin, and J. Schamus, [19] “RTKLIB: An Open Source Program Package for
“Software GPS receiver,” GPS Solutions, vol. 5, no. 2, pp. GNSS Positioning,” http://www.rtklib.com/, (accessed
63–70, Oct. 2001. September 22, 2014)

[7] C. Kelley, J. Barnes, and J Cheng, “OpenSource GPS.
Open source software for learning about GPS,” in Proc. of
the 15th International Technical Meeting of the Satellite
Division of the Institute of Navigation (ION GPS’02),
Portland, OR, Sept. 2002.
[20] T.Takasu and A.Yasuda, “Development of the low-
cost RTK-GPS receiver with an open source program
package RTKLIB,” International Symposium on
GPS/GNSS, International Convention Center Jeju, Korea,
November 4-6, 2009

[8] Gunawardena, S., “A Universal GNSS Software [21] FFTW, http://www.fftw.org/, http://www.fftw.org/,
Receiver MATLAB Toolbox for Education and Research,” (accessed September 22, 2014)
in Proc. of the 26th International Technical Meeting of
The Satellite Division of the Institute of Navigation (ION [22] DSP and FEC Library,
GNSS+ 2013), pp. 1560-1576, Nashville, Tennessee, http://www.ka9q.net/code/fec/, (accessed September 22,
USA, Sept. 2013. 2014)

[9] M. G. Petovello, C. O’Driscoll, G. Lachapelle, D. [23] Gnuplot, http://www.gnuplot.info/, (accessed

Borio, and H. Murtaza, “Architecture and benefits of an September 22, 2014)
advanced GNSS software receiver,” Positioning, vol. 1,
no. 1, pp. 66–78, 2009.
[24] RTL-SDR, http://sdr.osmocom.org/trac/wiki/rtl-sdr,
(accessed September 22, 2014)

[25] Sparkfun Electronics, SiGe GN3S Sampler v3,

https://www.sparkfun.com/products/10981, (accessed
September 22, 2014)

[26] SiGe Semiconductor, “SE4120L GNSS receiver IC

datasheet,” May 26, 2009, Ottawa, ON, Canada.

[27] Nuand, bladeRF Software Defined Radio,

http://nuand.com/, (accessed September 22, 2014)

[28] Nottingham Scientific Ltd Stereo Dual Frequency

SDR FE, http://www.nsl.eu.com/primo.html, (accessed
September 22, 2014)

[29] Maxim Integrated Products, Sunnyvale, CA,

MAX2769 Universal GPS Receiver, June 2010, Ref. 19-
0791; Rev2.

[30] Ettus Research USRP™ (Universal Software Radio

Peripheral), http://www.ettus.com/, (accessed September
22, 2014).

[31] GNSS Firehose,

https://github.com/pmonta/GNSS_Firehose, (accessed
September 22, 2014).

[32] C. Fernández-Prades, J. Arribas, P. Closas, “Turning

a Television into a GNSS Receiver,” in Proc. of the ION
GNSS+ 2013 Conference, Nashville, Tennessee (USA),
15-16 Sept. 2013.

[33] D. Sundararajan.. “Digital signal processing: theory

and practice,” World Scientific Publishing Company, pp.
43-58, Singapore, 2003.

[34] Yang, C., “FFT Acquisition of Periodic, Aperiodic,

Puncture, and Overlaid Code Sequences in GPS,”
Proceedings of the ION GPS 2001, Sept. 11-14, 2001,
Salt Lake City, UT, pp. 137-147.

[35] Kaplan, E. and Hegarty, C., Understanding GPS:

Principles and Applications, 2nd Edition, Artech House,
Boston, 2005.

[36] G. W. Heckler and J. L. Garrison, “SIMD correlator

library for GNSS software receivers,” GPS Solutions, vol.
10, no. 4, pp. 269–276, Nov. 2006.

[37] T. Suzuki, N. Kubo, T. Takasu, “Evaluation of

Precise Point Positioning Using MADOCA-LEX via
Quasi-Zenith Satellite System,” ION-ITM 2014, San
Diego USA, 2014.