Content uploaded by Carles Fernández-Prades
Author content
All content in this area was uploaded by Carles Fernández-Prades
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(t−lT
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
N−1
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(t−lT
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[n−mT
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[n−mT
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
N−1
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
(τ)
dτ
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 REAL–LIFE 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
k−1
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
k−1
n
f
IN
+mod
(
ˆ
φ
k−1
,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
=
ˆ
φ
k−1
+ 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
k−i
|
2
, and
ˆ
P
tot
=
1
U
P
U −1
i=0
|P
k−i
|
2
.
13: Phase lock indicator:
T
carrier
=
P
U −1
i=0
P
I
k−i
2
−
P
U −1
i=0
P
Q
k−i
2
P
U −1
i=0
P
I
k−i
2
+
P
U −1
i=0
P
Q
k−i
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.