GOOSE – GNSS Receiver with an OpenSoftware Interface

Matthias Overbeck∗, Fabio Garzia∗, Alexander Popugaev∗, Oliver Kurz∗, Frank Forster∗, Wolfgang Felber∗,Ayse Sicramaz Ayaz�, Sunjun Ko�, Bernd Eissfeller�,

∗Fraunhofer Institute for Integrated Circuits IIS, Erlangen/Nuremberg, Germany�Universitat der Bundeswehr Munchen, Germany

BIOGRAPHY

Matthias Overbeck received his Dipl.-Ing. (MSc) degreein Electrical Engineering from the University of Erlangen-Nuremberg, Germany, in 1999. Since September 1999 heis working at the Fraunhofer Institute for Integrated Cir-cuits (IIS) in the Power Efficient Systems Department onthe topic hardware development for global navigation satel-lite system (GNSS) receivers. Within this scope he de-veloped digital baseband hardware like signal condition-ing, correlators and microprocessor for field-programmablegate array (FPGA) and for application-specific integratedcircuits (ASIC) for an assisted global positioning system(GPS)/European Geostationary Navigation Overlay Ser-vice (EGNOS) receiver for mobile applications. He gath-ered profound skills in the design of an application specificDSP for signal acquisition, tracking and the PVT solutionfor the same application. Moreover he has developed arapid prototyping platform on FPGA basis for GPS/Galileoprototype receiver. Since 2009 he has taken over for Fraun-hofer the technical leadership of the GSA project GalileoReceiver for Mass Market Applications in the AutomotiveArea (GAMMA-A). Since 2013 he is the Group Managerof Precise GNSS Receiver at Fraunhofer IIS.

Dr. Fabio Garzia received his MSc degree as ElectronicsEngineer in March 2005 from the University of Bologna,Italy. After his graduation, he worked for a few months atARCES Labs in Bologna, first as VLSI Layout Engineerthen as Digital Designer. In 2006 he moved to Tampere,Finland, where he started his PhD studies. His PhD The-sis focused on the design of a coarse-grain reconfigurableaccelerator at RTL level, the development of programmingtools, design of SoC platforms based on this accelerator,implementation on FPGA and mapping of some applica-tions on it. He received his Dr.Tech. (PhD) Degree inDecember 2009. From January 2010 to April 2011, hereceived a research grant for the development of a high-level compiler for the reconfigurable accelerator. In Oc-tober 2011 he moved to Germany, where he joined theNavigation Group, Power Efficient Systems Department at

Fraunhofer IIS. His main task is the development of digitalhardware and HW/SW interfaces for GNSS receivers tar-geting both ASIC and FPGA technologies. In May 2015he received the title of Senior Engineer at Fraunhofer IIS.

Dr. Alexander E. Popugaev was born in Suzdal, RussianFederation, in 1981. He received the MSc degree (withhonours) in radio engineering from the Vladimir State Uni-versity, Russia, in 2004, and the Dr.-Ing. (PhD) degree(summa cum laude) from the Technical University of Il-menau, Germany, in 2013. Since 2004, he has been withthe Fraunhofer IIS, Erlangen, Germany. Currently, he isa senior engineer in the radio frequency (RF) and SatComSystems Department. His current research activities focuson the design of customer-specific microstrip antennas, im-proving the efficiency of their design process and providingcost effective solutions. Dr. Popugaev has authored and co-authored several scientific papers and book chapters andhas received several patents.

Oliver Kurz did his Bachelor of Physics at the Universityof Wuerzburg, Germany. After that he pursued a Master ofSpace Science and Technology at University of Wuerzburg,Germany, and Lulea, Sweden. He started to work at Fraun-hofer IIS, Nuremberg, Germany, in 2008. Since then he isworking in development of GNSS receiver technology, es-pecially software. His experience in his present job and theresponsibilities are system design, test management, sup-porting team infrastructure, software development and ar-chitecture for GNSS receivers, design and development ofsignal processing algorithms for satellite navigation sys-tems, software related system integration in cooperationdevelopment and research projects.

Frank Forster received his Dipl.-Ing. degree in ElectricalEngineering from the University of Erlangen-Nuremberg,Germany, in 2003. Since then, he is at the Fraunhofer IISas a system design engineer. Currently he is involved inseveral navigation and communication projects where heis responsible for designing, evaluating and testing analogfrontends for GNSS receivers in harsh signal environments.

Dr. Wolfgang Felber received his Dipl.-Ing. (MSc) de-

gree from Helmut Schmidt University - University of theFederal Armed Forces Hamburg in 2002 and his Dr.-Ing.(PhD) in 2006. He is working for the Fraunhofer IIS since2009. From 2009 – 2011, he was a research scientist inthe area of satellite communication in Ilmenau and washeavily involved in building up a test facility for “Satcomon the move” (SOTM) applications. This test facility istoday one of the few approved GVF (Global VSAT Fo-rum) test entities in the world for SOTM-terminals. From2011-2014 he was Head of the Group “Satellite Com-munication” and since 2013 Deputy Head of ResearchGroup “Wireless Distributed Systems / Digital Broadcast-ing” in Ilmenau. In 2014 he moved to Nuremberg andtook over the Head of a long-standing department devel-oping localisation technologies, mainly technologies forcombined GPS/EGNOS/Galileo receivers for different ap-plications. His department today is also working in inertialsensor systems and navigation, multi sensor systems andsensor fusion, high precision microwave localisation sys-tems for sport applications, power management systems forcommunication transceivers and navigation receivers andlow power communication modules for embedded systems.Before working for Fraunhofer he was with the FederalArmed Forces working as a Technical Officer at the AirForce in different technical units and positions.

Dr. Ayse Sicramaz Ayaz received the BSc degree in Elec-tronics Engineering from Dokuz Eylul University, Turkey,the MSc degree in Information Technology from Univer-sity of Erlangen-Nuremberg and PhD degree in 2013 at theInstitute of Space Technology and Space Applications inUniversity FAF. Major interests are signal processing im-plementations, synchronization, interference and mitiga-tion algorithms in GNSS Receivers and Real Time Kine-matic (RTK). Since 2004, she is a research associate in theInstitute of Space Technology and Space Applications atthe University FAF.

Dr. Sun-Jun Ko received his PhD in Electronics Engineer-ing at Ajou University, S. Korea in 2006. He worked forR&D Institute of Samsung Electro-Mechanics from 2006to 2009. Since 2010, he has worked with the institute ofSpace Technology and Space Application, University ofFAF, Munich, Germany. He has a lot of experiences in as-pect of receiver and next generation of communication de-vices, also published many papers on GPS/GNSS researcharea since 2000. His research interests are GNSS Signalprocessing, architecture of GNSS receivers, detection andmitigation of interference signal, and multi-sensor fusionfor indoor navigation system and its implementation.

Prof. Bernd Eissfeller is Full Professor and Vice-Directorof the Institute of Space Technology and Space Applica-tions at the University FAF Munich. He is responsible forteaching and research in the field of navigation and signalprocessing. Till the end of 1993 he worked in industry asa project manager on the development of GPS/INS navi-

gation systems. From 1994 - 2000 he was the head of theGNSS Laboratory and since 2000 full professor of Navi-gation at University FAF. He is author of more than 215scientific and technical papers.

ABSTRACT

For the typical user of positioning and navigation applica-tions, a precise GNSS receiver is a black box which de-livers not well specified raw measurements with very re-duced configuration possibilities. However, the process-ing of precise positions from such measurements needs adeeper insight about the way how these measurements wereobtained (filtering etc.). In addition, precise positions areusually needed in critical environments like forests, fieldsand outdoor storage which require different kind of sensorsto circumvent position disturbance caused by shadowingand reflections. In order to keep the precise position, thecarrier phase solution needs to overcome short signal out-ages. The most common solution is to support the PLLwith deeply coupled sensors. Unfortunately, this techniquecannot be used with standard commercial receivers as thereis no possibility to control the tracking loops from outsidethe receiver. In order to make this possible the objectiveof the GOOSE project (German acronym for ”GNSS Re-ceiver with open software interface”) is to provide a flexibleGNSS development platform for all kind of precise GNSSapplications including an open software interface availableto guarantee a transparent free and deep access to the re-ceiver’s hardware.

INTRODUCTION

The GNSS receiver black box

Nowadays the GNSS receivers are available as chip setmodules, OEM boards and full housing receiver products;all offering position, velocity and time component (PVT)and some additional raw measurements. Most of them areconfigurable in terms of update rates and some also in re-ceived signals and systems. Some of them even supportthe processing of additional sensors. But, what they allhave in common is that the user has to arrange with theoutput measurement results not knowing how they wheregenerated. The closed receiver systems don’t allow to runown software for machine steering on the receiver proces-sor. Therefore such systems are always interfaced to addi-tional devices like other receiver(s), processing engines andman-machine-interfaces (displays) spread over the driverscabin. An even bigger problem is that it is not possible tofeedback sensor information to stabilize the receiver track-ing loops in harsh environment. So the possibility of usingnowadays receiver in several applications is very limited.

State of The Art

The GOOSE platform provides the flexibility of an aca-demic receiver setup combined with the performance of

professional OEM boards. Therefore in the next two sub-sections the state of the art of academic and OEM receiversis described and compared to GOOSE.

Academic Open Receiver Approaches

The ”University of New South Wales“ provides the Na-muru receivers which use components off the shelf for thefrontend, combined with an FPGA as the hardware base.Most of them use the GP2015 Zarlink chip for GPS L1as a frontend base and the soft-processor NIOSII on Al-tera FPGA [1]. Together with the Auquarius software, anexperimental single frequency GNSS receiver can be real-ized [2]. In the newest versions of the hardware dual-bandfrontends are provided. The focus has been to be robustenough for low earth orbit operation and less on high pro-cessing power nor on multi signals and systems.

A similar approach is used by the Tampere University ofTechnology using an Altera FPGA with the NIOSII softcore [3]. Three different L1-frequency front-ends fromAtmel, Sige and NEMERIX were used with their setup.Again the limiting factors are the number of channels.There was only space for 16 channels left which is suffi-cient for one system and one signal (GPS L1) but startsalready to get pretty too little if Galileo is added or severalfrequencies and signals. The receiver development was partof the FP7 GRAMMAR project [4].

Also a couple of software defined radio (SDR) approachescan be found. They are all limited by the amount of datawhich can be processed in realtime. Allowing higher band-widths with higher sampling rates reduces the number ofchannels and with that the number of signals and systemswhich can be processed.

Professional OEM Boards

Despite of the academic flexible receivers every marketplayer in the GNSS receiver sector offers several OEMboards for integration in own systems. These OEM boardsare the before mentioned black boxes, which offer high per-formance raw-data and position precision but neither givean insight as to how these measurements are generatednor allow to run own applications on the receiver proces-sor. Two high-end example OEM boards from well knownmanufacturers are described.

The TR-G3T is one of the highend OEM boards fromJavad and provides from revision 5 on three signal bandsfor reception and tracking of GPS L1/L2/L2C/L5, GalileoE1/E5 AltBOC, and GLObal NAvigation Satellite System(GLONASS) L1/L2/L3 [5]. The digital signal processing isexecuted in the TRIUMPH R© Chip offers up to 216 chan-nels split in 72 standard channels with 5 correlators and 48

channels for combined data pilot tracking with 10 correla-tors as well as 48 memory code channels with again 5 cor-relators for Galileo [6]. A fast acquisition engine is usedwith 100k correlator equivalents. The given precision of 10cm code phase and 1 mm carrier phase precision is state ofthe art.

The OEM638 from Novatel is the flagship of their OEMproducts. It also provides state of the art precision [7]. Withup to 240 channels it is able to track GPS L1/L2/L2C/L5,GLONASS L1/L2, Galileo E1/E5a/E5b/AltBOC, BeiDouB1/B2, SBAS and QZSS . The signal processing from in-termediate frequency is done by two MINOS6 R© ASICs [8].As a triple frequency frontend is used not all signals areavailable at the same time.

GOOSE Approach

In this paper we present the GOOSE development chain toovercome the limitation of state of the art receivers and takeGNSS researchers with their development work from ideato demonstrator, assisting them in finding the right receiverconfiguration. The limitations on academic side are thenumber of supported systems, signals and channels and onthe professional side the black-box concept. The require-ments to overcome these limitations is a flexible hardwaresupporting all GNSS bands, a fast hardware signal process-ing with open access, high processing performance and anopen software interface. The steps from demonstrator toa product after successful demonstration with GOOSE canbe kept small with low risk of failure.

This paper is divided into the following sections. In the sec-tion GNSS Receiver with an Open Software Interface thedifferent components which build up the GOOSE platformsoftware are described. This is the new L-Band antenna,the triple band frontend, the baseband hardware implemen-tation on FPGA, the software with the open interface andthe GOOSE development chain.

The ”Preliminary Receiver Evaluation” section gives ashort status about current measurements taken from theGOOSE receiver.

A short sum up of the project goals and the possibilitiescoming with the GOOSE platform is given in section ”Con-lusion”.

GNSS RECEIVER WITH AN OPEN SOFTWAREINTERFACE

Antenna

The GOOSE hardware platform supports two differentGNSS antenna inputs. The first one is for a compact em-bedded antenna. The second one can be used for an exter-nal high-performance GNSS antenna. As the GOOSE an-tenna should provide a possibility for system extendability,both antennas have been designed to operate for all existingand planned satellite navigation frequencies in L-band.

The active stand-alone GNSS antenna has been already de-scribed in [9]. Amongst others, the distinctive feature of thedesign is a broadband square radiator with four triangularlegs and a miniaturized four-point circular polarization feednetwork composed of quarter-circular rings [10]. Throughreplacement of the antenna electronic to the GOOSE hard-ware platform and some modifications of the radiator (fill-ing with a dielectric material) as well as the feed network,a more compact design has been developed – see figure 1.The miniaturized antenna requires a certain ground planesize (about 100 × 100 mm2) to achieve acceptable per-formance in terms of antenna gain, polarization purity andimpedance matching within the specified frequency range.As such, the metalization of the receiver board is used. Theradiation pattern is shown in figure 2.

(a) Radiator (b) Feed network

Figure 1. Embedded GOOSE antenna (60× 60 mm2)

(a) Vertical cut: azim. 45◦ (b) Horizontal cut: elev. 30◦

Figure 2. Radiation pattern of the embedded GOOSE antenna(passive gain in dBic): RHCP (solid line) and LHCP(dashed line) at 1.16 GHz (black) and 1.61 GHz (grey)

Frontend

The GOOSE front end allows the reception of threeseparate GNSS bands with bandwidths between 40 and68 MHz. It is composed of discrete components and in-cludes a low noise amplifier (LNA), band pass filters, aconfigurable RF integrated circuit (IC) with a local oscil-lator (LO) and an analog-to-digital converter (ADC). Thefirst reception channel covers in standard configuration thesignals of GPS L1, Galileo E1, GLONASS G1 and Bei-dou B1, the second channel receives the L2/L2C-band andGLONASS G2 and the third path obtains E5, E5a, E5b, L5

and B2.

The frontend board can be found as one major part of figure6. The block diagram for one reception path is illustratedin figure 3. The first LNA is used to guarantee a low over-all noise figure (NF). A three-way splitter distributes theamplified antenna input signal to the dedicated RF band-pass filter which attenuates out-of-band interferences andselects the reception band. Dielectric RF filters are usedto obtain an excellent group delay behavior. A commercialoff the shelf I/Q downconverter RF IC is used providing azero-IF or low-IF architecture depending on its LO setting.The LO (and therefore the resulting intermediate frequency(IF)), the amplifier gain and the anti-aliasing low-pass filterbandwidth can be configured using SPI and I2C interfaces.The setting of these parameters is performed by the base-band board. A control loop is implemented and sets thevariable gain amplifier according to the ADC-level.

Figure 3. Frontend block diagram of one reception path

The RF IC budget plan concerning its gain, noise figure(NF) and input intercept point 3rd order (IIP3) is given intable 1 for the L1 configuration. Since the RF IC has a75 input impedance, a broadband resistive matching net-work is used for interconnection with the RF filter, addingsome implementation loss. The frontend is designed to beused with an active antenna. The noise figure is then de-termined by the antenna. The DC power supply for theactive antenna is controlled by the baseband board. Threedual-channel ADCs run at 81 MSPS sampling rate and 8bit resolution.

A dedicated clock generation and distribution chip is usedto coherently derive all the frequencies required for theRF IC, the ADCs, and the FPGA. The reference clockcomes from a 10MHz temperature controlled crystal oscil-lator (TCXO). The board provides a buffered clock output.An external reference input is also available where clockswith a higher performance can be attached. The TCXO hasan Allen Deviation of 0.1ppb which shows a good tradeoffbetween cost and performance.

At the moment an alternative front end is brought on theway which supports 4 signal bands from 400 MHz to3.7 GHz and will be also fully supported by the GOOSEplatform.

LNA Splitter RF filter 50→ 75R RF IC overallGAIN [dB] 14 -6 -1.2 -4 75 77.8

NF [dB] 1.2 6 1.2 4 8 6.6IIP3 [dBm] 25 50 50 50 -40 -39.5

Table 1. Frontend budget plan

Baseband

The baseband board consists of a customized PCB con-nected to the front end through a Samtec connector (seefigure 6). The core of the baseband board is a XC7K410TFPGA where a dedicated GNSS HW subsystem is imple-mented. By default it is planned to provide digital sig-nal conditioning and hardware channels for tracking of 90satellite signals using 900 correlators. The versatile track-ing channels can be mapped to any combination of GPS,Galileo and GLONASS signals. On a lower level the sig-nal can be evaluated with the help of raw signal recordingwhich can for example be used for software based acquisi-tion, interference detection, characterization and mitigationpurposes. The tracking channels and the complete hard-ware are controlled via Peripheral Component InterconnectExpress (PCIe) either by a single-board computer (SBC)equipped with an ARM R© A9 processor or a desktop com-puter. In order to allow that, the board is equipped witha standard SBC connector and an optional PCIe riser cardis provided as an adapter between the SBC connector andthe PCIe connector of a PC motherboard. This choice pro-vides additional flexibility on the user environment, sincethe system can be inserted in a common PC for laboratorytests or used as standalone board for on-the-field tests. Bothapproaches offer enough processing power to run complexuser applications and algorithms.

FPGA baseband subsystem

The architecture of the FPGA baseband subsystem is de-picted in figure 4.

The baseband subsystem provides the core functionalitiesrequired in a GNSS receiver using dedicated hardwaremodules controlled through AMBA/AXI ports. A Xilinxcore provides the additional interface between the AXI in-terconnections and the PCIe port which is used to commu-nicate with the SBC or the PC. The physical PCIe is fastenough to handle the amount of data and has the flexibil-ity to use the GOOSE hardware either in a PC or togetherwith a single board computer (SBC, SMARC-sAMX6i) asan embedded platform.

One of the dedicated HW modules instantiated in the sys-tem is a FFT-based acquisition core, which allows the de-tection of L1/E1 satellites, their Doppler and code offset. Atypical acquisition procedure is based on a iteration over allthe possible satellites and Doppler bins. For each try, theacquisition module returns a flag and, in case of success,the peak position and the peak size. The peak size can be

used to make a decision over the Doppler, the peak posi-tion provides a measure of the code offset. Here the userhas already room for algorithmic exploration, i.e., whichDopplers should be tested (large Doppler bin for speed,small Doppler bins for precision) plus the possibility tohave a variable amount of coherent or incoherent accumu-lations. In addition to the acquisition module, the base-band is equipped with dedicated correlators to track the de-tected satellite signals using FLL/DLL/PLL implementedin SW. The current target is to have up to 90 5-tap trackingchannels, i.e., each one equipped with 5 complex correla-tors (VE/E/P/L/VL), which can be mapped to any combina-tion of GPS, Galileo and GLONASS signals and differentfrequency bands. Here the user has a direct access to thecorrelator control interface, the integrate-and-dump valuesneeded for the loop closure and the measurement interface(code phase and carrier phase). The user can specify theintegration time and the measurement rate. Increased flex-ibility is guaranteed by the fact that the loops are closed inSW by the SBC or the PC.

Also, an FPGA is used as target platform. This allowson-the-field deployment of different architectural config-urations tailored to specific user needs. For example, theuser can decide to remove the acquisition module and useonly the correlators to perform a Tong-search acquisitionand get a large amount of channels. Or the user can choosebetween different channel configurations: instead of thestandard one, a configuration with 14 32-tap channels foradvanced tracking features (e.g. multipath detection) or aconfiguration with up to 150 3-tap channels to support onlyBPSK signals.

The main software building blocks, like tracking loop con-trol, measurement generation and PVT are all not hard-

Figure 4. FPGA baseband block diagram

coded in the baseband component but separated over theflexible interface. They are available as replaceable soft-ware components that can be used as-is in the user applica-tion or replaced by the customized implementations.

Open software interface

In the field of GNSS there exist few standards for data ex-change and a multitude of proprietary protocols specific toindividual receiver manufacturers. For raw measurementsthe Receiver Independent Exchange Format (RINEX) textprotocol can be considered standard. The format is textbased and designed for post-processing use. It cannot beused straightforward for real-time data exchange betweena receiver baseband part providing the measurements anda consumer of these measurements, e.g. a standard PVTor coupling for sensor fusion using an Intertial Naviga-tion System (INS). Another widely used protocol used insatellite navigation devices is NMEA 0183. It is simple toprocess however very limited to deliver measurements ofa receiver. For higher demands of bandwidth, e.g. whenexchanging raw measurements like carrier phase or coderange measurements or even undecoded subframe content,it is unsuitable. For RTK applications as also consideredin the project GOOSE other approaches are commonly fol-lowed but most of them are tuned towards a special use caseand therefore limited.

The goal of Open GNSS Receiver Protocol (OGRP), as it isdefined as part of the development undergone in the projectGOOSE, is to offer a well-defined and self-describing for-mat in terms of available measurements and units while be-ing vendor neutral. It was also required to represent all dataof current GNSS formats also in OGRP. One requirementin design of the protocol was to allow archiving messagesas well as allowing real-time exchange of data between dif-ferent components of a system, e.g. a low-level receiveroutputting measurements and a high-level consumer of themeasurements. The format also fulfills the demand to beeasily readable and simple while still providing flexibilityfor future enhancements and vendor specific data. To ful-fill this specification a protocol based on JavaScript ObjectNotation (JSON) was designed. Many libraries for imple-mentation in various programming languages exist to parsethe data. In comparison to XML there is less keyword over-head and an even easier specification. OGRP is meant to beextend able and future-proof rather than optimized regard-ing performance for a specific case. The main messages arealready defined and some of them can be extended by ven-dor specific properties. Messages that are not defined canbe easily defined into the common scheme based on cus-tom requirements. Modern processing platforms are pow-erful enough to handle OGRP in real-time with insignif-icant processor load. Though it is a text based protocol,it can still be used efficiently by adding a layer of com-pression around it, e.g. for communication over a physicallink with limited bandwidth. The transport mechanism, e.g.

TCP, RS232, etc., is not part of the OGRP definition. Anymeans of exchanging serial data can be used. The simpleLine Delimited JSON standard is proposed to use in streamprotocols.

The GOOSE receiver comes already with example imple-mentation of the signal processing GPS L1 and L5 as wellas for Galileo E1 and E5a. Further signals like GPS L2Cand Galileo E5 AltBOC processing are currently under de-velopment in followup projects based on the GOOSE plat-form.

These software modules are interconnected via OGRP. Aproposal for standardization exists and is available in a pub-lic github repository [11].

Development chain

The development chain is setup by different hardware vari-ants and a software development environment supportingthese.

Different hardware variants

The GOOSE hardware platform is available as a PCIe slotcard setup as well as a portable version which uses a SBCas processing platform. This is possible because of usingthe same physical interface PCIe between the software partand the hardware of GOOSE for both hardware variants.

Figure 5. PC based receiver hardware

The PC based variant shown in figure 5 builds the start-ing point for the development. The developer has highprocessing power and an easy to use, comfortable Ubuntulinux platform. With the PC based platform tests with sig-nal generator or stationary antennas can be conducted. ThePC based variant can probably not setup enough mobile forgeodetic field tests but could be used in the PC racks in theboot of cars prepared for development.

The embedded variant marks the technology readiness level(TRL) 6 which means it is foreseen to conduct field testswith this platform (see figure 6). The step from PC based

platform to embedded is kept small as the development en-vironment (see next section) fully supports both platforms.For a later product development the platform has to be op-timized in form factor and power consumption. In that wayGOOSE provides a complete development chain support-ing developers from a PC based solution to a field test readyembedded professional receiver.

Software development environment

The goals of the development chain for GOOSE users areto have minimal effort to use a PC based GNSS platformas well as do a small step to go to an embedded platformbased on a compatible architecture. The SBC as used aspart of the embedded platform is provided with Linaro, anUbuntu based GNU/Linux distribution for ARM architec-ture, current version 12.04 LTS precise pangolin. To beable to develop applications for the target platform OS adevelopment package is provided which should make thisprocess as easy as possible. The proposed PC based devel-opment environment is Ubuntu for x86 64.

EXAMPLE RTK APPLICATION SOFTWARE

In order to provide precise position estimates, an RTK unitis implemented and is evaluated in post processing whichoperates on the platform developed. Comparing with code-range based GNSS receivers, an RTK system has morecomplicated architecture in aspect of the algorithms, com-munication, infrastructures, and etc. The followings are thekey factors for RTK system development.

• The carrier-phase measurements based on dual-frequency

• Integer ambiguity resolution techniques

• RTK reference stations, i.e. International GNSS Ser-vice (IGS) sites

Figure 6. Embedded receiver hardware

• Communication link between reference and rover

Carrier-phase measurements can be the key factor toachieve more accurate positioning estimates, since it pro-vides more fine resolution and more accurate ranges thanpseudorange measurements. However it has integer cycleambiguities which are not able to be estimated due to theincrease of unknown parameters when generating carrier-phase ranges between satellites and receivers. In orderto solve the problem, several integer ambiguity resolutiontechniques have been studied and Least-squares AmbiguityDecorrelation Adjustment (LAMBDA) technique is wellknown as one of the best integer ambiguity estimators. Inthis paper LAMBDA has been implemented to provide thebest RTK performance through finding optimal ambiguitysolutions. In addition, the relative positioning scheme isalso fundamental for RTK system, since it reduces the un-known parameters required to estimate through removingcommon biases between measurements from different lo-cations. Although several differencing methods can be uti-lized corresponding to Linear Combination models, suchas ionosphere free model and geometry free model, Dou-ble Difference (DD) is generally used for removing clockbias and ionosphere delay. Based on such a requirement,it needs the reference station and the appropriate commu-nication link to deliver raw measurements to users. Ingeneral, Radio Technical Commission for Maritime Ser-vices (RTCM) standard is widely used, and users can eas-ily receive it from IGS sites. In this paper, RTK referencestation which supports RTCM standard via User DatagramProtocol (UDP) based on wired and wireless connection isimplemented.

Figure 7. Architecture of the implemented RTK system

Figure 7 shows the RTK system architecture implementedfollowing with generic RTK architecture. It has severalcomponents, such as receiver, RTK engine and auxiliaryfunctions, Interface APIs, and GUI web-server. The fol-lowings are descriptions of each operation.

• Receiver

– Generation of raw measurements and OGRP

– Interface between hardware and RTK unit

– Receiver configuration and initialization

• RTK unit

– RTK engine: operation in integer ambiguityresolution and estimation in precise positions

– TCP: Interface module to receive OGRP fromreceiver. Also it supports RTK outputs inOGRP to web-server

– Reference station: RTCM standard generationand transferring it to RTK engine via wired orwireless connection (UDP)

– Auxiliary functions: imrpoving quality of inte-ger ambiguity estimates and preventing abnor-mal data

• GUI web-server

– User interface and GUI for RTK outputs

– Interface between RTK unit and server via TCP

As mentioned in the section above, OGRP based on JSONprovides the flexible data protocol for GNSS receivers,which makes it available to easily generate a user definedprotocol. The appropriate data protocol has been designedto include all raw measurements, ephemerides, clocks, andinitial positions. The RTK unit defines two types of OGRPas the input and output data corresponding to data flow andits requirement. The physical links are used in wired TCPconnection via LAN.

Reference station tracks all visible satellite signals and itprovides raw measurements having the highest accuracy.Based on such a high performance, it generates and trans-mits RTCM standard data including raw measurements, an-tenna information, and data relating to the station. In gen-eral, RTCM standard 2.3 and 3.1 version are widely used,and transferred to RTK user through Ethernet-link. The im-plemented reference station provides the same functions asgeneric reference stations and RTCM standard 2.3 and 3.1version are also supported.

When RTK unit processes RTCM standard, time synchro-nization between RTCM standard and OGRP is quite im-portant because RTK positioning performance becomesworse and integer ambiguity searching would be failed dueto data latency. Therefore the data latency should be main-tained within the reasonable time range from several mil-liseconds to seconds. To cope with a large data latency,RTK unit stacks several OGRP messages ( 10 seconds) tofind the right data having the same measurement time. Af-ter synchronization, raw measurements can be used to cal-culate in DD. UDP link is used for RTCM standard con-nection using LAN and WLAN via UMTS device.

As RTK engine is the core part in RTK the unit, it pro-vides precise position estimates, integer ambiguities, pre-cise time, and others relating to navigational information.LAMBDA estimates the optimal integer ambiguity solu-tions, and RTK position estimator fixes precise positionshaving the centimeter-level accuracy. Such outputs aretransmitting to web-server which tracks and demonstratesRTK positioning outputs in real-time and evaluates its per-formance. Its communication link is also based on TCPconnection.

All of RTK unit modules described in this paper are imple-mented in software APIs and individual programs to eas-ily perform unit-tests and to guarantee the performance ofeach module without collisions between software modules.Their performance is evaluated in post processing and filetest.

Reference Station

The Reference Station (RS) tracks all visible satellite sig-nals and provides measurements of the highest accuracy. Itis capable to generate output RTCM standard V2.3 / V3.1delivering it to RTK rover through Ethernet port. Correc-tions are broadcasted from the reference receiver placed ata known location. There is also the possibility to store themessages within a log file.

The data link between the RTK rover and the RS is criticalsince in case of a correction failure or latency the systemperformance may be degraded. Therefore, a high data rateUMTS network is used to receive data corrections from ref-erence station over UDP.

PRELIMINARY RECEIVER EVALUATION

In a first development stage the PC based platform is setupin a laboratory connected to a roof antenna receiving a realGNSS signal from satellites. This setup was verified to suc-cessfully track GPS L1 C/A + L5I. Next step in the verifi-cation is to verify tracking of Galileo E1B + E5aI using theGalileo FOC satellites.

Example output of a measurement message in OGRP for-mat showing the measurements of two channels trackingGPS satellite nr. 14, a Block IIR(M) satellite. One chan-nel is successfully tracking GPS L1 C/A, the other one issearching for the L5 signal, which is actually not presenton this satellite:

{"ch_meas":[{"carrier_phase":198694980.7956696,"ch_nr":3,"channel_state":"SYNCED","doppler":-2023.860188201070,"gnss":"GPS","locktime":4660.0,"pseudorange":22571871.58366107,"sat_id":14,"signal_type":"L1CA","snr":48.07287465853545},{"carrier_phase":34179599168.21297,"ch_nr":43,"channel_state":"SEARCHING","code_phase":0.0,"doppler":1894.189696758986,"gnss":"GPS","locktime":0.0,"pseudorange":-1.0,"sat_id":14,"signal_type":"L5I","snr

":31.21265038674681}],"id":"measurement","protocol":"OGRP1","sw_version":32768,"time_status":"FINESTEERING","timestamp":1116253497.0}

As OGRP is based on JSON an evaluation is straight for-ward based on the easily parseable message content. Fig-ure 8 shows a “Code minus double carrier” (CMDC) eval-uation of a one-hour long measurement based on a simpleevaluation script reading in JSON using a standard libraryin python programming language, calculating the CMDCfrom the data included in OGRP for one satellite signal andplotting the values together with statistical parameters.

Figure 8. Evaluation of OGRP data yielding CMDC from a pre-liminary roof antenna setup showing a mean code jitterof 1.8 m (GPS L1 C/A) / 0.5 m (GPS L5I)

For this measurement the Phase Locked Loop (PLL) filterorder has been 3 with a bandwidth of 10 Hz and for theDelay Locked Loop (DLL) filter the order has been 2 witha bandwidth of 1 Hz. For L1 the early late spacing wasapproximately 0.4 and for L5 1.0 chips.

CONCLUSION

The GOOSE hardware platform provides to the GNSScommunity a development chain from experimental PCIeslot card to a professional embedded GNSS receiver. TheGOOSE platform can be seen as a hardware-assisted soft-ware receiver where computational complex methods areimplemented on digital FPGA hardware whereas algo-rithms can be developed and implemented on receiver sideon a user friendly GNU/Linux system. A transparent ac-cess to the hardware is made available via the Open GNSSReceiver Protocol which gives deep access to the hardwarecontrol and enables deeply coupling of inertial sensors andoptimized precise positioning solutions. It is therefore tar-geted at researchers, software developers and algorithmexperts to build up new methods and applications in theGNSS area. At the end of the project 20 GOOSE platformswill be available for selected researchers for free. The main

benefits for potential product developers are an improveddevelopment process for GNSS receiver firmware, the pos-sibility to embed application-specific software on the re-ceiver, an access to all potentially relevant data for an im-proved position solution based on open white box approachand the enabling of deeply coupling of inertial sensors.

ACKNOWLEDGMENT

The GOOSE project is funded by the ”Bundesministeriumfur Wirtschaft und Energie” (German Federal Ministry forEconomic Affairs and Energy).

REFERENCES[1] N. Shivaramaiah, J. Wu, J. W. Cheong, M. Choudhury, and

K. Parkinson, “Annex 5. Developing a Satellite Naviga-tion Receiver for the Space Mission.” online, June 2013.http://www.garada.unsw.edu.au/Final%20Report/Annex%205.%20Developing%20a%20Satellite%20Navigation%20Receiver%20for%20the%20Space%20Mission.pdf.

[2] K. P. Eamonn P. Glennon, Peter J. Mumford, “Aquar-ius Firmware for UNSW Namuru GPS Receivers.” online,November 2011.

[3] T. Paakki, J. Raasakka, F. Della Rosa, H. Hurskainen, andJ. Nurmi, “Tutgnss university based hardware/software gnssreceiver for research purposes,” in Ubiquitous PositioningIndoor Navigation and Location Based Service (UPINLBS),2010, pp. 1–6, Oct 2010.

[4] S. Sand, “Galileo Ready Advanced Mass MArket Receiver,Final Report,” tech. rep., DLR, 2011.

[5] Javad, “TR-G3T.” online, October 2012. http://www.javad.com/downloads/javadgnss/sheets/TR-G3T_Rev.5_Datasheet.pdf.

[6] Javad, “Triumph Chip.” online, 2008. http://www.javad.com/downloads/javadgnss/sheets/TRIUMPH.pdf.

[7] Novatel, “OEM638.” online, March 2015. http://www.novatel.com/assets/Documents/Papers/OEM638-PS-D17916.pdf.

[8] Novatel, “OEM6 R© Family; Installation and Opera-tion User Manual.” online, January 2015. http://www.novatel.com/assets/Documents/Manuals/om-20000128.pdf.

[9] A. E. Popugaev and R. Wansch, “Multiband GNSS an-tenna,” A. Heuberger, G. Elst, R. Hanke (Ed.): Micro-electronic Systems: Circuits, Systems and Applications,Springer, Berlin/Heidelberg, 2011.

[10] A. E. Popugaev, Miniaturisierte Mikrostreifenleitungs-Schaltungen bestehend aus zusammengesetzten Viertelkreis-ringen. PhD thesis, Technical University Ilmenau, Germany,2014.

[11] “OGRP - the Open Gnss Receiver Protocol,” 2014. https://github.com/Fraunhofer-IIS/ogrp.