RT-PPP: Development of a real-time PPP processing facility · 6.2 RTCM-SSR (WP 5200) ..... 78 . PPP_Serve– Network based GNSS Phase Biases to ... Figure 3-7: Bias types of modified

PPP_Serve– Network based GNSS Phase Biases to

enhance PPP Applications Final Report Date:26.02.2014 Page 1 / 86

Network based GNSS Phase Biases to enhance PPP Applications – A new Service Level of GNSS Reference Station Providers

Final Report

Prepared by: Vienna University of Technology (TUW), Vienna, Austria Graz University of Technology (TUG), Graz, Austria Wien Energie Stromnetz GmbH (WS), Vienna, Austria



This page has intentionally been left blank.



Document Information:

Project: PPPserve – Network based GNSS Phase Biases to enhance PPP Applications – A new Service Level of GNSS Reference Station Providers Project Short Title: PPP-Serve Document Title: Final Report Version: 1.1 Date: 26.02.2014 Number of Pages: 81 File Name: PPPServe_FR_V1.1.docx



Table of Contents

Introduction .............................................................................................................................................. 15 1 Scope and Administrative management ..................................................................................... 17 1.1 Scope of the project ............................................................................................................................ 17 1.2 Project Partners................................................................................................................................... 18 1.3 Work Package Breakdown structure ................................................................................................... 19 1.4 Technical work .................................................................................................................................... 20 1.5 Meetings ............................................................................................................................................. 20 1.6 Time schedule ..................................................................................................................................... 21 1.7 Deliverables ......................................................................................................................................... 22 1.8 Milestone Payment Plan ..................................................................................................................... 22 1.9 Scientific Presentations ....................................................................................................................... 23 2 Fundamentals ........................................................................................................................... 24 2.1 Motivation ........................................................................................................................................... 24 2.2 Background PPP .................................................................................................................................. 25 3 State of the Art and Design ........................................................................................................ 27 3.1 PPP Model (WP 2100) ......................................................................................................................... 27 3.2 De-coupled clock model (WP2200) ..................................................................................................... 31 3.2.1 Model equations ................................................................................................................................. 31 3.2.2 Wide-lane ambiguities from reference station network .................................................................... 32 3.2.3 N1 fixing from zero-difference observations ...................................................................................... 32 3.2.4 PPP solution with CNES data ............................................................................................................... 34 3.2.5 Comparison of Wide-lane observables with and without using CNES bias products ......................... 37 3.3 Phase recovery from fractional parts (WP2300) ................................................................................. 39 3.3.1 Narrow-lane fixing and estimation of the phase biases ..................................................................... 39 3.4 Model Selection (WP 2400)................................................................................................................. 41 4 Simulation and Post-Processing (WP3000) ................................................................................. 42 4.1 Bias Simulation (WP3100) ................................................................................................................... 42 4.2 Post processed Satellite Phase Biases and their stability (WP3200) .................................................. 45 4.2.1 The software PPP Post ........................................................................................................................ 45 4.3 Application of Biases (WP3300) .......................................................................................................... 58 4.3.1 PPP observation model ....................................................................................................................... 58 4.3.2 WL ambiguity fixing ............................................................................................................................. 59 4.3.3 NL ambiguity fixing .............................................................................................................................. 60 4.3.4 PPP with fixed ambiguities .................................................................................................................. 61 4.3.5 PPP convergence depending on quality of approximate coordinates ................................................ 62 5 Real-Time Processing (WP 4000) ................................................................................................ 64 5.1 Real-Time Global Corrections (WP 4100) ............................................................................................ 64 5.2 Real-Time Phase Bias Generation WL and NL (WP 4200) ................................................................... 66 5.3 Forwarding Biases to Rover (WP4300)................................................................................................ 68 5.4 Rover PPP-Applications (WP4400) ...................................................................................................... 70 5.4.1 Results of Ambiguity fixing with UPDs from PPPserve ........................................................................ 70 5.4.2 Correlation of ambiguities .................................................................................................................. 74 6 Future Developments and Products (WP 5000) .......................................................................... 76 6.1 Service Level of GNSS service provider (WP 5100) ............................................................................. 76 6.2 RTCM-SSR (WP 5200) .......................................................................................................................... 78



6.3 Conclusions ......................................................................................................................................... 81 7 Annex ....................................................................................................................................... 82 7.1 Annex 1: Programm EPOSA - Anwendertreffen .................................................................................. 82 7.2 Annex 2: Questionnaire – EPOSA Anwendertreffen ......................................................................... 83 7.3 Annex 3: Questionnaire GeoAustria ................................................................................................... 85



List of Tables

Table 1-1: RT-PPP deliverables .............................................................................................................................. 22 Table 1-2: Milestone Payment Plan ....................................................................................................................... 22

List of Figures

Figure 1-1: Main PPP error sources ....................................................................................................................... 17 Figure 1-2: Work package Breakdown Structure .................................................................................................. 19 Figure 1-3: Time schedule of PPP-Serve ................................................................................................................ 21 Figure 2-1: EPOSA station network ....................................................................................................................... 24 Figure 3-1: Float solution (GRAZ256.11O) with Broadcast Eph. + IGS real-time corrections ................................ 28 Figure 3-2: Ambiguities of float solution with IGS real-time corrections .............................................................. 28 Figure 3-3: Float ambiguity of PRN9 ...................................................................................................................... 29 Figure 3-4: Advantages and drawbacks of the method of integer PPP ................................................................. 34 Figure 3-5: Single station solution with and without integer ambiguity resolution ............................................. 34 Figure 3-6: RTCM messages of CLK9B converted to ASCII by PPP-wizard demonstrator based on BNC 2.4 ........ 35 Figure 3-7: Bias types of modified RTCM message 1059 ...................................................................................... 35 Figure 3-8: Example of wide-lane observable of a single PRN (receiver bias still present)................................... 36 Figure 3-9: Melbourne-Wübbena SD-observable of all satellites without the use of CNES phase biases ............ 37 Figure 3-10: Melbourne-Wübbena SD-observable of all satellites using of CNES phase biases ........................... 37 Figure 4-1: NEU coordinates differences of simulated data of station ADIS ........................................................ 42 Figure 4-2: Ambiguity float estimates of simulated data ...................................................................................... 43 Figure 4-3: Integer SD-WL ambiguities for simulated data ................................................................................... 43 Figure 4-4: Satellites' elevation of simulated data ................................................................................................ 43 Figure 4-5: Integer SD-NL ambiguities for simulated data .................................................................................... 44 Figure 4-6: European network ............................................................................................................................... 45 Figure 4-7: Design of PPP Post ............................................................................................................................... 47 Figure 4-8: ZD MW LEICA GRX1200PRO ................................................................................................................ 49 Figure 4-9: ZD MW LEICA GRX1200GGPRO ........................................................................................................... 49 Figure 4-10: ZD MW TRIMBLE NETR5 .................................................................................................................... 49 Figure 4-11: ZD MW JPS LEGACY ........................................................................................................................... 49 Figure 4-12: SD MW fractional parts PRN 12 - PRN 24 .......................................................................................... 50 Figure 4-13: SD MW fractional parts PRN 1 - PRN 14 ............................................................................................ 50 Figure 4-14: SD MW positive fractional parts PRN 12 - PRN 24 ............................................................................ 50 Figure 4-15: SD MW positive fractional parts PRN 1 - PRN 14 ............................................................................. 50 Figure 4-16: SD WL UPD PRN 16 - PRN 30 ............................................................................................................. 51 Figure 4-17: WL UPD PRN 12 - PRN 29 ................................................................................................................. 51 Figure 4-18: Comparison of the ZTD for station CAEN .......................................................................................... 52 Figure 4-19: Comparison of the ZTD for station ROVE .......................................................................................... 52 Figure 4-20: SD NL UPD PRN 16 – PRN 18 ............................................................................................................. 54 Figure 4-21: SD NL UPD PRN 1 – PRN 23 ............................................................................................................... 54 Figure 4-22: SD NL UPD PRN 8 – PRN 28 ............................................................................................................... 54 Figure 4-23: SD NL UPD PRN 9 – PRN 15 ............................................................................................................... 54 Figure 4-24: Stability of SD WL UPD PRN 9 – PRN 10 ............................................................................................ 55



Figure 4-25: Stability of SD WL UPD PRN 12 – PRN 2 ............................................................................................ 55 Figure 4-26: Stability of SD WL UPD PRN 9 – PRN 15 ............................................................................................ 56 Figure 4-27: Stability of SD WL UPD PRN 12 – PRN 29 .......................................................................................... 56 Figure 4-28: Stability of SD WL UPD PRN 9 – PRN 18 ............................................................................................ 56 Figure 4-29: Stability of SD WL UPD PRN 12 – PRN 4 ............................................................................................ 56 Figure 4-30: Comparison of SD WL UPDs .............................................................................................................. 57 Figure 4-31: ZD PPP solution with initial coordinates with arbitrary accuracy ..................................................... 62 Figure 4-32: ZD PPP solution with approximate position of 1 m accuracy .......................................................... 62 Figure 4-33: ZD PPP solution with approximate position of 0.5 m accuracy ........................................................ 63 Figure 4-34: ZD PPP solution with approximate position of 0.1 m accuracy ........................................................ 63 Figure 4-35:ZD PPP solution with approximate position of 0.05 m accuracy ....................................................... 63 Figure 5-1: Current stations of the RTIGS-Network .............................................................................................. 64 Figure 5-2: Modified design of the PPP Post software .......................................................................................... 66 Figure 5-3: SD PPP float solution of GRAZ0880.13O ............................................................................................. 70 Figure 5-4: Satellites' Elevation of GRAZ0880.13O ................................................................................................ 70 Figure 5-5: Skyplot of GRAZ0880.13O ................................................................................................................... 71 Figure 5-6: PPP fixed solution of GRAZ0880.13O .................................................................................................. 71 Figure 5-7: Satellites with fixed NL ambiguities in GRAZ0880.13O ....................................................................... 72 Figure 5-8: Satellites with fixed WL ambiguities in GRAZ0880.13O ...................................................................... 72 Figure 5-9: PPP fixed solution of DALA088.13O .................................................................................................... 73 Figure 5-10: Skyplot of DALA088.13O ................................................................................................................... 73 Figure 5-11: Satellites with fixed NL ambiguities in DALA0880.13O ..................................................................... 73 Figure 5-12: Satellites with fixed WL ambiguities in DALA0880.13O ................................................................... 73 Figure 5-13: Satellite Skyplot of GRAZ0870.13O ................................................................................................... 74 Figure 5-14: Satellite elevation plot of GRAZ0870.13O ....................................................................................... 74 Figure 5-15: Correlation plot of GRAZ0870.13O in epoch 10 ................................................................................ 75 Figure 5-16: Correlation plot of GRAZ0870.13O in epoch 420 .............................................................................. 75 Figure 5-17: Correlation plot of GRAZ0870.13O in epoch 5000 ........................................................................... 75 Figure 5-18: Correlation plot of GRAZ0870.13O in epoch 9420 ........................................................................... 75 Figure 6-1: EPOSA correction data streams .......................................................................................................... 76 Figure 6-2: Invitation EPOSA Anwendertreffen 2013 ............................................................................................ 77 Figure 6-3: PPP-AR solution (coordinates constrained to 1 m) ............................................................................. 79 Figure 6-4: PPP-AR solution (coordinates constrained to 5 cm) ........................................................................... 79 Figure 6-5: PPP-AR solution (coordinates constrained to 1 cm) ........................................................................... 79



Reference Documents

[CALAIS 2006]

Calais E, Han JY, DeMets C, Nocquet JM (2006): Deformation of the North American plate interior from a decade of continuous GPS measurements. J Geophys Res 111:B06402. doi:10.1029/2005JB004253.

[COLLINS 2010] P. Collins, S. Bisnath, F. Lahaye, P. Heroux (2010): “Undifferenced GPS Ambiguity Resolution Using the Decoupled Clock Model and Ambiguity Datum Fixing”, Navigation, Journal of the institute of Navigation, Vol. 57, N° 2, 2010.

[EUREF] http://www.epncb.oma.be/

[GE 2008] M. Ge, G. Gendt, M. Rothacher, C. Shi, J. Liu (2008): “Resolution of GPS carrier-phase ambiguities in precise point positioning (PPP) with daily observations”. Journal of Geodesy Volume 82, Number 7, 389-399, DOI: 10.1007/s00190-007-0187-4.

[GENG 2010] J. Geng, X. Meng, A. Dodson, F. Teferle (2010): "Integer ambiguity resolution in precise point positioning: method comparison", Journal of Geodesy Volume 84, 569–581, DOI 10.1007/s00190-010-0399-x.

[GIOMO_D6_FR] Final Report of project GIOMO, ASAP7, version 1.0, July 2012

[GLO ICD 2008] GLONASS Interface Control Document, Edition 5.1, Moscow 2008

[GLONASS HP] GLONASS Information Home page by the Federal Space Agency - Information-analytical centre: http://www.glonass-ianc.rsa.ru/en/GLONASS/ (04.05.2012).

[HOWE 2007] B. Hofmann-Wellenhof, H. Lichtenegger, E. Wasle (2007): GNSS – GPS, Glonass, GALILEO and more, Springer Wien New York

[ICD] NAVSTAR GLOBAL POSITIONING SYSTEM INTERFACE SPECIFICATION IS-GPS-200, Revision D, IRN-200D-001, 7 March 2006, Navstar GPS Space Segment/Navigation User Interfaces

[KLO 1987] Klobuchar JA (1987): Ionospheric Time-Delay Algorithm for Single frequency GPS Users, Aerospace and Electronic Systems, IEEE Transactions on, 1987 – ieeexplore.ieee.org.

[KOUBA 2001] J. Kouba and P. Héroux (2001): Precise Point Positioning Using IGS Orbit and Clock Products, GPS Solutions, Vol.5 Nr. 2

[LAURICHESSE 2009] D. Laurichesse, F. Mercier, J.P. Berthias, P. Broca, L. Cerri (2009): “Integer Ambiguity Resolution on Undifferenced GPS Phase Measurements and its Application to PPP and Satellite Precise Orbit Determination”, Navigation, Journal of the institute of Navigation, Vol. 56, N° 2, Summer 2009.

[MELBOURNE 1985] Melbourne, W. G. (1985): The Case for Ranging in GPS Based Geodetic Systems, in Proceedings of the 1st International Symposium on Precise Positioning with the Global Positioning System, edited by Clyde Goad, pp. 373–386, US Department of Commerce, Rockville, Maryland.

[MOPS] Minimum Operational Performance Standards for Global Positioning System / Wide Area Augmentation System Airborne Equipment: RTCA Do-229C Appendix A: WAAS Signal Specification.

[NIELL 1996] Niell, A. E., Global mapping functions for the atmosphere delay at radio wavelengths, J. Geophys. Res., 100, 3227-3246, 1996.

[NMEA] NMEA 0183 Standard, Version 3.01, 01/2002

[NOVATEL 2010] OEM6™ Family Firmware Reference Manual, Revision 1, Novatel Inc., 2010

http://www.glonass-ianc.rsa.ru/en/GLONASS/



http://www.novatel.com/assets/Documents/Manuals/om-20000129.pdf

[RAPPP FR] Final Report of project RA-PPP (ASAP 6).

[RTCM10403] Radio Technical Commission for Maritime Services (2011): Differential GNSS (Global Navigation Satellite Systems) Services – Version 3. RTCM 10403.1 RTCM Paper 142-2011/SC104-STD with Amendment 5. Version 3. July 1.

[RTPPP MT] Midterm Report of project RT-PPP (ASAP 7).

[RTPPP TN5] Technical Note 5 of RT-PPP: Test Document.

[TEUNISSEN 1993] Teunissen, P.J.G. (1993). Least-squares estimation of the integer GPS ambiguities. Invited lecture. Section IV Theory and Methodology, IAG General Meeting. Beijing,China. (16 p.) Also in Delft Geodetic Computing Centre LGR series No. 6.

[TEUNISSEN 2001] Teunissen, P.J.G. 2001. GNSS ambiguity bootstrapping: theory and application. Proceedings of KIS2001, June 5-8 2001, pp. 246-254. Banff, Canada: University of Calgary.

[WÜBBENA 1985] Wübbena, G. (1985): Software Developments for Geodetic Positioning with GPS Using TI 4100 Code and Carrier Measurements, in Proceedings First International Symposium on Precise Positioning with the Global Positioning System, edited by Clyde Goad, pp. 403–412, US Department of Commerce, Rockville, Maryland.



Abbreviations

The specific abbreviations used in the document are provided below.

ASAP Austrian Space Applications Programme by the FFG

BKG Bundesamt für Kartographie und Geodäsie (Federal Agency for Cartography and Geodesy)

BNC BKG Ntrip Client

BNS BKG Ntrip server

C/A Coarse/acquisition

CDR Critical Design Review

CODE Center for Orbit Determination in Europe

COTS Common of the shelf

CRC Cyclic redundancy check

DCB Differential code bias

DGPS Differential GPS

DOP Dilution of precision

FFG Austrian Research Promotion Agency

FR Final Review

GDOP Geometric DOP

GLONASS Globalnaja Nawigazionnaja Sputnikowaja Sistema

GNSS Global Navigation Satellite Systems

GPRS General packet radio service

GPS Global Positioning System

HDOP Horizontal DOP

IGS International GNSS Service

IONEX Ionosphere map exchange format

IP Internet protocol

ITRF International Terrestrial Reference Frame

LC Linear Combination



MR Midterm Report

NL Narrow lane

NMEA National marine electronics association

Ntrip Networked transport of RTCM via internet protocol

OS Operating system

PDOP Position DOP

PE Position error

PPP Precise Point Positioning

PVT Position, Velocity, Time

PZ90.02 Parametri Zemli 90.02 (Russian Reference System for GLONASS)

RAIM Receiver Autonomous Integrity Monitoring

RA-PPP Innovative Algorithms for Rapid Precise Point Positioning, ASAP 6 project

RINEX Receiver Independent EXchange Format

RMS Root mean square

RTCM Radio Technical Commission for Maritime services

RTK Real-Time Kinematic

RT-PPP Real-time PPP

SBAS Satellite Based Augmentation System

SD Single difference

SNR Signal to noise ratio

STEC Slant Total Electron Content

SU Soviet Union

SV Space Vehicle

TCP Transmission Control Protocol

TDOP Time DOP

TEC Total Electron Content

TN Technical Note

TRR Technical Readiness Review



UDRE User Differential Range Error

UMTS Universal Mobile Telecommunication System

USNO United States Naval Observatory

USB Universal serial bus

UTC Universal Time Coordinated

WGS84 World Geodetic System 1984

WL Wide lane

ZTD Zenith Total Delay

ZWD Zenith Wet Delay



Zusammenfassung

Das Projekt PPPserve (Network based GNSS Phase Biases to enhance PPP Applications – A new Service Level of GNSS Reference Station Provider) zielte auf die Entwicklung und Umsetzung geeigneter Algorithmen zur schnellen GNSS-basierten Positionierung mit cm-Genauigkeit ab. Im Gegensatz zur Funktionsweise gegenwärtig verfügbarer RTK (Real-Time-Kinematic) Techniken, bei denen GNSS Referenzstationsbetreiber den Nutzern bodengestützt standardisierte Beobachtungskorrekturen (RTCM-Standard) für Differenzverfahren anbieten, gelingt im PPP-Modell die Positionsbestimmung auf Einzelpunktniveau (also nicht über Basislinienbildung). Die führenden GNSS-Empfängerhersteller haben dieser Entwicklung bereits im Mai 2011 Rechnung getragen und einen neuen PPP-kompatiblen RTCM Standard (RTCM 3.1, Anhang 5, State Space Representation) verabschiedet, welcher künftig PPP Anwendungen favorisiert und erstmals ab 2014 in der ausgelieferten Hard- und Software von kommerziellen GNSS-Empfängern verfügbar wird. Dies zwingt auch die Korrekturdienstanbieter ihren Kunden geeignete Services (RT-Correction Data Streams) anzubieten. Globale SSR Informationen wie Satellitenbahn- und Uhrverbesserungen erlauben im PPP-Modell allerdings noch keine Phasenmehrdeutigkeitslösung. Damit benötigt man im PPP-Modell noch immer deutlich längere Konvergenzzeiten (10-20 Minuten) als mit RTK Verfahren. PPPserve geht einen Schritt weiter und beschäftigt sich mit der Unterstützung der PPP-Nutzer bei der Phasenmehrdeutigkeitslösung, welche, geeignete Randbedingungen vorausgesetzt, die Konvergenzzeit auf wenige Sekunden reduzieren kann. Es wurden die beiden optionalen Möglichkeiten der Satelliten-Phasenbiasfestlegung untersucht und eine Software entwickelt, welche diese Biases aus den Beobachtungsdaten eines globalen GNSS-Netzes IGS) und des regionalen GNSS-Service-Providers (WienEnergie-Stromnetz/EPOSA) bestimmt. Diese Parameter werden dann dem Nutzer als neuer Servicelevel in einem derzeit noch proprietären Format weitergeleitet und im Rahmen der Mehrdeutigkeitslösung im Feld zur Punktbestimmung herangezogen. Eine standardisierte Weitergabe der Satelliten-Phasen-Offsets wird derzeit im Rahmen einer RTCM 3.2 Weiterentwicklung international diskutiert. PPP-Serve hat dafür ein Konzeptvorschlag erarbeitet. Das Projektkonsortium besteht aus dem Department Geodäsie&Geoinformation (vormals Institut für Geodäsie und Geophysik) der TU-Wien, dem Institut für Navigation (INAS) der TU-Graz, sowie der Wien-Energie Stromnetz GmbH.



Abstract

The project PPPserve (Network based GNSS Phase Biases to enhance PPP Applications – A new Service Level of GNSS Reference Station Provider) aimed at the development and realization of adequate algorithms to enhance fast GNSS based point positioning at cm level. Regularly established RTK-techniques (Real-Time-Kinematic) are based on building and processing observation differences while the required observation corrections are forwarded to the user community in the standardized RTCM format. In contrast to the differencing technique, the PPP-model is based on code/phase single point positioning, which requires a limited amount of correction data just transferring model parameters instead of observation corrections. Leading manufacturers have already in 2011 agreed on a new RTCM Standard (RTCM 3.1, Amendment 5, State Space Representation = SSR) which supports PPP. New receiver hard- and software issued from 2014 onwards will be capable to process this standard. Therefore GNSS-service providers have to adapt to this situation by offering new service levels. Unfortunately global SSR information like satellite orbit- and clock-correction models do still not allow for phase ambiguity resolution in real-time and suffer from long convergence times (10 minutes and more compared to RTK). PPPserve aimed in a further step at the provision of so-called satellite-phase-biases which are the missing link at user side to allow for PPP based phase ambiguity resolution. Under optimum boundary conditions applying relevant satellite phase-biases will reduce the convergence time down to a few seconds. Both currently known techniques for establishing these phase biases will be investigated. Software to determine these parameters from the observation data of the global IGS network as well as from the regional GNSS service provider (Wien-Energie-Stromnetz/EPOSA) has been established. Finally these parameters are forwarded to the user community in a proprietary format as a new service level. The project consortium has developed a proposal how this parameters can be forwarded by means of an upgrade of the RTCM 3.2 standard. The project consortium consists of the Department of Geodesy&Geoinformation (formerly Institute of Geodesy and Geophysics) at Vienna University of Technology, the Institute of Navigation (INAS) at Graz University of Technology and the Wien-Energie Stromnetz GmbH.



Introduction

Satellite based positioning techniques rely on measuring so-called pseudo-ranges between usually ground based rover receivers and the satellites of the currently active global satellite navigation systems (GNSS) like GPS and GLONASS. These range measurements can be carried out with diverse accuracy, wherein we distinguish in first place between Code- and Phase-measurements. The Code-range measurements make use of the measured signal travel-time of the code-modulations on the carrier-waves broadcasted by the satellites in the microwave (1.2-1.6 GHz) band. Code-range measurements nowadays achieve accuracies at the few-dm level which corresponds to about 1 ns in signal travel time. On the other hand phase based ranges achieve a much improved accuracy at the 1-2 mm level, which corresponds to about 0.5-1% of the carrier wave-length. Assuming to have knowledge about the precise position of the satellites the only remaining parameters of the positioning process are the rover site coordinates and the rover receiver clock correction. This clock correction constitutes the above mentioned term pseudo-range in contrast to the direct range measurement in case of synchronized satellite and rover clocks. For details concerning positioning techniques by means of satellite navigation systems we refer to the huge variety of available literature. Distance measurements are subject to a number of error sources. Primarily, these are global effects such as the imprecise knowledge of satellite orbits and satellite clocks (in relation to GPS-time). Aside, signals are delayed when they pass the atmosphere. These influences due to the ionosphere and troposphere can be described as regional effects. Additionally, a number of local, respectively device-specific effects may occur. A precise modelling of these errors is limited. Finally, the determination of the unknown phase-ambiguities remains. These represent the exact number of carrier wave cycles between the satellite and the receiver and also contain device-specific errors. Only with knowledge of these ambiguities the accuracy potential of phase measurements can be exploited. Highly precise positioning with cm level accuracy is particularly possible by forming the difference between user-side observations and observations of a reference station nearby, whose position is well-known. This approach allows to minimize or even to eliminate global, regional and time-dependent errors. Another possibility, particularly to eliminate the ionospheric delay, is based on forming linear combinations of the emitted carrier signals on (at least) two frequencies. The convenience of forming observation differences is that phase-ambiguities can be assumed to be integers, which simplifies and accelerates their determination. Most of the present-day techniques of GPS- or GNSS-point determination in post-processing and real-time (RTK-processing) are based on this approach. The reference observations therefore are available either from a reference station installed by the user or as in most cases from a GNSS correction service. This service (GNSS service provider) generally operates a network of GNSS reference stations, distributed over the service area. The observation data from each reference station are sent to a service control facility in real-time, where they are on the one hand used to compute miscellaneous regional error models and on the other hand delivered to users in standardized formats like RTCM. Dependent on the data quality and further implemented information on the transformation of the established rover coordinates into certain reference systems, different service levels are offered. The project consortium of PPP- Serve consists of the Vienna University of Technology (Department of Geodesy and Geoinformation), the Graz University of Technology (Institute of Navigation) and the GNSS Service Provider Wien- Energie Stromnetz GmbH (EPOSA-Service) which operates a nationwide GNSS reference site network. PPP-Serve (Network based GNSS Phase Biases to enhance PPP Applications – A new Service Level of GNSS Reference Station Provider) aims at the development and realization of adequate algorithms to enhance fast GNSS based point positioning at cm level. Regularly established RTK-techniques (Real-Time-Kinematic) are



based on building and processing observation differences while the required observation corrections are forwarded to the user community in the standardized RTCM format. In contrast to the differencing technique the PPP-model is based on code/phase single point positioning, which requires a limited amount of correction data just transferring model parameters instead of observation corrections. In PPP therefore spatially and temporally correlated error sources have to be modelled properly as they are not eliminated or minimized due to differencing. Leading receiver manufacturers have already agreed on a new RTCM Standard (RTCM 3.1, Amendment 5, State Space Representation = SSR) which supports PPP. Receiver hard- and software issued from 2014 onwards is capable to process this standard. Therefore GNSS-service providers have to adapt to this situation by offering new service levels. Unfortunately RTCM 3.1 provides solely global SSR information like satellite orbit and clock-correction models. This information is still not sufficient to allow for phase ambiguity resolution in real-time and positioning therefore suffers from long convergence times (10-20 minutes) compared to RTK. On the other hand, the advantage of PPP compared to RTK-techniques is a dramatically reduced requirement of bandwidth for data transmission between service provider and user because PPP only needs model parameters compared to RTK which requires observations or observation correction information at high update rates. PPP-serve aims in a further step at the provision of so-called satellite-phase-biases which are the missing link at user side to allow for PPP based phase ambiguity resolution. Applying relevant satellite phase-biases will reduce the convergence time down to a few seconds. The most promising techniques for establishing these phase biases (UPD = Uncalibrated Phase Delay) were investigated. A software to determine these parameters from the observation data of both, the global IGS RT Network as well as the regional GNSS service provider (Wien-Energie-Stromnetz/EPOSA) was developed. Finally, these parameters are forwarded to the user community in a proprietary format as a new service level to allow for a fast ambiguity resolution. The project workflow consisted of a design and evaluation phase which covered the processing of real GNSS observation data in order to identify the adequate method for bias determination. Subsequently, by means of simulated observation phase bias data, we investigated the potential of the chosen approach to re-establish UPDs and access the quality and accuracy of the re-established parameters. Further on, we used observation data of two weeks to establish UPD time-series and check their temporal stability. Introducing the UPDs to rover observation data for PPP point positioning completed the design and evaluation phase. Based on the attained knowledge we established a basis for a real-time service which estimates wide-lane and narrow-lane UPDs from the reference sites observation data at the EPOSA central computing facility and forwards these parameters to users by means of a proprietary format. The UPD processing has to take place every 10-30 minutes. In parallel also global corrections (satellite orbits and clocks) are established. The processing of these global corrections can be performed by means of knowledge and software already made available by a technical pre-project (RT-PPP).



1 Scope and Administrative management

Precise Point Positioning (PPP) is a satellite based positioning technique that uses code pseudorange or phase observations from a single GNSS receiver. The main GNSS error sources relevant for PPP processing are visualized in Figure 1-1.

Figure 1-1: Main PPP error sources

A precise position can be determined due to the additional compensation for orbit and clock inaccuracies by the introduction of precise orbits and clock corrections. These precise ephemerides are available through web services operated by organizations like the International GNSS Service (IGS) or the Center for Orbit Determination in Europe (CODE). Ionospheric influences on the signals can be eliminated by building ionosphere free linear combinations of at least two observed carrier frequencies. If PPP is used in a single-frequency mode, ionospheric modelling has to be applied. Tropospheric delays can either be modelled or estimated. At the rover side PPP requires the provision of so-called global models of satellite orbit and clock corrections as well as regional models of the atmospheric corrections. Last but not least the calibration phase biases both at the satellite and rover side have to be known. The project aimed at the calculation and provision of so-called satellite-phase-biases which at the user side are the missing link to allow for PPP based phase ambiguity resolution. Applying relevant satellite phase-biases will reduce the convergence times at the

1.1 Scope of the project



rover side down to a few seconds. Software to determine these parameters from the observation data of the regional GNSS service provider (Wien-Energie-Stromnetz/EPOSA) was established. The remaining receiver calibration biases can be eliminated by building epoch differences between observations to an arbitrary satellite and a reference satellite. The advantage of this new service level is to allow for a fast ambiguity resolution.

The work of project PPP-Serve has been jointly conducted by an Austrian project consortium consisting of

Vienna University of Technology (TUW), Vienna, Austria, Department of Geodesy and Geoinformation,

RG Advanced Geodesy (Project Lead)

Graz University of Technology (TUG), Institute of Navigation (INAS), Graz, Austria

Wien Energie Stromnetz GmbH (WS), Vienna, Austria

The following personnel are involved in the work on PPP-Serve during the project’s runtime: Graz University of Technology (TUG), Institute of Navigation Project management: Manfred Wieser Project coordination: Katrin Huber Technical management: Roman Lesjak Secretary: Sandra Berghold Vienna University of Technology (TUW), Institute of Geodesy and Geophysics Project management: Robert Weber Technical management: Fabian Hinterberger Technical Management: Gregor Möller Secretary: Susanne Linsmayer Wien Energie-Stromnetz GmbH (WS) Project management: Christian Klug Technical management: Gottfried Thaler Technical management: Robert Karas

1.2 Project Partners



Within PPP-Serve (FFG-project 833419) the following work package breakdown structure was defined. All the WP responsibilities and the corresponding distribution of work are displayed in the organization chart in Figure 1-2.

Figure 1-2: Work package Breakdown Structure

1.3 Work Package Breakdown structure



The project PPP-Serve started on April 1, 2012. The first part of the project (from project start to end of October 2012) was covered by work related to the goals of ‘State of the Art and Design’ detailed in WP 2100, WP 2200, WP 2300 and WP2400. Results were reported in Technical Note 1. In the subsequent months the focus was laid on post-processing simulations in order to establish a reasonable UPD recovery. Furthermore the decision concerning the model selection was made. Prior to the TRR Meeting (begin of May 2013) all Work Packages concerning ‘Simulation and Post Processing (WP 3100, WP3200 and WP3300) could be finalized. In addition the project consortium started with the development of a real time software for the estimation of the WL and NL biases (WP 4100, and WP4200). Furthermore the WP5100 (Service Level of GNSS Service Provider) was sustained during the huge user forum in May 2013. The results of these investigations were major contents of the MTR. As of begin of May 2013 the project was delayed by about 2 months compared to the proposal, therefore the consortium decided to enquiry for project prolongation which was accepted by FFG(Until November 30th, 2013). Between June-November 2013 the work concerning the “Real-Time Processing” detailed in WP 4100, WP4200, WP4300 and WP4400 was completed. In November 2013 the Work Package 5200 concerning ‘Future Developments and Products’ has been finalized.

The project Kick-Off meeting (KOM) as well as a first technical Meeting was held on April 17th, 2012, at Vienna University of Technology. A further technical Meeting was held an September 27th,2012 at Graz University of Technology. The Critical Design Review (CDR) Meeting took place on November 16th, 2012, again at Vienna University of Technology. Afterwards the communication was mainly characterized by email exchange. The Technical Readiness Review Meeting (TRM) took place on May 3rd, 2013 at TU-Vienna. Two further technical progress meetings mainly focusing on the convergence time and the stability of UPDs took place in summer and autumn 2013. The first one was held on August 6th, 2013, at TU-Graz and the other one on November 8th, 2013 at TU-Vienna. The Final Review Meeting (FRM) is scheduled for February 18th 2014 at FFG.

1.4 Technical work

1.5 Meetings



Figure 1-3: Time schedule of PPP-Serve

The project started in April 1 and lasted due to an extension of 2 months until Nov 30, 2013

1.6 Time schedule



The following reports have been provided:

Identification Title Origin Target due date

Delivered

TN1 Technical Note 1 WP1100 31.12.2012 OK

MR Midterm Report WP 1100 31.05.2013 OK

FR Final Report WP1100 31.01.2014 this document Table 1-1: RT-PPP deliverables

According to the project contract, the FFG has made / will make the following payments:

Payment Target due date Amount

Advance Payment 01.04.2012 50%

Progress Payment 31.05.2013 30%

Final Payment After approval of Final Report 20% Table 1-2: Milestone Payment Plan

The Advance and the Progress Payment have been received.

1.7 Deliverables

1.8 Milestone Payment Plan



The project PPP-Serve was presented at the following events and conferences: K. Huber, R. Lesjak, R. Weber, F. Hinterberger (2012): PPPserve; Poster at Navigations-Get-Together; 9.10.2012, Graz, Austria. K. Huber, F. Hinterberger, R. Lesjak, R. Weber, Ch. Klug, G. Thaler (2013): PPPserve – Network based GNSS Phase Biases to enhance PPP Applications, Paper and Presentation at ENC2013, 22. – 25. 04. 2013, Vienna, Austria. F. Hinterberger, R. Weber: "Real-Time GPS satellite clock correction estimation at the Technical University Vienna"; Poster: The European Navigation Conference, Vienna, Austria; 23.04.2013 - 25.04.2013. F. Hinterberger, R. Weber: "Precise Point Positioning (PPP) - Berechnungsmodell, Einsatzbereiche, Grenzen"; Vortrag: DVW Seminar, Karlsruhe, Germany (eingeladen); 14.03.2013 - 15.03.2013. R. Weber, F. Hinterberger: "Precise Point Positioning (PPP) - Berechnungsmodell, Einsatzbereiche, Grenzen"; in: "GNSS 2013 - Schneller. Genauer. Effizienter. Schriftenreihe Band 70/2013.", herausgegeben von: DVW; DVW e. V. - Gesellschaft für Geodäsie, Geoinformation und Landmanagement, 2013, ISBN: 978-3-89639-902-1, S. 63 - 82. F. Hinterberger, R.Weber, K. Huber, R.Lesjak: Determination of Uncalibrated Phase Delays for Real-Time PPP; accepted presentation at EGU 2014, Vienna.

1.9 Scientific Presentations



2 Fundamentals

Wien-Energie-Stromnetz GmbH operates in collaboration with two commercial partners (‘BEWAG’, the Burgenland power supply company and ‘ÖBB-Infrastruktur IKT’, a 100% subsidiary company of the Austrian railways) the GNSS correction Service EPOSA. EPOSA is a nation-wide operating service which has established about 40 GPS/GLONASS reference sites (see Figure 2-1) delivering observation data in real-time to the EPOSA control computing facilities. Two control facilities are operational to enable integrity and stability of the provided service levels.

Figure 2-1: EPOSA station network

EPOSA offers various RTCM standardized correction data streams covering a broad range of accuracy levels (from sub-meter towards cm level) to the user community. Furthermore coordinate transformation services and technical user support are provided. Although format and provision of the correction data further distinguishes by the supported RTCM level and the concept of delivering error model data in general the differential RTK model is applied (see Figure 2-1). For further information it may be referred to the EPOSA webpage www.eposa.at. In typical RTK the user is dependent on the reference site coordinates, the reference frame of the service provider and last but not least on the quality of the delivered correction data. To overcome these deficiencies nowadays the PPP concept is promoted and corresponding service levels have to be established.

2.1 Motivation

http://www.eposa.at/



Precise Point Positioning is a GNSS based positioning technique that uses code pseudorange or phase observations from a single GNSS receiver. A precise position can be determined due to the additional compensation for orbit and clock inaccuracies by using precise orbits and clock corrections. These precise ephemerides are available through web services operated by organizations like the IGS or CODE. Ionospheric influences on the signals can be eliminated to a large extend by building ionosphere free linear combinations of at least two observed carrier frequencies. If PPP is used in a single frequency mode, ionospheric modeling has to be applied. Tropospheric delays can either be modeled or estimated. The concept of Precise Point Positioning was first introduced in the 1970s by R.R. Anderle, and was characterized as single station positioning with fixed precise orbit solutions and Doppler satellite observations (cf. [KOUBA 2001]). First investigations using dual frequency data from a single GPS receiver for a few cm-positioning in post-processing mode have been published in 1997 by JPL (Jet Propulsion Laboratory). These results have been achieved utilizing the ionosphere free linear combination together with precise orbits and clocks issued by the IGS. Depending on the observation time, centimeter to decimeter accuracy can be achieved by combining precise satellite positions and clocks with a dual frequency receiver to eliminate ionospheric effects. Compared to DGPS and RTK systems, PPP has several advantages:

No nearby base station or network of base stations is necessary, and thus PPP reduces the costs,

no simultaneous observations are necessary,

state-space-representation of error sources instead of range corrections in observation space, and

no limit of operational range thanks to global valid corrections.

According to Hofmann-Wellenhof et. al. [HOWE 2007] the basic mathematical model underlying PPP is the ionosphere-free combination of code pseudoranges and carrier phases

Tropcff

fR

ff

fR

2

2

2

1

2

12

2

1

2

1

2

11 2-1

.2

2

2

1

2

222

2

2

2

1

2

111Trop

2

2

2

1

2

222

2

2

2

1

2

111

ff

fN

ff

fNc

ff

f

ff

f

2-2

with

c speed of light,

fi frequency on carrier i ,

λi wavelength on carrier i ,

ρ geometrical range containing the receiver position,

Δδ difference between the receiver and the satellite clock error,

ΔTrop tropospheric delay and

2.2 Background PPP



Ni ambiguities affected by instrumental biases.

Summing up, within the last decade a number of approaches have been carried out to serve applications in near real-time by this technique. In comparison with common techniques like DGPS or RTK, the costs are reduced, because no base stations and no simultaneous observations are necessary. On the other hand, the necessary models have to be fetched either from globally acting services like IGS (orbits, satellite clocks) or from regional GNSS service providers (atmospheric delays) and standard interfaces (e.g. RTCM) have to be developed to forward this information to the rover. Further problems still to be solved are coordinate convergence periods of up to 2 hours as well as ambiguity resolution, which are harmed by non-integer calibration phase biases. These biases vanish only in difference mode and have to be determined a priori.



3 State of the Art and Design

The basic principle of GNSS Precise Point Positioning (PPP) with phase measurements, as it is used in most commercial processing packages, is shortly described below in order to give a basis for the following work packages of the project. Basically within PPP code and phase measurements of a single static or kinematic receiver are used to estimate an independent solution of position coordinates with the aid of externally provided precise orbit and clock information. In the case of single-frequency measurements an additional model concerning ionospheric influence has to be taken into account, while usually for dual-frequency observations an ionosphere-free linear combination is built, that accounts for the first order term of the ionospheric delay. In the following only the dual frequency case is described: After widely eliminating satellite orbit and clock errors by using external ephemerides products and strongly reducing the influence of the ionosphere by building the so-called ionosphere-free combination, the observation equations for code pseudoranges PIF and phase pseudoranges λΦIF are

trprsIF dtdtcP )( 3-1

IFIFtrprsIF Ndtdtc )( . 3-2

The term ρ denotes the geometric distance between the satellite and the receiver antenna containing their 3-dimensional coordinates. The term c stands for the speed of light while dts and dtr are the satellite and the receiver clock errors. Δtrp stands for the tropospheric delay. The phase equation contains in addition the ionosphere-free effective carrier-phase wavelength λIF and the ambiguity parameter NIF. This ambiguity parameter NIF is due to instrumental biases not an integer number any more. We may interpret NIF as the sum of real-valued initial phase biases originating in the receiver’s and the satellite’s hardware plus the full number of cycles. Remaining effects like phase wind-up, relativity corrections, tidal corrections, antenna phase center variations and so on have to be accounted for in advance according to appropriate models. In difference-mode the aforementioned initial phase biases for the individual satellites and the receiver cancel, but since PPP is a zero-difference technique, the bias terms prevent the fixing of ambiguities to integers. Therefore in most PPP software packages, the ambiguities are estimated as real values along with other parameters like receiver clock error, position coordinates and remaining tropospheric delay. Therefore PPP solutions generally need long observation times to achieve the optimum position accuracy. Furthermore it is well known that the east-component within float-solutions can be improved by resolving integer phase ambiguities (cf. [GE 2008]). [CALAIS 2006] observed that the PPP accuracy of the east-component is also not that good concerning repeatability, as that of network solutions. Typically with PPP processing position accuracies at the dm-level can be achieved after half an hour of observation. Cm-accuracies can only be reached after long observation times of two hours and more. Within WP2100 a detailed literature survey on PPP accuracy and convergence time was conducted. A PPP float solution was generated as a basis for further work packages as well as for comparison to the later integer PPP approach implemented in the subsequent work packages.

3.1 PPP Model (WP 2100)



The Figure 3-1 shows the north, east and up position differences (with respect to the reference position) of the generated float solution of the IGS station Graz Lustbühel. For this solution dual-frequency data as well as broadcast orbits and clocks combined with real-time IGS corrections were used. The position coordinates reach an accuracy of a few cms after some tens of minutes. The corresponding float ambiguities (Figure 3-2) seem to be stable after an initialization time of 3000 epochs (interval of 1s). This is a good basis for the planned ambiguity resolution procedure.

Figure 3-1: Float solution (GRAZ256.11O) with Broadcast Eph. + IGS real-time corrections

Figure 3-2: Ambiguities of float solution with IGS real-time corrections

07 08 09-0.4

-0.3

-0.2

-0.1

0

0.1

0.2

0.3

0.4

Positions Over Time

Time [h of day]

Variation in P

lane C

oord

inate

s [

m]

dN

dE

dh

0 1000 2000 3000 4000 5000 6000 7000 8000-10

-5

0

5

10

15

epochs

am

big

uitie

s [

m]

(not

absolu

te o

nes)

Estimated GPS Ambiguities [m]

Prn2

Prn4

Prn9

Prn12

Prn14

Prn15

Prn17

Prn25

Prn27

Prn29

Prn31



Figure 3-3: Float ambiguity of PRN9

In the following paragraphs some promising approaches to recover integer nature of zero-difference phase ambiguities to perform integer PPP are presented. Generally we can distinguish between two approaches, presented in studies, to enable integer resolution on zero-difference level by applying improved satellite products, where phase biases have been separated from the integer ambiguities. A comparison of these methods can be found in [GENG 2010]. a) [LAURICHESSE 2009] proposed an approach which allows to directly fix the un-differenced ambiguities to integers. They assigned an arbitrary value to the phase bias of a specific receiver in order to determine the satellite phase biases. The wide-lane bias determination takes place in accordance with that of [GE 2008]. The narrow-lane biases however are not determined specifically, but assimilated into the clock estimates. Within a network of reference stations narrow-lane ambiguities have to be identified and fixed to integers prior to estimating the clocks (De-coupled clock model). [COLLINS 2010] developed a similar concept, where pseudorange-clocks differ from phase clocks. Both approaches aim at producing clock corrections able to recover integer nature of narrow-lane ambiguities at a single receiver. b) [GE 2008] decomposed un-differenced ambiguities into wide- and narrow-lane ones. Thereby a satellite-to-satellite single-difference was used to eliminate the receiver-dependent calibration biases. Within a network of reference stations the wide-lane phase biases were determined from averaging the fractional parts of all wide-lane-estimates using the Melbourne-Wübbena combination of the measurements. These wide-lane phase biases are very stable over several days. The Melbourne-Wübbena combination is a linear combination of four observables (carrier phases on L1 and L2, code measurements on L1 and L2) eliminating the effect of the ionosphere, the geometry, the clocks and the troposphere. This combination is described by [MELBOURNE 1985] and [WÜBBENA 1985]. The narrow-lane phase biases are determined similarly by averaging the fractional parts of all narrow-lane ambiguity estimates derived from the wide-lane ambiguities and the ionosphere-free observables. The narrow-lane phase biases do not have a high temporal stability and are proposed to be estimated for 15 minute intervals. The estimated phase biases can then be used for ambiguity estimates of single-receivers to recover their integer nature.

1000 2000 3000 4000 5000 6000 7000 800011

11.2

11.4

11.6

11.8

12

epochs

am

big

uitie

s [

m]

(not

absolu

te o

nes)




Within WP2200 a detailed literature survey on decoupled clock models to produce clock products restoring the integer characteristics within zero-difference observations has been conducted. Further the question has been discussed, if all the necessary products for integer PPP with the aid of ‘phase clocks’ could be transmitted to the PPP user via standardized RTCM messages, or else if RTCM extensions have to be created. The calculation of ‘integer phase clock’ products from a global or regional network data has been tested in post-processing within the project, to work out the strengths and deficiencies of this technique. Afterwards a comparison to the solution of [GE 2008] recovering integer phase ambiguities from fractional parts of the phase biases can be given. This technique is further described in section 3.3.



The term decoupled clock model describes an observation model that, contrary to the standard PPP approach, differentiates between code clocks and phase clocks. [COLLINS 2010] and [LAURICHESSE 2009] use such a decoupled clock model. [COLLINS 2010] states that there is no functional difference between the hardware specific code biases and the underlying oscillator which can be analogously stated for phase biases. However, within standard PPP solutions the clock computation relies on both, code and phase, even though the code and phase measurements cannot be treated as fully synchronized at the level of phase precision. Therefore estimated ambiguities are contaminated by the code observables. In the following the concepts of producing so-called phase clocks enabling integer ambiguity resolution for single stations will be described according to [LAURICHESSE 2009]. The notations therefore are chosen according to that paper.

Let us state that pseudorange measurements P1 and P2 (expressed in meters) and phase measurements L1 and L2 (expressed in cycles) are modeled as

222222

111111

22

11

NheWDL

NheWDL

heDP

heDP

pp

pp

3-3

with

2

2

1

1

2

1 ,,²

²

f

c

f

c

f

f

f1, f2 Carrier-frequencies of the GPS signals L1 and L2, c speed of light, D geometrical propagation distance between satellite and receiver phase centers (including

tropospheric and relativistic effects), W phase wind-up effect (in cycles), e ionospheric delay on L1 (in meters) that has an opposite sign for phase and code

measurements, Δh = hi - h

j difference between the ionosphere-free phase clocks for satellite j and receiver i,

Δhp corresponding term for pseudorange clocks, Δτ = τi - τ

j difference between the phase clocks on L1 and the ionosphere-free phase clocks,

Δτp corresponding term for pseudoranges, which can be denoted as Time Group Delay, and N integer carrier phase ambiguities (Unambiguous phase measurements are L1 + N1 or L2 +

N2).

3.2 De-coupled clock model (WP2200)

3.2.1 Model equations



The independent parameters Δh, Δhp, Δτ and Δτp denote the separated reference clocks for pseudorange and phase (for each observable) and the corresponding hardware offsets, that are assumed to have slow variations with time.

In a first step the wide-lane ambiguities can be directly observed and fixed from the four GPS elementary measurements (code-pseudoranges and phases on two frequencies f1 and f2). The wide-lane (Melbourne-Wübenna) ambiguity, which is an integer, is defined by 12w NNN and has a

wavelength of about 87 cm for GPS L1 and L2 bands. The measured pseudorange ionosphere contribution and the measured ambiguities are defined by

22

p221

1

p11

21p L

e2PN~

Le2P

N~

1

PPe

.

3-4

Since the noise level of pseudorange measurements is too large (~10 cycles) to estimate ambiguities on the cycle level, [LAURICHESSE 2009] first focus on the wide-lane ambiguities. From equations 3-3 and 3-4 the measured wide-lane can be expressed as

jiww dNN

~ 3-5

where i and j denote the receiver and satellite specific wide-lane hardware offsets (a linear combination

of the specific hardware offsets τ and τp and h - hp), that vary only slowly with time for the satellites and are stable for the receivers under good environmental conditions. The term d , whose contribution is neglected in the further concept, is the geometric offset between D1 and D2 expressed in wide-lane cycles and virtually is the offset between the phase centres of L1 and L2 (usually a few cm). By averaging the wide-lane observations over the duration of a pass, usually a correct estimate of the integer

Nw, and therefore the biases i and j can be obtained.

Since the solution of 3-5 results in multiple solutions due to the possible shift of Nw for an arbitrary integer number, only the fractional parts of the wide-lane biases are accessible. Further the problem remains

singular, because only the differences of ji are contained in the equation. After choosing a reference

station and iteratively computing and correcting the values of ambiguities, station and satellite biases and

finally the solutions for i , j and the corresponding values for Nw can be obtained.

With the wide-lane delays known it is possible to fix wide-lane ambiguities within un-differenced measurements.

After wide-lane fixing only one ambiguity N1 or N2 (or any combination between them) is left unknown. To get rid of the ionospheric influences, the ionosphere-free code combination cP and the ionosphere-free phase

combination cQ are described by

3.2.2 Wide-lane ambiguities from reference station network

3.2.3 N1 fixing from zero-difference observations



.

1

NNLNLQ

1

PPP

w122111c

21c

3-6

Further 1N̂ can be used to achieve the best approximation of the ionosphere-free phase combination cQ̂ ,

where 1N̂ is the best estimate of 1N that is the closest integer to 11

p1

1 Le2P

N~

. The symbol ...

indicates the average over all passes. Due to the fact that Nw is known, only N1 has to be found. Therefore the reformulated problem is

cm6.101

NN11

LLQ 21

c1cw22211

c

. 3-7

In the following it is solved only for the ambiguity correction 111 NN̂N that can reach up to 10 cycles.

Substituting 3-3 in 3-6 results in

1cwc

pc

NhDQ̂

hDP

3-8

and shows, that before finding the ambiguity correction, precise estimates for the propagation distance

WDDw and for the clocks Δh have to be estimated from a network of receivers. Afterwards the

ambiguity corrections can be computed. These 1N are not integers, but reveal their integer nature, when

computing station-station single-differences and therefore removing hj. To solve this problem it is possible to solve not only for one integer value for 1N per pass, but also for a set

of clocks hi, hj per epoch. As with this observation equation we have the same singularity problems as with

equation 3-5, a reference station has to be chosen to set the values for 1N and hi to zero for this station.

Afterwards an iterative solving process starts, where more and more stations become involved. Once all stations are included a set of integers for 1N and the corresponding satellite clocks can be identified.

[LAURICHESSE 2009] call these clocks (hi and hj) integer phase clocks’ to underline their specific property of

restoring integer nature of single station ambiguities.



Figure 3-4: Advantages and drawbacks of the method of integer PPP

Source: D. Laurichesse, EGU Vienna 2010

Figure 3-5: Single station solution with and without integer ambiguity resolution

Source: D. Laurichesse, EGU Vienna 2010

The Centre National d’Etudes Spatiales (CNES) produced a demonstrator called “PPP-wizard” (see www.ppp-wizard.net) that enables among others the integer ambiguity resolution within PPP with the aid of ‘integer phase clocks’ that are generated and broadcasted to the PPP client. This tool was set up as a proof of the aforementioned concept. Figure 3-4 shows the performance comparison of the methods standard PPP with float ambiguities, RTK and Integer PPP and Figure 3-5 compares the user position of a PPP float and fixed solution. Especially the better accuracy and convergence to 1 cm after about half an hour of observation demonstrates the great advantage over PPP float solutions that only achieve a few decimeters after the same observation time. Further it has to be mentioned, that the concept is applicable in post-processing as well as in near real-time (~3 cm latency).

CNES offers not only a demonstrator software, but also real-time as well as post processing phase bias data to recover integer ambiguities. Therefore, the PPP user software at INAS was modified to perform wide-lane and narrow-lane ambiguity fixing, based on the CNES orbit, clock and bias streams. Once the ambiguity fixing

3.2.4 PPP solution with CNES data



routines worked stable, they were modified to comply with our proprietary data streams calculated in this project. The most recent stream CLK9B on CNES’ PPP-wizard caster (works with PPP-wizard 1.5) contains, beside orbit and clock corrections (RTCM SSR messages 1066 and 1060), the following bias parameters (modified RTCM SSR message 1059):

Figure 3-6: RTCM messages of CLK9B converted to ASCII by PPP-wizard demonstrator based on BNC 2.4

Figure 3-7: Bias types of modified RTCM message 1059

Thereby the Code bias types are standardized in the most recent RTCM version, but still there are no standardized types for phase biases. Therefore CNES introduces the bias types 21 for L1 and 22 for L2 (see Figure 3-7). These biases can be added directly to the GNSS observations to recover the integer nature of GPS ambiguities. Note, that in earlier CNES streams the phase biases were contained in the clock parameter as phase clocks (oscillator bias + phase bias), but the former representation is more independent on the processing and resolution method. In the previous sections of this chapter the generation of biases was treated from a theoretical point of view. Now the processing of these data from the user’s point of view will be described. As described earlier, the ionosphere-free linear combination of observations should be used for the integer PPP solution. This linear combination unfortunately contains also a real-valued combination of ambiguities plus phase delays. Therefore the integer ambiguities N1 and N2 cannot be addressed directly in the first



instance. To get rid of this problem we again separate this problem into a wide-lane lane fixing and a narrow lane fixing (cf. section 3.2.2 and 3.2.3). Wide-lane fixing: The wide-lane fixing can be performed in the pre-processing step. Therefore the Melbourne-Wübbena combinations of all satellites can be built epoch-wise. This combination uses Code and Phases on two carriers (L1 and L2) and results in an observable with a huge wavelength of ~86 cm containing only an integer wide-lane observable, a wide-lane receiver-emitter dependent bias term and noise, which should be no more than 0.1 to 0.2 cycles depending on the satellite’s elevation. The emitter dependent bias is calculated and transmitted by CNES while the receiver dependent part still remains present in the observable.

Figure 3-8: Example of wide-lane observable of a single PRN (receiver bias still present)

For the fixing routine, wide-lane observations from 300 epochs are calculated. Firstly, the remaining receiver bias is calculated from one “good” satellite as the remainder to the nearest integer value. Afterwards all other integer ambiguities can be estimated in an iterative procedure. If the first satellite is chosen carefully, the integer fixing of wide-lane ambiguities should be unproblematic, as their biases remain rather stable over one day. Narrow-lane fixing: The narrow-lane fixing is performed in the main processing routine. This step is more problematic than the wide-lane fixing, as the narrow-lane biases are not that stable and the noise compared to one NL-cycle is much higher. In a first step a standard float-solution of ionosphere-free observables has to be computed. As soon as the estimated float ambiguities have converged, a narrow-lane estimate can be computed from the float values



and the fixed wide-lane values. Similar to the wide-lane procedure a receiver bias has to be estimated to enable narrow-lane integer fixing. As soon as one NL-ambiguity is fixed correctly, it can be used to enhance the float solution. Therefore the fixed narrow- and wide-lane ambiguities are used to reconstruct the ionosphere-free ambiguity (cf. equation 3-7). This value is subtracted from the respective measurement, which leads to an unambiguous phase observable. In an iterative procedure more and more ambiguities are tried to be fixed and the solution becomes more stable. Unfortunately the detection of wrong fixes is not an easy task, since the only comparison measure is the noisy float ambiguity. Therefore, without further smoothing and filtering procedures, the narrow-lane ambiguities can only be detected within a range of ±1-2 cycles. Furthermore the biases change more rapidly which decreases the solution’s stability. Further details on the fixing routines that were finally chosen for the user client are given later on in this report (see 5.4 – Rover PPP Applications).

3.2.5 Comparison of Wide-lane observables with and without using CNES bias products

To show the presence of hardware delays on phase observables, a small comparison of Wide-lane observables before and after application of respective satellite-specific bias corrections is provided in Figures 3-9 and 3-10.

Figure 3-9: Melbourne-Wübbena SD-observable of all

satellites without the use of CNES phase biases

Figure 3-10: Melbourne-Wübbena SD-observable of all

satellites using of CNES phase biases

Here satellite to satellite differences of the Melbourne-Wübbena linear combination are shown for all satellites in the GRAZ3350.12O observation file. The receiver specific part of the phase biases is already eliminated by producing sat-to-sat differences. On the left side the satellite specific phase biases are still present as no corrections have been applied at all, while on the right side the phase biases are strongly reduced by using bias corrections from the CNES data stream CLK9B. Note, that for a better visualisation integer values were subtracted from the observables.

20 30 40 50 60 70 80-0.5

-0.4

-0.3

-0.2

-0.1

0

0.1

0.2

0.3

0.4

0.5MW-SD with Reference Satellite PRN30

Elevation [°]

WL o

bserv

able

s [

cycle

s]

20 30 40 50 60 70 80-0.5

-0.4

-0.3

-0.2

-0.1

0

0.1

0.2

0.3

0.4

0.5MW-SD with Reference Satellite PRN30

Elevation [°]

WL o

bserv

able

s [

cycle

s]



Without using the external CNES products, the WL-ambiguity observations do not approach integer values (here denoted by zero) at all; this happens only after the compensation for satellite phase hardware biases. Therefore we can conclude that WL-integer fixing is possible by using external correction products for hardware delays, as they are produced e.g. by CNES.



The term phase recovery from fractional parts describes an approach to estimate the fractional parts of the single-difference (SD) un-calibrated phase delays between satellites in wide- and narrow lane from a global or regional (European) reference network. By applying the obtained SD-UPDs as corrections to the SD-ambiguities at a single station, the corrected SD- ambiguities have a naturally integer feature and can therefore be fixed to integer values. In the following the concept of producing such SD UPDs will be described according to [GE 2008]. In a first step the wide-lane phase biases are determined from averaging the fractional parts of all wide-lane estimates within a network of reference stations as it is already described in chapter 3.2.2. Instead of assimilating the narrow-lane phase biases into the clock estimates [Laurichesse 2009], narrow-lane phase biases are determined by averaging the fractional parts of all pertinent narrow-lane ambiguity estimates derived from the wide lane ambiguities and the ionosphere-free-observable ambiguities.

In PPP, because only one single station is involved, only SD-ambiguities between one receiver k and two satellites i and j can be defined. According to [GE 2008] the ionosphere free phase observations, in form of integer ambiguities and phases biases are described by:

jiji

kji

n

ji

kn

ji

k

ji

kn

ji

kc nff

ffn

ff

fb

ff

ffb

ff

fb ,,

22

21

21,,

21

1,

22

21

21,

21

1,

3-9

with:

jin

ji

kn

ji

kn nb ,,, jiji

k

ji

knb ,,,

f1, f2 frequencies on L1 and L2 of the GPS system, ji

kcb,

carrier-phase ambiguity

ji

kb

,

and ji

knb,

wide- and narrow-lane ambiguity

ji

kn

,

and ji

knn,

Integer ambiguities

jin, and ji,

SD wide- and narrow-lane phase biases

Each SD phase bias has an integer and a fractional part, where only the fractional part is important for recovering the integer nature of SD-ambiguities. Assuming the wide-lane SD ambiguity can be fixed to an

integer one gets the narrow-lane ambiguity with the following reformulation of Eq. 3-9 as

ji

k

ji

kcjiji

k

ji

kji

n

ji

kn nff

fb

ff

fnn

ff

fn

,

21

2,

21

1,,,

21

2,,ˆˆˆ

3-10

3.3 Phase recovery from fractional parts (WP2300)

3.3.1 Narrow-lane fixing and estimation of the phase biases



The difference between k

jinn ,

and

kjin ,ˆ

is caused mainly by the pseudo-range biases und the integer

part of ji, Δ

which are both constant. Therefore the second and third term can be merged into the

narrow lane phase bias. Eq. 3-10 can be rewritten as:

ji

k

ji

kc

ji

kn nff

fb

ff

fb

,

21

2,

21

1,

ˆˆˆ

3-11

with:

)ˆ( ,,,

21

2,, jiji

k

ji

kji

nji

n nnff

f

3-12

jin

ji

kn

ji

kn nb ,,,ˆ 3-13

The narrow-lane ambiguity can now be fixed to an integer if the fractional part of the narrow-lane UPD, which is actually the mixture of the fractional parts of both wide- and narrow-lane, can be estimated precisely. Due to this reformulation, the estimated wide-lane UPD is only needed for making the fixing decision, but not for the derivation of narrow-lane ambiguities and the reconstruction of the fixed ionosphere-free ambiguities. One must be aware of that if the estimated wide-lane UPD is biased, the fixed values for all ambiguities of the same satellite pair will be shifted by a common integer value. This shift will also cause a constant change in their narrow-lane ambiguities and can be absorbed by the narrow-lane UPD. Therefore, for the ambiguity fixing, the knowledge of the fractional parts of the UPD is sufficient. Concerning the determination of the narrow-lane phase-biases a number of further approaches (besides that one described above) are reasonable. In case the phase-observations are undifferenced, an additional datum problem has to be solved. Thus the bias of one arbitrary chosen satellite can be fixed to an integer value and all remaining real-valued phase-biases are resolved afterwards with respect to this ‘reference satellite’. This procedure conserves the internal phase relationship and is therefore also valid for coordinate determination.



Both investigated concepts, the “decoupled clock model” and the “recovering from fractional parts” can be reformatted to be RTCM consistent. From the processing point of view the main difference between the “decoupled clock model” and the “recovering from fractional parts” is the treatment of receiver specific biases. By using the “decoupled clock model” no differences are built. Therefore the receiver-specific biases have to be estimated somehow, which is an additional error source. The “recovering from fractional parts” approach uses satellite-to-satellite differences to eliminate receiver influences. Therefore the ambiguities can be directly fixed to integers, without treating any receiver biases. After in-depth tests and discussions the project group decided to pursue the “recovering from fractional parts” approach. The main argument is that due to the satellite-to-satellite differences the receiver UPDs do not have to be estimated. Therefore this approach has been realized in the upcoming WPs and in the RT-demonstrator.

3.4 Model Selection (WP 2400)



4 Simulation and Post-Processing (WP3000)

Within WPs 3000 the agreed model has been implemented by post-processing of global and regional network data and subsequent investigations on the stability of the derived UPDs have been conducted. In a previous step the successful recovery of artificially introduced UPDs has been proven.

4.1 Bias Simulation (WP3100)

In a first step, simulated observation data was generated in order to avoid model errors for the implementation of PPP algorithms. These data was generated by the Bernese software version 5.0 for the DOY 235 in 2012 based on accurate reference positions and final orbits by the IGS. The data contains phase and code observations in an interval of 5 s without satellite clock offsets as well as receiver specific biases or hardware phase delays in general. Further no receiver phase center offsets, no atmospheric delays and no noise is contained in this simulation. Using these observations the calculation of an ambiguity-fixed solution with PPP should be possible completely without knowledge of receiver or satellite un-calibrated phase delays (UPDs). At first, a PPP float solution of the simulated data for the station ADIS (at Addis Ababa University) was generated – showing the general quality of the processing algorithms. Figure 4-1 shows the NEU-differences of a single-differenced (sat-to-sat) solution with respect to the reference coordinates. Thereby the slight position variation can be explained by different interpolation methods used in the Bernese software and the software produced in PPPserve. Nevertheless, the positioning accuracy is at the cm-level which is/should be sufficient for subsequent ambiguity fixing routines.

Figure 4-1: NEU coordinates differences of simulated data of station ADIS

01 02 03 04 05 06

-0.15

-0.1

-0.05

0

0.05

0.1

0.15

0.2

Positions Over Time

Time [5 s interval]

Variation in P

lane C

oord

inate

s [

m]

dN

dE

dh



Figure 4-2: Ambiguity float estimates of simulated data

Figure 4-2 shows the estimated float values for the ambiguity parameters of the SD-PPP solution. The jump in epoch 2275 occurs due to the change of the reference satellite from PRN 20 to PRN 28. As expected from simulated data the values are distributed around zero. In a further step, the simulated data was used to fix integer wide-lane ambiguities without the need for wide-lane UPD corrections. Figure 4-3 shows the wide-lane fixes for the simulated data of station ADIS. The WL-fixing routine in this case is applied from the 50th epoch on. As we have used simulated data it is not surprising, that all WL-values are 0. Therefore also changes in reference satellites, occurring in epoch 2275, are not visible here, as they would be for real data. In Figure 4-4 the whole satellite elevation plot is shown for a matter of comparison of the number of satellites and the number of satellites with a fixed WL ambiguity.

Figure 4-3: Integer SD-WL ambiguities for simulated data

Figure 4-4: Satellites' elevation of simulated data

0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000-0.5

-0.4

-0.3

-0.2

-0.1

0

0.1

0.2

0.3

0.4

0.5

epochs

am

big

uitie

s [

m]

(not

absolu

te o

nes)


Prn2

Prn4

Prn5

Prn7

Prn8

Prn10

Prn11

Prn12

Prn13

Prn16

Prn17

Prn20

Prn23

Prn26

Prn27

Prn28

Prn30

Prn32

500 1000 1500 2000 2500 3000 3500 4000 4500 5000

5

10

15

20

25

30

epochs (5 seconds)

PR

N

Fixed integer SD-WL ambiguities

-1

-0.8

-0.6

-0.4

-0.2

0

0.2

0.4

0.6

0.8

1



Additionally we also tried to calculate narrow-lane integer fixes for the simulated data. Therefore, after 500 epochs, a search space consisting of possible integer values was defined. All possible combinations of a set of ambiguities were calculated and eliminated from the equation system in separate adjustments. Afterwards the best solutions were chosen with respect to the a posteriori variance from the respective adjustment and visualized in Figure 4-5. As for the WL-integer ambiguities it was expected, that also NL-integers are zero for the simulated data. But, there are two satellites in the beginning of the observation period, that are fixed to the value -1 by the actual fixing algorithm. This problem emerges already in the estimated float ambiguities of the same satellites of this dataset (Figure 4-2), with estimates below zero. This effect may occur due to an still insufficient converge (even after 500th epochs).

Figure 4-5: Integer SD-NL ambiguities for simulated data

As there is no noise in the simulated data, the fixing of especially the NL-ambiguities is not that problematic as for real data.

500 1000 1500 2000 2500 3000 3500 4000 4500 5000

5

10

15

20

25

30

epochs (5 seconds)

PR

N

Fixed integer SD-NL ambiguities

-1

-0.9

-0.8

-0.7

-0.6

-0.5

-0.4

-0.3

-0.2

-0.1

0



4.2 Post processed Satellite Phase Biases and their stability (WP3200)

This work package is the essential step from the design and simulation phase towards a continuous operating service level. By means of PPP Post we processed one week of recent observation data of a European network (see Figure Figure 4-6) to recover wide-lane and narrow-lane biases as described in WPs2000. Of special interest will be the stability of these biases. The wide-line UPDs should be stable over a number of days or a few weeks. The processing results in a table of single difference wide-lane and narrow-lane phases (SD WL UPDs and SD NL UPDs) with respect to a respective reference satellite. This table will be forwarded in WP3300 to the user receiver to apply the UPDs prior to position calculation.

Figure 4-6: European network

To test the stability of the WL UPDs and NL UPDs the software PPP Post was developed since the beginning of the project. It was possible to adopt some algorithms of RTIGU Control also for PPP Post which made it possible to finish most of the essential parts of the software within such a short time frame. The software allows the estimation of SD WL and NL UPDs in relation to one chosen reference satellite for the whole network. The advantage of the usage of only one reference satellite for the whole network is the amount of data which has to be transferred to the user. In the case of a single reference satellite only a maximum of 31

4.2.1 The software PPP Post



SD UPDs for the WL and NL observations each have to be transmitted to the user. If the corrections for every possible SD combination would be transmitted, then the number of corrections would increase to a maximum of 992 (32*31) for each observation type. The software is based on the concept of a real-time software. That means that the observations are read in and processed epoch by epoch. So the only difference between the PPP Post and the real time software is how the observations are read in. The approach and the design (see Figure 4-7) of the current status of PPP Post are described below. The blue filled boxes indicate the software components which have been developed until the submission of the MTR. The green filled boxes identify the components of the last past months. They finally allow the estimation of the SD NL UPDs and are therefore an essential part of the software. Since the BNC software offers no possibility to stream observations for post processing operations, routines to read in observations from RINEX files, have to be implemented in the PPP Post software. The current software is able to read in observation from RINEX files of version 2 and 3. The routines to read in orbits, differential code biases, station coordinates, antenna phase centre information and receiver information could be adopted from RTIGU control. Currently the software is not able to read in broadcast information plus the additionally needed orbit and clock corrections. The IGS products of the IGS are used to generate the orbits instead. Both products (IGS – Broadcast information plus orbit and clock corrections) are comparable in terms of accuracy, therefore the usage of the IGS products has no effect on our investigations.



Figure 4-7: Design of PPP Post

After successful input of all the necessary information PPP Post processes observations of a defined network epoch by epoch. This process includes the conversion of the Code observation to P1 and P2 observations, several algorithms to detect cycle slips and outliers plus the calculation of a number of smaller corrections. In a first step the SD WL UPDs are estimated. A detailed description of the process is given in chapter 4.2.1.1. Afterwards a PPP SD solution is estimated at every station of the network (see chapter 4.2.1.2). These two processes are totally independent of each other which enables parallel processing to save computation time in the future. In a next step the SD WL UPDs are used to fix the SD WL ambiguities of each station. After a successful fix they are subtracted from the corresponding SD ionosphere-free ambiguities. Those results are used for the estimation of the SD NL UPDs, see chapter 4.2.1.3.

The theoretical background for the estimation of the SD WL UPDs was already described in section 3.2.2 but for convenience it is repeated at this point. The so called Melbourne-Wübbena MW combination is built in a first step. It is a linear combination of both, carrier phase (L1 and L2) and code (P1 and P2) observables and

4.2.1.1 The estimation of SD WL UPDs



eliminates the effect of the ionosphere, the geometry, the clocks and the troposphere. It provides a noisy estimation of the wide-lane ambiguity BW, according to the following equation: 4-1

where NW = N1 − N2 is the integer wide-lane ambiguity, bW accounts for the satellite and receiver instrumental delays and ε is the measurement noise, including carrier phase and code multipath. Since the MW combination is a combination of phase and code measurements the noise of the combination is strongly correlated with the noise of the code observables. To reduce the noise of the MW combination the mean

and sigma values are estimated with a real time algorithm for each epoch k:

4-2

4-3

This calculation is performed for every satellite with an elevation angle larger than 15 degrees at every station of the whole network. The selection of the stations of our European network was not based on a homogenous distribution only, we also took care that the network consists of not too many different receiver types. To illustrate the influence of the code measurements on the MW combination and to get an idea of the accuracy of the MW combination, some typical examples of different receivers are given (Figure 4-8 to Figure 4-11). The red line indicates the zero difference ZD raw MW observation in cycles, the blue one the mean value plus standard deviation in cycles and the black one the elevation angle in degrees. In the first example (see Figure 4-8) it is obvious that the noise of the raw MW combination is correlated with the elevation angle. This indicates that the noise of the code observations is higher for satellites at lower elevations for this specific receiver type. In our whole network this is the only receiver type where this effect could be seen. In the second example (see Figure 4-9) the noise of the raw MW observation is quite small. One explanation might be that the software of the receiver already applies some kind of smoothing to the code observations. In our network only two receiver types exist which show such a behaviour. All the other receivers show a similar behaviour like the last two examples (see Figure 4-10 and Figure 4-11). The raw MW observations are quite noisy and no obvious correlation between the noise of the MW observations and the elevations can be seen. Despite the different quality of the raw MW observations, the mean values of the MW observations are rather stable for all receiver types. Furthermore the variation (standard deviation) of the MW observations is smaller than 0.3 cycles in most of the cases. This indicates, that based on MW observations a reliable estimation of the SD WL UPDs is possible.



Figure 4-8: ZD MW LEICA GRX1200PRO

Figure 4-9: ZD MW LEICA GRX1200GGPRO

Figure 4-10: ZD MW TRIMBLE NETR5

Figure 4-11: ZD MW JPS LEGACY

In the next step every SD with respect to the chosen reference satellite is built for each of the stations. Then the positive fractional part for each of these SDs is calculated. The concept of the “positive fractional part” deserves a closer look. Building the SDs by a simple subtraction between two satellites will result in fractional parts between minus one and plus one cycle. Figure 4-12 and Figure 4-13 show the calculated fractional parts of two specific satellite pairs which are observed at several stations. Each station is illustrated by a different line style. It can be seen in both examples that building only the difference will result in two different solutions. One in the positive and one in the negative value ranges. In the case of values which are near to an integer the situation is even a little more complex (see Figure 4-13). Keeping in mind that a summation of one cycle to the values in the negative value ranges does not affect the ambiguity resolution, we developed a simple but effective algorithm to receive only the “positive” fractional parts (see Figure 4-14 and Figure 4-15). As mentioned before in the case of fractional parts near integer value the situation is a little more complex. This means that some of the values are still in the negative value range but we do not have two solutions anymore (see Figure 4-15). Furthermore it can be seen that the values for the different stations are stable during the whole observation period and are within a range of 0.2 cycles. This is a proof for our assumption that satellite specific phase biases exist and that they can be estimated using a reference station network.



Figure 4-12: SD MW fractional parts PRN 12 - PRN 24

Figure 4-13: SD MW fractional parts PRN 1 - PRN 14

Figure 4-14: SD MW positive fractional parts

PRN 12 - PRN 24

Figure 4-15: SD MW positive fractional parts

PRN 1 - PRN 14

In a next step the positive fractional parts for each SD are forwarded to the next filter sequence. Only single differences which are observed by at least 20 stations will be processed in a respective Kalman filter. This quantity of stations seems quite high but is necessary for a reliable estimation of the SD WL UPDs. The following figures illustrate some of the results. The collared lines indicate the SD WL UPDs observed at different stations of the network, whereby outliers which are detected and removed within the Kalman filter, are missing. The thick black solid line marks the estimated SD WL UPD based on the observations. As it can be seen the UPDs of the different stations show a very good agreement and are very stable during the time the reference satellite is visible. Therefore a continuous estimation of the UPD is possible. As expected the estimated UPD is close to the mean value of the observations. This is also the case for the estimated UPDs at different times which are related to different reference satellites. The results are saved within and the software and are used within the next segment.



Figure 4-16: SD WL UPD

PRN 16 - PRN 30

Figure 4-17: WL UPD

PRN 12 - PRN 29

The theoretical background for the estimation of the SD NL UPDs was already described in section 3.3 but for convenience a short repetition is given. In our case only SD ambiguities between one receiver k and two satellites i and j can be defined. According to [GE 2008] the ionosphere free (IF) phase observations, in form of integer ambiguities and phases biases are described by:

jiji

k

ji

n

ji

kn

ji

kc nff

ffn

ff

fb ,,

2

2

2

1

21,,

21

1,

4-4

with: f1, f2 frequencies on L1 and L2 of the GPS system,

ji

kcb,

carrier-phase ambiguity

ji

kn

,

and ji

knn,

Integer ambiguities

jin, and ji,

SD wide- and narrow-lane phase biases

At first we need an estimate of all the SD IF ambiguities ji

kcb,

at a specific station. Those ambiguities are with

respect to a station specific reference satellite. In most of the cases the station specific reference satellite will correspond to the reference satellite of the network, but it must not be the same. This particular case occurs if there is no observation to the reference satellite of the network, due to a cycle slip for instance. In such a case the reference satellite at the station must be changed. However this has no effect on the estimation of the carrier-phase ambiguities itself and can be ignored in the first place. The SD IF ambiguities are estimated together with the ZTD within a SD PPP solution at each station. All other errors are modeled or eliminated by building the ionosphere free linear combination and the difference between the observations of two satellites. The station coordinates are well known and are not taken into account. To test the quality of our SD PPP solution we compared our estimated ZTD values with the values which are estimated within the routine operations of the EUREF network [EUREF]. The two following figures

4.2.1.2 Single Difference PPP solution



show the comparison for two stations of our chosen network. The blue line indicates the ZTD estimate of our SD PPP solution the red one the one of the EUREF solution. The peeks in our SD PPP solution have their origin in the initialization of the filter after a reset. After a short initialization time the differences between our SD PPP solution and the EUREF solution are in the range of only a few centimeters. This is also the case for all other stations of our chosen network. This circumstance indicates that our SD PPP filter performs very well.

Figure 4-18: Comparison of the ZTD for station CAEN

Figure 4-19: Comparison of the ZTD for station ROVE

Before we focus on the estimation of the SD NL UPDs we would like to outline a big issue which was already mentioned, the issue of different reference satellites. As stated previously it can happen that the reference satellite at a station differs from the reference satellite of the network. As we want to combine the results of all stations it is necessary to have one common reference satellite. A change of the reference satellite at a station is done by a simple combination of the regarding observations, in this case the SD IF ambiguities. The principle shall be explained by an example. In our example the reference satellite of our network is satellite 16. At one of the stations of our network the following SD IF ambiguities are estimated:

SD satellite pair SD IF ambiguity

3-6 3,9

3-16 -5,7

3-24 8,3

These are the SD IF ambiguities between the reference satellite of the station (satellite 3) and all the other satellites visible at the station (satellites 6, 16 and 24). To change the reference satellite from 3 to 16 we simply take the inverse value of the SD IF ambiguity of the SD satellite pair 3-16 and add it to the other ambiguities:

SD satellite pair SD IF ambiguity

16-6 = 16-3 + 3-6 9,6 = 5,7 + 3,9

16-3 5,7

16-24 = 16-3 + 3-24 14 = 5,7 + 8,3

The same procedure is also used for the combination of the SD WL and NL UPDs in the software of the client.



After the shift of the reference satellite we can continue with the estimation of the SD NL UPDs. With the

help of the SD WL UPDs which have been already estimated we try to fix the SD WL ambiguities .

Therefore we use a very simple algorithm. At first we apply the corrections to the specific SD WL ambiguities, afterwards we calculate the difference between each ambiguity corrected and the integer value next close to it. Is the difference smaller than a certain value (in our case 0.25 cycles) we fix the SD WL ambiguity to the

integer value. After a successful fix one gets the SD NL ambiguity ji

n

ji

knn ,, with the following

reformulation of Eq. 3-9:

ji

k

ji

kc

ji

n

ji

kn nff

fb

f

ffn

,

21

2,

1

21,,ˆˆ

4-1

with: ji

kcb,

carrier-phase ambiguity estimated within the SD PPP solution

ji

kn

,ˆ Fixed WL ambiguity

At last the positive fractional parts of the particular SD NL ambiguities are forwarded to the next filter sequence.

Most of the algorithms which were already developed for the estimation of the SD WL UPDs were also used for the estimation SD NL UPDs in further consequence. The main difference between the two estimation processes is the stability of the SD UPDs. As mentioned at the beginning, concerning the narrow-lane UPDs we face a sophisticated problem. Narrow-lane UPDs are less stable by far which is due to their small wavelength of about 10 cm as well as unmodelled effects introduced by remaining error sources (troposphere, remaining ionosphere, orbits and clocks). Therefore we expected major differences between the SD NL UPDs estimates of the different stations. The following figures (Figure 4-20 to Figure 4-23) illustrate some of the results. The coloured lines indicate the SD NL UPDs observed at different stations of the network, whereby outliers which are detected and removed within the Kalman filter, are missing. The thick black solid line marks the estimated SD NL UPD based on the observations. As it can be seen the SD NL UPDs of the different stations are in the range of only a few tenths of a cycle. One has to keep in mind that one NL cycle corresponds to approximately ten centimetres, so one tenth of a cycle corresponds to only one centimetre. Those results even exceeded our own expectations and therefore we can conclude that all necessary errors are modelled quiet well. Another very interesting point is that the SD NL UPDs are very stable for each of the satellite pairs. So a continuous estimate of the UPDs is possible and no time-dependent change has to be considered in order to provide high quality biases. In further consequence the long term stability of the SD NL UPDs is of special interest. This topic will be treated in the upcoming section. At this point we want to remind that the NL UPDs are calculated on top of the a priori determined wide-lane UPDs. Thus the narrow lane UPDs cover not solely satellite calibration biases but also remaining effects, which mimic to a certain amount the regional atmospheric environment. This is on the one hand unpleasant, because these parameters cannot be determined a priori or from a post-processing step, but have to be determined in close to real time from the reference station data. On the other hand this process allows recovering unique information from the dense regional reference station network like EPOSA. In other words

4.2.1.3 The estimation of SD NL UPDs



the narrow-lane UPDs cover the individual additional value offered by the chosen network provider via a special service level.

Figure 4-20: SD NL UPD

PRN 16 – PRN 18


PRN 1 – PRN 23


PRN 8 – PRN 28


PRN 9 – PRN 15

In summary, in the operational phase the narrow-lane UPDs will be determined within the real-time environment (see chapter 5; WPs 4000). In the next section we will investigate the stability of the WL and NL UPDs to evaluate the optimal validity periods of these parameters.

Within this section we will investigate the stability of the WL and NL biases by processing one whole week of observations with the software PPP Post. This is necessary to validate which update rate guarantees a good performance at the client site. We expect the WL UPDs to be stable over a couple of days or even weeks. The following figures show the stability of the SD WL UPDs for four different satellites with respect to the reference satellite 9 and 16.

4.2.1.4 Stability of the biases



Figure 4-24: Stability of SD WL UPD

PRN 9 – PRN 10


PRN 12 – PRN 2

Taking a look at the figures shown above it becomes clear that estimated SD WL UPDs are very stable during the whole week we investigated. So the SD WL UPDs are not only stable during the time they are observed (usually once per day) they are also stable over much longer periods. In consideration of an operational service we have now two possibilities to process the SD WL UPDs. The first option is to post process the UPDs with our PPP Post Software with a delay of one day. The second one is to estimate them in real-time together with the SD NL UPDs. The first option has the advantage of reduced computational burden for the real-time software. On the other hand it is sufficient enough to estimate the SD WL UPDs only every 30 seconds or even only every minute which does not need a lot of computer power. Therefore we decided to estimate the SD WL UPDs in real-time. Of special interest is the stability of the NL UPDs. The results shown in the previous section indicate a better stability as expected at the beginning of the project. Now it is of special interest to verify if the NL UPDs are also stable over longer periods. As it can be seen in the following pictures most of the estimated SD NL UPDs are very stable during the time they are observed (once per day), but contrary to the SD WL UPDs they are not stable over longer periods. Those differences are probably caused by remaining errors in the orbits and satellite clocks and errors introduced by the mapping function. One has to keep in mind that one full NL cycle corresponds to about 10 cm, so the differences between the different “daily” solutions are in the range of a few centimetres only. In one of the examples given below the estimated SD NL UPDs seem to drift (see Figure 4-29). Those drifts may have their origin in un-modelled satellite specific errors. Since the effect is rather small it can be neglected in the first place but it will be investigated during the implementation of an operational service. Due to those drifts the SD NL UPDs should be estimated every 10 to 30 seconds.




PRN 9 – PRN 15


PRN 12 – PRN 29


PRN 9 – PRN 18


PRN 12 – PRN 4

Beside their real time service CNES also provides post processed WL UPDs on their ftp server. They offer daily files which include corrections for each satellite referred to midday of each specific day. We used this service to compare our real time estimated WL UPDs with the corrections made available by CNES. Therefore we processed one day of observations for the 28th of March 2013. Since CNES provides zero difference UPDs no direct comparison with our estimated single difference UPDs is possible. So in the first step we used the zero difference corrections from CNES to create a table with all possible single difference UPD combinations. Afterwards we compared them with our estimated UPDs. Since we processed one whole day of observations the reference satellite changed several times (see section 4.2.1.2). In this specific test scenario we have nine different reference satellites. To make a robust conclusion concerning the quality of our estimated UPDs we compared one set of UPDs per reference satellite with the UPDs provided by CNES. These comparisons are content of nine tables which are taken together in Figure 4-30, which can be seen below. Each one of the tables is related to one reference satellite and includes the differences of the SD WL UPDs between CNES and

4.2.1.5 Comparison with CNES



our estimates (second row) given in WL cycles (one WL cycle corresponds to ~86 cm) for all difference satellites available (first row). For most of the cases six to seven corrections are available. The number of available UPDs is mainly limited by our European network. With such a regional network it is not possible to estimate corrections for the whole constellation. The number of corrections available can be expected using a regional network like this. But much more interesting are the differences between CNES and our solution. The biggest differences are in the region of one tenth of a cycle (highlighted in red). These differences do not state a problem but they are much bigger than all the other differences. The majority of the differences are below one tenth of a cycle. The mean value accounts for 0.034 WL cycles, which corresponds to ~3cm. Based on this investigations we may infer that our WL UPDs are almost identical to the WL UPDs provided by CNES. RefSat: 1

SDSat 11 14 17 20 23 31 32

Δ 0.009 0.011 0.007 0.002 0.009 0.075 0.024

RefSat: 2 SDSat 4 5 7 8 10 13

Δ 0.004 0.049 0.028 0.089 0.032 0.021

RefSat: 3 SDSat 1 6 11 14 18 19 22

Δ 0.077 0.018 0.083 0.089 0.016 0.010 0.028

RefSat: 4 SDSat 1 6 9 12 19 22

Δ 0.024 0.030 0.015 0.020 0.004 0.008

RefSat: 5 SDSat 7 8 9 10 15 26 28

Δ 0.024 0.031 0.073 0.014 0.084 0.011 0.159

RefSat: 9 SDSat 11 14 16 17 23 25 27

Δ 0.148 0.038 0.059 0.016 0.026 0.019 0.020

RefSat: 12 SDSat 2 4 14 24 25 29

Δ 0.030 0.006 0.003 0.047 0.022 0.062

RefSat: 29 SDSat 5 16 21 25 31

Δ 0.001 0.096 0.032 0.008 0.008

RefSat: 30 SDSat 3 6 16 18 19 21 22

Δ 0.045 0.009 0.031 0.002 0.046 0.001 0.013

Figure 4-30: Comparison of SD WL UPDs

For the transmission of the post-processed UPDs within WP3200 the project consortium has agreed on a simple text format which is shown in an example below. * 2013 3 28 10 22 0.00000000 382920 4 20 -0.452 0.001 23 0.419 0.001 The first line contains the epoch of the corrections, the second one the reference satellite (in this case 4) and the following lines the corrections plus standard deviation of all the difference satellites of the network (in this example the satellites 20 and 23).

4.2.1.6 Forwarding the biases to the rover (Post processing)



4.3 Application of Biases (WP3300)

The WL and NL UPDs are tested and evaluated in the PPPserve user client. There the UPDs are applied to recover the integer nature of the WL and NL ambiguities. The fixed integer ambiguities can be re-introduced in the PPP solution. In case of successfully established and applied UPDs the convergence of the coordinate solution should be extremely short. In other words the applied UPDs should allow for an ambiguity fixing in zero-difference mode after introducing only a few epochs of observations. The tests in WP3300 are performed by means of the PPPserve user client, which is a Matlab-based software that enables, on the one hand, several modes of standard PPP processing, where ambiguities are estimated as float values, and, on the other hand, was modified to apply certain types of phase biases for integer

ambiguity fixing. Aside from CNES phase biases (see section PPP solution with CNES data3.2.4) also the use of the UPDs calculated in the course of the PPPserve project itself are supported. In this chapter the PPP-ambiguity fixing concept is described from the user’s point of view. The design of the software developed at INAS during PPPserve will be presented.

Generally, the observation model of standard PPP solutions is a zero difference model (ZD), where no differences are built between receivers or satellites. But, as PPP in the broadest sense only denotes the processing of isolated stations, we could also switch to a slightly different model, where satellite-to-satellite single-differences are built (SD). By doing so, all receiver specific errors (also receiver specific UPDs) cancel out and the parameters to be estimated are reduced by the receiver clock error. Remaining parameters are the receiver’s three-dimensional static or kinematic coordinates and , the wet part of the troposphere zenith delay (the hydrostatic part is modelled by e.g. a Hopfield model), and the

differenced ambiguity estimates of the satellites w.r.t. a reference satellite . The observation

differences (observed minus computed range ) contain the SD code- and phase-observations

und .

4-2

As the functional dependence between the parameters and the observations is non-linear, a linearized model has to be used. Thereby, the design-matrix for the single-difference model between reference satellite and the other satellites consists of the following partial derivatives

4-3

4.3.1 PPP observation model



,

whereby each component is a difference of the derivative of the reference satellite minus the actual satellite. Therefore the complete design matrix looks like

.

4-4

The ambiguities can be estimated in metres instead of cycles, therefore the wavelength can be replaced by 1. Experiments show that it leads to the same coordinate results, no matter which design is chosen, the single-difference or the zero difference model. In the beginning of the processing of the PPPserve user client a standard PPP solution is implemented using the SD model. Precise orbit- and clock data for the satellites can be either taken from post-processed precise orbit and clock files from the IGS, or from an RTCM 3.1 stream providing PPP corrections in real-time. To decode these binary data streams, the open-source BNC RTCM-client is used in addition. Implementing a proprietary RTCM encoder/decoder would have gone beyond the financial and temporal scope of the project. Further error influences such as hydrostatic troposphere delay, tidal corrections, phase centre offsets of receiver and satellites, phase wind-up effects and so on are modelled within the PPPserve client to reach an accuracy of only few centimetres. Generally the PPPserve client performs 4 elementary processing steps

1. WL-fixing in the pre-processing step

2. PPP-float solution

3. IF-ambiguity estimates as input for NL-ambiguity fixing

4. LSQ with fixed WL- and NL-integer ambiguity values

The WL-fixing procedure works similar as described in section 3.2.4 for the WL-fixing with CNES data. Again MW-observations (see equation 4-5) are built and collected over some epochs. But in this case, no separate phase-corrections to L1 and L2 are used as it was the case for CNES correction sets, now the P1, P2 code pseudoranges as well as the L1 and L2 phases are used without corrections for code or phase biases. Only after the MW-observables are built, the sat-to-sat WL-UPD correction by TU Vienna is applied to the combined observations. Note that the WL-UPDs have to be adapted to be valid for the reference satellite of the actual epoch in the PPP software, which might differ from the reference satellite of the UPDs.

4.3.2 WL ambiguity fixing



. 4-5

As the SD-WL-combination is free from receiver specific biases, after application of the satellite specific UPD the WL-integer values can be fixed by simple averaging over a short time. As soon as the average of a WL-observation minus its rounded value is beneath a threshold of ±0.25 cycles, the WL-ambiguity is fixed to this rounded value.

4.3.3 NL ambiguity fixing

The input values for this function are the SD IF-ambiguities estimated in the float solution as well as its variance and covariance values. Further the NL-UPDs obtained from TU Vienna are needed for integer ambiguity fixing here. The estimated IF-ambiguities, the WL-integer ambiguities as well as the NL-UPDs are used to calculate estimates for the NL ambiguities according to equation 3-11. Note, that the WL UPDs were only needed for the WL ambiguity fixing – once the WL integer values are known, they are not used any more. The NL estimates get corrected by means of the NL-UPDs - afterwards the ambiguity values are sorted by their standard deviations. From now on we start with a bootstrapping method to find the right NL-integer ambiguity values. This algorithm is characterized by 4 steps and is shortly described afterwards.

1. A subset of the best n ambiguities (n starts with 2) is selected. These are the ones with the smallest

standard deviation values in the float solution.

2. The ambiguity subset together with its variance-covariance matrix is processed in the so-called

LAMBDA method. The LAMBDA (Least-squares ambiguity decorrelation adjustment) method is a

strategy developed by [TEUNISSEN 1993] for ambiguity resolution by decorrelation of ambiguities.

This method produces optimal solutions (to the integer least squares problem in quadratic form) of

integer values depending on float-ambiguities and their variances and co-variances. Further a quality

factor to each solution is given.

3. Afterwards two criteria have to be fulfilled.

The is calculated from the quality parameters of the best and the next-best solution derived

in step 2. In the beginning of the fixing procedure this ratio has to be larger than 3, meaning that the

best solution is significantly better than the second-best one. Unfortunately this value becomes

larger and larger with time, and therefore has to be adapted.

. 4-6

The second criterion, the so-called success-rate (see [TEUNISSEN 2001]) is calculated simply from the variance-covariance matrix of the ambiguity subset by



, 4-7

Where is the probability of the integer solution as the true integer value . is the number of integer ambiguities. If both criteria are fulfilled, the algorithm restarts with a new subset of ambiguities to be

fixed. This goes on until at least one criterion is not fulfilled.

4. If one criterion fails, the preceding subset of integer ambiguities is fixed as the correct set of integer

values.

The described algorithm is done every epoch for all the satellites above a predefined elevation angle (e.g. >15°). As the noise of the ambiguities is quite high compared to the small wavelength of ~10.6 cm, it is not guaranteed, that the right integer values are fixed – therefore, the fixed integer value can be released again, if another value seems to fit better after some more epochs. Especially in the first processing epochs, when the float solution has not converged yet, it is likely that one or another value is fixed to the wrong integer. Unfortunately, the true value cannot be accessed with real data, therefore the success of integer PPP strongly depends on the following factors:

Satellite geometry – a bad geometry implies strong correlations between the satellites, which makes

independent ambiguities more difficult to fix to their correct integer values.

Convergence time of the solution and therefore also the quality of the initial rover coordinates

introduced – also the avoidance of troposphere estimation by introducing highly accurate models can

increase the fixing time and quality of the PPP solution

Quality of the introduced UPDs

4.3.4 PPP with fixed ambiguities

As soon as some NL integer ambiguities are fixed, they can be introduced to a 2nd PPP solution. Therefore the IF ambiguities are reconstructed from WL-integers and NL-integers plus the respective UPD-value (see equation 3-9). Note, that equation 3-9 is only a general formulation of the IF-ambiguity. In PPPserve, the UPDs are estimated in a way, where only the NL-UPDs are needed for the reconstruction – the WL-ambiguities are inserted as integers without correction. Afterwards there are two possibilities to introduce the ambiguity information to the least-squares-adjustment: Either the ambiguity values are treated as known values and subtracted from the phase observations, or they are introduced as pseudo-observations with large weight additionally to the equations already used in the float solution. Both should result in the same estimated position coordinates. In the PPPserve user client we use a least-squares-adjustment with all available observations per epoch, even if there is no ambiguity fix for the satellite. This has the advantage that the solution does not fail completely, in case there are too few fixed satellites, which can occur for some reasons. The parameters are the same as in the float solution, except that the ZWD of the troposphere is introduced from the float solution and not estimated again. Ambiguities are fixed as they are forced to the calculated values by inserting large weights for the pseudo-observations, while the remaining ambiguities are still



estimated as float values as a side-product. There are some satellites in every observation data - mainly low ones - that cannot be fixed at all. This has no effect on the solution, as long as they are outnumbered.

To show the convergence of a standard PPP solution the calculation was performed with a series of approximate coordinates of different accuracy. Therefore observation data of the IGS station Graz Lustbühel (GRAZ) from DOY 335 in 2012 was used. The observation interval of the data is 1 second and real-time orbit and clock corrections by CNES were used to get best possible information on satellite orbits and clocks. In the following the standard deviations for the station coordinates used as approximate values were assumed as follows:

1. 3e5 m 2. 1 m 3. 0.5 m 4. 0.1 m 5. 0.05 m The tests show, that an accurate approximate position can strongly reduce the convergence time of the coordinate solution in PPP. Thereby it makes nearly no difference, if the starting point of the solution is chosen completely arbitrary or just in the proximity of 1 m to the true position. If the approximate position is more accurate than 1 m, the convergence time can be significantly reduced. Further, this investigation shows, that the filter used in our software behaves as expected and works properly.

Figure 4-31: ZD PPP solution with initial coordinates

with arbitrary accuracy

Figure 4-32: ZD PPP solution with approximate

position of 1 m accuracy

200 400 600 800 1000 1200 1400 1600 1800 2000-0.5

0

0.5

dN

[m

]

200 400 600 800 1000 1200 1400 1600 1800 2000-0.5

0

0.5

dE

[m

]

200 400 600 800 1000 1200 1400 1600 1800 2000-0.5

0

0.5

dh [m

]

Epochs [1 s interval]

200 400 600 800 1000 1200 1400 1600 1800 2000-0.5

0

0.5

dN

[m

]

200 400 600 800 1000 1200 1400 1600 1800 2000-0.5

0

0.5

dE

[m

]

200 400 600 800 1000 1200 1400 1600 1800 2000-0.5

0

0.5

dh [m

]


4.3.5 PPP convergence depending on quality of approximate coordinates




position of 0.5 m accuracy



Figure 4-35:ZD PPP solution with approximate


200 400 600 800 1000 1200 1400 1600 1800 2000-0.5

0

0.5

dN

[m

]

200 400 600 800 1000 1200 1400 1600 1800 2000-0.5

0

0.5

dE

[m

]

200 400 600 800 1000 1200 1400 1600 1800 2000-0.5

0

0.5

dh [m

]


200 400 600 800 1000 1200 1400 1600 1800 2000-0.5

0

0.5

dN

[m

]

200 400 600 800 1000 1200 1400 1600 1800 2000-0.5

0

0.5

dE

[m

]

200 400 600 800 1000 1200 1400 1600 1800 2000-0.5

0

0.5

dh [m

]Epochs [1 s interval]

200 400 600 800 1000 1200 1400 1600 1800 2000-0.5

0

0.5

dN

[m

]

200 400 600 800 1000 1200 1400 1600 1800 2000-0.5

0

0.5

dE

[m

]

200 400 600 800 1000 1200 1400 1600 1800 2000-0.5

0

0.5

dh [m

]




5 Real-Time Processing (WP 4000)

In order to assist RT- Precise Point Positioning of a user client two different types of global corrections have to be calculated. These global corrections are on one hand radial, along track and cross track orbit corrections to broadcast ephemeris, on the other hand so called clock corrections. The estimation of orbit and clock corrections to broadcast ephemeris in real-time is performed using the software RTIGU-Control which is under development at the institute of Geodesy and Geophysics of the Technical University of Vienna. In addition the BNC-software provided by BKG (Bundesamt für Kartographie und Geoinformation) can be used for uploading the corrections to a NTRIP server/caster.

The software RTIGU-Control

The IGS (International GNSS Service) Real-Time Working Group (RTIGS) disseminates raw observation data of a globally distributed steady growing station network for several years in real-time via the internet. This network consists mostly of IGS permanent stations spread more or less regularly around the globe. The actual station distribution is shown in Figure 5-1.

Figure 5-1: Current stations of the RTIGS-Network

Currently, more than 100 stations are contributing in the RTIGS network. The data format is the so called RTIGS format. Within this format observation data but also broadcast ephemeris or meteorological data can be streamed through the internet to the users. These real-time observations can be used for calculating clock errors w.r.t. GPS-Time and orbit parameters of the GPS satellites in near real-time (delay of 10-15 seconds). The resulting products are used for the calculation of correction terms to broadcast ephemeris. These correction terms consist of orbit corrections in radial, along track and cross track direction plus a correction for the satellite clock error. Therefore, based on pre-processed ITRF- station coordinates, clock corrections w.r.t. GPS-Time for GPS-satellites and site-receivers as well as satellite orbits are calculated in near real-time and forwarded to the software package BNC. BNC is able to calculate broadcast corrections for satellite orbits and clocks using broadcast ephemeris

5.1 Real-Time Global Corrections (WP 4100)



and real-time orbit and clock parameters in sp3-format. The correction terms are then uploaded to the NTRIP Broadcaster IGS-IP and are afterwards available to a broad user community. Within RTIGU Control the following general steps are currently performed:

Code smoothing: The Code smoothing algorithm is based on a weighting procedure of temporal

phase differences together with raw Code observations. Actual Code DCB´s provided by CODE are

applied to both frequencies. Also Cycle-Slip detection is performed within this calculation step.

Ionosphere free linear combination: The smoothed PRs of frequency 1 and 2 are merged into PR3

using the iono-free linear combination to get rid of the ionospheric delay of the signals.

Apply corrections: The tropospheric effect is corrected using gridded ZHD and ZWD values calculated

from numerical weather models (predictions). They are mapped into the specific elevation using the

VMF1. The 2nd-order relativistic effect is applied and the absolute antenna offsets (IGS05.atx) are

included.

Linear Kalman Filter; Clocks: Within this calculation step the satellite clock errors w.r.t. GPS-Time as

well as their linear drifts are calculated. Because of the unpredictable behaviour of most station

clocks, they are a priori calculated using the pre epoch satellite clocks and applied to the

observations. In the filter only correction terms are estimated. The mean of all satellite clocks is

aligned to the IGU clock mean (reference).

Extended Kalman Filter; Orbits: Using again the observations corrected for the satellite and station

clock errors the orbits of the satellites are estimated. The used kinematic model consists of the

central term for earth gravitation plus the oblateness (J2) of the Earth. The predicted values are

created using numerical integration. After this step the positions as well as the velocities of all

available satellites are obtained.

Archiving and Streaming: All calculation results are implemented in Clock RINEX and SP3 orbit files

for further analysis and stored on the ftp-server of the institute of Geodesy and Geophysics of the

Technical University of Vienna. Additionally sp3-Files containing the calculated orbits and clocks are

generated every epoch and forwarded to BNS. BNS then is able to calculate correction terms to

broadcast ephemeris and upload them to the NTRIP Broadcaster.

Within PPPserve the software RTIGU-Control was modified. Missing corrections like phase wind-up

corrections and the station displacement conventions from the International Earth Rotation and Reference

System Service have been applied. Furthermore the estimation of float ambiguities was implemented, which

made it possible to determine the clock and orbit corrections based on phase observations.



The software PPP Post which was developed in the context of WP 3000 (see section 4.2.1) is based on the concept of a real-time software. That means that the observations are read in and processed epoch by epoch. So for the realization of a real time software only slight modifications have to be made. These modifications are related to the observations and orbits only.

Figure 5-2: Modified design of the PPP Post software

Figure 5-2 shows a slightly modified version of the block diagram which was already presented in section 4.2.1. The only differences (highlighted in red) are related to the input of the observations and the orbits. The observations can be obtained from a real time network like the RTIGS network (see section 5.1). In case of the orbits broadcast ephemeris plus orbit and clock corrections are used (also see section 5.1). The corrections must not necessarily be obtained from RTIGU-Control. These days a lot of analysis centers, like the BKG, CNES etc. are providing corrections in real time. The observations as well as the broadcast ephemeris plus corrections can be obtained using the software BNC. There is no need to change the routines

5.2 Real-Time Phase Bias Generation WL and NL (WP 4200)

http://www.dict.cc/englisch-deutsch/necessarily.html



to import the remaining information for differential code biases, station coordinates, antenna phase centre information and receiver information. Unfortunately we were not able to establish an operational implementation of real time software within the given life span of the project (until end of November 2013). This final implementation has to be realized within the upcoming months (partially already executed in January 2014). Within the project we therefore concentrated on the successful operation of the software PPP Post.



The UPDs calculated have to be transmitted to the user in real-time. During the system’s setup phase and for testing purposes text files as described earlier in section 4.2.1.6 were transmitted. This way of provision has the big advantage, that tests can be repeated over and over again with the same settings. But, to provide real field-users with the UPD-corrections to enable integer-PPP we have to switch to another concept. Up to now in RTCM 3.1 only message types to transmit orbit and clock corrections are defined. There are no message types for the transmission of SD UPDs. Within the last group meeting the project consortium agreed on a concept which is very similar to the one which is used by CNES for the transmission of UPDs in real-time (see section 3.2.3). The message type 1059 of RTCM 3.1 is usually used for the transmission of differential code biases. This message could be used for the transmission of our estimated UPDs but we have to take care of one important aspect:

- The message type 1059 is designated to direct biases to the un-combined observations, while we

would like to transmit messages for linear combinations of the UPDs for WL and NL.

- The usage of such sat-to-sat differences of the UPDs, makes it necessary to define a reference

satellite, where all satellites’ UPDs are referenced to.

To identify this reference satellite we will use a simple trick. All the estimated WL and NL corrections are defined in a specific range (see section 4.2.1.1). So the reference satellite can be identified by transmitting a correction value which is out of this specific value range. Table 5-1 gives an example how this could look like. In this example the reference satellite is the satellite G01 and this is indicated by the correction related to the satellite (99.99). Since our corrections are defined within a range of -1 to +1 this would be a simple and robust method for the identification of the reference satellite. To distinguish between WL and NL UPDs we will use an indicator number. According to the RTCM 3.1 standard the integer numbers between 1 and 15 serve to indicate already existing signals. The integer numbers between 16 and 31 are currently not in use. So we decided to use 21 to indicate WL UPDs and 22 to indicate NL UPDs. CNES uses the same numbers to indicate their corrections (see Figure 3-7).

Message Type

GPS Week

Second in GPS Week

PRN Number of Biases

Indicator to specify the signal

UPD

1059 1771 218845.0 G01 2 21 99.99

1059 1771 218845.0 G22 2 21 0.148

1059 1771 218845.0 G11 2 21 -0.153 Table 5-1: Example of proprietary message

This is of course not RTCM standard. So we will need a modified RTCM encoder at the server side and a modified decoder at the client site. The modifications can be implemented very quickly to an existing RTCM en- and decoder, like BNC. In addition to the UPDs we will also clock corrections have to be transmitted. To forward all this information to the user a modified version of BNC could be used. BNC is able to upload a correction data stream for global orbit and clock corrections to an NTRIP-Caster. The user client receives all these messages via a TCP/IP connection established to the NTRIP-Caster. At the user client side the received correction data stream has to be decoded using the RTCM 3.1 standard at the one hand and using the proprietary message definition on the other hand to extract the correction information and to start the RT-PPP algorithm.

5.3 Forwarding Biases to Rover (WP4300)



Though, by now this is only a conceptual design of a field-suitable version of our PPP system, which can easily be realized based on open-source tools. If the service was integrated in commercial network services like EPOSA, the whole concept of transmitting biases has to be planned in a more detailed way.



In the following paragraphs some PPP results generated with UPD-data by TU Vienna are presented. The first result (see Figure 5-3) is a standard PPP solution with ambiguities estimated as float values. These results shall mainly serve as a matter of comparison with the processing results obtained with ambiguity fixing. All PPP results presented below were calculated with an observation model using only satellite-to-satellite differences to avoid the estimation of a receiver clock offset, and for the ambiguity fixed solution, to avoid the treatment of receiver UPDs (un-calibrated phase delays). Observation Data GRAZ0880.13O Station Graz Lustbühel (1s interval)

Approximate position +4194423.6810 m +1162702.8440 m +4647245.5050 m

(ITRF08 - epoch 01/2013)

Orbit Data igs17335.sp3

Clock corrections igs17335.clk_30s

Troposphere Hopfield + ZWD estimated

DCBs From CLK9B0880.13C Real-time stream by CNES (Only Code biases)

Epochs Processed 4000 – 15000 1:06:40 h – 4:10:00 h

Elevation Mask 10°

Figure 5-3: SD PPP float solution of GRAZ0880.13O

Figure 5-4: Satellites' Elevation of GRAZ0880.13O

1:30 2:00 2:30 3:00 3:30 4:00-2

-1.5

-1

-0.5

0

0.5

1

1.5

2

Positions Over Time

Time [1 s interval]

Variation in N

EU

Coord

inate

s [

m]

dN

dE

dh

5.4 Rover PPP-Applications (WP4400)

5.4.1 Results of Ambiguity fixing with UPDs from PPPserve



Figure 5-5: Skyplot of GRAZ0880.13O

The results of the same dataset processed in the ambiguity-fixing-mode are shown below (Figure 5-6ff.). Here UPDs calculated at TU Vienna are taken into account. These UPDs are given for defined satellite pairs (reference satellite minus all remaining satellites). Two types of UPD corrections are transmitted - one for the WL- and one for the NL- linear combination of observations.

Figure 5-6: PPP fixed solution of GRAZ0880.13O

As soon as the 4th narrow-lane ambiguity value is fixed to an integer – in the example illustrated in Figure 5-6 this happens after 30-40 minutes – the horizontal position solution stays extremely stable in the surrounding of ±2 cm of the reference coordinates. In contrast to common float PPP solutions the east-component is as accurate as the north-component – this arises from the fact, that now the ambiguities are no unknowns anymore. The periodrequired to fix the first 4 NL ambiguities strongly depends on the quality of UPDs as well as on the satellite constellation. It still needs to be investigated why sometimes satellites with high elevation angle cannot be fixed in the beginning.

1:30 2:00 2:30 3:00 3:30 4:00-0.5

-0.4

-0.3

-0.2

-0.1

0

0.1

0.2

0.3

0.4

0.5

Positions Over Time

Time [1 s interval]

Variation in N

EU

Coord

inate

s [

m]

dN

dE

dh



Figure 5-7: Satellites with fixed NL ambiguities in

GRAZ0880.13O

Figure 5-8: Satellites with fixed WL ambiguities in

GRAZ0880.13O

Another dataset from the same day but another GNSS station from the EPOSA station network was processed with the ambiguity-fixing method. This station (Dalaas) was chosen because it is known for its bad satellite visibility because situated in a valley in Tirol. The results in Figure 5-9 to Figure 5-12 look really promising: Observation Data DALA0880.13O EPOSA station Dalaas (1s interval)

Approximate position +4282049.6158m +754384.1266 m +4652140.6534 m

(ITRF08 – observation epoch) From static PPP solution over whole day

Orbit Data igs17335.sp3

Clock corrections igs17335.clk_30s

Troposphere Hopfield + ZWD estimated

DCBs From CLK9B0880.13C Real-time stream by CNES (Only Code biases)

Epochs Processed 4000 – 15000 1:06:40 h – 4:10:00 h

Elevation Mask 10°

4000 6000 8000 10000 12000 14000

5

10

15

20

25

30

epochs (1 seconds)

PR

N


0

10

20

30

40

50

60

4000 6000 8000 10000 12000 14000

5

10

15

20

25

30

epochs (1 seconds)

PR

N


-20

-15

-10

-5

0

5



Figure 5-9: PPP fixed solution of DALA088.13O

Figure 5-10: Skyplot of DALA088.13O

For this dataset the 4th satellite integer ambiguity is fixed even faster than for the GRAZ-station. Sub-dm horizontal accuracies can be reached only after some minutes of observation.

Figure 5-11: Satellites with fixed NL ambiguities in

DALA0880.13O

Figure 5-12: Satellites with fixed WL ambiguities in

DALA0880.13O

From this example we learn that the convergence period is not only governed by the satellite geometry , especially in the case of low additional low elevation satellites with hard to model atmospheric delays. So the quality and low-latency of the NL UPD, capturing also parts of the atmospheric delays, is an essential parameter.

1:30 2:00 2:30 3:00 3:30 4:00-0.5

-0.4

-0.3

-0.2

-0.1

0

0.1

0.2

0.3

0.4

0.5

Positions Over Time

Time [1 s interval]

Variation in N

EU

Coord

inate

s [

m]

dN

dE

dh

4000 6000 8000 10000 12000 14000

5

10

15

20

25

30

epochs (1 seconds)

PR

N


-50

-40

-30

-20

-10

0

10

20

30

4000 6000 8000 10000 12000 14000

5

10

15

20

25

30

epochs (1 seconds)

PR

N


-3

-2.5

-2

-1.5

-1

-0.5

0

0.5

1



5.4.2 Correlation of ambiguities

In the following a phenomenon occurring with PPP processing with coordinate constraints is shown on

basis of one of the datasets used for the tests of the PPPserve client application. In the dataset of the station Graz Lustbühel on DOY 087 in 2013 a special satellite geometry can be found. The plots below (Figure 5-15-Figure 5-18) show the correlation matrix of the parameters which are the 3D-coordinates dX, dY, dZ, the estimated wet troposphere delay dTro and afterwards the ambiguity estimates of the satellites in view. In the beginning of the processing the satellites with PRN 3, 6 and 16 have a quite similar elevation and azimuth. That is why the ambiguities are also strongly correlated in epoch 10 (see Figure 5-15). The observation interval of this dataset is 1 s. After some time in epoch 420 (Figure 5-16) this correlation has come to a maximum – the ambiguities are correlated with a factor of nearly 1 and also the correlation between these ambiguities and the Y-component of the coordinates is at a maximum. At that time the satellites physically still must have a strong correlation due to their geometry. But in Figure 5-17 corresponding to epoch 5000 and Figure 5-18 corresponding to epoch 9420 we can still observe this high correlation of parameters, even though physically the satellites now have drifted apart and one could assume, that also the correlation should fade. Several tests showed that such a correlation maximum remains present, until one of the satellite drops out for some reason. Obviously this effect occurs due to the settings of the processing filter – in static PPP usually the processing noise of the coordinates as well as the ambiguities is set to zero, which means that these parameters do not change over time. This is a necessary constraint to exploit the full potential of static PPP. Though, this effect is quite problematic, as the parameters do influence each other intnsely. For example, if one ambiguity is fixed to a wrong integer value, the other highly correlated ambiguities may be also fixed to a wrong value and the solution does not improve, when the geometry changes.

Figure 5-13: Satellite Skyplot of GRAZ0870.13O

Figure 5-14: Satellite elevation plot of GRAZ0870.13O



Future work towards a more robust approach (software) has also to deal with this aspect. A suitable choice of the filter parameters should avoid such an inappropriate parameter lockin effect in case of special unfavorable satellite geometry.

Figure 5-15: Correlation plot of GRAZ0870.13O in

epoch 10


epoch 420


epoch 5000


epoch 9420



6 Future Developments and Products (WP 5000)

6.1 Service Level of GNSS service provider (WP 5100)

EPOSA currently offers a variety of service levels to the user community. Among them are technical customer support, receiver rental services and data processing services as well as complete project handling. From the technical point of view a number of correction data streams are made available associated with different levels of RTCM. To support, for example, location services aiming at sub-meter level code corrections are provided via a reduced RTCM 2.3 standard. To offer cm-accuracy the complete RTCM 2.3 standard offers code- and phase corrections for GPS and GLONASS signals. In support of new receiver types and to reduce the amount of data transfer also recent realizations of RTCM 3.x are provided. In this context we should emphasize the provision of RTCM 3.1 correction streams which enable immediate transformation of the geocentric ITRF rover coordinates into the national coordinate system also compensating for network distortions ( below noted as ‘Rasterinformation’). Moreover EPOSA also offers this transformation opportunity for elder receiver types by means of an adapted RTCM 2.3 data stream. Figure 6-1 shows the provided data streams via GSM and NTRIP.

Figure 6-1: EPOSA correction data streams

To investigate short-term and medium-term plans of the EPOSA user community to take advantage of the new signals made available by the modernized GPS and GLONASS systems or to exploit the new opportunities offered by the upcoming Galileo system this WP is focused on a thorough user survey. Tracking of new signals will go along with equipment changes at user side as well as on provider side. In the context of this survey also the utilization of new positioning concepts like PPP instead or in parallel to current RTK services has to be challenged.



Last but not least further user groups shall be attracted by the new service levels. This implied to organize a user information workshop, designated as “EPOSA Anwendertreffen 2013”, which has demonstrated to old and potential new user groups the new PPP capabilities offered by EPOSA. This user information workshop was held at the Landwirtschaftskammer in St. Pölten on May 7th.

Figure 6-2: Invitation EPOSA Anwendertreffen 2013

This event allowed the user community to get in contact with each other and to present the integration of EPOSA services within their workflows. Therefore several presentations by different companies were delivered. As additional part of the meeting new features and services were presented by EPOSA. Amongst others new coordinate transformation features and also plans to integrate PPP algorithms into the EPOSA service portfolio. Detailed information on PPP algorithms, possible scenarios for their practical application and a comparison to conventional RTK positioning were given by R. Weber of the Technical University of Vienna. Last but not least representatives of several GNSS device manufacturers attended the workshop to present their latest GNSS positioning devices. To conclude the workshop and to get feedback from the user community a questionnaire on different kind of topics was handed out to the auditorium. Beside questions about the already provided EPOSA services and customer satisfaction also questions who deal with PPP and the interests and perspectives of the EPOSA user group using this new positioning approach were asked.



The questionnaires were analyzed after the workshop. The “EPOSA Anwendertreffen 2013” was a great success. More than 100 persons, many of them already users of some of the EPOSA services, attended the workshop and contributed to our analysis by submitting their completed questionnaires. As an example, almost 60 percent of the asked persons have graded the workshop as “very good”, 40 percent as “good”. Similar results were achieved for questions about the quality of presentations, EPOSA support, and so on. There was also a very positive feedback on questions within the PPP section of the questionnaire. More than 60 percent of the users would be interested in using an EPOSA service supporting PPP in the future, most of them already by the end of 2014. Another interesting result was that more than 40 percent of the users/companies plan to buy new GNSS receivers within the next 1 – 2 years which are capable of tracking the new GPS L5 and Galileo signals and which are of course able to support the new RTCM 3.1 and RTCM 3.2 standards. The questionnaire is attached to this document as Annex2. In parallel a customer survey has been performed by Wien Energie within WP5100 jointly to the ‘GeoAustria’ fare 2013. The approached customers are civil engineers, technicians, people working in the field of precise farming, people from infrastructure companies like power supply and transportation companies, fleet management and last but not least from academia. About 70% of the consulted persons have shown interest in an upcoming PPP Service. Also this questionnaire is attached to this document as Annex3. On behalf of these results the EPOSA team is looking forward to establish new services based on the results of PPPServe in 2014.

Within the RTCM 3.1 Amendment 5 (A5) format, which was released in mid 2011 by the RTCM Committee (Radio Technical Commission for Maritime Services), numerous of so-called SSR (State Space Representation) Messages are included. These new messages allow transmitting Orbit Corrections, Clock Corrections and Code Bias information both for the GPS and the GLONASS system to the user (see section 5). The document also includes information about upcoming developments of SSR messages in the RTCM standard. In addition to the orbit and clock corrections for GPS and GLONASS there are plans to develop additional SSR messages in two steps. The first one includes the development of vertical TEC (VTEC) messages, the second one the development of slant TEC (STEC), tropospheric messages and satellite phase bias messages. During the life time of the project a new RTCM standard (RTCM 3.2) was released. Unfortunately this new standard does not provide any further information concerning the development of the SSR messages, at least not in its initial version. Therefore it was necessary for PPPServe to create a proprietary, RTCM-like message to forward UPD information to the client (see section 5.3). Within WP5200 various tests were performed to confirm the correct transmission of the UPDs and their application. Instead of the field tests (as indicated in the project proposal) a huge number of PPP calculations based on RINEX station data were carried out in order to optimize convergence time and robustness of our positioning approach. One option for reducing convergence time is to get better initial coordinates, which is not an easy task for arbitrary receiver positions. Figure 6-3, Figure 6-4 and Figure 6-5 show some example results. The same observation data (DOY 088 /2013, station GRAZ) was calculated several times by putting different constraints on the approximate initial position coordinates. The different solutions were calculated with approximate coordinates with an initial standard deviation of 1 m, 5 cm and 1 cm. The reference coordinates themselves were not changed, only their assumed accuracy.

6.2 RTCM-SSR (WP 5200)



Figure 6-3: PPP-AR solution (coordinates constrained to 1 m)

Figure 6-4: PPP-AR solution (coordinates constrained to 5 cm)

Figure 6-5: PPP-AR solution (coordinates constrained to 1 cm)

13:15 13:30 13:45 14:00 14:15 14:30 14:45 15:00-0.5

0

0.5

Positions Over Time

Time [1 s interval]

Variation in N

EU

Coord

inate

s [

m]

dN

dE

dh

13:15 13:30 13:45 14:00 14:15 14:30 14:45 15:00-0.5

0

0.5

Positions Over Time

Time [1 s interval]

Variation in N

EU

Coord

inate

s [

m]

dN

dE

dh

13:15 13:30 13:45 14:00 14:15 14:30 14:45 15:00-0.5

0

0.5

Positions Over Time

Time [1 s interval]

Variation in N

EU

Coord

inate

s [

m]

dN

dE

dh



In all versions the routines for the ambiguity fixing were started in the 200th epoch (= 200th second), which is in time before the solution usually converges. Here, the solution with 1 m initial coordinate constraint needs 37 min minutes to produce valid fixed coordinates, the solution with 5 cm initial coordinate constraint needs 12 minutes and the solution with 1 cm constraint needs only 4 minutes for the optimum fixed-solution. Within the context of this project we also wanted to test the compatibility of the SSR corrections processed by PPPserve with commercial implementations of this standard. Although the RTCM 3.1 A5 was released at the very beginning of the project there are currently no commercial receivers which make use of the SSR messages. This circumstance clarifies that the commercial application of PPP is still in an early stage of development. The first commercial receiver supporting SSR messages has been announced by Alcatel for spring 2014.



In PPPserve we could prove, that it is possible to calculate PPP-corrections to phase observables, which enable ambiguity resolution of wide- and narrow-lane ambiguities at the user-side. By applying these biases and using special ambiguity fixing algorithms, it is possible to partially fix these ambiguities to integer numbers. The algorithms on network- and user-side established by PPPServe are designed to work in post-processing and real-time for the GPS system. With respect of a commercial service the following important findings concerning the server side are briefly summarised:

- The quality of the WL and NL UPDs strongly depend on the quality of the orbits and clocks,

- The WL UPDs are stable over several days so they can be post processed or estimated in real time,

- The NL UPDs are not very stable. They must be updated at least every 30 seconds.

From side of a PPP-user we state, that the success in ambiguity fixing strongly depends on the following factors:

- The Quality of the UPDs,

- The Quality of orbits and clocks,

- The introduced approximate coordinates of the rover as well as

- The satellite geometry.

If for example approximate coordinates of the rover are not better than a few decimetres, we could manage to fix at least four ambiguities within 10 to 30 minutes. If better initial coordinates or a good a priori knowledge on the tropospheric delay are introduced, these “convergence times” can be even shorter. After some ambiguities are fixed correctly, the horizontal solution accuracy improves to only some centimetres immediately. As expected, also the East component reaches the same quality level as the North component. This usually is not the case for solutions with floating ambiguities. Nevertheless, the experience shows that, under bad GNSS conditions (bad satellite geometry), it is still very difficult to fix correct integer ambiguities, and therefore still research has to be carried out to make our solution more robust. All developed algorithms allow the implementation of additional GNSS systems like GLONASS or GALILEO with less effort in the near future. The implementation of additional GNSS systems would not only be interesting in a scientific point of view, it would also be of interest in context of a commercial service. In connection with a commercial service also the development of the RTCM standard and the application of SSR messages in commercial receiver software is of special interest. These days we are only at the beginning of an interesting process of development. Last but not least we would like to state that the developed PPP approach is by a factor of 3-5 more accurate as the currently intended quality of the Galileo High Accuracy (PPP) Approach to be delivered by the Galileo CS (with similar convergence times).

6.3 Conclusions



7 Annex

7.1 Annex 1: Programm EPOSA - Anwendertreffen

Programm Anwendertreffen 201307. Mai 2013 8:30-16:00

08:30 - 09:00 Eintreffen

09:00 – 09:15 Begrüßung

09:15 – 09:35 Status Galileo und dessen Nutzen für die präzise Positionierung

Ao. Prof. Dr. Robert Weber, TU Wien

09:35 – 09:55 Anwendungen von TEPOS in Forschungsprojekten der ÖBB-Infrastruktur AG

DI Dr. Michaela Haberler-Weber, ÖBB

09:55 - 10:30 EPOSA – Status und Ausblick

DI Christian Klug, Wienenergie Stromnetz GmbH

10:30 – 10:50 Kaffeepause

10:50 - 11:10 Airborn Laserscanning mit EPOSA

DI Dr. Paulo Jorge Mendes Cerveira,Energie Burgenland Geoservice GmbH

11:10 – 12:30 Traktorsteuerung, Live Demo

Ing. Reinhard Prenner, Bakk. techn.,Austro Diesel GmbH

12:30 – 13:30 Mittagspause

13:30 – 13:50 ITRF/ETRF - Wahl des zweckmäßigen Koordinatenrahmens der GNSS-Positionierung

Ao. Prof. Dr. Robert Weber, TU Wien

13:50 – 14:10 GPS Positionsbestimmung im Laserscanning

DI Christian Sevcik, RIEGL Laser Measurement Systems

Aussteller/Sponsoren:



Fragebogen EPOSA Anwendertreffen

Wie hat Ihnen das Programm des Anwendertreffens gefallen?

Sehr gut

Gut

Weniger gut

Gar nicht

Haben die Vorträge Ihren Erwartungen entsprochen?

Sehr gut

Gut

Weniger gut

Gar nicht

Wie sind Sie auf die Veranstaltung aufmerksam geworden?

EPOSA - Homepage

Verständigung per Email

Ankündigungsplakat

Persönliche Einladung durch das EPOSA Team

Wie sind Sie mit dem Support von EPOSA zufrieden?

Sehr gut

Gut

Weniger gut

Gar nicht

Welche Services von EPOSA nutzen Sie?

Code-DGNSS

RTK (RTCM2.3 oder RTCM3.1)

7.2 Annex 2: Questionnaire – EPOSA Anwendertreffen



RINEX bzw. Virtual RINEX

RINEX PPS

Welche Services vermissen Sie bei EPOSA?

Precise Point Positioning (PPP) - Echtzeit

RTK L1 only, GPS & GLONASS

andere:……………………………………..

Würden Sie dieses Anwendertreffen wieder besuchen?

Ja. Jährlich , alle zwei Jahre , alle ........Jahre.

Nein

Welche Informationsquellen zu EPOSA nutzen Sie?

EPOSA - Homepage

Twitter

Veranstaltungen und Messeauftritte von EPOSA (GEO-Austria, AGIT, Geodätentag....)

EPOSA Hotline

Persönliche Kontakte zum EPOSA Team

Optionale Angaben: Name: ________________________________ Firma: ________________________________



7.3 Annex 3: Questionnaire GeoAustria



END OF DOCUMENT