PPP solutions with the Swiftnav Piksi Multi

I have had a couple recent questions about the Swiftnav receiver and PPP solutions so before leaving the stationary rover for a moving rover, I thought I would take a quick look at this subject.

Unlike RTK or PPK which are differential solutions using two receivers, PPP (precise point positioning) is an absolute solution done with just a single receiver.  Since we don’t have the advantage of eliminating the errors through differencing, it is a more challenging problem and is usually (but not always) done with dual frequency receivers for stationary targets.  RTKLIB does support PPP solutions and we will look at them too, but in general I prefer using one of the free online services since it is easier to do this and the answers are more accurate.  PPP solutions require precise clock and ephemeris data which must be downloaded from the internet.  Since you need to be connected to the internet anyways to download these, I see very little advantage to trying to run your own solution with RTKLIB unless you are using it as a learning tool.

There are several different online services available and they all have their own advantages and disadvantages.  I will use the CSRS service, provided by the government of Canada, in this experiment for a few reasons.

First of all, unlike some of the other services, CSRS uses the GLONASS satellites in the PPP solution.  This is particularly relevant for the Swift receiver since it is L2C and only half of the GPS satellites include dual frequency measurements.  In this case, including the GLONASS satellites roughly triples the number of measurements.  CSRS will also process L2C data directly.  Some of the other services won’t work with L2C data unless you modify the header of the observation file.   If you do run into this problem trying to use another service, manually editing the Rinex file header and changing the observation type from C2 to P2 in the file header will usually work.

Another reason for using CSRS for this experiment is that it will solve for single frequency data sets as well as dual frequency.  The single frequency solutions are based on code observations only and significantly less accurate than the dual frequency solutions but they are available.   In this case I will take advantage of this to compare the PPP solution for both single frequency M8T data and dual frequency Swift data.

CSRS also has a very convenient data submission tool that can be downloaded to your computer.  With this tool installed and configured, you simply need to drag any observation file onto the tool icon and it will email you a solution a few minutes later.  It’s hard to get much simpler than that!  You do need to setup an account before accessing the service or downloading the tool but that is a relatively quick and easy process and only has to be done once.

One last feature that CSRS provides that many of the other services don’t is the option to process kinematic data sets as well as static but I have not tried this out yet.

For this experiment, I used eight hours of data collected from the Swiftnav GPS-500 antenna on my roof which was connected to both a Swiftnav receiver and a u-blox M8T receiver through a splitter.  The antenna is mounted on a one meter pole at the bottom edge of a low-angled roof so has a reasonably good, but certainly not ideal, sky view.

The accuracy of the PPP solution will depend on the accuracy of the ephemeris used.  This will vary based on how long it has been since the measurement data was collected.  Here is a list from their website of the three possibilities along with their wait times and accuracies for the CSRS solutions.

  • FINAL (+/- 2 cm): combined weekly and available 13 -15 days after the end of the week
  • RAPID (+/- 5 cm): available the next day
  • ULTRA RAPID (+/- 15 cm): available every 90 minutes

In my case, I had collected this data a few days earlier so CSRS was able to use the rapid precise ephemeris data for the solution.

I converted both raw binary files to Rinex format using the RTKCONV app in RTKLIB.  CSRS only accepts the older 2.11 format so I did need to specify this in the RTKCONV options.  Usually I use the newer 3.03 format since it is easier to read and to parse with Matlab.

Next I dragged the two files onto the CSRS tool icon and a few minutes later both solutions appeared in my email folder.  I had previously configured the tool with a few bits of information including my email address.  The results included a pdf summary file and a csv file with the epoch by epoch convergence of the solution.

Here is the solution from the csv file for the Swift receiver.  The results in the file are in LLH format where latitude and longitude are both in degrees.  I converted both from degrees to meters using the appropriate meters per degree constants for my particular location, then subtracted the final point to generate the plot below.    Note that this is a different coordinate system than I used in the plots in my last post in which I converted the LLH coordinates to earth-centric XYZ coordinates.  In XYZ coordinates, the Z coordinate is only equivalent to height if you made the measurement at the North or South pole.  In this case I have used the angle to meter conversion to preserve the separation between vertical and horizontal components to better show their relative accuracies.


In this case the horizontal components converged to something very close to the final answer in about two and a half hours whereas the vertical component doesn’t seem to have fully converged even in eight hours.

The 95% confidence levels for the results reported in the summary file were about one cm for the combined horizontal components and 2.5 cm for the vertical component.  This was consistent with my best guess for the actual errors based on both RTK and PPP measurements made with multiple receivers and online services. I estimate the actual error being about one cm in the combined horizontal components and about 1.5 cm in the vertical component.

I did not include any antenna calibration corrections in my solutions since I am not aware of a calibration file available for the GPS-500 antenna.  This means my solutions will be for the location of the phase center of the antenna, not the geometric center.    In this particular experiment, since I am only using the results to compare with other results from the same antenna, the errors will cancel and can be ignored.   Normally though, this offset will an add additional error to the position measurements.  Ideally for accurate absolute measurements, a calibrated antenna would be used, in which case the calibration file can be specified in the solution and RTKLIB will apply the correction to remove this error.

Unfortunately the CSRS PPP single frequency results for the M8T data were much less accurate with about half a meter of error in the horizontal components and three quarters of a meter error in the vertical axis.


I then ran a PPP solution with RTKLIB for both data sets using a configuration similar to what is recommended in this tutorial.   The Swift data produced a result with very similar accuracies to the CSRS result in the horizontal components but nearly five cm of error in the vertical component.  Note that the convergence times are longer in the RTKLIB solution.  It is likely that both solutions would have reduced vertical errors if I had run with a longer data set.  The typical recommendation for PPP solutions is at least two hours of measurement data but longer data sets will generally improve accuracy.  Here is a plot of the RTKLIB PPP solution for the Swift data.


In this case I was not able to get an RTKLIB PPP solution for the M8T data because of too large residual errors.  In other cases I have got PPP solutions with single frequency data but the accuracy of the solutions has always been much lower than the dual frequency data.  I do not have a lot of experience with the PPP settings in RTKLIB so it is possible I am not getting the most out of RTKLIB.  I hope to dig into this side of things more in the future.

PPP is great for locating static receivers but if you need to track moving rovers, you will still want to use RTK or PPK solutions for that.  The ability to get accurate locations for your base station using a PPP solution though is a significant advantage of using dual frequency receivers rather than single frequency receivers.  This is particularly true  if your base station is not close enough to a CORS type reference station to get an RTK/PPK solution for your base station location.

There is a significant advantage in having two identical receivers for RTK/PPK solutions since it will give the maximum number of overlapping measurements to difference and will allow ambiguity resolution with the GLONASS satellites.   In this case the simplest configuration would be to use Swift receivers for both base and rover.  A less expensive alternative worth considering would be to connect a Swift receiver and M8T receiver to the base station antenna through a splitter and then use an M8T receiver for the rover.   You could then use the Swift receiver to find your base location and the two M8T receivers to find the rover location relative to the base position.

For me at least, this ability to locate the base with PPP would be the most compelling reason to justify the extra cost of the Swift receivers over the M8T receivers.

Hopefully, this time in my next post, I will actually get to looking at the moving rover case with the Swift receivers.  After that I hope to do a four way comparison between the M8T, and low cost dual frequency receivers from Swift, Tersus, and ComNav.  I met Andy from ComNav at the recent drone expo in Las Vegas and he was kind enough to lend me two of their receivers and antennas for a couple months to use for evaluation.  I also understand that Tersus has recently updated their firmware so I’m quite excited about all the different options becoming available in the low cost dual frequency receiver market.



12 thoughts on “PPP solutions with the Swiftnav Piksi Multi”

  1. Hello!
    Thanks for this very interesting post (and for this blog)!

    I was wondering if you had any chance to also compare the absolute positions computed by CSRS and RTKLib: any thought you can share on this?



    1. Hi Alberto. I didn’t compare this particular data set with CSRS but in general I have not had great results with CSRS for single frequency data. Still it would probably be better than my SSR solution. CSRS is replacing their PPP engine with a new version on Aug 14 which should have many improvements including using the carrier-phase measurements for single frequency data. I have high hopes for this version. There are more details from Simon at his BlackDotGNSS blog


      1. Hi,
        thanks for your reply! Actually I was referring to dual-frequency PPP solutions. Were you able to compare the absolute positions computed by the two tools by using dual-frequency PPP?


        1. Hi Alberto. The accuracy of the CSRS solution is going to depend on how long after the collection time that the data is submitted. CSRS solutions are not available for data less than 90 minutes old so is not directly comparable to the SSR real-time solution. Here are the published accuracies from the CSRS website.

          FINAL (+/- 2 cm): combined weekly and available 13 -15 days after the end of the week
          RAPID (+/- 5 cm): available the next day
          ULTRA RAPID (+/- 15 cm): available every 90 minutes (not available to download)

          I have only submitted data for which CSRS used the RAPID and FINAL ephemeris. This generally produces results more accurate than the real-time SSR solution. The SSR solution was more accurate than the published accuracies for ULTRA RAPID ( 6 cm vs 15 cm) but my data point was for only one location so they are not directly comparable.


  2. Dear author,

    thanks for your article. I am not a surveyor, but trying to assemble a universal low-cost solution for civil engineering projects.

    Information on the CSRS-PPP page claims that error correction works globally. In my understanding I could thus take a Piksi Duro, log to the SD card as a moving rover and then correct afterwards using the Canadian correction service. This would allow me f.ex. in the African bush to survey points with 20cm accuracy just by driving around with a Duro attached to the car roof.

    For a short comment I would be greatful.

    Best regards



    1. Hi Sebastian. My experience with CSRS is only for static solutions. They do provide kinematic solutions for moving rovers as well but I don’t know how large the errors are for these or what the limitations are on rover dynamics. If you have two receivers I believe you will get better results by getting a static solution for one and using that as a base station for an RTK or PPK solution. Here is a quote from the CSRS website that suggests using a slightly more involved version of this technique:

      “A popular methodology is to establish accurate coordinates for 2 points within the survey area (a fair distance apart and inter-visible). Collect raw GNSS data simultaneously at both points and post-process both using Static NAD83 (CSRS). Also process both files as a baseline (distance, azimuth) using your phase differential post-processing software. From the CSRS-PPP output coordinates, you can compute the distance and azimuth between points as well (program INDIR, inverse solution). Comparing these results can serve as quality control plus you now have 2 geodetic control points to choose from. Make one of them the main Base Station location; the survey will be anchored to this point. The other point can be tied with the Rover during the RTK survey (as an additional check) and used as a back sight for traditional surveying.”


  3. You can do PPP with SBAS data (WAAS for sure) so technically you don’t need an internet connection. The rapid or final products will give a better solution though.

    A few years back I looked a single frequency PPP using inexpensive equipment. Basically with a hour of data you can usually get to sub meter horizontal accuracy with RTKLIB. If you go to 2 or 3 hours it’s like 0.5 meters horizontal with just WAAS and 0.25 meters (~95%) with precise or rapid ephemeris and clocks. Accuracy is roughly 2 to 4 times better than the receiver’s internal solution so it helps some if you have no other option.

    I don’t know if anything has changed, but at the time I was generally getting better results from RTKLIB than CSRS for single frequency. For dual frequency RTKLIB currently only supports a float solution so CSRS is going to have the fixed integer advantage there.

    It’s interesting that RTKLIB failed on your single frequency data. I don’t remember that happening over hundreds of data sets I tried over the years. For atmospheric corrections were you using SBAS data or IONEX files?

    Does SwiftNav have a calibration file for their antenna? For the highest accuracy it’s necessary – especially for dual frequency data. If not, it certainly looks like a Harxon 500 or Tersus 3702. The NGS calibration files for those two antennas are essentially identical so I’d try one of those if you’ve done processing without antenna corrections just to see what happens.


    1. Hi JB. Excellent points! The Swift firmware doesn’t support the SBAS satellites so SBAS ephemeris was not a choice in this case but I could have used it for the u-blox solution. I do hope to go back and look at the u-blox solution more carefully to understand why it didn’t work since the same configuration has worked for me with other data sets. However, my interest in PPP is mostly for locating the RTK base which means I am looking for accuracies reasonably similar to the RTK solutions. I don’t believe I will be able to accomplish this with single frequency PPP. I used the IONEX files in my u-blox solution for ionospheric corrections but have since gone back and tried the SBAS corrections without success.

      I am not aware of a calibration file for the GPS-500 antenna so did not include antenna corrections in the solution. I meant to explain that in the post but somehow left it out. I have just gone back and added a few words about it. Thanks for catching that. Since the RTK solutions and other PPP solutions I was using for reference also used the same antenna my reported errors won’t include the antenna offset errors but the absolute positions will.


  4. Nice work! I would like to point out one thing about the “If you do run into this problem trying to use another service, manually editing the Rinex file header and changing the observation type from C1 to P1 in the file header will usually work”. Usually there is a satellite differential code bias (DCB) between C1 and P1, so it will hurt a little bit in the convergence time if you manually mark the C1 data as P1 data. You can download the satellite DCB file from IGS center, and convert the C1 to P1 by removing the satellite DCB effects.


    1. Hi Yudan. Oops, I meant C2 to P2, not C1 to P1. I’ve fixed it in the post. That probably doesn’t affect your comment though as presumably there will be a bias between C2 and P2 as well. By the way, the CSRS summary report included a warning that “Your GPS RINEX data contains C2 observation types and no P2 observations. … The CSRS-PPP dual-frequency solution using C1 and C2 may not be optimal.” so it may be that it isn’t fully accounted for in the CSRS solution either, although as you suggested, it will probably only affect convergence time, not the final answer.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: