Previously I collected some data with a pair of ComNav K708 receivers and compared the internal real-time ComNav position solution with a real-time RTKLIB solution from a pair of u-blox M8T receivers. The results showed, at least for the moving rover case, that the two were quite similar. In this post I will post-process the ComNav raw data with RTKLIB and compare the results both to the internal ComNav solution and the M8T post-processed RTKLIB solution . The ComNav receiver configured to sell for sub-$1000 is setup to receive only GPS and GLONASS L1 and L2 frequencies so this is how I ran this test. The M8T will also receive Galileo and SBAS satellites so I included these in the M8T solutions.
RTKLIB is not able to directly process raw binary ComNav data, but I had configured the receivers to output the raw data in RTCM3, then converted this to Rinex using RTKCONV, so this was not a problem.
Before we can get a solution however, we need to deal with the issue that the ComNav GPS L2 observations are a mix of L2 and L2C as seen in the RINEX observation data below.
RTKLIB handles multiple code types for the same frequency like this by choosing the code with higher priority as set in the code priority table in rtkcmn.c. Unfortunately this choice is made for the full data set, not each individual observation, so the lower priority observations are thrown out even for epochs when the higher priority code observations are not present. There is an option in the ComNav configuration to force all observations to L2 and this would have been one solution to the problem. However, in theory, the L2C code should be more robust than the L2 code, so using L2C when we have the option as the ComNav default setup does is probably the right choice.
I was not able to find any simple fix for the RTKLIB code or configuration that would allow it to process both observation types so I simply edited the list of observation types in the RINEX file headers and changed “C2X L2X S2X” in the list to “C2W L2W S2W”. With this change, all the observations are now described as L2 and none will be thrown out. It would be a problem if we were mixing L2 observations from the rover with L2C observations from the base, but since both will be consistently L2 or L2C, the differences should cancel, and this should not cause any significant errors in the solution.
I looked at three data sets, all from a moving rover with a local base station. The first data set is configured as described in my earlier post, with both the M8T and the ComNav rover receivers sharing the same antenna. In the second two data sets, the rovers are connected to separate antennas. I ran with continuous ambiguity resolution set and GLONASS ambiguity resolution enabled for all solutions. The only change I made from the default ComNav config settings was to change the “rtkquality” setting from “quick” to “normal” since I had trouble with false fixes when it was set to”quick”.
First of all, let’s compare the ComNav internal solution to the ComNav RTKLIB solution. Here’s the internal solution on the left, and the RTKLIB solution on the right. In this case RTKLIB had a little higher fix rate at 76.8% vs the internal solution at 68.8%.
What I found more surprising was that the internal solution did not stay fixed for the circles I drove in the parking lot from 23:37 to 23:40. Normally I rarely have trouble maintaining 100% fix for this part of the route since there are very few trees here and the sky views are almost 100%.
Here’s a comparison of the difference between the two solutions.
I expect the difference to be near zero for all fixed sections and for the most part this is true. There is an exception though between 23:32 and 23:33. I don’t have an absolute reference to compare to so I can’t be absolutely certain which is correct and which is in error. However I can compare to the M8T solution and in this case the ComNav RTKLIB solution nearly exactly matches the M8T solution so I am fairly certain that it is the internal ComNav solution that is wrong. This error is fairly large and is most likely caused by a false fix. Also, in general, the error in the U-D axis is fairly large in both cases relative to what I am used to, but is worse in the COMNAV internal solution. Below is the difference between the RTKLIB u-blox and RTKLIB ComNav solutions on the left, and the difference between the RTKLIB u-blox and internal ComNav solutions on the right, both for the U-D axis only.
Here is the M8T RTKLIB solution for comparison. Fix rate was 81.8%, just slightly higher than the ComNav RTKLIB solution.
One advantage of post-processing the data over a real-time solution is that solutions can be run in combined mode where the result is a combination of running the solution through the kalman filter forwards and backwards. Here’s the combined mode results, ComNav on the left, and M8T on the right.
In this case both solutions were near 100% fix. ComNav does sell post-processing software that would probably also let you do the same thing but I do not have a copy of it and don’t know how much it cost.
The results for the second two data sets with separate antennas showed similar differences to this one so I’ll include the plots here but won’t go into any detailed analysis. In both sets of plots, the left is the ComNav internal solution, the middle is the ComNav RTKLIB solution, and the right is the M8T RTKLIB solution.
The biggest difference in these two data sets is that the M8T results were slightly worse relative to the ComNav results than in the above example but this is most likely because the antennas were separate and I used a low-cost single feed L1 antenna instead of the higher performance dual feed L1 antenna I prefer to use in these comparisons. There is a good description here of why the dual-feed antenna should give better results.
It is always dangerous to conclude too much from a single experiment but this data does support what I have found in my other single frequency to dual frequency comparisons. For short baselines with a pair of matched receivers and moving rovers, an L1+L2 GPS/GLONASS solution tends to be similar in performance to a L1-only GPS/GLONASS/SBAS/Galileo solution. I expect this would be less true for longer baselines and stationary receivers.
In the last couple of posts I compared the u-blox M8T receiver and the Swift Piksi Multi receiver for a stationary rover and an external base station using the latest 1.2 firmware from Swift. I did this for both RTK and PPP solutions. In this post I will look at a moving rover case with a pair of Piksi receivers and a pair of M8T receivers.
The new Swift firmware supports raw observations and float solutions for the GLONASS satellites, but does not yet support ambiguity resolution for GLONASS. In the previous experiments the lack of GLONASS ambiguity resolution did not affect the comparison since an external (non-matching reciever) base was used. This meant that the RTKLIB solutions were not able to use GLONASS ambiguity resolution either.
In this experiment I did use matching receivers for the base data, so the RTKLIB solutions do include GLONASS ambiguity resolution and so should provide an advantage to the Swift internal solutions. As I did last time, I will compare the real-time Swift RTK solution with post-processed RTKLIB solutions for the Piksi pair and the M8T pair. In this case the M8T receivers are from CSG Shop and are running the 3.01 firmware so they include Galileo observations in addition to GPS, GLONASS, and SBAS.
In my previous moving rover experiments I shared a base antenna for the two base receivers but used separate antennas for the two rover receivers. In this case I decided to also share the rover antenna between the two rover receivers to enable some more direct comparisons. The base antenna is the same Swift GPS-500 antenna mounted on my roof that I used for the rover in the previous experiment. The rovers are using a Tallysman TW7872 antenna mounted on top of a car. In both cases I use a capacitively coupled splitter to isolate the two receivers and allow only one DC supply voltage to reach the antenna. As usual, the data was collected while driving around my local neighborhood.
Whenever connecting two receivers to one antenna, or even locating to antennas close to each other there is always the concern that they may interfere with each other. So, as a baseline, I first did a run with separate antennas for the rovers. I used my inexpensive u-blox antenna for the M8T since it has a very long cable allowing me to separate both the receivers and the antennas by over a meter. Here are the position solutions for the baseline test. The Swift internal solution is on the left, the RTKLIB post-processed solution in the middle, and the M8T post-processed solution on the right. As always, green is fixed points and yellow is float.
The post-processed solutions were both run forward-only and with continuous ambiguity resolution including GLONASS. The percent fix for the three solutions were 69% for the Swift internal solution, 33% for the Swift RTKLIB solution, and 75% for the M8T RTKLIB solution. I will use percent fix as a very coarse measure of goodness for now, later I will look at the solutions in more detail. In this case I consider the Swift internal solution and the M8T RTKLIB solution roughly equal. Both achieved 100% fix for a number of circles in a parking lot with open skies (22:30 to 22:35), and both struggled with partial fixes on the rest of the route which had more obstructed sky views driving along residential streets. The Swift RTKLIB solution was noticeably worse and had 0% fix in the parking lot, and lower percent fix everywhere else.
I then re-ran a similar route a short time later, but this time with the M8T rover sharing the dual frequency antenna with the Swift rover, produced the following results in the same order as above. The percent fixes were 53% for the Swift internal solution, 79% for the Swift RTKLIB solution, and 62% for the M8T RTKLIB solution.
Again I would consider the Swift internal and the M8T RTKLIB solutions roughly equal. A different parking lot with open skies (1:43 to 1:48), gave no trouble to either solution, but both had only partial fix for the rest of the route. In this case the Swift RTKLIB solution was noticeably better than the other two solutions which is interesting since last time it was noticeably worse. This has been my experience in general with the Swift RTKLIB solutions, that they tend to be quite inconsistent. With the previous firmware I traced some of the reason for this to unreported cycle slips. I suspect the same is probably going on here but haven’t looked close enough to fully verify that. As far as any interference occurring between the antennas, if it exists, it is too small to detect with this simple comparison.
Here are the raw observations for the two rovers for the second run, M8T on the left, Swift on the right. Green lines are dual frequency, yellow are single frequency and red ticks are cycle slips. There are 19 measurements available for the M8T solution and 22 for the Swift solution. All are used for ambiguity resolution in the RTKLIB solutions but only the 11 GPS measurements are used for ambiguity resolution in the internal Swift solution. The relatively cycle-slip-free region from 1:43 to 1:48 is from the parking lot where the sky views are open.
Since the exact same signal was fed into both receivers the observations can be compared more directly than in previous experiments. Here is a zoom into the time in the parking lot and shortly after. If you look carefully, you will notice that there are definitely more cycle slips reported in the M8T observations than in the Swift data.
We can verify if those cycle slips are real or not by plotting the double differences of the bias states from the RTKLIB statistics output file. I selected two satellites that had more cycle slips in the M8T data, G03 and R04, and plotted their double differences relative to the most cycle-free satellite in their constellation. In the plots below, the red lines are the double differences from the M8T bias states and the blue lines are the double differences from the Swift bias states. The red circles are cycle slips reported in the observations and the discrete jumps are actual cycle slips. The green x’s are half cycle invalid flags and not relevant to this particular example.
Both plots show good correlation between the reported cycle slips and the true cycle slips as well as confirming that their are more slips in the M8T observations than in the Swift observations. So, at least in this example, the quality of the Swift observations is noticeably better than the M8T observations, even though both came from the same antenna. Of course this might be expected since the Swift receiver, although low cost by dual frequency standards, is still significantly more expensive than the M8T receiver.
The solutions however, don’t reflect this difference in observation quality. The Swift internal solution appears to be no better, and possibly even a little worse than the RTKLIB M8T solution. This is probably because the M8T solutions include GLONASS ambiguity resolution and the Swift solutions do not. Once Swift adds this feature to their firmware I would expect the Swift internal solutions to be better than the M8T solutions.
The variability for the results from the Swift RTKLIB solutions are harder to explain and I don’t have any good answers for this yet. I still do see cases of unreported cycle slips causing problems even with the new firmware and suspect this is a part of it. I hope to investigate this further.
Another thing I wanted to look at is how good are the float solutions. In Swift’s description of the new firmware they state that:
“Swift also suggests that users utilize the estimated accuracy fields
in navigation outputs for an indication of solution quality rather than using the
transition to RTK “fixed” mode as an indicator of solution quality, as the new
and improved float solution performance can often fulfill precision navigation
So, let’s take a look at the float portion of the internal Swift solution. I loaded the .csv output file from the Swift internal solution into matlab, then plotted histograms for the horizontal and vertical accuracies for the fix and float solution points. Here’s what it looks like:
Notice that the float accuracies are significantly larger than the fix accuracies but they are probably realistic unlike the RTKLIB float accuracies which I demonstrated to be at least a factor of two overly optimistic in a recent post.
Here is an example of the solution points from the above data set in which the RTKLIB solution re-converges more quickly than the Swift internal solution. This allows us to evaluate the accuracy of the Swift float values. The top plot is one component of the horizontal position, and the bottom plot is the vertical position. Yellow is the Swift float solution, Olive green is the RTKLIB float solution and blue is the RTKLIB fix solution. From the beginning of the data to 22:47:14 both solutions are float. The RTKLIB solution converges to a fix at 22:47:14 and the Swift internal solution converges to a fix at 22:47:37. Since both solutions eventually converge to the same value I will assume the RTKLIB fix solution is correct.
The errors in the float solutions appear to be similar between RTKLIB and Swift and consistent with the Swift estimates of accuracy. So the Swift float solution does not appear to be any more accurate than the RTKLIB float solution but the Swift estimates of the accuracy do seem to be more realistic. Three quarters of a meter vertical accuracy is better than a single point solution but I suspect it is too large to be useful for many applications. Still, it is a noticeable improvement from the very noisy float values I saw in the internal Swift solution in my previous comparison.
So what does all this mean? I would summarize by saying that the results for a pair of Swift receivers with the new firmware are noticeably better than the results in my previous comparison and so are definitely a step in the right direction. At least in my particular example, though, it still only puts them roughly on par with the results from a pair of M8T receivers. They certainly seem to have the potential to be better than the M8T’s and hopefully with further improvements from Swift and maybe improvements in RTKLIB as well, we will see this soon.
I did not include a single M8T or Swift receiver paired with an external CORS or similar base station example in this moving rover comparison but would expect the Swift receiver to outperform the M8T receiver in that case because of a better overlap in satellite pairs. Also keep in mind that the Swift receiver does have some definite advantages in static and long baseline experiments as I showed in my previous two posts, especially the ability to get accurate locations for the base station using PPP solutions.
As always I want to emphasize that these are only one users results in one particular configuration and other users experiences in other environments could be quite different. I have uploaded the raw data and RTKLIB config files to the sample data section on the rtkexplorer.com website if anybody would like to explore further.
I am just getting my newly borrowed NavCom receivers up and running and have upgraded my Tersus receiver with their new firmware so I hope to have results for these other low-cost dual frequency receivers soon.
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.
Swift Navigation just released a major upgrade to the firmware for the Piksi Multi low cost dual frequency receiver. This should significantly improve performance since it adds support for the GLONASS L1 and L2 satellites. This is an L1/L2C only receiver so it only supports L2 on about half of the GPS satellites, those recent enough to support the new codes. On GLONASS however, there is no L2/L2C distinction and the Swift receiver supports the second frequency on all of the GLONASS satellites. There are fewer GLONASS satellites than GPS satellites but overall this change roughly doubles the measurements available to the solution. Looking at a recent six hour data set I took, the number of GPS satellites varied from 7 to 9 and the total L1 plus L2 GPS measurements varied from 11 to 14. During the same time there were only 5 to 7 GLONASS satellites but 10 to 14 total GLONASS measurements including L1 and L2.
Unfortunately, the update does not include ambiguity resolution for the GLONASS satellites within the Swift internal RTK solution. The raw GLONASS measurements are available though and RTKLIB supports GLONASS ambiguity resolution provided both receivers are identical. This means you can use GLONASS ambiguity resolution if you have two Swift receivers and are doing post-processing with RTKLIB.
I did a comparison between the Ublox M8T and the Swift Piksi Multi a few months ago and found that with only L1 GPS and partial L2 GPS, the Piksi simply did not provide enough measurements to generate a robust solution. With the new measurements available, along with other improvements they have added with the new firmware, I thought it was time to give it another test.
As I did previously, I will compare a Swift internal RTK solution to an RTKLIB post-processed PPK solution using the Swift data as well as an RTKLIB post-processed solution from a u-blox M8T L1 receiver. Swift does not provide any tools for doing post-processed solutions so the Swift internal solution will have to be real-time.
My first test was with a static rover to make evaluation of the results easier. Even though the rover was stationary, I ran all solutions in kinematic mode to get a better sense for the errors. For the rover I used a SwiftNav GPS-500 antenna mounted on my roof and connected through a signal splitter to both a Piksi Multi and a u-blox M8T receiver. For the base I used the P041 CORS/UNAVCO station which is the closest station for which I have real time access to through the UNAVCO network. It is about 17 kilometers away so a long enough baseline to be fairly challenging. I did run from early evening to late night so the ionospheric errors were not as large as they would have been at mid-day. There also happened to be about two inches of snow that fell during the measurement period, possibly affecting the result through snow accumulation on base or rover antennas? Other than the snow, this is very similar to the test I ran previously comparing a Tersus dual frequency receiver to an M8T receiver.
Let me start by giving my usual warning that these comparisons are only meant to be a snapshot of one users experience and not a comprehensive evaluation of any sort. Measurement environments vary tremendously and there is no guarantee that other people’s results will match mine.
I ran the test for approximately eight hours. Here are the rover observations for both receivers, Swift on the left, and M8T on the right. Green lines indicate dual frequency measurements and yellow are single frequency. The Swift receiver has GPS and GLONASS observations, the M8T has GPS, GLONASS, Galileo, and SBAS. Both receivers averaged roughly 25 measurements with the additional L2 measurements on the Swift roughly balancing the additional satellites on the M8T.
To more easily compare the internal Swift solutions to the RTKLIB solutions I wrote a simple matlab script that translates the csv logs written by the Swift receiver to the format of an RTKLIB .pos file, allowing me to plot both together using RTKPLOT.
When I first plotted the solutions I saw DC offsets between the Swift solution and the RTKLIB solutions. I had seen this before in my previous test. Last time I had ignored the offsets assuming they were coming from datum differences but this time wanted to pinpoint exactly where they were coming from. Usually it is easier to do these comparisons with relative measurements between the two receivers (ENU coordinates) rather than absolute solutions since the absolute solutions often involve translating between different datums. In this case though , the relative solutions were giving differences in the z axis exceeding 45 meters! I eventually traced the source of this error to different origins for the ENU coordinates between Swift and RTKLIB. Swift uses the rover as the origin and RTKLIB uses the base as origin, causing a rotation of the axis of the two ENU coordinate systems. Combined distance in three dimensions is the same either way but the distribution between axes changes significantly.
I then switched to comparing absolute solutions using LLH coordinates. I specified the same base location to both solutions using the numbers I got from the base station location file. The offsets were still there but smaller now, just a few centimeters. Eventually I realized that Swift was not using the base location I specified on the settings page but was substituting a slightly different base location generated from location messages in the incoming base RTCM stream, presumably from a different datum. I switched the RTKLIB solutions to use this base location and this eliminated the DC offsets. RTKCONV places the base location provided in the RTCM stream into the “APPROX POSITION XYZ” field in the Rinex file header, so selecting “rinexhead” option for the base station location in the config file accomplishes this.
Here are the position solutions for the first hour of the test after sorting out the offsets. On the left is a comparison of the internal Swift solution to the RTKLIB Swift solution. The yellow/green line is the internal Swift solution and the olive/blue line is the RTKLIB Swift solution. On the right is the RTKLIB M8T solution (yellow/green) and the RTKLIB Swift solution (olive/blue). The large errors are caused by the initial acquires of the RTKLIB solution (the Swift solution had already acquired when I started the data collection) and from me disconnecting the antenna twice to force a re-acquire of all solutions.
The Swift solution is re-acquiring after losing fix much more quickly than the RTKLIB solutions. In these two examples, the Swift solution re-acquired in less than one minute while the RTKLIB solutions required 5 to 10 minutes. Interestingly, the RTKLIB re-acquire times were roughly the same for the M8T or the Swift data. Presumably the Swift solution is taking advantage of linear combinations of the L1 and L2 measurements in ways that RTKLIB is not. Previously I was seeing the Swift solution sometimes take very long to re-acquire (well over ten minutes). This issue seems to be fixed and the Swift solution now seems to re-acquire quickly and reliably. So, by this metric, the Swift receiver is a clear winner, provided you are using the internal solution. For the RTKLIB solutions, the two receivers are very similar. This might be expected since they are both working with roughly the same number of raw measurements. I should mention that GLONASS ambiguity resolution was disabled in the RTKLIB solutions since the base and rover were not using identical hardware.
Next let’s compare the relative accuracy of the three solutions. I will ignore any errors that are common to all three solutions and focus on differences between the three. To do this I will use the mean of all three solutions in each axis as the “correct rover location”. I will also only use the fixed points for now, and ignore the float. First let me show the rest of the eight hours of data in which I did not disconnect the antenna at all. Again the Swift internal (green/yellow) vs Swift RTKLIB (olive/blue) solutions on the left, and M8T RTKLIB (green/yellow) vs Swift RTKLIB (olive/blue) solutions on the right.
Clearly several disruptions are common to all three solutions. Again, the Swift solution re-converges much more quickly than the RTKLIB solutions. Given that the disruptions are common to both M8T and Swift receivers, the most likely suspect is the base station. Sure enough, the base observations show simultaneous cycle slips on multiple satellites at most of the disruption points. I’m not sure what caused these anomalies but am more interested in the solution responses to them than their actual cause, as they are common to all solutions.
The mean rover position was very close for all three solutions, as were the standard deviations for each axis. It is difficult for me to interpret errors measured in degrees of latitude or longitude so I converted the LLH positions to ECEF for comparison. Here are the results, all in meters. The maximum deviation from the combined mean was 7 mm and the largest standard deviation was 1.5 cm. These errors are all small enough and similar enough that I would say the differences between them are probably not very meaningful.
Swift internal: dx=0.003 dy=0.007 dz=0.003
Swift RTKLIB: dx=-0.002 dy=-0.003 dz=-0.001
M8T RTKLIB: dx=-0.001 dy=-0.004 dz=-0.002
Swift Internal: stdx=0.006 stdy=0.013 stdz=0.010
Swift RTKLIB: stdx=0.006 stdy=0.012 stdz=0.014
M8T RTKLIB: stdx=0.005 stdy=0.012 stdz=0.015
Here are the plots of the three solutions all laid on top of each other, all relative to the combined means. All three are fairly well correlated, but in particular I find it surprising how correlated the Swift RTKLIB solution is to the M8T RTKLIB solution. They overlay on top of each other so well that it is difficult to even see the Swift solution but that is only because the M8T is on top, both had roughly the same percent of fixed points.
So in terms of accuracy, there is very little difference in any of the three solutions. However, it is clear from these plots that in relatively long baseline situations like this, the Swift internal solution will fix and re-acquire more quickly and hence would take less time to make a measurement. This difference would be smaller for shorter baselines where all solutions would fix fairly quickly and be nearly 100% fixed.
RTKLIB does have some additional flexibility over the Swift internal solution, especially in a post-processing situation which could be used to improve the RTKLIB solution, including static vs kinematic, continuous AR vs kinematic AR, and combined (forward/backward) mode instead of just forward. In this case, probably combined mode would be the most effective choice since it causes the solution to approach the anomalies in the raw data from both directions and minimize their disruption. Here is the same solution as above for the M8T RTKLIB solution (green/yellow) and the Swift RTKLIB solution (olive/blue) , but processed in combined mode. It improves both solutions significantly and brings the Swift solution to nearly 100% fix.
Overall, the new Swift firmware looks like a significant improvement over the previous version, particularly for real-time applications where time to first fix is most important and post-processing options are not available.
In my next post, I will extend the comparison to a moving rover case.
OK, so let’s say you’ve just gone out and collected some decent raw measurement data, everything looks like it is working properly and you get a nice-looking solution from RTKLIB, maybe something like this.
The next thing you might want to know is how accurate is that solution? Fortunately, RTKLIB does include accuracy estimates in the solution file. These are expressed as standard deviations, one for each axis. Here’s an example for a solution calculated in ENU (east/north/up) coordinates. The sde, sdn, and sdu columns are the standard deviation estimates for each solution point and are given in meters. If the solution were calculated in XYZ coordinates, the columns would be labelled sdx, sdy, and sdz.
You can display these on the solution plot with RTKPLOT by setting “Error Bar/Circle” in the options menu to “Dots” or “Bar/Circle”. You can see the gray lines in the plot below that represent the solution value plus and minus one standard deviation.
Visually, I prefer to see three standard deviations plotted, rather than just one. Three standard deviations represents 99.7% of the distribution, so the correct value should nearly always appear between the two gray lines. One standard deviation, on the other hand, represents only 68% of the distribution which is hard for me to attach any physical meaning to. This can be easily changed in RTKLPLOT by replacing SQRT(s[j]) with 3*SQRT(s[j]) all three places it appears in the plotdraw.cpp file and recompiling RTKPLOT which gives this:
Of course these are just estimates of the solution uncertainty made by the kalman filter in RTKLIB and we can not assume they are accurate without some analysis. They are a function of the input parameters that set the input measurement uncertainties and process noises for the kalman filter. These are all in the “stats” section of the input configuration file. Even if these are all set to correctly match your actual configuration, there will be additional errors in these estimates caused by non-linearities in the system, non-gaussian distributions, and time-correlated measurements among other things.
So, let’s do a little analysis to get a feel for how useful these estimates are. We’ll start with the above data set which includes eight hours of measurements from a stationary u-blox M8T receiver and a CORS reference station 8 km away. I enabled fix-and-hold for ambiguity resolution with relatively low tracking gain (pos2-varholdamb=0.1). I ran both static and kinematic solutions on the data, then turned off ambiguity resolution and re-ran the solutions to get examples of both fixed and float solutions for static and kinematic modes.
After running the solutions, I pulled the solution files into matlab for plotting and analysis. Since the rover was stationary and I knew it’s precise location I was able to easily calculate the true errors. I then plotted for each solution point, the absolute value of the errors and three times the standard deviation estimate for each point, similar to the above RTKPLOT plot. The raw data is in E/N/U coordinates but I combined the East and North values into a single horizontal error and error estimate. After finding that in some cases the error estimates were too low, I also plotted a line using double the error estimate, to see if that might be a usable value . In the title of each plot I’ve included the percent of samples that were inside the error lines, the first number is for the undoubled estimate, the second is for the doubled estimate. I also made one more modification to the error estimates by limiting them to a minimum value. In the case of the static solutions, the RTKLIB error estimate will continue to decrease almost all the way to zero but this is not realistic since there are errors that are not visible to the solution. I arbitrarily limited each horizontal axis standard deviation to no less than 5 mm, and the vertical axis to 1 cm. I don’t have good justification for these particular numbers but do believe there needs to be some limits set.
For a perfect Gaussian distribution, plus or minus three standard deviations should include 99.7% of the data. Given that these are not perfect distributions and will also contain outliers, I would consider the estimates useful if more than 95% of the data fell within them.
Here are the plots for the above data set run with static solutions, float on the left, and only the fixed values of the solution with ambiguity resolution enabled on the right. The blue line is the actual error, the red line is the RTKLIB estimate, and the yellow line is double that. The top plots are for the horizontal axes and the bottom plots for the vertical axis. In the static cases, all the error lines dropped below the minimum estimate values I set above fairly quickly, so only the initial convergence of the float solution was really of any interest. Still the error estimates in that region look somewhat reasonable, although the undoubled estimates are clearly optimistic. The undoubled estimates (red) are not visible on the plots where both estimates have dropped below the minimum and they get overwritten by the doubled estimate.
Next are the same plots for the kinematic solutions. Just to confuse you, I have accidentally put the float solution on the right this time. Again, the solution with ambiguity resolution enabled (on the left) only includes points that were fixed. These are more interesting than the previous plots since they are not dominated by the arbitrary minimum error estimate limits I added. Looking at the float solution first, the undoubled estimates again look too optimistic with only 92.2% and 75.2% of the data within that limit. At 100% and 99.6% the doubled values (yellow lines) appear to be better estimates. For the fixed values on the left however the undoubled estimate percentages and plot lines appear to be fairly reasonable.
In one last example, I used a different data set, this one is one of the sample data sets on my website which was taken with two M8T receivers, one on each end of a kayak out on the ocean. In this case we know that the distance between the two receivers will remain constant so we can use that information to do a similar analysis as above. Because the kayak is moving in all three axes with the waves we can not separate the horizontal and vertical components but can do an actual error to estimated error comparison for the three axes combined.
The float solution is back on the left again, just the fixed values from the ambiguity resolution enabled solution on the right. Based on the calculated percentages and the shapes of the curves, it seems fairly reasonable to again choose the doubled estimates for the float solution and the undoubled estimates for the fixed values. Even with the doubling, the percent of solution values within three standard deviations is still only 88.5% which is rather low but most of the outliers were in the initial convergence where we might expect more issues.
So, based on these few examples I do see correlation between the RTKLIB error estimates and the actual errors, not as much as I would have liked, but there is some. Maybe these adjustments I made would hold up for other cases as well, but I would not have a lot of confidence without trying more examples first.
Clearly these error estimates can not be taken at face value. Do they have any value? It probably depends on what you are trying to do with them. If you are just trying to get a rough idea of the accuracy of the measurements, especially if it is in a statistical sense, and you have done some previous analysis with similar data sets, then you can most likely derive some value from them. If the absolute accuracy of a single measurement is important to you then you will probably need to find another solution.
What about trying to adjust the input configuration parameters (measurement and process noises) to make the accuracy estimates more accurate? You may be able to make small improvements but I suspect they will not be significant enough to avoid post-solution adjustments. You will also find that adjusting these parameters will affect the quality of the solution and it will be difficult to optimize for both.
I am interested, though, if anyone has any ideas for simple (or at least only moderately complicated) code changes that could be made to RTKLIB to improve these estimates or any other ideas on how to improve them.
I’ve just released the b28 version of the demo5 code. It includes all of the updates in the b28 update of the official RTKLIB 2.4.3 code. It also now supports both Tersus and Swift low cost dual frequency receivers. The Tersus updates were part of the official 2.4.3 release although I did make a few changes to fully support the L2 measurements as well as some changes to the makefiles to get all apps to build. The Swift receiver support is based on code I pulled from the Swift RTKLIB Github page. I suspect the receiver specific RTKLIB code for both receivers could use some improvements in translating from the raw binary formats to the Rinex/internal observation formats but at least this is a starting point. The executables are available from the download section at rtkexplorer.com. The source code is available on my Github page.
I’ve also uploaded some data sets comparing the Swift Piksi Multi and the u-blox M8T as well as between the Tersus BX306 receiver and the u-blox M8T. This data is also available from the download section at rtkexplorer.com.