I have recently got my hands on a copy of the Springer Handbook of Global Navigation Satellite Systems, edited by Peter Teunissen and Oliver Montenbruck. I am quite impressed with the list of contributing authors, with many experts on GNSS sharing their knowledge on a wide variety of topics contained in 41 chapters. While I encourage anyone interested in learning more about GNSS to order a copy of this book, I also want to point out an erratum related to GLONASS RTK processing.
The 2017 edition of the IGS Workshop was held in Paris from 3-7 July. I had the pleasure to attend this meeting for the first time and was quite pleased with the quality of the talks and the networking opportunities. Below is a summary of what I consider were important topics: these notes are based on my own understanding of the presentations and I encourage you to look for the original presentations for all the details once they are made available on the workshop website.
With ongoing work at NRCan aiming at offering an online PPP service supporting ambiguity resolution, we performed a validation exercise consisting of processing nearly 40 permanent GPS stations in eastern Canada over a 10-year period. As a by-product of this analysis, we computed station velocities and compared them with the values derived from the Bernese network solutions done at NRCan. The results were published last week in Survey Review and I am offering a short summary here.
It has been a few weeks since my last update on the u-blox data processing. The lack of stability of the position estimates in the single-frequency PPP (SF-PPP) solution without precise external ionospheric constraints bothered me and I spent some time thinking about possible means of improving the solution. In this blog post, I present the preliminary results of my investigation and I invite everybody with insights to share them so that we can all solve this issue.
It is only a matter of time before our smartphones can provide cm-level positioning accuracies. Thanks to the Centre National d’Études Spatiales (CNES, the French Space Agency) and its contractor CS, a giant step forward has been made towards the accomplishment of this goal with the release of two new Android apps on the Google Play store. This blog post features an invited contributor from CNES, Denis Laurichesse, who presents initial positioning results obtained using these apps.
Since my work is mainly focused on improving the accuracy of GNSS processing algorithms, I do not always spend the time required to optimize the code I am writing. Every now and then, I make a few adjustments to the code structure to avoid common pitfalls like excessive memory allocation which is particularly time consuming. I did such an exercise last week and thought I would share the process in case someone else wishes to shave a few seconds off their software processing time.
As promised, I took my new u-blox NEO-M8T outside. My first test simply consisted of evaluating the data quality of the carrier-phase and code measurements collected with a 20$ patch antenna. To achieve this, I have simply put the antenna on the roof of my car and parked on the street for 45 minutes. Results show that a cm-level precision is definitely achievable in a pseudo-kinematic mode using the PPP-RTK processing scheme.
Archives like CDDIS and SOPAC are great resources for accessing data from permanent GNSS stations using dual- or triple-frequency receivers. There is however a lack of publicly available single-frequency data sets to improve the development of processing algorithms aimed at low-cost receivers. For this reason, I decided to buy myself a little “toy” to collect my own data and, hopefully, get enough insights to benefit the precision, accuracy and integrity of these devices.
Processing of GLONASS data has always been more complex than GPS due to frequency division multiple access (FDMA). As a consequence of inter-frequency code biases, satellite clock corrections from different analysis centers are often offset by a few nanoseconds. Since accounting for such offsets is not really problematic, why has the IGS never produced a GLONASS clock combination? From personal experience, I think that I know the answer to this question and I agree with the IGS decision.
For almost two years now, I have been extracting precise slant ionospheric delays from over 200 permanent GNSS stations in Canada using PPP-AR. Since there is no official data format for storing GNSS-derived slant ionospheric delays, I have developed by trial and error a format that is at least suitable for my own purposes. Since precise ionospheric delays are key to fast PPP convergence, we can certainly foresee a need for exchanging this kind of information in the future.