Online RTKLIB post-processing demo service

[ Update 5/21/19:  Due to changes in the Google Gmail API, this service is no longer functional.  The easiest way to try out the demo5 RTKLIB code is to download the Windows executables from here.]

Recently, while experimenting with low cost dual frequency receivers, I discovered a few of the free online post-processing PPP services available from various academic and government organizations such as OPUS, CSRS, and AUSPOS.  These are a great way to easily compute a fast and accurate precise location for your base station for kinematc RTK/PPK work if you are using a dual frequency receiver.  I’ll leave the details to another post but bring them up here because they were the inspiration for a much more modest version I have put together for generating online PPK solutions using RTKLIB.

In this case, the intent is not so much to actually generate useful solution data, as it is to give new or potential RTKLIB users a chance to try out the software while avoiding some of the learning curve associated with setting it up and running it on their computer.

The PPP online services generally have a web page interface to upload the data and specify configuration options.  They then email the results to you a short time later.  To keep the implementation simple, the RtkExplorer online service works entirely through email.  You send the data and any custom config options in an email and it will email you a solution.  It runs entirely off of a single old laptop setup in the spare bedroom so is not capable of processing enormous amounts of data but hopefully will be able keep up with what I expect to be modest demand at the most.  My son has been back from college for the summer and is much better at coding things like Google APIs than I am, so he actually did most of the work with a little direction from me.

My hope is not only that it may be helpful to a few people getting started with RTKLIB, but also that it will help me improve the demo5 version of RTKLIB.  By seeing more data sets, especially those using low-cost receivers, I hope to better understand how people are using RTKLIB and what limitations they are running into.  So, even if you are already an RTKLIB expert, but run into a data set that you think it should have done a better job with, please submit it and get it added to the database.  I am sensitive to privacy issues, so while I may use relative position plots from the data to demonstrate issues in my posts, I will never share any absolute position information or anything else that would identify where the data came from.

Also, to help me evaluate how the demo5 version of code is working, and to provide a comparison for those who might be interested, two solutions are computed and plotted, one with the latest demo5 code and the other with the latest version of the official 2.4.3 code.

To help the user spot possible reasons for a poor solution, the observations for both base and rover are also plotted, along with some guidelines on common data quality issues to look for.  The solution files and configuration files for both solutions are also attached for more detailed analysis.

Before running the solutions, the data is briefly analyzed for receiver type and sample rate.  If it can be determined that both receivers were u-blox M8Ts, then the solution defaults to continuous ambiguity resolution and GLONASS AR enabled.  Otherwise, the solution defaults to both AR settings set to fix-and-hold with relatively low tracking gain.  Either way it defaults to kinematic mode and forward only solution.  Configuration inputs that are sample rate dependent are adjusted for the sample rate unless they are specified separately by the user.

If the user would like to run with any of the RTKLIB input configuration parameters set to something other than the selected defaults, that can be done by adding the appropriately set line from the config file to the body of the email.  This allows the user to specify a static or combined solution or any other variation that can be specified through the configuration file.  Any antenna types that are included in the ngs14.atx file can be specified.

For the time being, the only raw binary format that is supported is u-blox.  All other data must be in RINEX form.

Once I have a little more confidence that everything is working properly I will post a link and instructions to the rtkexplorer.com website but for now I’ll give some quick instructions here.

RTKLIB Demo Instructions

Send an email to rtklibexplorer@gmail.com that follows these rules:

  1. The email subject must include the words “rtklib demo”
  2. The base and rover data must be in attached files , either separate or zipped together and the total attachments must be less than 25 MB
  3. If the files are zipped, zip the files directly, not the folder that the files are in. (This is a temporary restriction until I improve the code)
  4. The rover files must have the letters “rov” in the file names
  5. The base files must have the letters “base” in the file names
  6. Valid file extensions are .ubx, .*nav, .obs, and .yy* where yy is the year (e.g.   .17o)
  7. At least one navigation file from either the base or rover must be included as well as observation files from both rover and base.
  8. If the base observations are in a Rinex file, the approximate base position in the header must be valid  and  in XYZ coordinates  (This is a temporary restriction until I improve the code)
  9. Config values are optional and should be copied by line directly from the config file into the body of the email, one to a line (e.g.    pos1-posmode = static)

If you’ve done everything right (and everything on my end is working properly), about five minutes after you have sent the email, you should receive a response with observation and solution plots and attached solution and config files.  Here is an example response I received after sending in one of the M8T data sets from a recent post.

email1

email2

Hopefully everything will just work the first time, but please be patient if there are a few glitches getting started.  I will be monitoring the emails closely at first and will try to keep things running smoothly as much as possible.

So, go ahead and give it a try, and help me iron out any last few bugs and also develop a database of data sets for further demo5 code development.

13 thoughts on “Online RTKLIB post-processing demo service”

  1. I need development one api for windows server. This api will receive data from rover and base station, and retur with data correct, use rtklib. You know somebody for this work ?

    Like

  2. Hi rtklibexplorer. First of all Thank you so much for everything you’re doing.
    I’m writing this comment to ask you some help, if possible. I’m aware there are 2 version of rtklib available now, the stable varion, i.e. 2.4.2, and the beta version, i.e. 2.4.3 b29.
    My goal is to create a custom application to perform PPP-static. For the moment I’m just using the RTKPOST application, without any modification. My equipment is composed of a dual frequency receiver able to spot only GPS satellites (L1 and L2 frequency). When I try to run the applications, both v2.4.2. and v2.4.3. with the same files and same configuration, I obtain two results that are completely different: I’m talking of error from 1 up to 4 meters for each axis (XYZ). Do you know if the v.2.4.3 has some known bug which may affect the final result?

    Like

    1. Hi AleC. I have seen issues with v2.4.3 when using SBAS for PPP solutions that work with v2.4.2. Usually though, I get no solution, not the wrong solution. I haven’t made many changes for PPP solutions in the demo5 code but you might try it just in case it helps.

      Like

  3. Hi,
    Just a quick note of sincere thanks for all the time and effort you’ve put into your blog. It is a fantastic resource – thank you. I have a student who is going to be looking at how the accuracy of post-process PPP degrades as the baseline increases. So thank you again, he will find this latest post of great use!
    I’ve put together an open-source design for a small, lightweight, battery-powered logger based on the NEO-M8T and the Adafruit Feather M0 Adalogger for the student to try. It doesn’t offer wireless connectivity, it simply logs the RAWX data direct to SD card. If it’s of any use, please feel free to clone!
    https://github.com/PaulZC/NEO-M8T_GNSS_FeatherWing
    Best wishes,
    Paul

    Like

    1. Hi Paul
      How can you make command to ublox for output raw data phase ?
      is there any special script for Adafruit Feather M0 Adalogger board?
      is there any special format for the SD-Card ?
      btw…
      this is good and very helpfull for post processing practice

      Like

      1. Hi Catur,
        You can find full details on GitHub:
        https://github.com/PaulZC/NEO-M8T_GNSS_FeatherWing
        The RAWX phase data is only available on u-blox “Time Sync” chips which includes the NEO-M8T. RAWX is not available on other members of the M8 family (e.g. the MAX-M8Q).
        The message you need is “RXM-RAWX”. Please follow the link to the M8 Protocol Specification for more details:
        https://github.com/PaulZC/NEO-M8T_GNSS_FeatherWing/blob/master/LEARN.md#datasheets
        The code for the Adalogger is all available on GitHub:
        https://github.com/PaulZC/NEO-M8T_GNSS_FeatherWing/tree/master/Arduino
        The SD card needs to be FAT32.
        Please see the important note about increasing the serial receive buffer size:
        https://github.com/PaulZC/NEO-M8T_GNSS_FeatherWing/blob/master/LEARN.md#rawx_logger
        If you need more advice, please get in touch via the link on my GitHub:
        https://github.com/PaulZC
        Best wishes,
        Paul

        Like

Leave a comment

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