A GNSS Software Receiver for Governmental

Applications
R. Capua, A. Bottaro, Sogei

BIOGRAPHIES
Roberto Capua is responsible for GNSS R&D activity at
Sogei S.p.A. He worked in several EC Framework
Projects tasks for Galileo applications and serves as a
delegate to the Galileo Services consortium. His areas of
activity are: advanced high-accuracy GNSS and
Augmentation systems, GNSS SDR development and
GNSS surveying.
Antonio Bottaro is currently the Head of Innovation,
Research and Development within Sogei S.p.A. His main
area of activity concerns Advanced GIS and GNSS
platforms Design and Development.
ABSTRACT
The paper presents the work of the Sogei GNSS R&D
Group for the development of a GNSS SDR receiver for
institutional applications.

The Parallel Search Acquisition provides results in about

300 ms for 32 GPS and 4 SBAS channels, using FFT and
zero-padding. Code matching ambiguities are avoided.
Tracking loop works on bit-parallelized samples through
a second order PLL and a first order FLL. Correlation is
performed using logical tables, while a Dot product DLL
discriminator is used. The Tracking processes 1s of
samples in less than 50 ms per channel. PVT is
implemented through an Extended Kalman Filter and
outputs NMEA.
A DSP GNSS SDR, developed for achieving high
performance processing, provides results comparable to
the PC platform.
At the end of the First Phase of the Project, the GNSS
SDR receiver implements Real-Time GPS, GIOVE-A/B
and SBAS Acquisition and Tracking, with an accuracy of
5 m.

Target applications are high accuracy GNSS Surveying

for Land Registry, Customs Border Control and Tracing
and Tracking.

The Second Phase will implement a Multi-Carrier/MultiConstellation Code/Phase SDR receiver based on MultiCore programming, including Hybridization with external
sensors and indoor positioning capabilities.

The objective of the project is to build a Real-Time GNSS

SDR receiver running on a Notebook, based on COTS
and internal developed source code.

INTRODUCTION

The GNSS SDR receiver is composed by an RF FrontEnd and four software modules: Data Dispatcher,
Acquisition, Tracking and PVT. The Software has been
written in C++, using SIMD primitives. Communication
is performed through TCP/IP sockets. Look-Up tables are
used for Code and Carrier replicas and logic operations.
The RF Front-End was developed using a reconfigurable
commercial IC sampler and is connected to the Notebook
through USB. IF is 1.023 MHz and undersampling is
performed at 4.092 MHz. A Data Dispatcher spools
samples to the processing modules.

During the 2014-2020 timeframe, GNSS applications will

face a revolution due to the introduction of new
frequencies and the full deployment of Galileo, the
GLONASS-K CDMA signal and incoming satellite
navigation constellations.
From the application side, this will imply the need to
upgrade receivers for being able to use new available
signals in space.
Such kind of revolution will impact in a significant way
on application developers and users costs. In particular,
such impact will be significant for high demanding
applications, characterized by high receivers costs.

Governmental applications are often requiring high

performances (high accuracy, high reliability and high
continuity, security), while needing Open and
customizable technologies. Such technologies should be
also able to incorporate legacy systems and proprietary
data formats, in order to facilitate their introduction with
minimal impact on well consolidated workflows and
regulation frameworks.
Applications of interest for the present work are Land
Administration and Land Registry/Cadastral Maps
updating through high precision GNSS surveying, Border
Controls and Dangerous Goods Tracing and Tracking for
Customs operations.
High accuracy applications require the installation and
maintenance of extensive GNSS Reference Stations
Networks at national or regional level. Such Reference
Stations are costly in terms of upgrade and maintenance.
On the other hand, Freights management applications for
institutional applications are requiring a high level of
reliability, data security and output customizability.
For such kind of applications, GNSS SDR is one of the
most suitable cutting-edge technologies, due to its
intrinsic flexibility, scalability and openness to the
integration of new signal waveforms.
Sogei, the IT Company of the Ministry of Economy and
Finance of Italy, started in 2008 a Project intended to
develop a GNSS SDR receiver for high demanding
applications. Sogei is currently managing the Italian
Cadastral Maps updating system and operating GRDNet,
a VRS Reference Stations Network in the centre of Italy
for Land Surveying activities. Sogei is also a member of
the international Galileo Services Consortium, a nonprofit organization devoted to GNSS downstream market
development.
A First Phase of the Project is intended to develop a
single frequency, code only SDR GPS/EGNOS rover
receiver for Tracing and Tracking applications. The
Second Phase will develop a multi-carrier/multiconstellation Code and Phase SDR receiver to be used for
high accuracy applications. The project is currently at the
end of the First Phase. A first version of Real-Time SDR
receiver has been currently delivered and will be
discussed in the following.
Main requirements are the following:
Use of Low Cost and commercial devices
Flexibility, scalability and easy upgradeability
Backward compatibility (integration within
existing legacy systems)
Independence from single manufactures
Customizability

Security
Standard data format and Openness

DESIGN AND DEVELOPMENT METHODOLOGY

The main driver coming from the requirements is to
develop a Real-Time GNSS SDR receiver, totally based
on COTS, General Purpose PC and in-house software
developments and to guarantee as much as possible
independence from proprietary software and libraries.
Concerning Hardware equipments, all the design has been
carried out in order to be able to work with different kinds
of Front-Ends and antennas.
We started our developments using a commercial GNSS
Front-End USB dongle. After this preliminary Phase, in
order to be independent from single manufacturers, we
designed and developed our own GNSS Front-End
starting from most flexible commercial IF samplers and
USB interfacing devices.
Concerning Software, we developed source code using
C++ language and working on Windows Operating
Systems. SIMD instructions have been used for FFT and
high computational load tasks implementation. A Cross
Platform (Windows and Linux) version will be released in
the Second Phase. Any proprietary library has been used
for the platform development.
GUIs for Control Panel implementation and plotting have
been implemented using Cross-Platform Open tools (e.g.
wxWidgets). GUI development and running is
intentionally decoupled by the core GNSS SDR modules.
Such choice avoids crashing on GUIs having an impact
on core modules running status.
SDR outputs are formatted using standard NMEA
messages.
For sake of comparison with a state of the art signal
processing hardware, a DSP Platform has been developed,
using a DSP board, using the relevant C Development
builder for compiling, uploading and running the code on
the DSP.

THE ARCHITECTURE
The architecture of the Sogei GNSS-SDR platform is
reported in Fig. 1.
Main architectural components are reported in the
following:

GNSS RF Front-End: composed by a Maxim

MAX2769 GNSS IF sampler, an FTDI
FT2232H USB interface and a Glue Logic
GPSsocket: software module able to grab
samples from the GNSS Front-End FIFO
through the USB (Real-Time processing) or
from a file (Post-Processing), to convert and to
transfer them with the required format to the
ReaderServer through TCP/IP socket
Reader Server: software module able to get data
from GPSsocket and to dispatch them to
Acquisition and Tracking modules
Acquisition: software module for performing
GNSS Acquisition through Parallel Search for
32 GPS, GIOVE-A/B and 4 SBAS channels; it
sends acquired satellite list to PVT for starting
the positioning process and outputs Acquisition
results to the Acquisition GUI
Tracking: software module able to parallelize
samples bits and to perform GPS and SBAS
tracking; it outputs In-Phase samples, code
phases and code length (number of samples for
the current code) to PVT, as well as Tracking
results to the Tracking GUI
PVT: software module able to perform
navigation message decoding, pseudorange and
positioning calculation and NMEA GGA and
GSV messages output to a socket; any NMEA
viewer able to read messages from TCP sockets
can be used for plotting PVT results
NMEA Reader: any NMEA sentences reader
able to plot PVT results

In order to perform correct synchronization among

modules, blocking and non-blocking TCP/IP socket mode
has been opportunely selected for each interface.
Such architecture allows maximum flexibility and
modularity. Sharing of tasks among several processors or
servers is in this way easily achievable.
Receiver operation is started by the PVT module, asking
Acquisition results to the Acquisition Module through the
PVT_MASK_PORT Control Socket. Consequently,
Acquisition results are sent to Tracking module and PVT
through TRACK_PORT and PVT_MASK_PORT
sockets. The Tracking module sends In-Phase output to
PVT packed into 500ms blocks. PVT decodes navigation
message, calculates position and sends positioning
solution to an NMEA reader.
GNSS RF FRONT-END
Since the beginning of the Project, several Front Ends
have been used, working at different IF and sampling
frequencies (e.g. SiGe SE4001L, MAX 2741 and
MAX2769).
A Front-End has been designed and developed using an
FTDI FT232H (Hi-Speed Single Channel USB
UART/FIFO device) for transferring samples data
through USB, the Maxim MAX2769 sampler and relevant
hardware for supplying power to the active antenna. A
hardware Glue Logic has been developed in order to
parallelize data and allow high data rate transfer from
ADC to USB. Due to FTDI FT232H speed limitations,
incoming samples are grouped by nibbles and sent
through two parallel buffering chains in order to decrease
the transferring rate from the ADC.
Several antenna models can be connected to the FrontEnd through relevant connectors and adapters. Both
consumer patches and geodetic antennas have been used
during tests.

Figure 1 - Sogei GNSS Platform System Architecture

Tasks are working in Multi-Thread in order to allow
maximum flexibility in assigning priorities and
concurrency management.
Control and Data channels for the communication among
software modules are implemented through standard
TCP/IP sockets.

Figure 2 - GNSS Front-End Architecture

Sample output format (2-bits/3-bits sign and magnitude or
I/Q samples) as well as IF frequency are configurable.
In order to minimize the number of samples and to reduce
the computational burden, respecting the Sampling

Theorem, the IF is set at 1.023 MHZ with a sampling

frequency of 4.092 MHz for GPS and a 2-bits (1-bit Sign
and 1-bit Magnitude) quantization. Using such
configuration, the number of samples per chip is 4 for the
GPS Signal. The integration of GIOVE A and B with
GPS data processing has been currently tested using an IF
of 2.046 MHz and a sampling frequency of 8.184 MHz.
Further developments are currently going on for working
at lower sampling frequencies (e.g. at baseband).
The used quantization levels are { 1, 3, -1 ,-3 } for 2-bit
and { 1, 5, -1, -5, 3, 7, -3, -7} for 3-bit output formats.
Samples stream is read through the USB interface (FTDI
driver), converted to signed chars, buffered through a
circular buffer with FIFO logic and sent to a TCP/IP
blocking Server Socket.
In order to assure Real-Time processing of data, proper
sizing of buffers is fundamental. In our architecture, the
output FIFO of the GPSsocket module has been
opportunely sized to 16MB. The Front-End Output rate
(4.092 MBps) is always less than the USB Maximum
Rate (480 MBps), while the Data Reader rate is
sufficiently high (about 8 MBps, as demonstrated during
the performance test) and allows avoiding GPSsocket
FIFO buffer filling. Using such configuration, a
maximum FIFO filling level of 2% is achieved. The Data
Reader input buffer filling is avoided through a sizing of
about 40 MB.
ACQUISITION PHASE
GPS and SBAS satellite acquisition is performed through
Parallel Code Phase Search. It has been implemented in
two stages. A first Coarse Acquisition phase is performed
with a Doppler range of +/-5000 Hz and a frequency step
of 500 Hz. In order to refine Doppler estimate, a second
Fine Acquisition, around the bin found during the Coarse
Acquisition, is therefore performed, with steps of 50 Hz
for frequency and 1 Code length for Code phase.

avoiding partial code matching peaks ([R1], [R2]). The

length of sequences is therefore the smallest power of two
above 2N-1:

N1 = min(2n ) 2 N 1 (1)
being n an integer. Input data are one code length streams
pre-treated through zero-padding with N1-N zeros. A
double-length code replica is generated using two N
sequences, and filling N1-2N zeros between two single
Code replicas. If circular correlation is restricted to the
first N shifts, the resulting peak is unique.
A scaling pattern analysis has been carried out and most
appropriate scaling factors for fixed point operation have
been selected, both for Code and Carrier samples.
In order to get a robust acquisition over time and to avoid
false acquisition, a double validation on results is
performed for Coarse and Fine Acquisition. In the first
case the classical maximum peak to second peak ratio test
is used, while in the second case the maximum peak is
compared to the mean noise level.
Due to the high computational load of FFT, weak-signals
correlation on longer data sets is not feasible. Therefore,
weak-signals Acquisition is performed at start-up through
a Non-Coherent integration on 10 ms of input data.
In Figure 3 the flowchart of the robust acquisition
algorithm is reported.
Due to the tight time constraints imposed by SDR, time
consuming Cold Start has to be avoided as much as
possible.
At this aim, Warm Start for GPS is performed by a
preliminary ephemeris determination through Almanac
parsing.

Sine and cosine Look-Up Tables and FFT code replicas

are generated off-line and loaded into the cache memory
at start-up.

In order to reduce the computational burden, periodic ReAcquisition after Tracking Pull-In is selectively
performed per channel every 60 s only on new raising
satellites (as derived from the Almanac) or due to a Loss
of Lock signaled by the Tracking Module.

High computational tasks like Circular FFT correlation

and multiplications are performed using SIMD (MMX
and SSE) instructions.

Following such approach, the average number of

GPS+SBAS channels to be acquired at each step is less
than 5.

Code Replicas are stored using a data structure containing

interleaved Real and Imaginary samples. Such kind of
data structure allows a very efficient access to single
samples and easy SIMD operations implementation.

Further reduction of computational load has been

achieved exploiting task parallelism at channel acquisition
level Multi-Core capability. At this aim, single channels
Acquisitions have been parallelized using the CrossPlatform OpenMP Parallel Programming API.

In order to get maximum FFT performances, DoubleLength Zero-Padding to power of two has been used for

Start acquisition
i=0

Visible sat &&

not tracked?

Prompt and Early-Minus-Late Code Look-Up tables are

generated off-line for 32 Code phase steps. Such tables
are oversampled, due to the fact that the sampling
frequency is higher than the chip rate. Code Doppler is
assumed to be zero in the Code-Look-Up table. The
expected correlation loss due to the unresolved Doppler
shift can be evaluated as ([R7]):

Satellite already
acquired?
N

Correlation S/N ratio >

WEAK_STRONG_THRE
SHOLD ?

sin(fT )

SNR = 10 log
fT

10ms Coarse
weak-signals
acquisition

1ms Coarse
acquisition

Acquisition success?

(2)

Taking into account that T=Nbit/fs, where Nbit = 32 and

fs=4.092 MHz in our case, the expected Power Loss is
negligible (0.087 dB for a Doppler shift less than 10
KHz).

Correlation S/N ratio >

WEAK_STRONG_THRE
SHOLD ?

10ms Fine
weak-signals
acquisition

1ms Fine
acquisition

Acquisition success?

Y
Save results (Code phase,
Doppler, Max peak)

i=i+1

A double length code replica is implemented. The 32 code

phases are selected in order to find the right trade-off
between storage occupation and maximum achievable
pseudorange measurement precision introduced by the
relevant digitalization levels. The maximum pseudorange
measurement error, corresponding to half of the possible
pseudorange resolution, is 1.14 m. Code samples are
represented using a single bit representation. Code LookUp table, storing Code Prompt and Early-Minus-Late
samples for each of 32 phases, has a total size of 9.3 MB.
Using such approach, it is always possible to select the
correct Code replica for each channel by simply moving
the pointer within the Code Look-Up table data structure.
The logic of code replica selection is reported in Figure 4.

i < TOTAL_CHANNELS ?

Channel i

Wait for next

acquisition period

Figure 3 - Robust Acquisition Flowchart

2 CA code samples

Word 0

Code shift 0

TRACKING PHASE

Word 255

Phase 0

Code shift k

Word k

Phase j

Word k+128

Code Replica selection

Tracking Loop is implemented by default through a

second order PLL and a first order FLL. A third-order
PLL can be activated on request.
In order to save computational resources, the FLL is
selectively activated at start-up or after a loss of lock and
switched off after a positive test on phase error variance.

Phase 31

32 bit word

1 chip = 4 samples
fs= 4.092 MHz

Figure 4 - Code replica selection

In order to improve performances through data
parallelism, raw samples are packet in two words of 32
Sign and 32 Magnitude bits. Using such data format, it is
possible to implement very efficient Code correlation and
Carrier mixing using only XOR processor logical
operations.

Sine and Cosine Intermediate Frequency Look-Up tables

for carrier wipe-off are generated with /8 phase steps and
175 Hz frequency steps. Carrier levels are represented by
2 bits (Sign and Magnitude).

Sine and Cosine Carrier Look-Up tables occupation is

totally 10.9 MB.
The expected C/N0 degradation due to frequency errors
induced by the frequency quantization in the sine and
cosine Look-Up tables can be evaluated using equation
(2), where f is the frequency step and T is the 1 ms code
period. In our case, the expected C/N0 degradation is 0.44
dB.
Carrier wipe-off and Code mixing is performed through
XOR between the 32-bit words input signal and Code and
Carrier Look Up tables. XOR results are mapped to
predefined logical levels and stored into related words,
containing ones if the mixing results provides the
assigned logic level and zeros otherwise.
Following the above representation, Accumulation and
Dump for In-Phase and In-Quadrature output calculation
can be implemented counting the number of ones
contained in the words representing code mixing results.
Such operation is easily implemented using precomputed
look-up tables, mapping all possible combinations of
zeros and ones contained in each word to the relevant sum
of ones.

Tracking is performed starting from samples sent by the

Acquisition to the TRACK_PORT socket and by the
Reader Server to the READER_PORT socket. Each
parallel tracking channel has to read different size of data
blocks at different times. Therefore, a raw data dispatcher
has been implemented. It is able to manage a common
buffer in order to feed all parallel tracking channels for
the tracking loop implementation. The dispatcher logic is
the following. Let us define the following arrays:
O = { O0, O1, , ON-1 }
L = { L0, L2, , LN-1 }
where O is the array of the offsets to be applied to each of
the N channels for reading the common buffer, while L is
the array of data block sizes (current Code length
expressed in number of samples) of each channel. Bytes
to drop in the common buffer, due to the fact that they
have already read by any channel, are:
bytesToDrop = Omin + Lmin
Therefore the new offset to be applied for reading the
buffer for the channel i will be:
Oi +Li-bytesTodrop

In order to guarantee maximum efficiency, such

operations are performed by SIMD instructions working
on 32-bits data words.
In order to minimize the number of needed correlators,
normalized Dot product DLL discriminator is used ([R6])
for Code tracking:

Dcode =

I EL I P + QELQP
2( I P 2 + QP 2 )

(3)

where IEL, QEL, IP and QP are the accumulator outputs.

Such approach allows generating an unbiased
discriminator, while reducing the Integration & Dump
channels from 6 to 4, due to the use of Early-minus-Late
instead of separate Early and Late replicas.
Costas loop discriminator is implemented through the
classical atan(QP/IP).
Very fine frequency estimation is fundamental for SDR
tracking. Therefore, the optimal atan2 Frequency Lock
Loop discriminator ([R5]) has been implemented. Its
significant computational load is compensated by the fact
that FLL is switched off as soon as PLL error variance
goes below a configurable threshold (0.01 by default).
Lock detection at Pull-In is performed through phaseerror check, while usual C/N0 check is used after Pull-In.

Using such algorithm, each channel can crop blocks of

data samples with the needed size and phases from the
same common data dispatcher buffer.
At Tracking Loop starting, acquisition results (Code
phases and Doppler shifts) are propagated in time to the
Tracking starting time using the following expression
([R3]):

f
CP(t ) = mod CP (0) + bs 0.001 p (t ) d (t ) s + 0.5, bs ( 4)

fc

where CP(t) and CP(0) are the code phase at current

tracking period and at the beginning Acquisition period
respectively, f s is the sampling rate, f c is the chipping
rate and bs is the nominal code length in number of
samples (e.g. 4092 for an f s of 4.092 MHz for GPS).
Code length is variable at each integration period for each
channel due to different Doppler shifts or sampling
frequency being not an exact multiple of the code rate. In
order to use the correct code length, samples per code are
usually real-time estimated in hardware receivers. This is
fundamental for pseudorange determination. An error of
one sample can indeed lead to a pseudorange error of 73
m using a sampling rate of 4.092 MHz. In our SDR
implementation, Code length estimation is performed at
each integration step.

Tracking results for each channel are buffered in an

appropriate data structure for 500 integration times and
sent to PVT through TO_PVT_PORT every 500 ms.
An optimized data structure has been designed in order to
send to the PVT non redundant information.
Pseudoranges are calculates summing up initial Code
Phases and accumulating relevant Code lengths during the
500 ms period, while the number of samples in a code
(e.g. the Code length) can differ over milliseconds only
by a few units. Therefore, only the difference with respect
to the nominal size (e.g. 16368 for Sige or 4092 samples
for MAX2769 in our case) is relevant in order to
reconstruct the accumulated absolute samples for
pseudorange calculation.
Data structure sent by the Tracking loop to PVT for each
visible satellite is reported in Table 1.
Table 1 - Tracking to PVT interfacing data content
Data field
Description
Data type
PRN
PRN number
int
I_P
In-Phase Samples
double
blksizeFlag
Current difference int
of Code length
with respect to
nominal
Code
length
CodePhase
Estimated
Code int
Phase
A reduced set of information is sent to the Tracking GUI
for real-time Tracking results plotting.

PVT PHASE
PVT
performs
Navigation
message
decoding,
pseudorange calculation, clock offset, drift and position
estimation. It works using an All-In-View approach.
As well known, in SDR architectures, sample data have
no absolute time reference and the only timing is provided
by the count of the progressing number of samples.
Therefore, the pseudorange measurement can be
calculated only in a relative way. We can start searching
the first available subframe for each channel by means of
preamble search. Therefore, we can take the difference of
the counted number of samples between the detected
Subframe start of each channel with respect to a reference
one. Such difference has to be converted into difference
of time [R3].
Navigation messages are transmitted at the same time by
each satellite, but they are received at different times due
to different satellite-receiver distances. We can take as
reference satellite the one having the earlier Subframe

start. The relative pseudorange for satellite i can be

expressed in the following way:

i = c(b + tti ts min ) (5)

where c is the velocity of light, b is a bias of 68 ms
(taking into account that the travel time between a GPS
satellite and the Earth ranges is in the 67-86 ms range),
able to assure that all relative pseudoranges calculated in
this way are positive, tti is the travel time derived by the
number of samples elapsed till Subframe starts and
represents the travel time of the reference satellite.

ts min

PVT starts requesting data to the tracking port. After such

request, it receives the Acquisition results from the
Acquisition module and waits for tracking results.
Tracking results are elaborated for allowing PVT
calculation with 2 Hz rate.
Therefore, sample data are accumulated with the correct
code length derived from tracking results messages. In
order to perform Frame Synchronization, a preamble
search is run for all the tracked channels. As soon as all
Subframe starts are identified, relative pseudoranges are
calculated, taking into account the time elapsed for
preambles search.
Particular attention has to be put on avoiding overflows
during samples data accumulation and counting. At this
aim, without loss of information, the absolute samples
modulo one Code length are used for pseudorange
calculation ([R3]).
A discrete Extended Kalman Filter is used for positioning,
including receiver clock bias and drift estimation. Due to
the fact that in the First Phase of the Project, only static
positioning is of interest, velocity is not directly
estimated. The following state vector is defined:

x = [x

z | b

f ]T

where x, y and z are the errors on Cartesian coordinates of

the receiver, b and f are the receiver code offset and drift
estimation errors, while the classical discrete-time model
is used:
xk +1 = k xk + wk , wk ~ N (0, Q k )
yk = H k xk 1 + vk , vk ~ N(0, R k )

0
I |
k =

| 1 t
0

| 0 1


Q pk
Qk =

|
Qck
|

Concerning Acquisition, the GNSS SDR platform is able

to acquire GPS, SBAS and GIOVE-A/GIOVE-B
satellites, as reported in Figure 5. In order to test
Acquisition results, warm start and re-acquisition with 60
s rate have been carried out. The test reported a stable
acquisition for the visible satellites all over the testing
time frame for strong and weak signal.

S t + S f t 3 / 2 S f t 2 / 2
Qck = b

2
S f t
S f t / 2
where t is the step time, k , k 1 is the transition matrix,
Qk and Rk are the process and measurement noise
covariance matrix and Sb = 8 2 h 2 and S f = 2h0 are the
spectral densities related to the Allan variance parameters
([R8]). Process noise covariance matrix has been
initialized based on commercial clocks nominal values
(e.g. [R9]) and carrying out a tuning phase. Reference
values in the order of 2*10-10 for random walk frequency
noise (h-2) and 2*10-11 for white frequency noise (h0) has
been used for the available clock.
The Clock model has been tuned taking into account the
frequency specifications of single TCXOs used by
different available samplers. The non integer nature of the
reference frequency of some of the used samplers leaded
to the necessity to perform a dedicated modeling able to
overcome rounding problems for pseudorange calculation.
Before applying Kalman Filter update, pseudorange
measurements are firstly corrected by the estimation of
satellite clock errors, earth rotation, troposphere, and
relativistic effects. Klobuchar Ionospheric model can be
applied on request.
PVT waits for connection on the receiver output socket
from any available external NMEA Reader. Once
connected, the NMEA reader can read and plot
positioning results using RMC and GGA as well as
visible satellites through GSV sentences.

RESULTS AND PERFORMANCES

The Sogei GNSS SDR receiver has been tested on a
Notebook equipped with an i7 Processor and 4GB RAM.
No RTOS has been used, but a commercial Windows 7
Operating System.

Figure 5 - GPS, GIOVE-A and EGNOS Acquisition

As NMEA reader and plotter, the Open Source tool

RTKLib was used.

Tracking results showed nominal performances, as

reported in Figure 6. Thanks to the Fine Acquisition, the
Pull-in phase is in the range of 50-125 ms.

A comprehensive test has been performed over different

sessions of 1 hour in a day in order to verify single
modules performances and robustness.

FLL is activated at start-up and under low C/N0

conditions, while it is switched off most of the time. In

Errors (m)

Figure 7, FLL activation for a weak signal satellite is

showed.

Time

Figure 8 - Position estimation errors

Initial Warm-Start Acquisition is performed in about 300
ms for an average of 10 satellites, using both Coarse and
Fine Acquisition, while acquisition time due to satellite
loss of lock or new raising satellites is negligible.
At steady state (first Acquisition performed, no new
satellites), Tracking is performed in about 50 ms per
channel, leading to about 500 ms for 10 channels, while
PVT tasks (pseudorange calculation and navigation
solution determination, excluding initial navigation
message decoding) are performed in about 10 ms every
500 ms. Such timing leads to a nominal processing time
for 1 s of samples of about 520 ms, assuring Real-Time
performances.

Figure 6 - In-Phase and In-Quadrature Tracking

outputs

As reported in Figure 9, CPUs load ranges at average

between 10% and 15%. The initial 25% occupation is due
to the heavy (Coarse and Fine Acquisition for all visible
satellites) first Acquisition. As can be seen, periodic reacquisition does not significantly impact on the CPU
Load.
Total CPU Load percentage
35
30

CPU Load (%)

25
20
15
10
5

20:04:39.330

20:04:04.323

20:03:29.332

20:02:54.326

20:02:19.319

20:01:44.329

20:01:09.322

20:00:34.331

19:59:59.325

19:59:24.318

19:58:49.328

19:58:14.321

19:57:39.330

19:57:04.324

19:56:29.333

19:55:54.326

19:55:19.320

19:54:44.329

19:54:09.323

19:53:34.332

19:52:59.325

19:52:24.319

19:51:49.328

19:51:14.322

19:50:39.331

19:50:04.324

19:49:29.333

19:48:54.327

19:48:19.320

19:47:44.330

19:47:09.323

19:46:34.332

Time

Figure 9 - CPU load analysis

Figure 7 - FLL switch-on/switch-off
Concerning timing, in the following, we consider timing
performance for processing (Acquisition, Tracking and
PVT) 1 s of data.
PVT position estimate error with respect to a known
point, after 20 minute continuous working, is less than 5
m horizontal and 10 m in height, as reported in Figure 8.

In order to perform a comparison of the developed PC

based SDR with respect to state of the art Signal
Processing equipments, a platform has been built up
based on a TMS320DM6446 DSP system-on-chip and a
TMS320C64+ DSP Core. The software development has
been carried out through a porting of modules from PC
based C language to the Texas Instrument Code
Composer Studio development suite. Source Code
without bit parallelization for the Tracking Phase has been
used.

A great effort has been spent on data types selection and

data structures optimization, Software Code and Look-Up
tables upload and storing on the DSP. L1 and L2 level
Chaces have been used as swapping memory, leading to a
great performance improvement, with respect to the use
of external 128 MB RAM. Optimized C64 SIMD
multiply instructions has been used for fastening
operations.

The intention of the Project, during the Second Phase, is

to perform a Pilot Project for testing the chance to use
SDR receivers for GNSS Surveying.

The DSP platform showed performance results

comparable with the PC based platform. The acquisition
for 32 satellites is performed in about 500ms, while the
Tracking Phase is carried out in 300 ms per channel per 1
s of raw data. Such comparison will be further carried out
in the future, using state of the art DSP modules.

A prototype rover receiver will be also developed, able to

implement RTK positioning using RTCM corrections
generated by the SDR Reference Station and to produce
results using the data format required by the Italian Land
Administration.

GOVERNMENTAL APPLICATIONS
A GNSS SDR receiver based on General Purpose
Processors and Programming Languages meets many of
the fundamental requirements of governmental users.
GNSS SDR can be fruitfully used in some applications
requiring high volumes and high equipment turnover due
to rapidly changing technologies.
Within such framework, two applications of interest for
our developments are:
GNSS Augmentation Networks and High
Accuracy (Cadastral Land Surveying)
Institutional Fleet Management (Customs
operations)
Concerning GNSS Networks development, having the
possibility to perform Network densifications through
SDR Reference Stations will provide high benefits in
terms of hardware, licensing and maintenance costs, as
well as upgradeability. Such issues are indeed the lacking
factors for the introduction of wide spread high accuracy
applications.
On the other hand, Land Surveyors are requiring high
reliability, customizability and low/medium cost for rover
receiver. Such kind of objectives can be achieved using an
SDR Multifrequency, Code and Phase receiver. The final
objective should be having a Software rover installed on
their own Notebook or advanced PDA. Data output
format is often an important requirement for such user,
also taking into account the needed input formats of the
Italian Cadastral Maps Updating system. Surveyors has to
produce the results of their measurements using
PREGEO, an institutional software able to elaborate
traditional topographic measurements and GNSS
measurements and to convert the results in a standard
format to be inserted within the Cadastral Mapping
System.

A prototype Reference Station will be inserted within the

GRDNet network. The Reference Station data quality will
be tested, and network adjustment will be performed on a
cluster of stations involving the SDR one.

Concerning Institutional Fleet and Freights Management,

main applications are: Tracing and Tracking of
institutional Fleets, Dangerous Goods monitoring and
deviation from prescribed itineraries, automatic Customs
declarations, pre-trip information and pre-screening.
Such applications require high integrity, reliability and
interoperability with legacy systems. Having a software
receiver to be uploaded on personal notebooks, PDAs or
smartphones will allow Transport Operators to be tracked
with a standardized performance and security level
through a real Software black box. Output format and
protocols able to meet the Italian Information System
AIDA and European Commission directives amending the
Community Customs Code, can be easily implemented
for the transmission of relevant location information from
Transport Operators to Customs Control Offices.
A SDR rover receiver will be implemented at this aim
during the Second Phase and tested using institutional
tools and advanced GIS Tracing and Tracking
applications.
CONCLUSIONS
During the present Project, an SDR GNSS (GPS+SBAS+
GIOVE-A/GIOVE-B) receiver has been developed,
running on a Commercial Quad-Core Notebook,
mounting a General Purpose Processor.
GNSS SDR showed a high level of compliance with
Governmental applications requirements in terms of
Openness, Flexibility and Low cost. Identified target
applications are GNSS Land Surveying for Land Registry
and Cadastral maps updating and Institutional Fleet
Management.
The software has been entirely developed using C/C++
Language and SIMD instructions.

A Front-End has been developed using COTS and

commercial samplers. A Glue Logic has been
implemented in order to overcome data rates limitations.
Code and Carrier Look Up tables are calculated and used
for efficient signal processing.
A robust acquisition has been developed, using Parallel
Code Search, implemented by FFT based on SIMD
instructions. While the first Warm start Acquisition is
performed in about 300 ms, following Acquisitions are
performed only on raising or lost satellites, leading to a
negligible computation load.
Tracking loop has been implemented using a second order
PLL and a First order FLL, activated at start-up and after
a Loss of Lock. Code correlation, accumulation and dump
are very efficiently performed through logical operations
on the data bit stream.
PVT has been based on and Extended Kalman Filter, able
to make available a positioning error less than 5 m
horizontal and 10 m in altitude.
A Performance test has been carried out on an i7
QuadCore processor. Real-Time capability has been
demonstrated, showing the possibility to process 1 s of
sample data for 10 channels in about 520 ms. Total CPU
load is below 15 % after the first Acquisition.
ACKNOWLEDGMENTS
The authors acknowledge the essential work performed
by L. Gattuso and M. Innocenti (University of Tor
Vergata) for software development as well as F. Frittella
(Sogei) and C. DAmico (Sogei) for the design and
development of the GNSS Front-End and relevant
software interfaces.
REFERENCES
[R1] New Fast GPS Code-Acquisition technique using
FFT, Van Nee, D.J.R., Coenen, A.J.R.M., IET Electronic
Letters
[R2] FFT Acquisition of Periodic, Aperiodic, Puncture,
and Overlaid Code Sequences in GPS, C. Yang, IONGPS 2001
[R3] Fundamentals of Global Positioning System
Receiver, J. Bao-Yen Tsui, Wiley
[R4] A Software-Defined GPS and Galileo Receiver K.
Borre, D.M. Akos, N. Bertelsen, P. Rinder, S. H. Jensen
[R5] Understanding GPS - Principles and Applications, E.
D. Kaplan, C. J. Hegarty, Artech House
[R6] Design of Galileo L1F Receiver Tracking Loops, O.
Julien, PhD thesis, Department of Geomatics
Engineering, University of Calgary

[R7]
CDMA
Principle of
Spread
Spectrum
Communication, A. J. Viterbi, Addison-Wesley
[R8] Global Positioning System Theory and
Applications, B. W. Parkinson, J.J. Spilker Jr, American
Institute of Aereonautics and Astronautics
[R9] Estimating Oscillator Stability in the time domain
using standalone GPS, ENGO 699.58R, University of
Calgary, M. Petovello