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.

ppp1

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.

ppp2

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.

ppp3

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.

 

Advertisements

Online RTKLIB post-processing demo service

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.

PPK vs RTK: A look at RTKLIB for post-processing solutions

The “RTK” in RTKLIB is an abbreviation for “Real-time Kinematics”, but RTKLIB is probably used at least as often for “PPK” or “Post-Processed Kinematics” as it is for real-time work.  In applications like precision agriculture, where the solution is part of a real-time feedback loop, RTK is obviously a requirement, but in many other applications there is no need for a real-time solution.  For example, drones are often used for collecting photographic or other sensor data but only need precision positions after the fact to process the data.  PPK is simpler than RTK because there is no need for a real-time data link between GPS receivers and so is often preferable if there is a choice.  The downside of course is that if there is something wrong with the collected data, you may not find out until it’s too late.

For the most part, RTKLIB solutions are identical regardless if they are run on real-time data (RTK) or run on previously collected data (PPK).  The most significant exception to this rule is what RTKLIB calls the “Filter Type”.  This is selected in the configuration and can be set to forward, backward, or combined.  Forward is the default and this is the only mode that can be used in real-time solutions.  In forward mode, the observation data is processed through the kalman filter in the forward direction, starting with the beginning of the data and continuing through to the end.  Backward mode is the opposite,  data is run through the filter starting with the end of the data and continuing to the beginning.  In Combined mode, the filter is run both ways and the two results are combined into a single solution.   This mode is set using the “Filter Type” box in the Options menu if using one of the GUI apps, or with the “pos1-solytpe” input parameter in the configuration file if using a CUI app.

There are two advantages to a combined solution over a forward solution.  First of all, it gives two chances to find a fix for each data point.  Let’s say there is an anomaly in the middle of the data set that causes the solution to switch from fix to float and not come back to fix for some period of time.   It may cause both the forward and backward solutions to lose fix but they will lose fix on opposite sides of the anomaly.  By combining the two solutions we are likely to get a fix for everywhere except right at the anomaly.  Another case where it often helps is in recovering the beginning of a data set.  Let’s say the first fix didn’t occur until five minutes into the data set.  With a forward solution, you would need to guarantee that nothing important happened during that five minutes, but with a combined solution, the backward pass will normally provide a fix all the way to the very beginning of the data set so there is no lost data.

The second advantage of the combined solution is that it provides an extra level of validation of the results.  To understand how this happens, it’s important to understand how RTKLIB combines the forward and reverse solutions.  For each solution position point there are three possibilities; both passes are float, one is float and one is fix, or both are fixed.  If both passes generate a float position, then the combined result will be a float with a value equal to the average of the two positions.  If one is float, and the other is fix, the float is thrown away and the fix is used.  In the case where both are fixed, then RTKLIB will attempt to validate the result by comparing the two values.  If they differ by less than four sigma, then the result will be a fix, otherwise it will be downgraded to a float.  Either way, the value will be the average of the two positions.  This degrading the solution type when the answers from opposite directions differ provides an increased confidence in the solution, at least for points for which we got two fixed values.

I will show a couple examples of the differences between forward and combined modes.  The first example is a more typical case and demonstrates how combined mode will normally give you a higher fix percentage while at the same time increasing confidence in the solution.

The plots below were taken from an M8N receiver on a sailboat using a nearby CORS station as base.  With ambiguity resolution mode set to fix-and-hold, I was able to get a solution with nearly 100% fix except for the initial convergence, but I would prefer to use continuous ambiguity resolution because of the higher confidence of the solution.  In the position plots below, the top was run in forward mode, the middle in backwards mode, and the bottom in combined mode, all in continuous ambiguity resolution mode.

combined1

As you can see the forwards and backwards mode solutions are not bad but both have gaps of float in the middle as well as floats during the initial acquisition.  The combined solution though has almost 100% fix rate and in addition includes the additional confidence knowing that every point found the same solution when running the data in opposite directions.

This second example comes from a data set posted on the Emlid Reach forum with a question on why the combined solution was worse than the forward solution.  In the plots below, the top solution is forward, the middle is backward, and the bottom is combined.

combined2

This data was GPS and SBAS only, so had a fairly low number of satellites, also included a mix of poor observations and the solution was run with full tracking gain (i.e fix-and-hold with the default gain).  Both forward and backward runs found fixed (green) solutions and tracked them all the way through the data set.  However, at least one of them was most likely a false fix, causing the fix to be downgraded to float (yellow) for most of the combined solution as can be seen be seen in the bottom plot.

To confirm this, the plot below shows the difference between the forward and backward solutions.  As you can see, the two differ by a fairly substantial amount and it is not possible from this data to know which one is correct.

combined3

In this case, turning off fix-and-hold and running ambiguity resolution in continuous mode sheds some light on what may be going on.  The plots below are again forward, backward, and combined.  This time the forward solution loses fix early on and never recovers it, whereas the backwards solution maintains a fix through the whole data set and is probably correct since without fix-and-hold enabled, it is very unlikely to stay locked that long to an incorrect solution.  The backward solution is also consistent with the beginning of the forward solution, since the combined solution remains fixed in the early part of the data set where both forward and backward solutions are fixed.

combined4

Again, this can be confirmed by looking at the difference between the forward and backward solutions.  In this case they agree everywhere that both are fixed.

combined5

As this example demonstrates, if post-processing is an option, it often makes sense to run in combined mode with continuous ambiguity resolution instead of forward mode with fix-and-hold enabled.  The additional pass will increase the chances of getting a fixed solution without the risk of locking onto a false fix that fix-and-hold can cause.  Even if you find you can not disable fix-and-hold completely, it may allow you to reduce the tracking gain (pos2-varholdamb)

So one last question is why are there still some float values in the middle of the combined solution? We would expect that since the backwards solution is fixed and the forward solution is float, that the combined solution should just become the backwards solution and all but the very end should be fixed.

The answer to this question turns out to be the way the reverse pass of the kalman filter is initialized.  I have chosen in the demo5 code to not reset the filter between forward and reverse passes if continuous ambiguity resolution is selected.  If fix-and-hold is selected then the demo5 code does re-initialize the kalman filter between passes.  This is different from the release code which always resets the filter between passes.

In this case, the results would have been slightly better if the filter were re-initialized but most of the time I find that allowing the filter to stay converged avoids a large gap in the backwards solution during the active part of the data set where the filter is reconverging. With fix-and-hold enabled I have found the chance of staying locked to an incorrect fix is too high and so it is better to reset the filter.  This is a recent change and hasn’t yet made it into the released version of demo5 but I should get it out soon.  The current version of the demo5 code (b28a) does not reset the filter for either case.

Modifying the if statement in the existing code in postpos.c to match the line below will give you the newest behavior.  Removing the if statement altogether will cause the filter to always be reset and will match the release code.

combined6

The other factor to consider when deciding whether to run the filter type in forward or combined mode is that combined mode will take nearly twice as long to run since it is processing each data point twice.  Most of the time this shouldn’t be an issue since it is not being run in real-time.

So to summarize, my recommendation would be to use combined mode if you do not need a real-time solution as the only real cost is a small amount of additional computation time and it will give you both higher fix percentages and more confidence in those fixes.

Real-time solutions with RTKLIB and NTRIP using a cell phone as data link

As I mentioned in an earlier post, I’ve recently acquired access to some low cost dual frequency receivers, specifically a Tersus Precis BX306 and a pair of Swift Piksi Multis.  I have been playing with them over the past few weeks and plan to share my experiences with them over a series of posts.

Both receivers provide internal RTK solutions as well as raw measurements that can be processed with RTKLIB.  I’m interested in how the RTKLIB solutions compare to the internal solutions as well as how both of these compare to solutions derived from single frequency data collected simultaneously with the dual frequency data.

The first issue I ran into with this experiment, however, is that both receivers will only provide an RTK solution for real-time data, neither have the capability to post-process previously collected data.  This meant that I needed a way to provide a real-time stream of dual frequency base station data to the receivers.  I wanted to be able to  do this while driving a car around the local area so I needed more range than a low cost set of radios would give.

Fortunately, I have fairly good cell phone coverage in this area so I was able to rely on my cell phone for the data link.  In this post I will explain how I did that, both for an external CORS reference station and for my own base station.  In both cases I used  NTRIP server/caster/clients to do this.  NTRIP is a protocol for streaming of DGPS or RTK correction data via the internet using TCP/IP.  The NTRIP server sends out the data to an NTRIP caster and the NTRIP client receives it. For more details, there is a good description here.

Using this setup I was able to run real-time solutions with RTKLIB as well as with the intenal RTK engines in the Swift and Tersus receivers.  Here’s a diagram from the RTKLIB manual showing the setup I used for running a real-time RTKLIB solution using RTKNAVI.  When I ran a Swift or Tersus solution, the configuration was similar, but the NTRIP caster streamed the base station data to STRSVR instead of RTKNAVI, and STRSVR then streamed it to the receiver where it was combined with the raw receiver observations to create an internal RTK solution.  Also missing in this diagram is the cell phone which should be in between the internet and the rover PC.

ntrip.rtklib

The amount of free base station reference data that is available online on a real-time basis is a fair bit more limited that what is available after the fact for post-processing.  Fortunately I was able to find a CORS reference station about 17 km away that is available real-time through the UNAVCO NTRIP caster.  The service is free if the data is used for educational purposes and appropriately attributed.   Most of their stations are on the west coast of the U.S. but they do have some scattered across the rest of the country as you can see in this map from their site.  There are other networks available in other parts of the world that can be found by searching online.

unavco_map

To access the UNAVCO data I had to request access through email but the process was very simple and within a couple hours of my request I was all setup with an account and password.

Once I had my account set up, I used RTKLIB on my laptop computer to collect the data from the internet and stream it to the rover receiver over a serial port.  If I were doing this experiment within range of a wireless router then I could leave the computer connected to the wireless.  In this case though, I wanted to roam outside the range of my home wireless.  To do this, I enabled a hot spot on my cell phone and logged into that with my computer.

I was able to access the raw observation data stream from the UNAVCO NTRIP caster directly using the NTRIP client option in RTKLIB.  If I had wanted to generate a real-time RTKLIB solution, I would have configured the input streams of RTKNAVI but in this case I want to stream the raw data directly to the receiver so it can use the observation data for it’s internal solution.  I did this using the STRSVR app in RTKLIB.  I specifed the “NTRIP Client” option as input type and then entered the information from my UNAVCO account into the “Ntrip Client Options” as shown below.

ntrip_client

In this case I wanted the data from station P041 in RTCM3 format so I had to specify the Mountpoint as “P041_RTCM3”.  For other networks, the mountpoint details may be a little different.  Most NTRIP casters use Port 2101, and that was the case for this one.  For the STRSVR output type, I specified “Serial” and then configured the serial port options for whichever rover receiver I was using.  Before doing the configuration, I had connected the receiver to the laptop using a USB cable.

I then had to configure the receiver to tell it to get its base station data from the COM port and specify that it is in RTCM3 format.  The details for doing this on the two receivers are a little different but fairly straightforward in both cases.  You may also need to specify the exact base station location manually or the receiver may be able to get it from the data stream depending on the receiver and NTRIP stream details.

And that’s it.  With this configuration, either receiver was able to fairly quickly lock to a fixed RTK solution and continue to receive base data as long as I stayed in range of cell reception.  Any lag in the base station observations appeared to be less than a second.

That worked great for using an existing external reference as base station.  However, I also wanted to run another real-time experiment where I used one Swift receiver as base and the other as rover.   To do this, I needed to set up an NTRIP server to stream the data to  a caster on the internet as well as an NTRIP client to receive it.

I started by connecting the second Swift receiver to an old laptop with a USB cable and then downloading RTKLIB, the Swift console app,  and the right USB drivers.  The base station antenna is on top of my roof and the laptop is in the house so I was able to connect the laptop to the internet using my home wireless.

For the NTRIP caster, I found it convenient to use RTK2GO which is a community caster available for anyone to use at no cost.  To send the data to the caster, I used the “NTRIP Server” as the STRSVR output type and configured it as shown below.

strsvr_server

Again, the port is 2101.  You can choose any name for the mountpoint.  If that name is already in use, then rtk2go will assign a suffix to it, so it is best to choose a name that is unlikely to already be in use.  The password at the current time is BETATEST but that may change from time to time so it’s worth verifying it is still correct.

For the STRSVR input, I selected “Serial” and specified the correct COM port for the base station receiver.  In this case the raw observations are in Swift binary format which RTKLIB does not support so it sends them unaltered.  If they were in a format that RTKLIB did support, then they could be converted to RTCM3 to reduce bandwidth and make them more easily usable by someone else not using a Swift receiver as rover.  You can specify the conversion to RTCM3 using the “Conv” menu on the STRSVR output.

Start STRSVR and your base station observations are now accessible to anyone in the world through RTK2GO.com!

On the rover side, the NTRIP client is set up as I previously described using STRSVR except you want to use the same caster/mountpint/password as you just did on the base station.  In this case the user-id is left blank.  Again, set the STRSVR output to “Serial” to send it to the receiver.   Then set up the receiver to get it’s base station data from the serial port and, in this case, specify that it is in the Swift Binary Protocol (sbp).  Start the receiver and it should fairly quickly get a fix.  If you are seeing baseline data but not a solution, then most likely you have not specified the base station location to the rover.

I was now able to drive around almost anywhere and get continuous real-time RTK solutions using either my own base station or the CORS reference station as base.  In the next post I will discuss some of the data I collected and analyzed.

 

 

 

 

Newest U-blox M8N receivers not usable with RTKLIB

It looks like it is no longer possible to access the raw GPS measurements on the newest version of the u-blox M8N receiver.  Access to these raw measurements on the M8N has always been through debug messages not officially supported by u-blox.  Last year, when they migrated from the 2.01 version of firmware to the 3.01, version they scrambled the output of these messages so they were no longer readable by RTKLIB.

Until recently though, the units they were shipping still had an older 2.01 version of ROM.  With these units it is possible to downgrade the firmware to 2.01 using the instructions on their website.  With the older firmware loaded, the receivers revert to their previous behavior and the debug messages are no longer scrambled.

Apparently their newest units are shipping with a 3.01 version of ROM and this ROM is not compatible with the older 2.01 version of firmware.  If you attempt to load the older firmware it will appear to succeed but will still be running the newer code.

You can see what version of ROM and firmware your receiver is running using the UBX-MON-VER message from the u-center console.  The example below shows the message output for one of the newer modules with the 3.01 ROM after attempting to download the older firmware.  I believe the firmware listed under “Extension(s)” is the ROM version and the firmware listed under “Software Version” is the version of firmware loaded to flash.  In this case you can see that the ROM is version 3.01 and that the flash is still running version 3.01 even though it was attempted to load the 2.01 firmware.

fw_ver

In an older version of the M8N module, the ROM code listed under “Extension(s)” would have been 2.01 and the firmware listed under “Software Version” could be either 2.01 or 3.01 depending on how old the module was and what firmware had been downloaded to it.

There are a few more details about the issue on the u-blox forum in this thread.  Thanks to Marco for making me aware of the issue and Clive and Helge for providing a detailed explanation of what is going on.

If you are using the u-blox M8T, and not the M8N, then you will be using the officially supported raw measurement messages and would normally not care about access to the debug messages.  The only exception I know of is that the resolution of the SNR measurements are 0.2 dB in the debug messages and 1.0 in the official messages.  I have not confirmed that the debug messages on the 3.01 M8T firmware are scrambled but it is likely that they are.

[Note 6/25/17:  A couple of readers have pointed out that this is not the whole story.  It would have been more correct to say that the newest M8N modules are not usable with the publicly available versions of u-blox firmware and RTKLIB.  It turns out that u-blox did not use a particularly sophisticated method to scramble the debug messages and there are now several modified versions of u-blox firmware and RTKLIB floating around that have been hacked to unscramble the messages.  I don’t want to get into the question of ethics or legality of using these codes but just say that I personally am less comfortable using the debug messages in the modules where u-blox has made an obvious attempt to prevent this and have avoided any use of them at least for the time being.]

Update to RTKLIB config file recommendations

I’ve just updated my “RTKLIB: Customizing the input configuration file” post from a few months ago with information on all of the new config parameters I have added to the demo5 code up through B26B.  I’ve also added more notes to some of the existing features based on my more recent experiences.

Receiver warm-up glitches

I’ve described before the occasional glitches that both the M8N and M8T seem to be susceptible too in their first few minutes of operation, but my previous description was buried in one of my more technical posts and maybe not seen by people more interested in just the practical side of using RTKLIB, so I thought it was worth bringing them up again.

Here is an example of one of these glitches which was in a data set recently sent to me by a reader, and one that was giving him trouble finding a solution.  The data is very clean, except for a nearly simultaneous cycle-slip (shown by red ticks) on every satellite.

rec_glitch

Here is a zoomed in image of the same glitch.

rec_glitch2

I see these glitches on both the M8N and the M8T receivers.  Every occurrence I have seen, the glitch occurred within a few minutes of turning on the receiver, and was present on every satellite.  In this example it occurred seven minutes after starting up, usually I see it within in the first five minutes.

These glitches are very disruptive to the RTKLIB solution.  Since the cycle-slips affect every satellite, all the phase-bias kalman filter states are reset and the solution has to start again from the beginning.  In some cases, the phase-biases initial values may have larger than normal errors in which case it is even worse than starting over.

I don’t have any good suggestions on how to deal with these other than to avoid them in the first place.  From my experience I believe they are more likely to occur if the external environment of the receiver has just changed.  For example if it went from hot to cold, or into the sun.  Once the receiver has had time to stabilize, everything is usually OK.

Giving the receiver time to adapt to it’s current environment before collecting data and protecting the receiver from sudden changes should help avoid these glitches.  Using external antennas with cables rather than the small antennas that come with the receivers helps because it allows you to place the receiver in a more protected location than the antenna.  For example, when I collect data from a moving car, I place the antenna on the roof but keep the receiver in the car.

For information on plotting the observations with cycle slip enabled see this post.  For another post where I discuss this problem in more detail, see this post.

Does anyone else have more information on what causes these glitches and maybe other steps that can be taken to avoid or deal with them?