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 firstname.lastname@example.org that follows these rules:
- The email subject must include the words “rtklib demo”
- 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
- 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)
- The rover files must have the letters “rov” in the file names
- The base files must have the letters “base” in the file names
- Valid file extensions are .ubx, .*nav, .obs, and .yy* where yy is the year (e.g. .17o)
- At least one navigation file from either the base or rover must be included as well as observation files from both rover and base.
- If the base observations are in a Rinex file, the approximate base position in the header must be valid (This is a temporary restriction until I improve the code)
- 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.
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.