Conference PaperPDF Available

An Open Source Galileo E1 Software Receiver

Authors:

Abstract and Figures

This paper presents an open source implementation of a GNSS software receiver that targets Galileo E1B and E1C signals. After discussing the signal structure and the general architecture of the proposed software receiver, we provide detailed descriptions of the main signal processing algorithms involved in acquisition and tracking of such navigation signals. Experimental results with signals broadcast by in-orbit Galileo satellites validate the approach. The connection to external software (that allows in-the-loop testing of algorithms implemented in popular commercial tools) is also presented and validated with real-life signals.
Content may be subject to copyright.
An Open Source Galileo E1 Software Receiver
Carles Fern
´
andez–Prades
, Javier Arribas
, Luis Esteve
, David Pubill
, and Pau Closas
Centre Tecnol
`
ogic de Telecomunicacions de Catalunya (CTTC)
Av. Carl Friedrich Gauss 7, 08860 Castelldefels, Spain. Email: {carles.fernandez, javier.arribas, david.pubill, pau.closas}@cttc.cat
Universitat Polit
`
ecnica de Catalunya (UPC), Dept. of Signal Theory and Communications
Jordi Girona 1–3, 08034 Barcelona, Spain. Email: luis@epsilon-formacion.com
Abstract—This paper presents an open source implementation
of a GNSS software receiver that targets Galileo E1B and E1C
signals. After discussing the signal structure and the general ar-
chitecture of the proposed software receiver, we provide detailed
descriptions of the main signal processing algorithms involved in
acquisition and tracking of such navigation signals. Experimen-
tal results with signals broadcast by in-orbit Galileo satellites
validate the approach. The connection to external software (that
allows in-the-loop testing of algorithms implemented in popular
commercial tools) is also presented and validated with real-life
signals.
I. INTRODUCTION
The race to complete the Galileo satellite constellation has
finally started. Two In-Orbit-Validation (IOV) satellites are
transmitting navigation signals since December 12, 2011, and
two more IOV satellites were launched by October 12, 2012.
An initial service constellation of 18 satellites is expected by
late 2014, and by the end of the decade a fully operational
service with a minimum of 30 satellites will be available, ac-
cording to the European GNSS Supervisory Authority (GSA).
As a matter of fact, the landscape of GNSS is going
to change rapidly in the following years (modernization of
GPS and GLONASS, advent of Galileo and COMPASS). A
number of new signals will be readily available for navigation,
providing means to determine position and time with an
unforeseen degree of performance. Nevertheless, the multi-
constellation, multi-frequency approach poses several tech-
nological challenges. In that sense, the flexibility provided
by the software defined radio approach appears as an ideal
environment for rapid prototyping and testing of new receiver
architectures and algorithms.
In response to this growing demand, in previous publi-
cations [1], [2] we presented an open-source GNSS soft-
ware defined receiver (so-called GNSS-SDR, available at
http://gnss-sdr.org) that makes use of the well-known GNU
Radio framework [3]. It provides a working implementation
of a whole processing chain of a GPS L1 C/A receiver,
from the output of a RF front-end to the computation of
position, velocity and time. It also outputs standard formats
(KML and NMEA for graphical representation, and RINEX
for observables and navigation data).
In the present work, we extend the receiver functionality to
acquire, track, and demodulate the navigation message of the
Galileo E1 open signal, including both E1B data and E1C
pilot components. Next Section describes the mathematical
model of the target signals, and then Section III presents
the proposed software receiver architecture and the signal
processing chain. Section IV shows some experimental results,
and finally Section V concludes the paper.
II. SIGNAL MODEL
The analytic representation of a signal received from a
generic GNSS satellite can be expressed as
r(t) = a(t)s
T
(t τ(t)) e
j2πf
d
(t)
e
j2πf
c
t
+ n(t) , (1)
where a(t) is the complex amplitude, s
T
(t) is the complex
baseband transmitted signal, τ (t) is the time–varying delay,
f
d
(t) = f
c
τ(t) is the Doppler shift, f
c
is the carrier fre-
quency, and n(t) is a noise term. The waveform s
T
(t) and
its parameters depend on the particular GNSS and frequency
band used by the receiver. The Galileo E1 band, centered at
f
(Gal E1)
c
= 1575.420 MHz and with a reference bandwidth
of 24.5520 MHz, uses the so-called composite binary offset
carrier CBOC(6,1,
1
11
) modulation, defined in baseband as:
s
(Gal E1)
T
(t) =
1
2
e
E1B
(t) (αsc
A
(t) + βsc
B
(t)) +
e
E1C
(t) (αsc
A
(t) βsc
B
(t))
, (2)
where the subcarriers sc
A
(t) and sc
B
(t) are defined as
sc
A
(t) = sign
sin(2πf
s,E1A
t)
, (3)
sc
B
(t) = sign
sin(2πf
s,E1B
t)
, (4)
and f
s,E1A
= 1.023 MHz, f
s,E1B
= 6.138 MHz are the sub-
carrier rates, α =
q
10
11
, and β =
q
1
11
. The E1B component
contains the bit sequence of the Integrity Navigation Message,
D
I/NAV
, transmitted at 250 sps and intended for navigation,
integrity and Safety–of–Life (SoL) services:
e
E1B
(t)=
+
X
l=−∞
D
I/NAV
h
[l]
4092
i
C
E1B
h
|l|
4092
i
p(tlT
c,E1B
),
(5)
where is the exclusive–or operation (modulo–2 addition),
C
E1B
is a pseudorandom noise (PRN) code (unique for each
satellite), [l]
L
means the integer part of
l
L
, |l|
L
means l modulo
L, T
c,E1B
=
1
1.023
µs, and p(t) is a rectangular pulse of
a chip–period duration centered at t = 0 and filtered at the
transmitter.
The E1C component is a pilot (dataless) signal with a
secondary code, forming a tiered code:
e
E1C
(t) =
+
X
m=−∞
C
E1Cs
h
|m|
25
i
4092
X
l=1
C
E1Cp
h
l
i
·
· p(t mT
c,E1Cs
lT
c,E1Cp
) , (6)
with T
c,E1Cp
=
1
1.023
µs and T
c,E1Cs
= 4 ms. The
C
E1B
and C
E1Cp
primary codes are pseudorandom mem-
ory code sequences defined in [4, Annex C.7 and C.8].
The binary sequence of the secondary code C
E1Cs
is
0011100000001010110110010. This band also contains an-
other component, Galileo E1A, intended for the Public Regu-
lated Service (PRS), that uses a so-called BOC(15,2.5) mod-
ulation with cosine–shaped subcarrier f
s,E1A
= 15.345 MHz
and T
c,E1A
=
1
2.5575
µs. The PRS spreading codes and the
structure of the navigation message have not been made public,
and hence E1A is not a target of the present work.
As is the case of other GNSS signals, the receiving power
level at the Earth surface of r(t) is extremely weak, well
below the noise floor. The minimum received power on
ground, defined at the output of an ideally matched right-hand
circularly polarized 0 dBi user receiving antenna when the
satellite elevation angle is higher than 10 degrees, is 157
dBW, considering 50/50 % E1B/E1C power sharing.
III. SOFTWARE RECEIVER IMPLEMENTATION
In order to acquire, track and demodulate those signals, we
based on GNSS-SDR, an open source software receiver written
in C++. The general software architecture was described in [2],
and it is sketched in Figure 1. It currently allows the use of
several radio frequency front-ends, and it can also work off-
line with raw signal samples stored in a file. Users can define
a custom signal processing flowgraph (type of signal source,
number of channels, algorithms to be used for each channel
and each module, strategies for satellite selection, type of
output format, etc.) through a configuration file, and populate
the signal processing blocks with their own algorithms.
The flowgraph is managed by a Control Plane, a thread
that runs concurrently with the processing blocks and is
in charge of receiving notifications and triggering run-time
changes in the application. Some of these notifications will
be sent directly from the processing blocks. For instance, an
Acquisition block that detects the presence of a satellite’s
signal will send a notification to the control thread via a
message queue, indicating its success. The control thread will
then change the internal configuration of the channel and pass
the results of the acquisition process to the Tracking block.
For the present work, we developed specific Galileo E1 im-
plementations for the blocks labeled as Signal Source, Signal
Conditioner, Acquisition, Tracking and Telemetry Decoder in
Figure 1, as well as the corresponding addition of Galileo
satellites in the control plane (activating PRN 11 and 12, the
two in-orbit satellites at that time), and a number of unit tests
that ensure the correct functionality of such implementations.
A. Signal source
The input of a software receiver are the raw bits that come
out from the front-end’s analog-to-digital converter (ADC).
Those bits can be read from a file stored in the hard disk or
directly in real-time from a hardware device through USB or
Ethernet buses. The Signal Source block is an abstraction layer
that hides the complexity of accessing each specific signal
source, providing a single interface to a variety of different
implementations. Depending on how the signal samples are
obtained, the user can configure the receiver for reading from
a file (and thus specifying the file location, sample format, and
the sampling frequency and intermediate frequency at what
the signal was originally captured) or for interacting with a
hardware front-end, if the host processor is fast enough to
allow real-time processing. Currently, GNSS-SDR provides
interfaces to the family of Ettus Research products through
the Universal Software Radio Peripheral (USRP) Hardware
Driver (UHD), allowing to set specific front-end parameters
such as the center frequency and the front-end gain; to the
SiGe GN3S Sampler v2 USB front-end, originally intended
to capture data for the Matlab-based GNSS software receiver
available from K. Borre’s book [5]; and to some low-cost USB
DVB-T dongles based on the Realtek RTL2832U chipset. The
user can also write custom drivers for any other hardware
device and wrap them as Signal Sources, allowing to expand
the functionality of the software receiver to potentially any
other RF front-end.
At the block output, there is an amplified, downconverted,
decimated, filtered and digitized version of r(t), becoming a
signal stream source that injects samples into the flowgraph
at the ADC sampling rate. Following the diagram of Figure
1, the Signal Source block output feeds the input of a Signal
Conditioner.
B. Signal Conditioner
A Signal Conditioner block is in charge of adapting the
sample bit depth to a data type tractable at the host computer
running the software receiver, and optionally intermediate
frequency to baseband conversion, resampling, and filtering.
Regardless the selected signal source features, the Signal
Conditioner interface delivers in a unified format a sample data
stream to the receiver downstream processing channels, acting
as a facade between the signal source and the synchronization
channels, providing a simplified interface to the input signal at
a reference, internal sample rate f
IN
. We denote the complex
samples at the Signal Conditioner output as x
IN
[n]. This signal
stream feeds a set of parallel Channels.
Each Channel encapsulates blocks for signal acquisition,
tracking and demodulation of the navigation message for a
single satellite. These abstract interfaces can be populated
with different algorithms addressing any suitable GNSS sig-
nal. The user can define the number of parallel channels
to be instantiated by the software receiver, and the thread-
per-block scheduler imposed by GNU Radio automatically
manages the multitasking capabilities of modern multi-core
and hyperthreading processors. In the following, we discuss
GNSS-SDR
CHANNEL N
CHANNEL 2
CHANNEL 1
SIGNAL
SOURCE
SIGNAL
CONDITIONER
ACQUISITION
OUTPUT
FILTER
PVT
TELEMETRY
DECODER
OBSERVABLES
FLOWGRAPH
MSG QUEUECONFIGURATION
CONFIGURATION
FILE
fs fIN
EPHEMERIS
QUEUE
RINEX
NAV
RINEX
OBS
NMEA
SIGNAL SAMPLES
HARDWARE
FRONT-END
TRACKING
RF generators and signal grabbers
Real-time front-ends
GNSS external tools and
scientific applications
Positioning applications
Inertial Measurement Unit
Intermediate signals analysis
Detailed receiver configuration sets
KML
GNU Octave
Fig. 1. Overview of the proposed GNSS software receiver. The user can define the signal source, the flowgraph and the specific algorithms and parameters
for each of the processing blocks through the configuration file. Signal can be injected or dumped into a file at any stage of the processing chain, allowing
the interaction with a wide range of external data and analysis tools.
implementation details of those blocks specifically addressed
to Galileo E1B and E1C signals.
C. Acquisition
The role of an Acquisition block is the detection of pres-
ence/absence of signals coming from a given GNSS satellite.
In case of a positive detection, it should provide coarse
estimations of the code phase ˆτ and the Doppler shift
ˆ
f
d
,
yet accurate enough to initialize the delay and phase tracking
loops. By exploiting the concepts and the methodology of the
estimation theory, it is possible to show that the maximum
likelihood (ML) estimates of f
d
and τ can be obtained by
maximizing the function
ˆ
f
d
ML
, ˆτ
ML
= arg max
f
d
ˆ
R
xd
(f
d
, τ)
2
, (7)
where
ˆ
R
xd
(f
d
, τ) =
1
N
N1
X
n=0
x
IN
[n]d[nT
s
τ]e
j2πf
d
nT
s
, (8)
x
IN
[n] is a complex vector containing I&Q samples of the
received signal, T
s
is the sampling period, τ is the code phase
of the received signal with respect to a local reference, f
d
is
the Doppler shift, N is the number of samples in a spreading
code (4 ms for E1), and d[n] is a locally generated reference.
The user can also configure the shape of d[n], allowing
simplifications that reduce the computational load. As shown
in Figure 2, in narrowband receivers the CBOC waveform
can be substituted by a sinBOC modulation with very small
performance penalty [6]. For the E1B signal component, the
reference signals available in our implementation are:
d
(CBOC)
E1B
[n] =
+
X
l=−∞
C
E1B
h
|l|
4092
i
p(t lT
c,E1B
) ·
·(αsc
A
[n] + βsc
B
[n]) , (9)
d
(sinBOC)
E1B
[n] =
+
X
l=−∞
C
E1B
h
|l|
4092
i
p(tlT
c,E1B
)sc
A
[n] , (10)
while for E1C, users can choose among:
d
(CBOC)
E1C
[n] =
+
X
m=−∞
4092
X
l=1
C
E1Cp
h
l
i
·p[nmT
c,E1Cs
lT
c,E1Cp
]·
·(αsc
A
[n] + βsc
B
[n]) , (11)
d
(sinBOC)
E1C
[n]=
+
X
m=−∞
4092
X
l=1
C
E1Cp
h
l
i
·p[nmT
c,E1Cs
lT
c,E1Cp
]·
·sc
A
[n]. (12)
1 0.8 0.6 0.4 0.2 0 0.2 0.4 0.6 0.8 1
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Code phase τ [chips]
!
!
R
xd
"
ˇ
f
d
= f
d
, τ
#
!
!
2
f
IN
=4Msps,d
( CBOC)
f
IN
=4Msps,d
( sinB O C)
f
IN
=8Msps,d
( CBOC)
f
IN
=8Msps,d
( sinB O C)
f
IN
=24Msps,d
( CBOC)
Fig. 2. Normalized
R
xd
ˇ
f
d
= f
d
, τ
2
for different sampling rates and
local reference waveforms.
The maximization in (7) requires a two-dimensional search in
a function which output results from a multiplication-and-sum
of N complex samples, becoming the computational bottle-
neck of the whole process. A usual method to alleviate this
issue is to resort to the FFT-based circular convolution, which
exchanges the expensive multiplication-and-sum operation by
a discrete Fourier transform, a vector product and an inverse
transform, taking advantage of the efficient implementations
available for such operations [5].
The magnitude of (8), also known as cross-ambiguity func-
tion, is also used to decide whether the satellite corresponding
to the local replica d[n] is in view or it is not. Resorting to
signal detection theory, it is possible to define tests statistics
with desirable properties. A criterion commonly used for a
detection problem is the maximization of the detection prob-
ability (P
d
) subject to a given false alarm probability (P
fa
).
It is well-known in the literature that the optimum solution to
that problem can be found by applying the Neyman-Pearson
(NP) approach, which requires perfect knowledge of the signal
parameters and constitutes the uniformly most powerful test
[7]. Assuming additive white Gaussian noise and replacing
the true synchronization parameters by their ML estimators in
the NP detector, one obtains the Generalized Likelihood Ratio
Test (GLRT) function, that can be written as:
T
GLRT
(x
IN
) = max
f
d
ˆ
R
xd
(f
d
, τ)
2
ˆ
R
xx
, (13)
where
ˆ
R
xx
is an estimation of the input signal power. It can be
shown [7] that this acquisition test statistic is a Constant False
Alarm Rate (CFAR) detector because P
fa
does not depend on
the noise power.
Our implementation is described in Algorithm 1. The com-
putation of the Fast Fourier Transform and its inverse (steps
Algorithm 1 Parallel Code Phase Search (PCPS) acquisition
algorithm.
Require: Input signal buffer x
IN
of N complex samples,
provided by the Signal Conditioner; on-memory FFT
of the local replica, D[n] = F F T
N
{d[n]}; acquisition
threshold γ; freq. span [f
min
f
max
]; freq. step f
step
.
Ensure: Decision positive or negative signal acquisition. In
case of positive detection, it provides coarse estimations
of code phase ˆτ
acq
and Doppler shift
ˆ
f
d
acq
to the Tracking
block.
1: Compute input signal power estimation:
ˆ
P
in
=
1
N
P
N1
n=0
|x
IN
[n]|
2
.
2: for
ˇ
f
d
= f
min
: f
step
:
ˇ
f
d
= f
max
do
3: Carrier wipe-off:
x[n] = x
IN
[n] · e
(j2π
ˇ
f
d
nT
s
)
, for n = 0, ..., N 1.
4: X[n] = FFT
N
{x[n]}
5: Y [n] = X[n] · D[n], for n = 0, ..., N 1.
6: R
xd
(
ˇ
f
d
, τ ) =
1
N
2
IFFT
N
{Y [n]}
7: end for
8: Search maximum and its indices in the search grid:
{S
max
, f
i
, τ
j
} max
f
|R
xd
(f, τ)|
2
9: Compute the GLRT function with normalized variance:
Γ
GLRT
=
2·N·S
max
ˆ
P
in
10: if Γ
GLRT
> γ then
11: Declare positive acquisition and provide
ˆ
f
d
acq
= f
i
and
ˆτ
acq
= τ
j
.
12: else
13: Declare negative acquisition.
14: end if
4 and 6) are performed by means of GNU Radio wrappers
of the FFTW3 library [8], an efficient implementation for
computing the discrete Fourier transform, and the product
in step 5 is implemented with the Vector-Optimized Library
of Kernels (VOLK) [9], which generates processor-specific
Single-Input Multiple-Data (SIMD) assembly instructions that
take advantage of parallel computing techniques and allows
writing efficient and portable code.
On top of Algorithm 1 (or any other providing the same
outputs), we could integrate results from more than one
consecutive code periods in order to enhance the acquisition
sensitivity, understood as the minimum signal power at which
a receiver can correctly identify the presence of a particular
satellite signal in the incoming RF signal within a given time-
out interval.
D. Tracking
The Tracking block is also receiving the data stream x
IN
, but
does nothing until it receives a “positive acquisition” message
from the control plane, along with the coarse estimations ˆτ
acq
and
ˆ
f
d
acq
. Then, its role is to refine such estimations and track
their changes along the time. Three parameters are relevant for
signal tracking: the evolution of the code phase τ , Doppler
shift f
d
and carrier phase φ. According the ML principle
expressed in (7), obtaining the optimum estimators implies
the maximization of the correlation of the incoming signal
with its matched filter. This is usually achieved with closed-
loop structures designed to minimize the difference between
the code phase, carrier phase and frequency of the incoming
signal with respect to a locally-generated replica.
In the case of code phase tracking, the cost function is driven
to the maximum using feedback loops that employ the deriva-
tive
dR
xd
(τ)
zero-crossing as a timing error detector. This is
the case of the Delay Lock Loop (DLL) architecture and its
wide range of variants usually applied for GPS L1 signals,
where the receiver computes three samples of R
xd
, usually
referred to as Early E = R
xd
(ˆτ ), Prompt P = R
xd
(ˆτ)
and Late L = R
xd
(ˆτ ), with ranging from 0.1T
c
to 0.5T
c
,
and then computes a timing error with some combination of
those samples, known as discriminator functions. In case of
Galileo E1, the CBOC(6,1,
1
11
) modulation creates correlation
ambiguities, as shown in Figure 2. The possibility of tracking
a local maximum instead of the global one can be avoided
by using discriminators that consider two extra samples of the
cost function, referred to as Very Early VE = R
xd
(ˆτ
0
) and
Very Late VL = R
xd
(ˆτ +
0
), with
0
> .
In the case of carrier tracking loops, the pilot channel E1C
can be used for the phase error estimation, since it does
not contain data bit transitions, and, theoretically, coherent
integration of several code periods can be used for as long as
needed. As a consequence, a discriminator that is insensitive
to phase jumps can be used. Using pure PLL tracking on the
pilot channel as well as longer coherent integration improves
the carrier tracking sensitivity, the minimum signal power at
which the receiver can keep the tracking process in lock.
In addition to track the synchronization parameters, the
Tracking block must also implement code and carrier lock
detectors, providing indicators of the tracking performance.
Our implementation is described in Algorithm 2. The com-
putation of the complex values VE, E, P, L and VL in
step 4 was implemented using the VOLK library. The PLL
discriminator implemented in step 5 is the extended arctangent
(four-quadrant) discriminator, and for the DLL we used the
normalized Very Early Minus Late Power discriminator pro-
posed in [10] (step 9). For code lock detection (step 12), we
used the Squared Signal-to-Noise Variance (SNV) estimator
proposed in [11]. In the case of carrier lock detection (step
13), we used the normalized estimate of the cosine of twice
the carrier phase [12]. The values of the lock indicator range
from 1, when the locally generated carrier is completely out
of phase, to 1, that indicates a perfect match. When either the
code or the carrier detectors are below given thresholds during
a consecutive number of code periods ϑ, the Tracking block
informs to control plane through the message queue.
E. Decoding of the navigation message
As shown in Equation (5), the E1B signal component
carries the I/NAV navigation message, which provides the
space vehicle identification (SVID), an Issue of Data, the
ephemeris data, a signal-in-space accuracy (SISA) indicator,
clock correction parameters, a ionospheric correction, the
Broadcast Group Delay (BGD), signal health and data validity
status, Galileo System Time (GST), GST-UTC and GST-GPS
time conversion parameters, the almanacs, and Search and
Rescue (SAR) service data. The message structure is depicted
in Figure 3: each frame contains 24 subframes, and each
subframe contains 15 nominal pages, having a duration of
2 seconds transmitted sequentially in time in two parts of
duration 1 second each. Each page part (denoted as even or
odd) consists of a 10-bit synchronization pattern followed by
240 coded symbols, corresponding to 114 data bits and 6 tail
bits (sequence of zeros) that allow Viterbi decoding. Three
levels of error coding are applied to the Galileo message
data stream: i) a Cyclic Redundancy Check (CRC) with error
detection capabilities after recovery of the received data, ii)
a one-half rate Forward Error Correction (FEC) convolutional
coding, and iii) block interleaving on the resulting frames, with
30 columns (where data is written) and 8 rows (where data is
read), providing robustness to the FEC decoding algorithm by
avoiding error bursts.
Frame i
Subframe j
Page k
Navigation Data
720 s
30 s
1 s
Frame 1
Subframe 1
Page 1
Sync
0101100000
Tail
000000
Subframe 24
Page 15
Frame N
Interleaving FEC coded
...
...
... ...
...
...
Navigation Data 1 sSync
0101100000
Tail
000000
Interleaving FEC coded
Even Page Part
Odd Page Part
{
Fig. 3. I/NAV navigation message structure.
F. Connection to third-party software
Each processing block can be configured to dump internal
data to a file, thus allowing the use of tools such as Octave
or Matlab for analysis, graphical visualization and debugging
purposes. Provided that GNSS-SDR is designed to easily
accommodate new algorithms, we cannot ignore the conve-
nience of other third-party tools for rapid prototyping widely
used by the industry, such as Mathworks’ Matlab/Simulink or
National Instruments’ LabView. These are commercial tools,
often with machine-related licenses that constrain the use
of the software to certain computers, maybe remote to the
user’s machine. In order to use them for algorithm validation
within the framework of GNSS-SDR, we developed a so-called
Transmission Control Protocol (TCP) connector, that allows
by-passing internal processing blocks by external ones, run
by other software tools and, optionally, in a remote computer.
This TCP connector allows, for instance, to perform
Simulink model-in-the-loop testing, using signal samples from
a file and integrating the model in a complete GNSS receiver.
In such a setup, the developer enjoys the design environment,
block libraries and tools for modeling, simulating and ana-
lyzing dynamic systems provided by Simulink, while using
GNSS-SDR for rapidly integrating the Simulink model into a
full receiver, which will make use of that model just as for
any other of the existing “native” loops. However, the TCP
connection severely slows down the execution of the whole
receiver, preventing its use in real-time mode. In practice, it
can be used with GNSS-SDR in post-processing mode only,
that is, capturing raw bits at the RF front-end’s ADC output,
storing them in a file, and then processing the signals offline.
IV. EXPERIMENTAL RESULTS WITH REALLIFE SIGNALS
The software receiver described so far was tested using
real signals broadcast by the in-orbit Galileo satellites. The
hardware front-end consisted of an active antenna (Novatel
GPS-600), which has a 3 dB pass at E1 of 1575 ± 8 MHz
and a built-in low noise amplifier that provides 28 ± 3 dB of
gain. The antenna was connected to a DBSRX daughterboard
[13], in charge of amplification, downconversion and filtering,
followed by a USRP v1 Rev. 4.5 [14] for analog-to-digital
conversion, fine downconversion and decimation, and USB 2.0
interface.
The DBSRX is a complete receiver system for 800 MHz to
2.3 GHz with a 3-5 dB noise figure. The DBSRX features
a software controllable channel filter which can be made
as narrow as 1 MHz, or as wide as 60 MHz. After the
antenna SMA input there is a 17 dB amplifier, followed by a
programmable (0-56 dB) amplifier, feeding two (I&Q) direct
conversion tuners (Maxim’s MAX2118, covering from 925 to
2175 MHz) followed by a another programmable (0-24 dB)
amplifier, a programmable lowpass filter (2 to 33 MHz) and
a switchable 5 dB amplifier. The output signals are connected
to the USRP, that ships with a voltage controlled, temperature
compensated crystal oscillator as a 64 MHz reference clock
(±20 ppm) and samples the I&Q signal components with an
Analog Devices’ AD9862 (14 bits per sample, f
s
= 64 Msps).
Then, an Altera Cyclone EP1C12Q240C8 FPGA performs
digital downconvertion to baseband with programmable deci-
mation rates, and finally sends the digital signal through USB
2.0 (which provides a 32 MBps bandwidth) to the computer
running the software receiver.
The host computer was an Intel Core2 Quad Q9400 proces-
sor at 2.66 GHz with 4 GB of RAM, running Linux Ubuntu
12.04 32 bits as operating system and GNU Radio 3.6.2. The
Signal Source block was configured with the UHD, setting
f
c
= 1575, 420 MHz and an amplification of 60 dB (the driver
internally adjusts the programmable amplifiers in order to get
a low the noise figure while avoiding ADC saturation), using
decimation rates of 8 and 16 (corresponding to f
IN
= 8 Msps
and f
IN
= 4 Msps), and then capturing samples in a hard disk
using a capture-to-file utility of the UHD driver.
Fig. 4. GLRT statistic of Parallel Code Phase Search acquisition algorithm
for a configuration of f
IN
= 4 Msps, a frequency span of ±5 kHz with steps
of 250 Hz, and using the E1B sinBOC local replica for Galileo’s IOV satellite
PRN 11.
Then, we configured the Signal Source to read from the
corresponding file, thus avoiding real-time constraints and
delivering a stream of complex, baseband samples with real
and imaginary parts in float data type (IEEE-754 32 bit
floating point). The Signal Conditioner was deactivated (pass–
through) and the Channels were configured to use Algorithm
1 for Acquisition and Algorithm 2 for Tracking.
The parameters for acquisition were set as T
int
= 4 ms,
N = T
int
f
IN
(thus N = 32000 and N = 16000 samples
per code period, corresponding to a receiver bandwidth of 4
MHz and 8 MHz, respectively), γ = 50, f
d
min
= 5 kHz,
f
d
max
= 5 kHz and f
step
= 250 Hz. The local reference
waveform were d
(sinBOC)
E1B
[n], defined in (10), for the Galileo
satellite identified with PRN 11. Figure 4 shows the search grid
computed in steps 2-7 of Algorithm 1. Similar results were
obtained when using d
(CBOC)
E1B
[n], d
(sinBOC)
E1C
[n] or d
(CBOC)
E1C
[n],
for both bandwidth configurations.
The tracking algorithm was configured with T
int
= 4
ms, T = 0.85, = 0.15 · T
c,E1B
,
0
= 0.6 · T
c,E1B
,
U = 10, CN 0
min
= 25 dB-Hz, ϑ = 20, BW
DLL
= 15
Hz, and BW
P LL
= 2 Hz (see description of those parameters
in Algorithm 2). Figure 5 shows the evolution in time of
the correlators VE, E, P, L and VL obtained with such
configuration.
In order to provide a simple example of the possibilities of
the TCP connector described in Section III-F, we configured
the software receiver to use a tracking block implemented in
Simulink instead of a C++ implementation, with the same
parameters. We established a TCP connection just after the
computation of the correlation samples VE, E, P, L, and VL
(step 4 in Algorithm 2), and the DLL/PLL discriminators and
filters (steps 5–11 in Algorithm 2) were implemented in a
Simulink model, as shown in Figure 6. Some details about the
implementation of the block labeled as Galileo E1 Tracking
8 9 10 11 12 13 14 15 1
6
0
0.2
0.4
0.6
0.8
1
1.2
Time [s]
Correlation absolute value
VE
2
I
+ VE
2
Q
E
2
I
+ E
2
Q
P
2
I
+ P
2
Q
L
2
I
+ L
2
Q
VL
2
I
+ VL
2
Q
Fig. 5. Evolution of VE, E, P, L and VL computed with a C++ implemen-
tation of the Tracking block.
gnss_sdr_galileo_e1_tcp_connector_tracking_tx
control ID
h
DLL
(
k
)
h
PLL
(
k
)
f
d
k
Galileo E1
GNSS-SDR
TCP CONNECTOR
gnss_sdr_galileo_e1_tcp_connector_tracking_rx
control ID
VE
I
VE
Q
E
I
E
Q
L
I
L
Q
VL
I
VL
Q
P
I
P
Q
f
d
acq
enable
Galileo E1
GNSS-SDR
TCP CONNECTOR
gnss_sdr_galileo_e1_tcp_connector_tracking
control ID
VE
I
VE
Q
E
I
E
Q
L
I
L
Q
VL
I
VL
Q
P
I
P
Q
f
d
acq
enable
control ID
h
DLL
(
k
)
h
PLL
(
k
)
f
d
k
VE,E,P,L,VL
Galileo E1
TRACKING
Zero-Order
Hold
VE,E,P,L,VL
Re
Im
Discrete-Time
Scatter Plot
Scope
Fig. 6. Simulink model-in-the-loop testing using GNSS-SDR and the TCP
connectors.
are shown in Figure 7. A TCP connector returned back the
results of the Simulink block to the software receiver, which
continued with the processing flow in the same way it does for
any other block implementation. Figure 8 shows the obtained
scatter plot, showing the data bits of signal E1B.
Finally, the obtained navigation bits are decoded by apply-
ing a de-interleaver, a Viterbi decoder and a CRC, as explained
in Section III-E. Figure 9 shows the correlation of the data bits
and the preamble (10-bit synchronization pattern), showing the
expected periodicity of 1 s (corresponding to the start of each
data page, as shown in Figure 3).
V. CONCLUSIONS
In this paper, we presented an open source software radio
implementation in C++ of the acquisition, tracking and nav-
igation message decoding of Galileo E1B and E1C signals.
We discussed the main signal processing aspects of such
stages, and experimental results using signals coming from
the in-orbit Galileo satellites validated the approach. The
receiver software architecture was designed to allow several
implementations for each processing block, as long as they
EPL Scope
5
carrier_doppler_Hz
4
carr_error_filt
3
code_error_filt
2
control_id_
1
Re
Im
Re
Im
Re
Im
Re
Im
Re
Im
double
double
double
double
double
single
single
double
single
Code Tracking
(DLL)
VE
E
L
VL
enable
h
DLL
(
k
)
Code
Tracking
(DLL)
Carrier Tracking (PLL)
P
f
d
acq
enable
h
PLL
(
k
)
f
d
k
Carrier
Tracking
(PLL)
|u|
|u|
|u|
|u|
|u|
enable_tracking
13
f_d_acq
12
d_P_Q
11
d_P_I
10
d_vL_Q
9
d_vL_I
8
d_L_Q
7
d_L_I
6
d_E_Q
5
d_E_I
4
d_vE_Q
3
d_vE_I
2
control_id
1
Fig. 7. Implementation details of the Simulink model of a Galileo E1
Tracking block (the yellow block in Figure 6).
Fig. 8. Screen capture of the discrete-time scatter plot scope of Figure 6.
follow a minimal common interface. As an example of such
flexibility, we implemented a tracking algorithm in Simulink
and performed model-in-the-loop testing using TCP connec-
tors for the communication between the software receiver and
an external third-party application. The documentation and
the source code of the software receiver described in this
work, as well as ongoing developments, are freely available
at http://gnss-sdr.org.
ACKNOWLEDGMENT
This work has been partially funded by the Google Summer
of Code 2012 program (GSoC 2012).
8 9 10 11 12 13 14 15 16
0
1
2
3
4
5
6
7
8
9
10
11
Time [s]
Preamble correlation absolute value
Fig. 9. Correlation of the data bits and the 10-bit synchronization pattern.
The peaks spaced 1 s apart mark the starting of the data pages.
REFERENCES
[1] C. Fern
´
andez–Prades, C. Avil
´
es, L. Esteve, J. Arribas, and
P. Closas, “Design patterns for GNSS software receivers, in
Proc. of the 5th ESA Workshop on Satellite Navigation Technologies
(NAVITEC’2010), ESTEC, Noordwijk, The Netherlands, Dec. 2010,
DOI:10.1109/NAVITEC.2010.5707981.
[2] 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.
[3] “GNU Radio, http://gnuradio.org/redmine/wiki/gnuradio, Retrieved:
July 31, 2012.
[4] European Union, European GNSS (Galileo) Open Service. Signal
In Space Interface Control Document. Ref: OS SIS ICD, Issue 1.1,
September 2010.
[5] K. Borre, D. M. Akos, N. Bertelsen, P. Rinder, and S. H. Jensen,
A Software–Defined GPS and Galileo Receiver. A Single–Frequency
Approach, Applied and Numerical Harmonic Analysis. Birkh
¨
auser,
Boston, MA, 2007.
[6] E. Simona Lohan, “Limited bandwidths and correlation ambiguities: Do
they co-exist in Galileo receivers, Positioning, vol. 2, no. 1, pp. 14–21,
Feb. 2011, DOI: 10.4236/pos.2011.21002.
[7] S. M. Kay, Fundamentals of statistical signal processing, Volume II:
Detection theory, Prentice Hall, Upper Saddle River, NJ, 1998.
[8] M. Frigo and S. G. Johnson, “The design and implementation of
FFTW3, Proceedings of the IEEE, vol. 93, no. 2, pp. 216–231,
2005, Special issue on “Program Generation, Optimization, and Platform
Adaptation”.
[9] “VOLK, http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk, Re-
trieved: October 14, 2012.
[10] A. Jovanovic, C. Mongr
´
edien, Y. Tawk, C. Botteron, and P. A. Farine,
“Two-Step Galileo E1 CBOC Tracking Algorithm: When Reliability
and Robustness Are Keys!, International Journal of Navigation and
Observation, 2012, Article ID 135401. Special issue on Advances
in Signal Tracking for GNSS Receivers: Theory and Implementation”.
DOI:10.1155/2012/135401.
[11] D. R. Pauluzzi and N. C. Beaulieu, A comparison of SNR estimation
techniques for the AWGN channel, IEEE Transactions on Communi-
cations, vol. 48, no. 10, pp. 1681–1691, Oct. 2000.
[12] A. J. Van Dierendonck, “GPS Receivers, in Global Positioning System:
Theory and Applications, B. W . Parkinson and J. J. Spilker, Jr., Eds.,
vol. I, chapter 8, pp. 329–407. American Institute of Aeronautics and
Astronautics, Inc., Washington, DC, 1995.
[13] Ettus Research, “Product Detail: DBSRX2 800-2300 MHz Rx,
http://www.ettus.com/product/details/DBSRX2, Retrieved: October 24,
2012.
[14] Ettus Research, “USRP1, http://www.ettus.com/product/details/USRP-
PKG, Retrieved: October 24, 2012.
Algorithm 2 Implemented tracking algorithm.
Require: Complex sample stream, x
IN
; estimations of code
phase ˆτ
acq
and Doppler shift
ˆ
f
d
acq
; buffer size for
power estimation, U; carrier lock detector threshold, T ;
CN 0
min
; maximum value for the lock fail counter, ϑ; cor-
relators spacing and
0
; loop filters bandwidth BW
DLL
and BW
P LL
; integration time T
int
.
Ensure: Track signal’s synchronization parameters within a
given lock margin. Inform about a loss of lock.
Initialization: Using ˆτ
acq
and a sample counter N, skip
samples until x
IN
is aligned with local PRN replica. Set
υ = 0, k = 0,
ˆ
f
d
0
=
ˆ
f
d
acq
,
ˆ
φ
0
= 0, ψ
1
= 0,
N
1
= round(T
int
f
IN
).
1: Increase the integration period counter: k = k + 1.
2: Generate local code references: for n = 1...N
k
,
s[n] = d
E1B/E1C
p
[round(δ
k
· n + ψ
k
)], where
δ
k
=
1
T
c,E1B
·f
IN
1 +
ˆ
f
d
k1
f
(Gal E1)
c
, and the Very Early, Early,
Late, and Very Late versions with and
0
.
3: Generate local carrier: for n = 1...N
k
,
c[n] = e
j
2π
ˆ
f
d
k1
n
f
IN
+mod
(
ˆ
φ
k1
,2π
)
.
4: Perform carrier wipe-off and compute the complex sam-
ples VE
k
, E
k
, P
k
, L
k
and VL
k
.
Example: P
k
=
1
N
k
P
N
k
1
n=0
x
IN
[n]s[n]c[n] .
5: Compute PLL discriminator:
ˆ
φ
k
= atan2
P
Q
k
P
I
k
.
6: Filter
ˆ
φ
k
with a bandwidth BW
P LL
: h
P LL
ˆ
φ
k
.
7: Update carrier frequency estimation (in Hz):
ˆ
f
d
k
=
ˆ
f
d
acq
+
1
2πT
int
h
P LL
ˆ
φ
k
.
8: Update carrier phase estimation (in rad):
ˆ
φ
k
=
ˆ
φ
k1
+ 2π
ˆ
f
d
k
T
int
+ h
P LL
(∆
ˆ
φ).
9: Compute DLL discriminator: ˆτ
k
=
E
k
−L
k
E
k
+L
k
, where:
E
k
=
q
VE
2
I
k
+ VE
2
Q
k
+ E
2
I
k
+ E
2
Q
k
, and
L
k
=
q
VL
2
I
k
+ VL
2
Q
k
+ L
2
I
k
+ L
2
Q
k
.
10: Filter ˆτ
k
with a bandwidth BW
DLL
: h
DLL
(∆ˆτ
k
).
11: Update code phase estimation (in samples):
N
k+1
= round(S) and ψ
k+1
= S N
k+1
, where
S =
T
int
f
IN
1+
ˆ
f
d
k
f
(Gal E1)
c
+ ψ
k
+ h
DLL
(
ˆ
τ
k
)f
IN
.
12: Code lock indicator:
ˆ
CN0 = 10 ·log
10
(ˆρ) + 10 ·log
10
(
f
IN
2
) 10 ·log
10
(L
PRN
),
where: ˆρ =
ˆ
P
s
ˆ
P
n
=
ˆ
P
s
ˆ
P
tot
ˆ
P
s
,
ˆ
P
s
=
1
U
P
U 1
i=0
|P
I
ki
|
2
, and
ˆ
P
tot
=
1
U
P
U 1
i=0
|P
ki
|
2
.
13: Phase lock indicator:
T
carrier
=
P
U 1
i=0
P
I
ki
2
P
U 1
i=0
P
Q
ki
2
P
U 1
i=0
P
I
ki
2
+
P
U 1
i=0
P
Q
ki
2
.
14: if T
carrier
< T or CN 0 < CN 0
min
then
15: Increase lock fail counter υ υ + 1.
16: else
17: Decrease lock fail counter υ max(υ 1, 0).
18: end if
19: if υ > ϑ then
20: Notify the loss of lock to the control plane through the
message queue.
21: end if
22: Output: P
k
, accumulated carrier phase error
ˆ
φ
k
, code
phase N N + N
k
+ ψ
k
,
ˆ
CN0.
... The tracking loops use the code replicas to estimate the derivative dR xd(τ) dτ zero-crossing, which is used as a timing error detector [60]. The code replicas are named VE (Very Early), E (Early), P (Prompt), L (Late), and VL (Very Late) [61]. The correlator outputs are integrated and dumped. ...
Article
Full-text available
Global navigation satellite system (GNSS) technology is evolving at a rapid pace. The rapid advancement demands rapid prototyping tools to conduct research on new and innovative signals and systems. However, researchers need to deal with the increasing complexity and integration level of GNSS integrated circuits (IC), resulting in limited access to modify or inspect any internal aspect of the receiver. To address these limitations, the authors designed a low-cost System-on-Chip Field-Programmable Gate Array (SoC-FPGA) architecture for prototyping experimental GNSS receivers. The proposed architecture combines the flexibility of software-defined radio (SDR) techniques and the energy efficiency of FPGAs, enabling the development of compact, portable, multi-channel, multi-constellation GNSS receivers for testing novel and non-standard GNSS features with live signals. This paper presents the proposed architecture and design methodology, reviewing the practical application of a spaceborne GNSS receiver and a GNSS rebroadcaster, and introducing the design and initial performance evaluation of a general purpose GNSS receiver serving as a testbed for future research. The receiver is tested, demonstrating the ability of the receiver to acquire and track GNSS signals using static and low Earth orbit (LEO)-scenarios, assessing the observables’ quality and the accuracy of the navigation solutions.
... GNSS-SDR can read assistance data such as the satellite's ephemeris and almanacs externally through the Internet for faster time to first fix (TTFF). The detailed GNSS-SDR architecture, framework and modules are described in Fernández-Prades et al. (2010, 2011, 2012. ...
Article
Full-text available
The GNSS software receiver has evolved as a promising tool for researchers and developers because of its flexibility and reconfigurability. As modernized GNSS signals have been emerging day by day, the need to adapt the software receiver to address the upcoming challenges of GNSS navigation has become inevitable. The main aim of this work is to assess the existing Global Navigation Satellite System Software Defined Receiver (GNSS-SDR) tool for Indian Regional Navigation Satellite System (IRNSS) signals using a low-cost RTL-SDR front-end. The IRNSS software receiver chain is developed using GNSS-SDR code and framework. GNSS-SDR is an open-source tool developed by the Centre Tecnològic de Telecomunicacions de Catalunya (CTTC) of Spain. This work is useful for carrying out various GNSS-related applications using IRNSS signals in the future and paves the way for further research and development of the IRNSS system by using it as a research/academic tool.
... Positive detection of an adversarial signal triggers further processing that includes peak identification, recovery signal generation, and signal recovery. GNSS-SDR allows external communications using TCP sockets as outlined here [36]. This enables GNSS-SDR to interact with the UAV's flight controller responsible for performing peak identification maneuvers. ...
... Positive detection of an adversarial signal triggers further processing that includes peak identification, recovery signal generation, and signal recovery. GNSS-SDR allows external communications using TCP sockets as outlined here [30]. This enables GNSS-SDR to interact with the UAV's flight controller responsible for performing peak identification maneuvers. ...
Preprint
Full-text available
It is well-known that GPS is vulnerable to signal spoofing attacks. Although several spoofing detection techniques exist, they are incapable of mitigation and recovery from stealthy attackers. In this work, we present SemperFi, a single antenna GPS receiver capable of tracking legitimate GPS satellite signals and estimating the true location even during a spoofing attack. The main challenge in building SemperFi is, unlike most wireless systems where \emph{the data} contained in the wireless signals is important, GPS relies on the time of arrival (ToA) of satellite signals. SemperFi is capable of distinguishing spoofing signals and recovering legitimate GPS signals that are even completely overshadowed by a strong adversary. We exploit the short-term stability of inertial sensors to identify the spoofing signal and extend the successive interference cancellation algorithm to preserve the legitimate signal's ToA. We implement SemperFi in GNSS-SDR, an open-source software-defined GNSS receiver, and evaluate its performance using UAV simulators, real drones, a variety of real-world GPS datasets, and various embedded platforms. Our evaluation results indicate that in many scenarios, SemperFi can identify adversarial peaks by executing flight patterns that are less than 50 m long and recover the true location within 10 seconds (Jetson Xavier). We show that our receiver is secure against stealthy attackers who exploit inertial sensor errors and execute seamless takeover attacks. We design SemperFi as a pluggable module capable of generating a spoofer-free GPS signal for processing on any commercial-off-the-shelf GPS receiver available today. Finally, we release our implementation to the community for usage and further research.
... They have built a testbed for customizable GNSS signal processing, able of permitting signal sources and signal processing algorithms management, guaranteeing systems and output format interoperability. In [18], the authors provide details about a GNSS software receiver implementation able to operate with Galileo E1B and E1C signals. They provide descriptions of the used algorithms that manage signals for navigation acquisition and tracking. ...
Article
Full-text available
Vehicle positioning is becoming an important issue related to Intelligent Transportation Systems (ITSs). Novel vehicles and autonomous vehicles need to be localized under different weather conditions and it is important to have a reliable positioning system to track vehicles. Satellite navigation systems can be a key technology in providing global coverage and providing localization services through many satellite constellations such as GPS, GLONASS, Galileo and so forth. However, the modeling of positioning and localization systems under different weather conditions is not a trivial objective especially considering different factors such as receiver sensitivity, dynamic weather conditions, propagation delay and so forth. This paper focuses on the use of simulators for performing different kinds of tests on Global Navigation Satellite System (GNSS) systems in order to reduce the cost of the positioning testing under different techniques or models. Simulation driven approach, combined with some specific hardware equipment such as receivers and transmitters can characterize a more realistic scenario and the simulation can consider other aspects that could be complex to really test. In this work, the main contribution is the introduction of the Troposphere Collins model in a GNSS simulator for VANET applications, the GPS-SDR-SIM software. The use of the Collins model in the simulator allows to improve the accuracy of the simulation experiments throughout the reduction of the receiver errors.
Article
Full-text available
As the security of global navigation satellite systems (GNSSs) for civilian usage is increasingly important, navigation message authentication (NMA) significantly improves resilience to spoofing attacks. However, not all attacks can be effectively countered: a strong variant of replay/relay attacks, distance-decreasing (DD) attacks, can shorten pseudorange measurements, without manipulating the cryptographically protected navigation message, thus manipulating the position, velocity, and time solution undetected. First, we discuss how DD attacks can tamper with GNSS signals, demonstrating the attack effectiveness on a recorded Galileo signal. DD attacks might introduce bit errors to the forged signals, but the adversary can keep this error rate very low with proper attack parameter settings. Then, based on our mathematical model of the prompt correlator output of the tracking phase at the victim receiver, we find that the correlator output distribution changes in the presence of DD attacks. This leads us to apply hypothesis testing to detect DD attacks, notably a goodness-of-fit (GoF) test and a generalized likelihood ratio test (GLRT), depending on the victim’s knowledge on the DD attacks. Monte Carlo simulations are used to evaluate the detection probability and the receiver operating characteristic curves for two tests, for different adversary configuration and noise settings. Then, we evaluate the effectiveness of the GoF test and the GLRT with a synthesized DD signal. Both tests can detect DD attacks with similar performance in high-signal-to-noise-ratio (SNR) environments. The GLRT detection probability is approximately 20% higher than that of the GoF test in low-SNR environments.
Article
Full-text available
The subject of this article are issues related to the navigation system in the field of analyzing the processed signal in the GNSS system receiver. The main purpose of the work is to discuss the Galileo E1 signal processing methods in the GNSS navigation system receiver, supported by adapted research tools in terms of solving the research problem (analysis, model, simulation tests) and the mathematical apparatus used. Key studies are concentrated around the process of generating the navigation data, dispersing sequences and signal modulation. Thus, when designing a receiver, it is better to use the simulation signals than the real ones, since one can get more control over the properties of the received signal. In the final part of the work, in accordance with the subject of research, based on the developed appropriate research tools, observations and final conclusions were formulated, which have practical applications.
Article
Full-text available
The majority of 3G mobile phones have an integrated GPS chip enabling them to calculate a navigation solution. But to deliver continuous and accurate location information, the satellite tracking process has to be stable and reliable. This is still challenging, for example, in heavy multipath and non-line of sight (NLOS) environments. New families of Galileo and GPS navigation signals, such as Alternate Binary Offset Carrier (AltBOC), Composite Binary Offset Carrier (CBOC), and Time-Multiplex Binary Offset Carrier (TMBOC), will bring potential improvements in the pseudorange calculation, including more signal power, better multipath mitigation capabilities, and overall more robust navigation. However, GNSS signal tracking strategies have to be more advanced in order to profit from the enhanced properties of the new signals.In this paper, a tracking algorithm designed for Galileo E1 CBOC signal that consists of two steps, coarse and fine, with different tracking parameters in each step, is presented and analyzed with respect to tracking accuracy, sensitivity and robustness. The aim of this paper is therefore to provide a full theoretical analysis of the proposed two-step tracking algorithm for Galileo E1 CBOC signals, as well as to confirm the results through simulations as well as using real Galileo satellite data.
Conference Paper
Full-text available
This paper introduces GNSS-SDR, an open source Global Navigation Satellite System software-defined receiver. The lack of reconfigurability of current commercial-of-the-shelf receivers and the advent of new radionavigation signals and systems make software receivers an appealing approach to design new architectures and signal processing algorithms. With the aim of exploring the full potential of this forthcoming scenario with a plurality of new signal structures and frequency bands available for positioning, this paper describes the software architecture design and provides details about its implementation, targeting a multiband, multisystem GNSS receiver. The result is a testbed for GNSS signal processing that allows any kind of customization, including interchangeability of signal sources, signal processing algorithms, interoperability with other systems, output formats, and the offering of interfaces to all the intermediate signals, parameters and variables. The source code release under the GNU General Public License (GPL) secures practical usability, inspection, and continuous improvement by the research community, allowing the discussion based on tangible code and the analysis of results obtained with real signals. The source code is complemented by a development ecosystem, consisting of a web-site (http://gnss-sdr.org), as well as a revision control system, instructions for users and developers, and communication tools.
Article
Full-text available
The aim of this paper is to provide guidelines for developing high–quality, well–written GNSS software receivers. The systematic application of software design patterns and programming methodologies speeds up the development process by providing tested, proven devel-opment paradigms, and improved code readability for coders, receiver architects, and users. This includes unit testing of all the modules, and the use of a code programming style stressing readability and language-specific conventions. All these good practices result in fewer bugs, reduce reinvention–of–the–wheel, and cut long–term maintenance costs. The paper provides an analysis of design patters, good coding practices, and methodologies for the design and implementation of GNSS software receivers, describing a working implementation released under the GNU General Public License.
Article
Full-text available
Galileo is the Global Navigation Satellite System that Europe is building and it is planned to be operational in the next 3-5 years. Several Galileo signals use split-spectrum modulations, such as Composite Binary Offset Carrier (CBOC) modulation, which create correlation ambiguities when processed with large or infinite front-end bandwidths (i.e., in wideband receivers). The correlation ambiguities refer to the notches in the correlation shape (i.e., in the envelope of the correlation between incoming signal and reference modulated code) which happen within +/– 1 chip from the main peak. These correlation ambiguities affect adversely the detection probabilities in the code acquisition process and are usually dealt with by using some form of unambiguous processing (e.g., BPSK-like techniques, sideband processing, etc.). In some applications, such as mass-market applications, a narrowband Galileo receiver (i.e., with considerable front-end bandwidth limitation) is likely to be employed. The question addressed in this paper, which has not been an-swered before, is whether or not this bandwidth limitation can cope inherently with the ambiguities of the correlation function, to which extent, and which the best design options are in the acquisition process (e.g., in terms of time-bin step and ambiguity mitigation mechanisms).
Article
Full-text available
The performances of several signal-to-noise ratio (SNR) estimation techniques reported in the literature are compared to identify the "best" estimator. The SNR estimators are investigated by the computer simulation of baseband binary phase-shift keying (PSK) signals in real additive white Gaussian noise (AWGN) and baseband 8-PSK signals in complex AWGN. The mean square error is used as a measure of performance. In addition to comparing the relative performances, the absolute levels of performance are also established; the simulated performances are compared to a published Cramer-Rao bound (CRB) for real AWGN, and a CRB for complex AWGN that is derived here. Some know estimator structures are modified to perform better on the channel of interest. Estimator structures for both real and complex channels are examined.
Article
Full-text available
The performances of several signal-to noise ratio (SNR) estimation techniques reported in the literature are compared to identify the "best" estimator. The SNR estimators are investigated by the computer simulation of baseband binary phase-shift keying (PSK) signals in real additive white Gaussian noise (AWGN) and baseband 8-PSK signals in complex AWGN. The mean square error is used as a measure of performance. In addition to comparing the relative performances, the absolute levels of performance are also established; the simulated performances are compared to a published Cramer-Rao bound (CRB) for real AWGN and a CRB for complex AWGN that is derived here. Some known estimator structures are modified to perform better on the channel of interest. Estimator structures for both real and complex channels are examined.
Article
FFTW is an implementation of the discrete Fourier transform (DFT) that adapts to the hardware in order to maximize performance. This paper shows that such an approach can yield an implementation that is competitive with hand-optimized libraries, and describes the software structure that makes our current FFTW3 version flexible and adaptive. We further discuss a new algorithm for real-data DFTs of prime size, a new way of implementing DFTs by means of machine-specific single-instruction, multiple-data (SIMD) instructions, and how a special-purpose compiler can derive optimized implementations of the discrete cosine and sine transforms automatically from a DFT algorithm.