ION GNSS+ 2016

The ION GNSS+ 2016 meeting took place last week, from September 12-16, in Portland OR. Here are the highlights of this meeting from a PPP perspective.

 

GLONASS ambiguity resolution in PPP is definitely a topic of interest at the moment, with three presentations on this topic. Jianghui Geng from Wuhan University compared two methods for GLONASS PPP-AR: 1) introducing ionospheric corrections to estimate widelane uncalibrated phase delays (UPD), and 2) the method proposed by NRCan of fixing ionosphere-free ambiguities. His conclusions were that both methods are suitable in post processing but that the NRCan method is not as reliable in real time due to the short wavelength of the ionosphere-free ambiguities (5.3 cm) and the quality of the GLONASS predicted orbits (Geng et al. 2016). I would however add that the NRCan method is applicable globally, regardless of ionospheric activity. These characteristics were put to good use in a paper from Wuhan University and GFZ, where the NRCan method was shown to improve GLONASS orbit determination (Liu et al. 2016a). Finally, although they did not explicitly acknowledge the method, it seems likely that Fugro has also tested it for kinematic PPP in regional and global networks (Liu et al. 2016b).

 

Triple-frequency GNSS signals can now be used from all constellations but GLONASS. Laurichesse and Blot (2016) have shown that, with 5 GPS IIF and 5 BeiDou satellites in view, instantaneous convergence of the horizontal position to 20-30 cm can be achieved when constraining the tropospheric delay. A presentation from Trimble showed that, when performing ambiguity resolution on all constellations, users in Australia can reach a 4 cm horizontal accuracy in about 8 minutes, 95% of the time. Adding triple-frequency observations only offered a 1 minute improvement in convergence time (Weinbach et al. 2016). These results match my own experience of triple-frequency data processing, where I noticed that the benefits of the third frequency are not as obvious as some early papers suggested.

 

Faster PPP convergence can be obtained, as we know, by providing slant ionospheric delay corrections to users. One challenge in this context is to separate STEC from DCBs. Members of the JPL team are currently testing singular value decomposition (SVD) to achieve this purpose, which was applied to a regional network of stations (Hajj and Bar-Sever 2016). The exact purpose of computing STEC corrections at JPL seems, for the moment, to serve single-frequency users in real time, although other applications could eventually emerge. While there was not a presentation on this topic, the GMV booth suggested that the magicGNSS PPP service might also offer faster PPP convergence in the future using ionospheric constraints.

 

One important challenge with real-time PPP, and especially in earthquake monitoring, is correction availability. A solution has been proposed to maintain an accurate position during an interruption of corrections: have the user download a copy of the predicted SP3 file (which contains the same information as real-time orbit corrections) and predict satellite clock corrections on the user end using a linear (or a more sophisticated) representation (El-Mowafy 2016). Even though the results presented sounded a little optimistic (cm-level accuracies for a couple of hours without corrections), the idea is surely applicable to short communication outages.

 

Another presentation worthy of interest was given by a member of The Topcon Technology Center, describing the performance of a new helix antenna that suppresses multipath better than a typical choke-ring antenna (Tatarnikov et al. 2016). The antenna looks like a 40-cm tall stick with a diameter of about 3 cm. With better multipath mitigation, mm-level short-baseline RTK positioning could be achieved, even in the vertical component. The only drawback for the moment seems to be that this technology is mostly applicable to the L1 frequency band. While the L2 signals are supported by the antenna and were used to obtain fast ambiguity resolution, the positioning solution was only computed based on the L1 signal.

 

I was also part of a panel discussion on high-precision GNSS positioning. The questions of interest were mainly related to the performance of PPP vs RTK, and the need to provide fast cm-level PPP solutions globally. To sum things up:

 

Can PPP perform like RTK? Yes, it can.

Can PPP perform like RTK globally? Not really.

 

A few explanations: with the state-space representation of corrections, PPP performance can be made pretty much equivalent to RTK by providing information on the ionosphere and the troposphere. In order to reach this level of accuracy with fast initialization times, it is required that at least one reference station be located in the vicinity of the user. Therefore, PPP can perform like RTK in regions with dense station coverage only. A densification of reference stations can be made to support specific applications in certain areas, but it is currently not feasible (or needed) on a global scale.

 

Finally, I attended the tutorial given by Frank van Diggelen and other colleagues from Google on using GNSS data from the new Android smartphones. The tutorial was very well attended (about 100 people registered, from companies like Uber to Trimble) and offered a comprehensive overview of the current state and challenges of using this data. I processed the data provided myself with my PPP software... but I'll save the results for another day!

 

References (all from ION GNSS+ 2016)

El-Mowafy A (2016) Facing Some Critical Challenges in Real-Time Precise Point Positioning

 

Geng J, Chen X, Wen Q, Chang H (2016) Undifferenced GLONASS Ambiguity Resolution Over Inhomogeneous Receivers: Introducing Ionosphere Corrections or Resolving Ionosphere-free Ambiguities?

 

Hajj G, Bar-Sever Y (2016) A Novel Approach for Processing GNSS Multi-systems/Multi-frequencies for Geodesy and Remote Sensing Applications

 

Laurichesse D, Blot A (2016) Fast PPP Convergence Using Multi-constellation and Triple-frequency Ambiguity Resolution

 

Liu Y, Ge M, Lou Y, Shi C (2016a) Improving Multi-GNSS Real-time Precise Point Positioning Services

 

Liu X, Stone M, Memarzadeh Y, Goode M, Tegedor J, Lapaucha D, Strandli R (2016b) Integer Ambiguity Resolution Enabled RTK and PPP Solutions Using GPS and Glonass Observations

 

Tatarnikov D, Stepanenko A, Astakhov A, Rapoport L (2016) Millimeter Accuracy of RTK Positioning Employing Helix Antennas with Cutoff Patterns

 

Weinbach U, Brandl M, Chen X, Drescher R, Glocker M, Landau H, Pastor F, Reussner N, Thomas K (2016) Triple Frequency PPP with Trimble CenterPoint RTX



Write a comment

Comments: 8
  • #1

    Stavros Melachroinos (Monday, 19 September 2016 22:08)

    I'm not sure if comparing PPP to RTK at a global scale makes any sense, since RTK is not directly applicable to a global scale. I would say that the PPP-RTK is concept is scalable at a global scale, whereas the RTK concept is not.

  • #2

    Stavros Melachroinos (Tuesday, 20 September 2016 00:16)

    Something else that was also discussed, and which I believe deserves the attention of current and future PPP-RTK service providers is the ability of the server-side to support a system integrity monitoring on user-side.
    For instance Rui Hirokawa et al. (2016) in session F2 presented a dual-integrity concept embedded in Melco's existing compact SSR definition for QZSS. This consists of :
    1) Integrity provided by the service provider is regards to malfunction of specific satellites for users. This means that the system needs to continuously monitor the satellite signal (signal in space) and warn users in a certain (To Be Defined) Time-to-Alert (TTA).
    2) The service provider should also transmit a quality indicator of augmented data for the fault detection and exclusion algorithm in the user receiver.
    Another presentation from session F2, which matched the second aspect of Melco's integrity definition, was the one from Lainez Samper et al. (2016) and GMV. One of the main features of this integrity approach, is that it combines in a well-balanced way, information from the system and information from the user, in order to build optimum horizontal and vertical protection levels.
    A final comment: Integrity is required by a critical or safety of life navigation system. That it may as well become the case for the use of real-time augmented PPP corrections in the Intelligent Transportation Systems (ITS) of the very near-future.

  • #3

    Miquel Garcia (Tuesday, 20 September 2016 00:47)

    Hi!

    Very nice overview! Thanks for sharing this!

    We have been trying to use the Google Android N API to extract the measurements but so far we have not have success in extracted the carrier phase using both Nexus 5X and Nexus 6. I am curious to know if the tutorial you attended in ION explained how. Did they gave details? Did they use any specific device to obtain them?

    Many thanks again!

    Best

    Miquel

  • #4

    Garrett Seepersad (Tuesday, 20 September 2016 01:40)

    @Miquel Garcia , currently only the code measurements are publicly available. At the tutorial they had a special build that allowed access to the phase data. Access to the phase data is chip specific and may not be possible with this generation of phones.

  • #5

    Miquel Garcia (Tuesday, 20 September 2016 03:27)

    @GarrettSeepersad Thanks Garret for your reply! We suspected there might be issues like the ones you suggested! I hope that upcoming smartphones ship GNSS chipsets that allow carrier phase delivery. Best!

  • #6

    Xianglin Liu (Tuesday, 20 September 2016 04:02)

    In Liu et al. 2016b, the NRCan method was not used. Otherwise it will be explicitly acknowledged.

  • #7

    Simon Banville (Tuesday, 20 September 2016 11:29)

    @Stravos Thanks for pointing out additional papers of interest!

  • #8

    Simon Banville (Tuesday, 20 September 2016 11:37)

    @Xianglin I apologize for this mistake: I must have misunderstood your colleague during out discussions after his presentation.

    The obvious question now becomes: how are you handling inter-frequency code biases (IFCBs) with mixed receiver types when using a global network? Are you simply assuming that all Trimble receivers (R5 and R9) have compatible IFCBs?