magicGNSS’ Real-Time POD and PPP Multi-GNSS Service

magicGNSS’ Real-Time POD and PPP multiGNSS Service Guillermo Tobías, GMV, Spain J. David Calle, GMV, Spain Pedro Navarro, GMV, Spain Irma Rodríguez, GMV, Spain Daniel Rodríguez, GMV, Spain BIOGRAPHY Guillermo Tobías González holds an MSc in Telecommunication Engineering by the University of Zaragoza. He has 7 years of experience in GNSS, notably in the area of Precise Orbit Determination and Clock Synchronisation, including contributions to the Galileo Program and the IGS. He has been the GMV's responsible for the magicGNSS suite for the last years. He is currently coordinating R&D activities related to PPP services and he is the technical manager for the development of the Galileo Commercial Service Demonstrator, which will include the provision of a High Accuracy service. J. David Calle Calle has an MSc in Computer Engineering from the University of Salamanca. He joined GMV in 2008 and he is currently working on the GNSS business unit designing and developing algorithms and applications. He has participated in the development of the magicGNSS suite, the Galileo Time and Geodetic Validation Facility and the Galileo Commercial Service study and demonstrator. Pedro Navarro has a Bachelor of Science in Mathematics from the University of Murcia (Spain) and Postgraduate studies in Theoretical Physics at the University of Valencia (Spain). He is a Senior Engineer at GMV. Daniel Rodriguez holds an MSc in Telecommunication Engineering by the Polytechnic University of Catalonia. He has more than 10 years of experience in the satellite navigation, precise orbit determination, time synchronisation and precise positioning areas. He is also an expert in the development of distributed/realtime/mission critical systems. In the past, he has been in charge of the development of the magicGNSS real time services. He is currently the technical leader of the Galileo Time Validation Facility, which acts as a preliminary Galileo Time Service Provider (GTSP) Irma Rodríguez has a MSc in Telecommunication Engineering, from the Universidad Politécnica de Madrid, Spain. She is Head of the GNSS Algorithms and Products Division within the GNSS Business Unit of GMV. ABSTRACT Back in 2008 GMV released the first version of its magicGNSS suite, an online set of GNSS tools which have been tailored throughout the years to cope with the needs of a wide variety of GNSS users (over 1000 registered users by 2013), providing added-value services including multi-GNSS Precise Orbit and Clock Determination, High Accuracy Positioning, Integrity and local augmentation developments among others. The precise orbit and clock products for the different satellite constellations are generated in an Orbit Determination and Time Synchronisation (ODTS) process. This process receives as input dual-frequency code and phase measurements from a network of reference stations and produces as output precise satellite orbits and clocks, together with additional estimated parameters such as station clock biases, tropospheric delays and phase ambiguities. All GNSS satellites are processed together to ensure a consistent solution is provided. Due to GLONASS satellites transmitting individual frequencies (FDMA as opposed to CDMA used by GPS and Galileo), an inter-frequency bias must be estimated when processing GLONASS data together with the inter-system bias for Galileo. The quality of the multi-GNSS orbit and clock products generated by magicGNSS have been assessed by means of their comparison with the products generated by different Analysis Centers (TUM, CODE, CNES and GFZ) in the frame of IGS’ Multi-GNSS Experiment (MGEX) project with centimetric differences. The Precise Point Positioning (PPP) capability of magicGNSS suite provides centimetric positioing error, and sub-nanosecond error in timing, using dual-frequency observations in RINEX format from a stand-alone user receiver and precise GNSS orbit and clock products calculated beforehand (products from the International GNSS Service (IGS), multi-GNSS products generated by GMV or orbits and clocks generated by the user). The user receiver can be fixed to the ground (static PPP) or can be a moving receiver (dynamic or kinematic PPP). One of the main advantages of PPP with respect to other precise-positioning approaches like Real Time Kinematics (RTK) in that no ‘base station’ or surrounding stations are needed. Another advantage is that since the GNSS orbit and clock products are by nature global, and therefore, the PPP solutions are also global. Together with the magicGNSS online suite, GMV has been developing over the last two years an infrastructure for the generation of precise GPS, GLONASS and Galileo orbits and clocks in real-time. This infrastructure acquires via NTRIP data streams from around eighty IGS tracking stations distributed worldwide, and produces orbit updates every fifteen minutes and clock updates every second from a combined multi-GNSS solution that can be then used consistently for PPP applications. These real-time satellite orbits and clocks are available as a real-time ephemeris correction stream in standard RTCM format and can be used for real-time PPP using GMV’s magicGNSS PPP demonstrator or any real-time PPP client which processes RTCM ephemeris corrections. This realtime High-Accuracy (HA) service is comparable to the IGS service; the clock RMS is around 0.3 nanoseconds compared to the IGS rapid product (75ps RMS) and the prediction orbit is around 6 cm of the IGS rapid orbit product (~2.5 cm). GMV’s magicGNSS real-time PPP demonstrator was developed in parallel to the real-time HA multi-GNSS products generation platform to evaluate real-time PPP performance in realistic scenarios (kinematic and static). It provides an end to end process including redundancy, communications, robustness and reliability and the ability to run on portable devices. The system has already been evaluated under several field scenarios representing many situations that potential users could address in real operations for many different applications. These include static, kinematic and combined use cases. In the carried out tests, different visibility conditions have been evaluated (open sky or different types of obstacles such as trees or walls), as well as the robustness of the solution against communication losses of different durations. The real-time PPP solutions are validated against RTK and/or post-processed PPP. As an example of the aforementioned tests, a receiver was mounted onto the roof of a car to test the real-time PPP solution in kinematic mode. This test showed that during the collection of data (a 15 km route around a base station) the solution degraded when a lower amount of satellites were in view due to obstacles such as trees and buildings. This degradation can result in a re-estimation of the ambiguities which can take up to 20 minutes to achieve. It was noticed that the inclusion of multiple GNSS observations during this testing was an advantage as more satellites were in view with respect to the GPSonly case, limiting the instances of a re-estimation of the ambiguities being needed. Currently intensive research is being carried out at GMV for developing strategies to reduce convergence times, which are normally around 30 minutes for decimetric accuracy. One such strategy that is used is the ‘quick start’ feature which involves starting at a point with calibrated (few centimetres) a-priori coordinates. Use of this feature can lead to convergence within a few seconds which is crucial for certain PPP users. Throughout this paper, magicGNSS` real-time orbits and clocks server and the real-time PPP demonstrator developments undertaken are described, together with both the server (i.e. orbit and clock) performances achieved with respect to IGS and the resulting positioning performances. We also discuss the major challenges faced in the development process, and some under research ways to improve the overall service. MAGICGNSS OVERVIEW magicGNSS service can be divided into 3 different elements:  Offline web service  Real-Time product server  Real-Time PPP client Figure 1 shows the high level architecture of all 3 magicGNSS elements, which will be described in the following sections of the document. Figure 1: magicGNSS overview All three elements share the same low level algorithmic libraries which guarantee results consistency and SW maintainability. MAGICGNSS’ WEB SERVICE magicGNSS web service (www.magicgnss.gmv.com) was firstly released in 2008 [3], it is a suite of data and software products which support a wide variety of GNSS projects and objectives, including (among others) ODTS module and a PPP module. Figure 2 includes the highlevel architecture of magicGNSS web service. Figure 2: magicGNSS web service The magicGNSS server maintains data from a selected subset of ground stations (Figure 3) from IGS, the International GNSS Service. They are called core stations throughout the application. Core station data is available starting from July 1st 2008, to current time (with a latency of typically one hour). Dual-frequency measurements from the two GNSS carriers per constellation are processed in ODTS in order to remove the ionospheric delay. This is done at preprocessing level. The tropospheric delay is removed as part of the estimation process, modeled as a zenith delay for each station using a mapping function to account for the measurement elevation. Station tropospheric zenith delays are estimated as constant values every two hours. Code-phase and carrier-phase measurements are used in ODTS. The code measurements are smoothed using the phase by means of a Hatch filter [4]. This reduces the level of noise/error of the code from typically one meter in the raw code to around 30 cm or less in the smoothed code. This technique reduces the level of error in the satellite and station clock estimations. Within ODTS, the satellite and Earth dynamics are based on high-fidelity models that follow IERS recommendations [5]. Modeled forces include a full Earth gravity model, Sun, Moon and planetary attractions, solid Earth tides, and Solar Radiation Pressure (SRP), including eclipses. Earth Rotation Parameters (ERPs) are downloaded from the IERS server, but they can also be estimated by ODTS itself. A priori station coordinate values come from ITRF or IGS solutions, and they can be refined within the ODTS process. The orbit fit is based on the estimation of the initial state vector (position and velocity) and 5 empirical Solar Radiation Pressure (SRP) parameters. The satellite orbits can be propagated (predicted) into the future time using the estimated parameters and the ODTS internal dynamic model. Satellite and station clock offsets are estimated with respect to a reference clock, normally provided by one of the stations. Clocks are calculated as snapshot values, i.e., as instantaneous values at the measurement time stamp. Thus, clocks are estimated at the same rate as the internal measurements used by the ODTS (typically every 5 minutes). These estimated snapshot values are adjusted to a linear model that can be extrapolated into the future for clock prediction. A particular aspect of the ODTS software is the usage of an empirical Solar Radiation Pressure (SRP) model for all GPS satellites. Figure 4 shows the reference frame used for the empirical SRP model. Figure 3: magicGNSS web interface The ODTS software is based on a batch least-squares algorithm that processes stations data files in RINEX format, solving for orbits, satellite and station clock offsets, phase ambiguities, station tropospheric zenith delays, and station coordinates. centimeter variations in the undifferenced code and phase observations, for example phase wind-up corrections, satellite antenna offsets, station displacements due to tides (earth and oceanic), etc. u eZ B    EPS eB eX eD  eY Figure 4: Reference frame for the radiation model In this frame the Y axis is oriented along the solar panels rotation axis, the D axis is oriented in the direction from the Sun to the satellite, and the B axis completes a righthanded frame. The major component of the solar radiation force is clearly in the D direction, since the solar panels are permanently oriented perpendicular to the Sun. D0, Y0, B0, BC, BS are empirical coefficients estimated in the ODTS process along the 3 reference frame directions. The D0 coefficient is equivalent to the classical CR radiation pressure coefficient for a cannonball model. The Y0 coefficient is the well-known GPS “Y-bias”, which represents the component of the force along the solar array. The B0, BC, BS coefficients capture the continuous and one-revolution (sine and cosine) effects on the direction perpendicular to the Sun direction. D0 is nondimensional and the rest of coefficients are measured in units of acceleration. This empirical radiation model simplifies the satellite dynamics and requires no a-priori information about the satellite geometrical and reflectivity properties, just approximate mass and area values are needed. The estimation of the 5 empirical SRP coefficients, together with the 6 components of the satellite initial state vectors (position and velocity), i.e. 11 dynamic parameters in total, allows orbit estimation accuracies well below the decimeter. No other empirical accelerations are used. The PPP algorithm in magicGNSS uses ionosphere-free measurements, obtained from the combination of undifferenced, dual-frequency observations coming from a single GNSS receiver, together with detailed physical models and corrections, and precise GNSS orbit and clock products calculated beforehand. The quality of the reference orbits and clocks used in PPP is critical, as they are both two important error sources in GNSS positioning. Apart from observations and precise reference products, PPP algorithm also needs several additional corrections which mitigate systematic effects which lead to The station parameters estimated by PPP are position (XYZ coordinates), clock, zenith tropospheric delay (constant value every hour), and float phase ambiguities. Cycle slips are detected but not corrected: if a cycle slip is identified a new phase ambiguity is estimated. Cycle slips are obviously undesired because they increase the number of nuisance parameters (ambiguities) to be estimated and, more importantly, they reduce the observability and convergence of each of the ambiguities to be estimated. Together with satellite visibility and geometry, the occurrence of phase cycle slips is the main factor affecting PPP accuracy in position when using short data periods (of the order of one hour or less). The underlying physical models are the same in ODTS and PPP, therefore the compatibility between ODTS output products for PPP input is guaranteed. The PPP algorithm can be run in static or kinematic mode, it supports RINEX 3.02 format and can be executed either by means of magicGNSS’ web service or by mail by sending the RINEX files to [email protected]. For PPP processing, a user may choose between IGS reference products or GMV’s reference products which are routinely generated by means of a GPS+GLONASS+Galileo ODTS process running in offline post-processing mode with a latency of 2 days and specific setup. The quality of GMV’s reference orbits and clocks has been assessed during the past years. Figure 5 and Figure 6 show that, for GPS, the typical performances are around 3.5 cm RMS for the orbit and 0.2 ns RMS for the clock accuracy. Figure 5: GMV’s GPS estimated orbits VS IGS orbits Figure 6: GMV’s GPS estimated clocks VS IGS orbits The quality of GMV`s Galileo products has been recently assessed against the different Analysis Centers (TUM, CODE, CNES and GFZ) in the frame of IGS’ MultiGNSS Experiment (MGEX) (http://igs.org/mgex/). Figure 7: magicGNSS’ Galileo orbits VS MGEX’s ACs The results in Figure 7 show that magicGNSS’ performances are comparable to the ones provided by the different ACs, with centimetric consistency between all the solutions (except with TUM for E20 and WUH for E12 and E19). MAGICGNSS’ REAL-TIME SERVER For the past years, GMV has been developing an infrastructure for the generation of precise multi-GNSS orbits and clocks with very low latency in a first step, and in real time in a second step. A high-level layout of the infrastructure is shown in Figure: 8. Figure: 8 magicGNSS real-time server This process retrieves dual-frequency code-phase and carrier-phase measurements in real time from the worldwide station network shown in Figure 9, via Networked Transport of RTCM via Internet Protocol (NTRIP). performances versus IGS rapid products can be seen in Figure 10. It covers the period from April 2013 till June 2014. Figure 9: magicGNSS’ Real-time GNSS network Once the observations are collected, they are preprocessed also in real time by a Pre-Processing and Validation module (PPV), which then makes ionospherefree and geometry-free measurements available to the different algorithms. The EPHEM module retrieves the ephemeris data from the different GNSS stations and generates a consolidated ephemeris stream which is then used by the other realtime modules. Figure 10: magicGNSS’ Real-time GPS products VS IGS Typical orbit accuracy is about 6 cm, RMS, and clock accuracy is about 0.25 ns, RMS. The reference product generation is based on an ODTS process, which runs every 15 minutes. The ODTS processes 2 days of data in every execution, and provides updated satellite orbits and other estimated parameters (such as phase ambiguities, station tropospheric zenith delays and Earth orientation parameters). In parallel to the ODTS, there is another process called CLK which estimates the satellite clocks in real time taking as input the pre-processed observations coming from PPV and the outputs from the last ODTS execution. There is a small latency in the delivery of the clock estimates, which is associated to the time that the algorithm waits for the arrival of the measurements from the stations through the Internet; typically one or two seconds. All the configured GNSS constellations are processed together, in order to ensure a consistent solution. It is necessary to estimate an inter-channel bias when processing GLONASS data. This must be done in order to compensate for the different internal delays in the pseudorange measurements through the GLONASS receiver, associated to the different frequencies used by the different satellites. Otherwise the station clock estimate would not be coherent with the pseudoranges. It has been observed that in GPS data this effect is much smaller and therefore negligible; normally it is not necessary to estimate such an inter-channel bias for GPS data. For the rest of the GNSS constellations, different inter-system bias values are also estimated. The real time orbit and clock reference products generated by one of GMV’s real-time serves are contributing since 2012 to the Real Time IGS Project (www.rt.igs.org); their Figure 11: magicGNSS’ Real-time GLONASS products VS ESOC Figure 11 shows the analogue comparison for GLONASS. This comparison has been carried out by comparing the real time orbit and clock generated by magicGNSS with respect to ESOC (European Space Operations Centre) products. The orbit RMS stays around 10 cm, and the clock RMS stays around 0.4 ns, as shown in Figure 12: rt.igs.org RTCM caster The RTCM networks used for the real-time product generation come from IGS’ and BKG’s NTRIP casters, whose networks are represented in Figure 12 and Figure 13 respectively. These 2 casters provide global coverage and some redundancy to cover the relatively frequent (especially from some stations) outages of the real-time data streams. The following table summarizes the current RTCM status regarding the messages definition for the different GNSS constellations. Table 1: RTCM messages status Due to the current RTCM status included in Table 1, magicGNSS’ real-time server ephemeris correction generation is currently limited to GPS and GLONASS, although the infrastructure is ready for multi-GNSS product generation. MAGICGNSS’ REAL-TIME PPP CLIENT In parallel to the real-time server a PPP client has been developed able to compute an accurate user position in a real-time basis [2]. Figure 14 shows the high-level architecture of the real-time PPP client. Figure 13: igs-ip.net RTCM caster Together with the precise GNSS orbits and clocks, the real-time server also generates RTCM ephemeris corrections by means of a module called PPP Server. This module also accepts multiple connection requests from real-time PPP clients and delivers the ephemeris corrections. Most of the commercial GNSS receivers already provide GPS and GLONASS observations and ephemeris in RTCM format, however, the RTCM multi-GNSS MSM messages definition is quite recent (November 2013), and very few GNSS receivers have upgraded their firmware to generate those messages. This makes it very difficult to generate HA products in a real-time basis without having access to the different manufacturer’s interface definition documents, where their proprietary multi-GNSS messages’ format is defined. The problem for generating real-time multi-GNSS HA product in an RTCM frame is not just limited to the aforementioned issue, but also to the computation of the GNSS ephemeris corrections. Even if the latest RTCM standard already defines the ephemeris messages for Galileo and QZSS, it does only defines State Space Representation (SSR) messages for GPS and GLONASS, which at present prevents (it is expected to change in the near future with additional multi-GNSS RTCM message definition) the generation of multi-GNSS ephemeris corrections. Figure 14: Real-time PPP client The PPP algorithm uses a sequential filter in which the process noise for the coordinates is adjusted depending on the receiver dynamics, the time evolution of the clock is more or less unconstrained (white noise with a high sigma), and the process noise for the tropospheric delay is adjusted to standard tropospheric activity. The phase ambiguities are considered as a constant per pass. The PPP client SW has been designed so that it can be installed in a portable device (Figure 15) to allow realtime field tests. The PPP client can also be run in standard laptops, but the development of the hardware device was carried out to support the integration with satellite communications and to research the ability of the PPP client to run on low-power processing boards with limited computing capabilities. The device has a processing board with flash storage that hosts the underlying Linux OS and the PPP client software, a communications board with the mobile Internet and the Iridium modems, a 7” touchscreen and various connectors. The user equipment features standard connectivity. It connects to any standard geodetic receiver using a serial port, and accepts real-time data in RTCM 3 format, making it work with virtually any modern equipment. The PPP outputs are stored locally for later analysis, and made available in real-time through a Bluetooth port in NMEA format, so they can be input to third-party professional applications running e.g. in a PDA. in the form of “protection levels” as shown in Figure 16. More information can be found in [3]. The aforementioned real-time PPP client has been deeply tested throughout the past years, both in static and kinematic environments. Several reference stations are being permanently monitored by means of several instances of the real-time PPP client. Figure 17 shows the typical PPP positioning error (with respect to the previously calibrated position) over a 24 hour period for one of the monitored stations. Figure 17: Real-time PPP base station monitoring The statistical horizontal position accuracy is below 10 cm and the vertical position accuracy is below 15 cm during 95% of the time over the first 6 months of 2014. Figure 15: Real-time PPP portable device A user interacts with the PPP client by means of a touchoperated MMI (man-machine interface), which allows the user to configure and monitor and control in real-time the PPP performances. Dozens of kinematic tests have also been performed, these tests have been carried out placing a receiver on the roof of a car and the routes stay within 15 km of a base station that can be used for generating reference trajectories using RTK (although RTK sometimes has performance issues at this distance), and allows testing under very different situations: open sky; trees, nearby buildings or other obstacles; and several connection dropouts. Figure 16: Real-time PPP MMI Together with the HA positioning solution, the PPP client also provides horizontal and a vertical reliability bounds. These reliability bounds have been designed for providing the user with an indication of the accuracy of its solution, Figure 18: Real-time kinematic route Figure 18 shows a typical route for one of the kinematic tests performed, and Figure 19 shows the comparison of the estimated position from the real-time PPP with respect to RTK both for the horizontal and vertical component. Figure 19: Real-time PPP performances VS RTK The results have shown that after the PPP has converged, the consistency between RTK and PPP under nominal circumstances is at the centimetre level, which is fully in line with the results obtained in the static case. During these tests, several issues have identified which clearly affect the real-time PPP performances. A typical situation that can affect in-the-field real-time PPP is the temporarily loss of communications with the ephemeris correction server, for example when operating far from urban areas or main routes. This implies that the PPP client has to extrapolate the last available correction for up to several minutes, which may not be a problem for the orbits but can affect negatively the clocks due to their stochastic behavior. Therefore some research has been made to improve the algorithm performance in these cases. As a result of these improvements, the real-time PPP client is able to withstand dropouts of several minutes by a careful extrapolation of the last satellite clocks and considering the associated uncertainty in a realistic manner. This way, and provided that the algorithm had already converged to good troposphere and ambiguity values (and that not many lines of sight are lost in addition), positioning performances are maintained during a few minutes with very slight degradation, and recovered after the connection with the server is back. Figure 20 show how communication loses of up to 10 minutes does not greatly degrade the real-time PPP performances. Convergence time is one of the major issues affecting real-time PPP users. The PPP solution takes typically not less than 20 minutes to reach 10-cm horizontal accuracy (RMS), due to the time needed to properly estimate parameters such as the tropospheric delay and the phase ambiguities. While this might not be considered a showstopper for many applications, at least for the start of operations, a 20-min or more re-convergence time after a total loss of satellites is a major issue for field use. Research is being carried out at GMV on the improvement of the convergence time, including strategies other than the integer ambiguity fixing. As a first approach, a quick start feature has been implemented. This feature yields convergence in a few seconds when the initial position is known within a few centimeters. While this is not a solution for all field users, it is directly applicable e.g. to precision farming, when the tractor is not moved between two consecutive labor days, and therefore the last computed position is valid for quick start. It is also useful to local surveys for civil works, in which one or several points can be calibrated (e.g. a static PPP of several hours) at the beginning of the campaign, and any subsequent measurement run can be quick-started from any of those points. Figure 21: Real-time PPP convergence without quickstart Figure 21 shows PPP accuracy without and Figure 22 with quickstart. When quickstart is not available, clear convergence patterns are visible, which disappear when a good initial position is known. Figure 20: Communication loses with the PPP server 2. Mozo, Álvaro, Calle, J. David, Navarro, Pedro, Piriz, Ricardo, Rodriguez, Daniel, Tobias, Guillermo, "Demonstrating In-The-Field Real-Time Precise Positioning," Proceedings of the 25th International Technical Meeting of The Satellite Division of the Institute of Navigation (ION GNSS 2012), Nashville, TN, September 2012, pp. 3066-3076. Figure 22: Real-time PPP convergence with quickstart Our future work will try to make the service even more robust, and explore alternatives to deal with the long convergence time of the PPP algorithm. This may include, but will not be limited to, integer ambiguity resolution. CONCLUSIONS AND FUTURE WORK magicGNSS has become over the last years a well-known reference for online GNSS processing tool with over 1000 registered users and more than 65000 PPPs run so far. In the short term, magicGNSS online version will be upgraded for multi-GNSS processing beyond GPS, GLONASS and Galileo. Several challenges both at server and client level have been identified for the overall improvement of magicGNSS service provision:  Products quality  Communications  Convergence  Robustness MSM data availability and multi-GNSS SSR message definition issues need to be tackled for real-time multiGNSS service testing ACKNOWLEDGMENTS RTK solution is calculated using RTKLIB, developed by Tomoji Takasu (www.rtklib.com). REFERENCES 1. Piriz, R., Mozo, A., Navarro, P., Rodriguez, D., "magicGNSS: Precise GNSS Products Out of the Box," Proceedings of the 21st International Technical Meeting of the Satellite Division of The Institute of Navigation (ION GNSS 2008), Savannah, GA, September 2008, pp. 1242-1251. 3. Merino, Miguel M. Romay, Lainez, Maria D., "Integrity for Advanced Precise Positioning Applications," Proceedings of the 25th International Technical Meeting of The Satellite Division of the Institute of Navigation (ION GNSS 2012), Nashville, TN, September 2012, pp. 2742-2758. 4. Hatch R., “The synergism of GPS code and carrier measurements. In: Proceedings of the third international geodetic symposium on satellite doppler positioning”, Las Cruces, NM, DMA/NGS, Washington, DC, 1982, p. 1213–32 5. http://www.iers.org/