Witch Navigator -- a Low Cost Software Receiver receivers to complex multi-GNSS-system,...

10
1 Witch Navigator – a Low Cost Software Receiver for Education and Research Pavel Kovar, Petr Kacmarik, Ondrej Jakubov, Frantisek Vejrazka [email protected], [email protected] Czech Technical University in Prague, Faculty of Electrical Engineering Prague 166 27, Czech Republic Abstract—The Witch Navigator is a low cost software receiver developed at the Czech Technical University for education and research purposes. The receiver is designed universally for various missions from simple single frequency GPS L1 C/A receivers to complex multi-GNSS-system, multi-frequency and multi-antenna receiver. The Witch Navigator receiver is designed as an ExpessCard periphery for a notebook or a PC. The cards can be mutually interconnected to the large system. The Witch Navigator is equipped with a powerful FPGA capable to run GNSS correlators (traditional receiver concept) or to send GNSS signal samples to the PC for entire processing (pure processor GNSS receiver). The universal GNSS correlators tailored for processing of the majority of civil GNSS signals were developed preferentially. The cost of the universality is small implementation losses for some GNSS signals, the receiver user can replace them by specialized correlator for given signal. The current state of the project is as follows: The hardware pro- totype as well as the universal GNSS correlators and the Linux device driver is fully functional. The tracking and acquisition algorithms are finalized and integrated with the PVT. We are working on finalization of the GPS L1 receiver. The GLONASS dual frequency receiver, GPS L2, Galileo E1, E5a, E5b and E5 will follow soon. We will present the Witch Navigator philosophy and concept, receiver applications, hardware and software design as well as preliminary performance of the GPS L1 C/A receiver. We plane to publish the source codes of the PC software, VHDL and the electrical schema of the ExpressCard as an open source. Index Terms—GNSS receiver, software receiver, signal acqui- sition, signal tracking, DLL, PLL, PVT estimation, Real-time Linux I. I NTRODUCTION A software receiver represents up-to-date conception of a receiver implementation. Its popularity grows together with processors computation power since demanding signal pro- cessing algorithms became feasible. Concerning a software GNSS receiver there is no exception. There are several GNSS software receiver projects with several years of history [1], [2]. Such projects are usually undertaken at universities and these receivers are considered as support platforms for research in GNSS: ipexSR [3], NAMURU [4], GSNRx TM [5]. The software receiver key features – config- urability and flexibility – are ideal for research purposes. The software receiver in a strict sense, so called pure processor receiver, is a receiver architecture which has the A/D converter as near as possible to the antenna. Concerning GNSS, the pure processor GNSS receiver has to implement correlators in CPU. Thus, relatively high-rate signals have to be treated by the software. Computation of the correlations is a rather time consuming task and several works are addressed how to implement it effectively. Typical solution on x86 platform is based on utilization of SMID instruction (single instruction, multiple data) [7] or of GPU (graphics processing unit) [6]. In contrast to the pure processor receiver, another typical architecture is based on utilization of a FPGA, where the cor- relators and replica signal generators are implemented. Thus, the FPGA is responsible for signal processing at high sampling frequency and relative slowly varying correlator outputs are treated by software in the CPU. The architecture shows better computational cost than the pure processor receiver, but lost some of its superior variability. At the department of radio engineering, Czech Technical University in Prague, Faculty of Electrical Engineering, we have developed several software GNSS receivers which were intended to support our research activities [8], [9], [10], [11]. All of these projects were based on cooperation between an FPGA and CPU. We have faced several drawback in depen- dence on chosen CPU platform. One of the this, the soft-core processor, hosted in FPGA, suffers from low computational power and lack of available memory. As a consequence, soft- core is not suitable for some advanced algorithm e.g. parallel acquisition based on FFT. On the other hand, utilization of x86 CPU on PC seems ideal since such architecture has enough computational performance and no restriction due to memory. Unfortunately, if just correlators are placed in FPGA (not the entire tracking loops) a problem with latency in communication between the FPGA and CPU arises. The Witch Navigator (WNav) is our latest software GNSS receiver which tries to overcome most of the previous project drawbacks. The WNav receiver is based on classical concep- tion which utilizes CPU and FPGA – in FPGA the correlators are implemented. We rely on x86 CPU since its computation power enables implementation of various kinds of demanding signal processing algorithms. Further, the algorithm can be implemented almost in similar manner as it was developed in a high simulation tool (like Matlab); no additional work to tailor the algorithm to e.g. fix-point arithmetic or memory restriction is needed. Consequently, the time to bring the algorithm to the test under real conditions (with live signal) is

Transcript of Witch Navigator -- a Low Cost Software Receiver receivers to complex multi-GNSS-system,...

Page 1: Witch Navigator -- a Low Cost Software Receiver receivers to complex multi-GNSS-system, multi-frequency and multi-antenna receiver. The Witch Navigator receiver is designed as an ExpessCard

1

Witch Navigator – a Low Cost Software Receiverfor Education and Research

Pavel Kovar, Petr Kacmarik, Ondrej Jakubov, Frantisek [email protected], [email protected]

Czech Technical University in Prague, Faculty of Electrical EngineeringPrague 166 27, Czech Republic

Abstract—The Witch Navigator is a low cost software receiverdeveloped at the Czech Technical University for education andresearch purposes. The receiver is designed universally forvarious missions from simple single frequency GPS L1 C/Areceivers to complex multi-GNSS-system, multi-frequency andmulti-antenna receiver. The Witch Navigator receiver is designedas an ExpessCard periphery for a notebook or a PC. The cardscan be mutually interconnected to the large system. The WitchNavigator is equipped with a powerful FPGA capable to runGNSS correlators (traditional receiver concept) or to send GNSSsignal samples to the PC for entire processing (pure processorGNSS receiver).The universal GNSS correlators tailored for processing of themajority of civil GNSS signals were developed preferentially. Thecost of the universality is small implementation losses for someGNSS signals, the receiver user can replace them by specializedcorrelator for given signal.The current state of the project is as follows: The hardware pro-totype as well as the universal GNSS correlators and the Linuxdevice driver is fully functional. The tracking and acquisitionalgorithms are finalized and integrated with the PVT. We areworking on finalization of the GPS L1 receiver. The GLONASSdual frequency receiver, GPS L2, Galileo E1, E5a, E5b and E5will follow soon.We will present the Witch Navigator philosophy and concept,receiver applications, hardware and software design as well aspreliminary performance of the GPS L1 C/A receiver. We planeto publish the source codes of the PC software, VHDL and theelectrical schema of the ExpressCard as an open source.

Index Terms—GNSS receiver, software receiver, signal acqui-sition, signal tracking, DLL, PLL, PVT estimation, Real-timeLinux

I. INTRODUCTION

A software receiver represents up-to-date conception of areceiver implementation. Its popularity grows together withprocessors computation power since demanding signal pro-cessing algorithms became feasible.Concerning a software GNSS receiver there is no exception.There are several GNSS software receiver projects with severalyears of history [1], [2]. Such projects are usually undertakenat universities and these receivers are considered as supportplatforms for research in GNSS: ipexSR [3], NAMURU [4],GSNRxTM [5]. The software receiver key features – config-urability and flexibility – are ideal for research purposes.The software receiver in a strict sense, so called pure processorreceiver, is a receiver architecture which has the A/D converter

as near as possible to the antenna. Concerning GNSS, thepure processor GNSS receiver has to implement correlatorsin CPU. Thus, relatively high-rate signals have to be treatedby the software. Computation of the correlations is a rathertime consuming task and several works are addressed how toimplement it effectively. Typical solution on x86 platform isbased on utilization of SMID instruction (single instruction,multiple data) [7] or of GPU (graphics processing unit) [6].

In contrast to the pure processor receiver, another typicalarchitecture is based on utilization of a FPGA, where the cor-relators and replica signal generators are implemented. Thus,the FPGA is responsible for signal processing at high samplingfrequency and relative slowly varying correlator outputs aretreated by software in the CPU. The architecture shows bettercomputational cost than the pure processor receiver, but lostsome of its superior variability.

At the department of radio engineering, Czech TechnicalUniversity in Prague, Faculty of Electrical Engineering, wehave developed several software GNSS receivers which wereintended to support our research activities [8], [9], [10], [11].All of these projects were based on cooperation between anFPGA and CPU. We have faced several drawback in depen-dence on chosen CPU platform. One of the this, the soft-coreprocessor, hosted in FPGA, suffers from low computationalpower and lack of available memory. As a consequence, soft-core is not suitable for some advanced algorithm e.g. parallelacquisition based on FFT. On the other hand, utilization ofx86 CPU on PC seems ideal since such architecture hasenough computational performance and no restriction due tomemory. Unfortunately, if just correlators are placed in FPGA(not the entire tracking loops) a problem with latency incommunication between the FPGA and CPU arises.

The Witch Navigator (WNav) is our latest software GNSSreceiver which tries to overcome most of the previous projectdrawbacks. The WNav receiver is based on classical concep-tion which utilizes CPU and FPGA – in FPGA the correlatorsare implemented. We rely on x86 CPU since its computationpower enables implementation of various kinds of demandingsignal processing algorithms. Further, the algorithm can beimplemented almost in similar manner as it was developedin a high simulation tool (like Matlab); no additional workto tailor the algorithm to e.g. fix-point arithmetic or memoryrestriction is needed. Consequently, the time to bring thealgorithm to the test under real conditions (with live signal) is

Page 2: Witch Navigator -- a Low Cost Software Receiver receivers to complex multi-GNSS-system, multi-frequency and multi-antenna receiver. The Witch Navigator receiver is designed as an ExpessCard

2

shortened. To solve the CPU-FPGA latency problem we utilizethe PCI Express (PCIe) interface which has enough throughputto transfer the data at a sufficient rate. The WNav device isimplemented in the form of an ExpressCard device and canbe plugged in either laptops or PC desktops. The deterministicbehavior of the signal processing software is ensured by theReal-time Linux kernel (RT_PREEMPT kernel patch) [12].

A. Project purpose and philosophy

The WNav project was established to support our researchactivities in the field of GNSS. Thanks to the PC it is relativelysimple to implement new algorithms (if we compare it withalgorithm implementation for embedded systems). Therefore,our intention is to attract university students to WNav whocan solve particular problems in frame of their study and theirworks can issue to their thesis. The WNav receiver can also beused as a demonstration tool in GNSS related courses at uni-versity, since the visualization of internal receiver signals andparameters is straightforward. Therefore, the WNav project isclaimed as a GNSS receiver for education and research.

The project is an open source project released under GPL(General Public License) version 2. The software is freelyavailable from the project website [15] together with otherrelevant information. The WNav receiver is completely devel-oped in free/open tools. It concerns both hardware (the WNavExpressCard device) and software.

B. Goal of this paper

The purpose of the paper is to present current status ofthe WNav receiver project. Since autumn 2011 the WNavproject is GPS L1 C/A capable. Thus, all GPS L1 C/Akey features were implemented and tested (signal acquisition,signal tracking and PVT estimation). The paper describescurrently implemented GPS L1 C/A algorithms. From thisdescription the WNav capabilities and restrictions follow.

II. RECEIVER COMPONENTS

A. Peripheral device of the Witch Navigator

A hardware part of the Witch Navigator receiver consists of aWNav device and suitable PC workstation. The WNav devicehas the form of an ExpressCard (54mm, L-shape) and is notonly a front-end of the receiver but also is equipped with apowerful FPGA where correlators and signal replica generatorsare implemented.

The block structure of the WNav device is depicted in Fig. 1.The device has two independent RF inputs fed into direct-conversion tuners (MAX 2120). The tuners can be tuned toan arbitrary frequency in the range of 1 to 2 GHz and signalbandwidth can be adjusted in the range of 4 to 20 MHz. Base-band signals are then digitized (MAX 1192). The samplingfrequency is 20 MHz and samples are 8-bit wide (both I andQ samples). Next digital signal processing is performed in theFPGA.

MAX 11922x8 bitADC

PCIelanes

Spartan 6xc6slx45t

Lin. Reg.2.5V (AUX)

Lin. Reg.1.2V (PCIe)

Lin. Reg.1.2V (core)

Config.flash

MAX 2120direct conv.

RX

Prog.connect.

CH1

CH2

I

Q

AGC

I2C

AGC

adc_clk

adc_clk

TCXO20 MHz

MAX 11922x8 bitADC

MAX 2120direct conv.

RX

I

Q

I,Q

I,Q

Figure 1. Block structure of the WNav ExpressCard device

B. Signal processing in the FPGA

1) Correlator organization: In simple terms, the FPGA servesas a coprocessor for the CPU in the PC workstation and itsduty is to effectively compute the correlations. To be morespecific, it computes mutual energy of a received signal anda signal replica over 1 ms interval. In the basic mode, a pairof correlators (Early and Late) is designated for one satellitesignal. If needed, another correlator pair can be set to thesame PRN but with different Early-Late spacing to form amore complicated structure with several correlator branches.The correlator pairs are further organized in groups of six.The reason of such organization is a less resource demandingimplementation in the FPGA. As a consequence, the correlatorpairs in one group have some common parameters or settings(common RF input, identical correlator spacing, commonloading of PRN code). Current implementation of WNavcontains four correlator groups, thus WNav is now capableto process 4× 6 = 24 satellite signals independently.The FPGA is also equipped with a snap-shot memory whichstores signal samples over a fix interval (between two succes-sive TICc, TIC interval is 800µs, see below). The memorycontents are then transferred to the PC workstation wheresuccessive memory blocks are concatenated to a longer one.Such concatenated signal samples are then used for the acqui-sition purpose. It can be adjusted using a configuration register,which RF input is used for sample loading to the snap-shotmemory. It can be one of the two RF inputs but also both ofthem simultaneously. In case of one RF input the 8-bit samplesare used, if both RF inputs are used the sample width is 4 bits.The WNav device can also be used as a front-end for thepure processor GNSS receiver. In this case, the correlators inthe FPGA are not used. The signal is fed through the tunerand A/D converter to the snap-shot memory. The snap-shotmemory then serves just as a buffer for signal sample transferto the PC workstation.

Page 3: Witch Navigator -- a Low Cost Software Receiver receivers to complex multi-GNSS-system, multi-frequency and multi-antenna receiver. The Witch Navigator receiver is designed as an ExpessCard

3

PC partFPGA part

PLL detector DLL detecor

si(t)

cod

eg

en

era

tor

NC

Oco

de

cod

em

eas.

carr

ier

gen

era

tor

NC

Oca

rr.

carr

.m

eas.

Late

corr

ela

tor

Late

corr

. ou

t

Earl

yco

rrela

tor

Earl

yco

rr.

ou

t

rE,i(t) rL,i(t)

cE,i(t)

cL,i(t)

DL

Ld

iscr

imin

ato

rP

LL

dis

crim

inato

r

DL

L l

oop

filt

er

PL

L l

oop

filt

er

Figure 2. Block structure of DLL and PLL in the WNav receiver: DLLs/PLLsare divided between FPGA and the PC workstation. Registers, which formFPGA – PC interface are marked as gray boxes.

2) Tracking loop structure: The implementation of the signaltracking algorithm in WNav is divided between the FPGA(correlators and replica generator) and the PC workstation(discriminators, loop filters). The block structure of DLL andPLL is shown in Fig. 2. The figure shows, which parts ofDLL/PLL are implemented in the FPGA or as software onthe PC side. The interface between the FPGA and the PCworkstation is formed with six registers: in the figure theregisters are depicted as gray boxes. The Early and Latecorrelator output registers contain correlation results over1 ms interval. These register values are complex, I and Qcomponents are of 16-bit width each. Next output registers arethe code and carrier measurement registers, each of them is32-bit width. In current software implementation, just the codemeasurement register is utilized as a base for pseudorangeforming, the carrier measurement register is now idle, and canbe used for phase measurement in future. There are two inputregisters which drive particular NCO, each of them is 32-bitwide.

3) Timing relation: The PLL/DLL discriminator outputs arecomputed on the PC side based on the Early/Late correlatoroutputs. Each correlator issues new value approximately in1 ms intervals (depending on actual Doppler shift). The events,when the Early and Late correlators issue new values aredenoted as Early and Late PRN TIC, respectively. Concerningthe data transfer between the FPGA and the PC, there is aproblem due to the fact, that the Early/Late PRN TIC events

in particular channels are not synchronized. To make the datatransfer of the correlator outputs feasible, all registers are re-sampled with slightly higher rate than is the rate of Early/LatePRN TICs. The WNav receiver chose 800µs interval for thisand the corresponding events are denoted as (main) TICs. Thetime relation of the TICs and Early (Late) PRN TICs for sixchannels (for six pairs of correlator) is shown in Fig. 3.To compute the PLL/DLL discriminator and loop filter outputs,both Early and Late correlator outputs are needed. In thefigure, the magenta circles mark these situations, when bothEarly and Late correlators issued new values and thus, thediscriminators and loop filters can be calculated. Evidently,there are situations when new Early and Late correlator outputsare not yet available (i.e. the outputs were used at previousTIC); such situations are marked with black circles in thefigure. It can also happen that the TIC occurs in the middle ofEarly and Late PRN TIC; these are denoted with red circle.Then, just the Early correlator output is available, and thechannel has to wait for next TIC when the Late will beavailable (in next TIC just Late correlator can issue output,thus, the situation has to be marked with blue circle). In otherwords, the discriminators and loop filters are calculated inthese TICs, which are marked with magenta or blue circles.It follows from this timing that in the loop a variable delayis introduced; this delay can vary from 800µs to 1.6 ms. Thedelay has to be taken into account when a loop model is con-structed (e.g. for determination of the loop noise bandwidth).The implementation of the replica generators is such thatthe Late PRN generator is just the delayed Early one. Con-sequently, the value in the code measurement register cor-responds to the code phase of the Early correlator. Sincethe code (and carrier) phase measurement registers are alsoresampled with the TIC event, all information exported fromthe DLL/PLL for PVT algorithm purpose has to be derivedfrom the Early PRN TIC. Specifically, we mean the tasksas the detection of navigation message bits or the main-taining counter with the number of PRN periods from thebit boundary. If this is not respected, the code (and carrier)phase measurement registers would not be consistent with theexported information for the PVT and, as a consequence, thepseudoranges can be corrupted.4) Communication between FPGA and PC: The data whichhave to be interchanged between the FPGA and the PC arearranged into two memory blocks (output and input). The datatransfer is synchronized with the TIC event, see Fig. 4. Whenthe TIC occurs, the new data (output registers) are availableand are copied using DMA to the user space. The time whenDMA transfer is finished is signalized in the user space usingMSI (Message Signaled Interrupts) interrupt. Then, the dataare treated in a real-time process. The real-time process ismainly responsible for DLL/PLL feed-back closing, i.e. hasto issue new values of the NCO control registers. These datahave to be written back do the FPGA, but this writing haveto be finished before next TIC.The real-time behavior of the WNav software is assured notonly with the real-time process priority but also with the real-time operating system. The WNav receiver relies on Real-Time

Page 4: Witch Navigator -- a Low Cost Software Receiver receivers to complex multi-GNSS-system, multi-frequency and multi-antenna receiver. The Witch Navigator receiver is designed as an ExpessCard

4

800 μs 800 μs

Early PRN TIC Late PRN TIC

800 μsTIC

ch.0

ch.1

ch.2

ch.3

ch.4

ch.5

Figure 3. Time relations of TICc and Early/Late PRN TICs in particular channels. The colored circles at TICs mark which correlator outputs are available:magenta: both, Early and Late, blue: just Early, red: just Late, black: neither of them.

800 μs 800 μs

MSIinterrupt

TIC TIC

DM

Atr

an

sfer

DM

Atr

an

sfer

MSIinterrupt

TIC

Real-timeprocess

Real-timeprocess

Figure 4. Time relations of the TIC, interrupt and real-time process running

Linux (the Linux kernel with RT_PREEMPT patch) [12].

The output register mapping is depicted in Fig. 5. This memoryblock also contains the acquisition memory, i.e. signal samplesover 800µs interval. Size of the acquisition memory is huge inconfrontation with the other output register areas and causesproblems if data transfer is purely controlled by the CPU. Tomeet strict time constraint (800µs TIC pattern), the devicehas implemented (one way) DMA transfer facility whichsignificantly reduces the transfer time from the FPGA to thePC side. The memory block also contains four status registerswhich are common for the WNav receiver.

The input register mapping is depicted in Fig. 6. The datawhich have to be written into the device have to contain anarea with NCO control registers. In addition, there is alsoanother area with universal contains. There can be placed asegment of PRN code, one 32-bit value of a control register,or it can be unfilled. The area contents are described in theblock header and the correct item placing with respect to theFPGA addressing is accomplished at the kernel level.

C. Software part of the Witch Navigator project

1) Device driver: A purpose of the device driver is to makeregisters and memory areas accessible in user space processes(in the real-time process). The device driver is written as akernel module for Linux operation system. The device itselfis treated as a character device and the device driver offersfollowing system calls: open(), close(), read() andwrite(). The user space process can accesses the device

correlator control register

0x0000

0x7cfc

0x7f00

0x7f10

0x7f08

0x7f18

0x7d00

0x7dfc

0x7e00

0x7efc

WN_SIZE_ALLDMA

0x7f1c

carrirer and codemeasurement registers

Early and Late correlatoroutput registers

acquisition memory(snap-shot memory)

correlator space register

TIC counter

i2c status register

0x7d00

0x100

2×0x80

Figure 5. Mapping of output registers in the memory block transferred formthe FPGA to the PC every TIC: 32-bit status registers common for the entireWNav receiver (blue color), the DLLs/PLLs related registers (red color), thesnap-shot memory for acquisition purpose (gray color).

0x0000

0x00fc0x8000

0x8004

0x8008

0x800c0x010000

0x013ffc0x014000

0x017ffc0x018000

0x01bffc0x01c000

0x01fffc

header

NCO controlregisters

correlator control reg.

DMA address

correlator space reg.

I2C control reg.

PRN mem. forcorr. group 0

PRN mem. forcorr. group 1

PRN mem. forcorr. group 2

PRN mem. forcorr. group 3

NCO ctr.registers

0x100 + 0x100 + 0x4

reg. value

0x4000

0x4000

0x4000

0x4000

0x100

(unused)

PR

N s

eg

men

t

Figure 6. Mapping of input registers in the memory block transferred formthe PC to the FPGA every TIC: 32-bit control registers common for the entireWNav receiver (blue color), the NCO control registers for replica generators(red color), a segment of PRN code (green color). The user space programwrites the block shown on the right side of the figure. Its contents is decodedat the kernel level (according the header) and written to the device in theblock arrangement shown on the left side of the figure.

Page 5: Witch Navigator -- a Low Cost Software Receiver receivers to complex multi-GNSS-system, multi-frequency and multi-antenna receiver. The Witch Navigator receiver is designed as an ExpessCard

5

registers through the special file /dev/wnavX , where Xstands for 0,1,2 ... (depending on recognized devices in thesystem).

It is supposed, that the user space program calls read()and write() system calls in an infinite loop. More detailsconcerning the device driver for WNav can be found in [14].

2) Software in user space: The WNav software consists ofthree main processes ruing in the user space: wnav_core,wnav_monitor, and wnav_pvt. The inter-process com-munication (IPC) among the processes is implemented usinga shared memory.

The wnav_core process is a real-time process (run withhigh priority under scheduler SCHED_FIFO). The processperforms the following tasks in an infinite loop:

• read the memory block from the FPGA (see Fig. 5)• do the control task according to a command in the task

queue (if any)• perform the task according the actual channel status• export data for the PVT algorithm (data for wnav_pvt

process)• write the memory block to the FPGA (see Fig. 6)

A task queue allows an efficient control of the WNav re-ceiver. Most of control commands results (in a low level)in read and/or write requests of the device. For example,commands can adjust the tuner parameters (frequency, band-width), perform the channel reset, load new PRN code forthe pair of correlators, change the correlator spacing, changethe acquisition memory mode, etc. Such commands can notbe performed in an arbitrary time because their processinghas to be synchronized with the FPGA-PC communicationpattern, i.e. with the TIC intervals. The strategy adopted inWNav is based on existence of the task queue where the otherprocesses (all except wnav_core) can put task objects (theobjects, which consist of an object ID and their parameters).The objects are then withdrawn and processed in wnav_coreat the right time.

The key task of wnav_core is the closing of DLL/PLLfeedbacks depending on particular channel status. The channelstatus will be discussed in Sec. III.

The wnav_monitor process serves as a user interface. Theprocess runs with normal priority (scheduler SCHED_OTHER)and it was written using NCurses library, see Fig. 7. First,wnav_monitor enables a look inside the shared memoryand visualizes selected receiver parameters. The parametervisualization is arranged into pages. E.g. in Fig. 7, there isa page with channel parameters. Other currently implementedpages are acquisition, tuner status, fault counters and flags,page with position, and help page. Second, wnav_monitorallows to control the WNav receiver through the commandstyped into the command line (see last line in Fig. 7). Thecommands are parsed to create the task objects which are thenput into the task queue.

Typing command manually is tedious, so wnav_monitorallows to load a sequnece of commands from a file. This isparticularly useful for initial receiver setting. As an example

Figure 7. Screenshot of WNav receiver user interface: wnav_monitor. Topline contains TIC counter, middle part contains the page with channel status,bottom line is the command line for receiver control.

see next file list, which is used for an initial settings ofcorrelators in one group (group with ID 0).

# WNav command file# set all correlator spacing to 8*Tsawrite corrspace 0x7777# adjust first tuner (ID 0): L1 frequency,# bandwith 4MHz, gain 10.0tuner 0 1575.42 4.0 10.0# set mode of the snap-shot memorywrite corrctr 0x803# prepare and load PRN code for corr.# pair in 1st (ID 0) groupprnld gps_l1_ca 0 2 12 21 26 15 10# perform acquisition for all channels# in 1st corr. groupacq 0 0acq 0 1acq 0 2acq 0 3acq 0 4acq 0 5

The wnav_pvt process receives the following informationfrom the wnav_core process every 0.1 s (every 125 TICs)

• measurement time in TIC• values of NCO tracking registers at the measurement time• soft information about the synchronized data bits/symbols• carrier-to-noise ratio estimates• others

and accomplishes the tasks of

• pseudorange formation• subframe synchronization• data decoding, parity check• navigation data storage• PVT estimation.

The data are decoded and stored to the navigation datastorage on the subframe basis. The wnav_pvt process can

Page 6: Witch Navigator -- a Low Cost Software Receiver receivers to complex multi-GNSS-system, multi-frequency and multi-antenna receiver. The Witch Navigator receiver is designed as an ExpessCard

6

SN

RI<

thre

sh.

INIT

LPRN

WACQ

AACQ

CTRK

FTRK

LTRK

pow

<th

resh

.

rese

t to

WA

CQ

rese

t to

IN

IT

Figure 8. Status diagram of one channel

estimate the user PVT using the least squares (LS), weightedleast squares (WLS), and the extended Kalman filter (EKF)algorithms.

III. IMPLEMENTED ALGORITHMS OF GPS L1 C/A – THEIRPERFORMANCE

In this section we describe algorithms of GPS L1 C/A signalprocessing as they are implemented in the current version ofthe WNav software. Actual source code is available from [15].The description can serve as an example how some new GNSSalgorithms can be implemented to the WNav receiver. Further,the description demonstrates receiver performance and alsoshows some limits due to its architecture (its hardware anddevice driver implementation).The behavior of the receiver channel depends on the actualchannel status. Current version of the WNav software hasimplemented seven statuses and their status diagram is shownin Fiq. 8.

A. Channel initialization, PRN sequence load

All receiver channels are in INIT status at the beginning ofwnav_core process. The INIT status is an idle status. Thenominal chip rate 1.023 106 chip/s is written into the codeNCO regardless of the correlator outputs.Concerning the carrier NCO, the situation is similar. Thevalue written to the carrier NCO corresponds to the zeroDoppler offset. But this value is not equal to zero since theresidual frequency offset due to the synthesizer step has to beconsidered (the residual offset is 35.4 kHz).The channel which is in INIT status can accept new PRNsequence and thus can be bounded with specific satellite. ThePRN sequence load is common to all channels in the group(the pair of Early/Late correlators are organized in group ofsix) and is initialized with PRNLD command.The PRN sequences are generated and formatted on the PCside. The reserved size for the PRN memory for one group

is 0x4000 bytes. The transfer of all these 0x4000 bytes inone write cycle will issue to breaking of time constraints (thewriting will not be finished before next TIC). Thus, the 0x4000memory block is divided into segments with size 0x100. Thereare 0x40=64 such segments which are written to the FPGAduring 64 TICs, i.e. it takes 64 × 0.8 ms = 51.2 ms. Duringthe load the channel is locked. This locking is indicated withLPRN (Load PRN sequence) channel status. When the PRNload is finished, the status is changed to WACQ where theacquisition results can be accepted.

B. Acquisition task

The acquisition algorithm of the WNav receiver runs intwo successive steps. In the first step, the acquisition isaccomplished over stored signal samples from the snap-shotmemory. The parallel search is utilized here. As a result,the receiver obtains an estimate of the frequency offset andcoarse code phase. Since this acquisition step takes some time(several seconds), the true code phase can differ in the timeof applicability (the receiver needs a code phase error smallerthen 0.5 chip to perform tracking). The acquisition task isfinished in the second step which accomplishes serial signalsearching using the correlators in the FPGA .

The snap-shot memory segment contains signal samples over800µs. The segments are concatenated on the PC side toobtain a longer signal. Due to the implementation reason, thesnap-shot buffer on the PC side can cover 2N − 1 segments.Now, N is set to 5, thus the signal length used for theacquisition is 800µs× (25 − 1) = 24.8 ms. The implementedalgorithm tries to be robust (not optimal). Since the receiverdoes not know where the bit boundaries of navigation messageare the entire signal (24.8 ms length) is divided into 24segments with 1 ms length. Then the segments are coherentlycorrelated with the signal replica; the circular correlation iscomputed in frequency domain (FFT/IFFT). These 24 coher-ently correlated results are then non-coherently averaged. Theacquisition result (the result contains frequency offset, codephase and TIC counter at the snap-shot beginning as a timereference) is stored as an item in the shared memory. The real-time process can then withdraw this result and use it for initialsetting of the second acquisition step. Obviously, the searchspace in the second step is significantly smaller then in thefirst one.

The receiver allows to save the buffer contents with signalsamples to a text file. Such file can be used for a debuggingpurpose in some higher simulation tool (Matlab). The resultof the first step algorithm (ambiguity function) processed inMatlab is shown in Fig. 9.

The receiver channel can accept the acquisition result only inWACQ (Wait for ACQuisition) status. In WACQ, the sharedmemory is checked every TIC for the acquisition result whichcan be applied for particular channel. If the result is found, itis used for initial settings of the serial search: The carrier NCOis set to the frequency offset from this result. Further, the codephase from the result is recalculated to the code phase in timeof applicability. For this recalculation the nominal chip rate

Page 7: Witch Navigator -- a Low Cost Software Receiver receivers to complex multi-GNSS-system, multi-frequency and multi-antenna receiver. The Witch Navigator receiver is designed as an ExpessCard

7

Figure 9. Ambiguity function computed over signal samples from the snap-shot memory; signal source Spirent GPS simulator GSS6560, PRN 02

is considered (1.023 106 chip/s). Due to the possible non-zeroDoppler, the code phase is corrected by several chips back.Such corrected code phase is then used for a calculation ofthe code NCO value, which ensures that the code phase in thetime of applicability (in next TIC) will arrive to this correctedcode phase.At the beginning of the serial acquisition, there is an idlephase for to proper initialization of an adaptive threshold. Thenthe following tasks are performed repeatedly: The correlationresult is obtained as a non-coherent average of several 1 mscoherent correlations which are obtained from the correlatoroutput registers. The correlation result is compared with thethreshold. If the result is higher then the weighted threshold,the acquisition finish is declared and the status is changed toCTRK (Coarse TRacKing). If not, the code phase is jumpedby 0.5 chip forward. If the entire frequency bin was searched(i.e. more than 2 × 1023 steps were accomplished) and thesignal was not found, the channel status is changed back toWACQ.The count of 1 ms coherent correlation taken into averagingand the weight of the threshold can be adjusted as algorithmparameters (now the correlation count is set to 20 and thethreshold weight to 4.0 ). The described serial search algorithmcan be well illustrated using Fig. 10 where the code phase andcorrelation results during AACQ are depicted.

C. Signal tracking task

The channel statuses which are designated to signal trackingtask are CTRK (Coarse TRacKing), FTRK (Fine TRacKing),and LTRK (Long TRacKing). There is a fundamental dif-ference between LTRK and two the others: in LTRK status,the bit synchronization is finished, thus, the coherent integra-tion can be prolonged up to 20 ms. Further, the LTRK alsoaccomplishes signal quality assessment, the signal-to-noiseratio (SNR) equivalently at correlator with 1 ms integrationis estimated. See the Fig. 11, where the various receiverparameters are visualized.

The implemented DLL, FLL and PLL detectors and loopfilter structures are described in [16]. The loop filter constants(ω0 and a) are designed in such a way that the loop noisebandwidth is widest in CTRK and narrowest in LTRK.

In all three statuses, the normalized Early minus Late powerdetector is used in the DLL. The CTRK and FTRK utilize 1 mscoherent integration, the LTRK accumulate 1 ms correlatoroutputs to prolongate coherent integration time to 20 ms. Theimplemented DLL loop is of the second order in all threestatuses.

The CTRK implement 1st order FLL. The FLL detector isatan2, whose output is corrected to cancel the BPSK modula-tion. The FLL detector in CTRK use 1 ms coherent integration.The FTRK and LTRK implement 2nd order PLL. The PLLdetecor is atan2, with correction due to the BPSK modulation.In FTRK and LTRK, the 1 ms and 5 ms coherent integrationare used, respectively.

The channel stays in CTRK and FTRK for fix amount of TICs(now, this is set to 4096 TICs = 3.8 s). Concerning LTRK,channel stays in LTRK if SNR is higher then given threshold(now set 0 dB). If SNR is low, the status is changed to WACQ.

The channel in AACQ or in one of the tracking statuses can bereset to stop its current task. The channel can be reset eitherto WACQ or INIT status using RST command. The reason ofthe reset to WACQ can be that the channel can start with newacquisition. The reset to the INIT enables to change associatedPRN (just channel in INIT can be loaded with new PRN).

D. Position, velocity and time estimation

The user can compile the program with three different PVTestimation/filtering algorithms – LS, WLS, FG. The LS al-gorithm is always employed in the initialization procedurewith 4 iterations to ensure convergence. For the next data,the previous position estimate is used as a new linearizingpoint and only a single iteration is calculated. In the EKFalgorithm, the prediction of user position is used instead. Theweights/variances for the WLS/EKF algorithms are estimatedbased on the approximate formulae derived for the code delayand carrier frequency tracking jitter [16] where carrier-to-noiseratio estimate, filter bandwidth, integration time, early/latedistance are substituted.

Comparisons of the total position error (TPE) and total veloc-ity error (TVE) of the WLS, EKF algorithms are depicted inFig. 12. The user was static and the velocity motion modelfor the EKF with 0.0001 m/s driving noise standard deviationwas used.

IV. CONCLUSION

In this paper, the Witch Navigator receiver was presented.The receiver hardware consists of an ExpressCard peripheralplugged into a PC workstation. The impressive receiver perfor-mance is ensured with a FPGA where the correlators togetherwith signal replica generators are implemented. Feedbacks ofDLLs/PLLs are closed on the PC side. Such solution promises

Page 8: Witch Navigator -- a Low Cost Software Receiver receivers to complex multi-GNSS-system, multi-frequency and multi-antenna receiver. The Witch Navigator receiver is designed as an ExpessCard

8

72.6 72.8 73 73.2 73.4 73.6 73.8 74

580

581

582

583

584

585

586

587

time [s]

code

pha

se [c

hips

]

code phase

WACQAACQCTRKFTRKLTRK

72.7 72.8 72.9 73 73.1 73.20

0.5

1

1.5

2

x 107 AACQ −− acknowledge acquisition

time [s]

correls. accu.average x THRHOLDaverageaccu. end

a) b)Figure 10. Serial acquisition – AACQ channel status: a) code phase during AACQ, b) the results of non-coherent averaging (values in red circle) andadaptive threshold (magenta)

superior performance and preserves sufficient variability. Thereceiver software is developed for Real-time Linux.The main receiver purpose is to be a research platform butalso a tool for GNSS education. The project is claimed as anopen source project, its software is available from the projectwebsite under GPL version 2.The up-to-date status of the Witch Navigator project is thatthe receiver is fully GPS L1 C/A capable. In the paper,we described in detail implemented algorithms (acquisition,tracking and PVT) and also their relation to the hardwareand device driver. The receiver capability but also some limitsfollowed from this description.

ACKNOWLEDGMENT

The authors would like to thank the Spirent Communicationfor lending the GPS simulator GSS6560, which was used forthe verification and testing of the final tracking and PVTalgorithms.

REFERENCES

[1] BORRE, K., AKOS, D., BERTELSEN, N., RINDER, P., JENSEN, S.:A software-defined GPS and Galileo receiver: a single-frequencyapproach. Birkhauser, 2007.

[2] PRINCIPE, F., BACCI, G., GIANNETTI, F., LUISE, M.: Software-Defined Radio Technologies for GNSS Receivers: A Tutorial Approachto a Simple Design and Implementation (Review Article). InternationalJournal of Navigation and Observation, Volume 2011 (2011).

[3] PANY, T., EISSFELLER, B., HEIN, G., MOON, S., SANROMA, D.:ipexSR: A PC Based Software GNSS Receiver Completely Developedin Europe. In Proceedings of ENC-GNSS. Rotterdam, 2004.

[4] MUMFORD, P., PARKINSON, K., DEMPSTER, A.: The Namuru OpenGNSS Research Receiver. In Proceedings of 19th international tech-nical meeting of the Satellite Division of the US, Inst. of Navigation.Fort Worth, Texas, 26–29 September 2006.

[5] PETOVELLO, M., O’DRISCOLL, C., LACHAPELLE, G., BORIO, D.,MURTAZA, H.: Architecture and Benefits of an Advanced GNSSSoftware Receiver. Journal of Global Positioning Systems, Vol. 7, No.2, pp. 156–168, 2008.

[6] HOBIGER, T., GOTOH, T., AMAGAI, J., KOYAMA, Y., KONDO, T.: AGPU based real-time GPS software receiver. GPS Solutions, Vol. 14,No 2, March 2010.

[7] HECKLER, G., GARRISON, J.: SIMD correlator library for GNSSsoftware receivers. GPS Solutions, Vol. 10, No. 4, November 2006.

[8] VEJRAZKA, F., KOVAR, P., SEIDL, L., KACMARIK, P.: ExperimentalSoftware Receiver of Signal of Satellite Navigation Systems. In 11thIAIN Word Congress. Berlin 2003.

[9] KOVAR, P., VEJRAZKA, F., SEIDL, L., KACMARIK, P.: Reception ofSignals of GLONASS System by Experimental GNSS Receiver. In 11thSaint Petersburg International Conference on Integrated NavigationSystems, pp. 210–212. Moscow: Russian Academy of Sciences. 2004.

[10] VEJRAZKA F., KOVAR P., ESKA M., PURICER P.: Software navigationreceivers for GNSS and DVB. TransNav – International Journal onMarine Navigation and Safety of Sea Transportation, Vol. 1, No. 2,pp. 137–141, 2007.

[11] KOVAR, P., KACMARIK, P., VEJRAZKA, F.: Interoperable GPS,GLONASS and Galileo Software Receiver. IEEE Aerospace and Elec-tronic Systems Magazine, Vol. 26, Issue 4, pp. 24–30, April 2011.

[12] Real-Time Linux Wiki: The Wiki Web for the CONFIG_PREEMPT_RTcommunity, and real-time Linux in general. [Online]. Cited 23.11.2011.Available at: https://rt.wiki.kernel.org/index.html

[13] JAKUBOV, O., KOVAR, P., KACMARIK, P., VEJRAZKA, F.: The WitchNavigator – A Low Cost GNSS Software Receiver for AdvancedProcessing Techniques. Radioengineering, Vol. 19, No. 4., December2010.

[14] KACMARIK, P., KOVAR, P., JAKUBOV, O., VEJRAZKA, F.: The WitchNavigator – A Software GNSS Receiver Built on Real-Time Linux. InProceeding of the 13th Real Time Linux Workshop. Prague, October2011.

[15] Witch Navigator project home page. [Online]. Cited 23.11.2011. Avail-able at: http://witchnav.cz/doku.php

[16] WARD, P., BETZ, J., HEGARTY, CH.: Satellite Signal Acquisition,Tracking, and Data Demodulation, In Understanding GPS: Principlesand Applications, Kaplan, E., Hegarty, Ch. (Editors). Norwood, MA,Artech House, Inc. 2006, pp. 153–241.

Page 9: Witch Navigator -- a Low Cost Software Receiver receivers to complex multi-GNSS-system, multi-frequency and multi-antenna receiver. The Witch Navigator receiver is designed as an ExpessCard

9

0 5 10 15 20 25 30 35 400

200

400

600

800

1000

1200

time [min]

code

pha

se [c

hips

]code phase

WACQAACQCTRKFTRKLTRK

104 104.2 104.4 104.6 104.8 105 105.2 105.4 105.6

−1500

−1000

−500

0

500

1000

1500

Early I&Q with bit detection FTRK(1ms) and LTRK (20ms)

Early IEarly Qbit detection

a) b)

73 74 75 76 77 78 79 80 81 82 83−1

−0.8

−0.6

−0.4

−0.2

0

0.2

0.4

0.6

0.8

1DLL detector output

time [s]

CTRKFTRKLTRK

73 73.1 73.2 73.3 73.4 73.5 73.6 73.7 73.8 73.9 74

−0.5

−0.4

−0.3

−0.2

−0.1

0

0.1

0.2

0.3

0.4

0.5

PLL detector output

time [s]

CTRKFTRKLTRKdet. corrected

c) d)

77.1 77.15 77.2 77.25 77.3 77.35 77.4 77.45 77.5 77.55 77.6

−0.5

−0.4

−0.3

−0.2

−0.1

0

0.1

0.2

0.3

0.4

0.5

PLL detector output

time [s]

CTRKFTRKLTRKdet. corrected

81.3 81.35 81.4 81.45 81.5 81.55 81.6 81.65 81.7 81.75 81.8

−0.5

−0.4

−0.3

−0.2

−0.1

0

0.1

0.2

0.3

0.4

0.5

PLL detector output

time [s]

CTRKFTRKLTRKdet. corrected

e) f)Figure 11. a) code phase – the code phase detail of WACQ, AACQ, CTRK status transition is shown in Fig. 10 a); b) output of Early correlator in LTRKstatus: I and Q components and detected navigation bits (red curve), the waveform of navigation bits is 20 ms delayed since the bit detection is performedafter 20 ms integration; c) output od DLL detector; d) output of PLL detector, corrected detector output due to BPSK modulation is drawn with red curve:beginning of CTRK status, just FLL works there; e) detail of the transition from CTRK to FTRK (FLL is replaced with PLL); f) detail of the transition fromFTRK to LTRK

Page 10: Witch Navigator -- a Low Cost Software Receiver receivers to complex multi-GNSS-system, multi-frequency and multi-antenna receiver. The Witch Navigator receiver is designed as an ExpessCard

10

0 500 1000 1500 2000 2500 3000 35002

4

6

8

10

12

14

time [s]

TP

E [m

]

total position error

WLSEKF

0 500 1000 1500 2000 2500 3000 35000

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

0.45

0.5

time [s]

TV

E [m

/s]

total velocity error

WLSEKF

a) b)Figure 12. Comparison of measured a) total position error , b) total velocity error of the WLS, EKF algorithms