Comparison of the u-blox M8T to the u-blox M8P

I recently acquired a couple of  u-blox C94-M8P receivers and so I am now able to do a direct comparison between the u-blox M8T and M8P modules, something I’ve been wanting to do for a while.

I believe the hardware between the two receivers is identical, the differences are only in firmware.  The most significant difference in firmware is that the M8P includes an internal RTK solution.  In order to squeeze this into the firmware, however, they had to remove support for the Galileo and SBAS constellations, so this is another fairly significant difference.

Cost, of course, is also different.  The M8T receivers I usually use are available from CSGShop for $75.  CSG sells an M8P receiver for $240 or you can buy a kit with two C94-M8P eval boards from u-blox for $400.  The C94-M8P boards also include on-board radios.

In this post, I will describe how I used RTKLIB and a cell phone hot spot to connect the M8Ps rather than using the internal radios.  I will also compare the RTKLIB solutions for a pair of M8T receivers with the internal u-blox RTK solution for a pair of M8P receivers. I hope to compare the RTKLIB solution to the internal solution for a pair of M8Ps in a future post.  If you are mostly interested in the M8T to M8P comparison results, you can jump directly to the end of this post.

To set up the experiment I first connected both a C94-M8P receiver and a CSG M8T receiver to the GPS survey antenna on my roof using a signal splitter.  I then connected both receivers to a laptop with USB cables.  I configured the M8P using u-center following instructions in the C94-M8P Setup Guide with a few modifications.  First of all, I normally use an NTRIP caster over a cell phone hot spot for my real-time data link so didn’t want to bother with the on-board radios.  I disabled the radios following the instructions in the setup guide.  This involves removing a plastic cover, soldering a wire to a capacitor, drilling a hole in the plastic cover to run the wire, then plugging the other end into a pin on the connector.  It is also possible to do this by connecting an external voltage and ground to the correct pins on the connector, but a simple jumper option would have been a lot more convenient.

The setup instructions are intended to run the setup and solution output messages over the USB port while running the RTCM raw observation messages between receivers over the UART interface.  The UART interface is internally connected to the radios.  Since I am not using the radios, I wanted to run all communication over the USB interface to avoid extra cables.  To do this, I disabled the UART interface and configured the USB interface for UBX messages in and RTCM messages out using the UBX-CFG-PRT configure command from u-center.  Following the C94-M8P setup instructions, I then specified a fixed base station location with the UBX-CFG-TMODE3 command and enabled 1005,1077,1087, and 1230 RTCM messages which include the raw observations, base station location, and GLONASS biases.

I setup the base station M8T receiver as I usually do to output the raw observations using the UBX-RXM-RAWX messages.

I then started two copies of the RTKLIB STRSVR app on the base station laptop and streamed both sets of base observations to an NTRIP server as I’ve described in an earlier post using the free RTK2GO.com community NTRIP server.  With this setup, I can receive the NTRIP streams anywhere I can get cell phone coverage, using a cell phone hot spot and a laptop connected to the two rovers and I can test over much longer distances than the radios would allow.

One thing to be aware of is that there are separate versions of the receiver firmware for the M8P base and M8P rover.  I didn’t realize this at first.  It turned out that both of my receivers came loaded with the rover firmware so I spent an embarrassingly long time unsuccessfully trying to configure one of them as a base station.  Once I realized the problem, I was able to fairly quickly download the base firmware from the u-blox website, then use u-center to download the base station firmware to the receiver.

Next, I attached the two rover receivers to a laptop using USB cables and to a single antenna using a signal splitter.  To make the results more comparable to some of my other recent experiments I used the same GPS-500 L1/L2 antenna from SwiftNav that I used for those experiments.  This is a more expensive antenna than generally would be used with these receivers but I wanted to avoid mixing differences between antennas with differences between receivers.

The M8P rover does not need much configuration since it will by default process any incoming RTCM messages as inputs to an RTK solution.  I did configure the USB port  to support NEMA, UBX, and RTCM messages in and UBX and NMEA messages out.  For the static rover test, I left the position message output rate at the default 1 Hz, but increased it to 5 Hz for the dynamic rover test.  I suspect this only affects the message output rate, and not the solution itself since the solution is probably run at a faster internal rate.

The only other setting I modified in the M8P rover receiver was the dynamic model of the navigation mode using the UBX-CFG-NAV5 message.  I set it to “Pedestrian” for my static rover test and “Automotive” for my moving rover test.

I then started another copy of STRSVR on the rover laptop to stream the M8P base station data from the NTRIP server to the M8P rover over the USB COM port.

At this point, getting the solution output messages from the M8P rover is a little tricky.  Only a single user can attach to a Windows COM port at one time and the STRSVR app is not fully bi-directional.  One solution might be to use u-center to stream the NTRIP data and receive the rover messages but I did not verify if this is possible.

Instead, I used a feature of STRSVR that allows you to pipe the data coming from the other direction to a TCP/IP port which can then be processed by either another copy of STRSVR, or plotted with RTKPLOT, or used as an input to RTKNAVI, or all three at once.  Below, on the left, I show how I modified the STRSVR setup that streams the base data from the NTRIP client to the rover by checking the “Output Received Stream to TCP Port” and selecting port 1000.  On the right, I show the STRSVR setup necessary to stream this incoming data from the rover to a file.  This is a convenient work-around for the problem of only being able to connect one user at a time to a COM port.

strsvr2

In my case I configured the rover receiver to send both the M8P internal solution position using NMEA messages and the raw observations using UBX messages so that I could post-process the raw observations later with RTKLIB.  In general though, it is only necessary to send the NMEA messages.  I configured the rover to send GGA and RMC NMEA messages, but others will work as well.

For the M8Ts, I ran a real-time RTKLIB solution using RTKNAVI and my normal kinematic solution configuration for both static and moving rover tests.  As usual, I used the demo5 version of RTKLIB for this test.

So, how did they compare?  First of all, a few differences to consider between the solutions.   The M8P solution only uses GPS and GLONASS satellites since the SBAS and Galileo satellites have been disabled in the M8P firmware as I mentioned earlier.  This should give the M8T solution an advantage.  The M8P also has limited processing power relative to the laptop running the RTKLIB solution, so this may also give the M8T solution an advantage.  On the other hand, I’m sure that u-blox has lots of smart people that know all the internal details of the hardware which should give the M8P solution an advantage.

For my first comparison, I did a a static rover test with the antenna located on a tripod a few meters from the house and partially obstructed by trees.  To avoid different starting conditions between the two receivers, I connected both receivers to the antenna and waited till they both converged to fixed solutions before starting the test.  I then disconnected the antenna for about 30 seconds, and then reconnected it.  This will cause both receivers to lose lock with all satellites and the solutions will have to re-converge from scratch so this should be a fair comparison.  I disconnected and reconnected the antenna several times to compare the times to re-acquire fix and the accuracies of the fixes.

The results are plotted below, the M8P internal solution on the top, and the real-time RTKLIB M8T solution on the bottom.  I re-connected the antenna five times.  Once, the internal M8P solution re-acquired fix slightly quicker than the RTKLIB M8T solution, once the M8T re-acquired fix slightly quicker than the M8P.  The other three times, the M8T re-acquired fix significantly quicker than the M8P.   The M8P times to re-acquire varied from 52 to 220 seconds.  The M8T took from 50 to 76 seconds.

The M8T RTKLIB solutions had no false fixes, the M8P internal solutions had false fixes with several meter errors for over five seconds in two of the five tests.  The false fixes are circled with red in the plot below.

m8p1

The E-W and N-S axes matched within one centimeter between the two solutions.  The U-D axis at first appears to differ by 21.5 meters between the two solutions but this is because I specified the RTKLIB vertical solution to be relative to the ellipsoid, while the M8P solution is relative to the geoid.  If I subtract the geoid to ellipsoid offset (available in the GGA message from the M8P), then the two solutions match in the vertical axis as well.

Overall, I would have to say that in this particular run,  the RTKLIB M8T solution out-performed the M8P internal solution by a fairly significant amount.

One other observation about the M8P solution is that the precision reported (at least in the GGA message) is only to one centimeter in the horizontal axes and 10 cm in the vertical accuracy.  I didn’t see any obvious way to get outputs with better precision than this, at least with the NMEA messages.  [Note 8/16/18: It turns out that the UBX-CFG-NMEA message can be used to enable high precision mode to fix this.  Thanks to Charles Wang for pointing this out in a comment]

Next I mounted the same antenna on the roof of my car and drove around the neighborhood.  The sky view varied from nearly unobstructed to moderate tree canopy.  Here are the results of that test, the MP internal RTK solution on the left, and the M8T real-time RTKLIB solution on the right.

m8p2

The fix rate for the M8P solution was 52.4%.  The M8T solution was noticeably better with a 95.2% fix rate.

Here’s a plot of the difference between the two solutions (green indicates both solution are fixed, yellow indicates that at least one is float).  The U-D axis differences are fairly large, mostly because of the 10 cm vertical precision of the M8P position messages.  There is also a fairly large discrepancy between the two solutions around 22:55:00.  This corresponds to a 15 second gap in base station data, probably due to a loss of cell phone reception.  This seems to be a large error for such a short base outage but I was not able to narrow down the cause beyond this or determine which receiver contributed more to this combined error.  This probably deserves more investigation in a future post.

m8p2d

Again, the real-time RTKLIB M8T solution appeared in this test to be better than the internal M8P solution.

The most likely reason the M8T is getting a better solution is that it is using more satellites.  Here are the rover raw observations for the M8P on the left, and the M8T on the right.  With the GPS and GLONASS constellations, both receivers are seeing 13 satellites.  With Galileo and SBAS, the M8T is seeing an additional 7 satellites.  One of these Galileo satellites is not fully operational yet and so is not used in the solution, but that still gives 6 extra satellites, nearly 50% more than the M8P solution.

m8p3

If the extra satellites are what is improving the M8T solution, then running a solution with the M8T data without the SBAS and Galileo satellites should give a solution similar to the M8P solution.

This is easy to do, so let’s try it.  Here’s a post-processed solution for the M8T data using only the GPS and GLONASS satellites.

m8p4

Fix rate is 66.5%, reasonably close to the 52.4% fix rate from the M8P internal solution.  This suggests that a large part of the improvement for the M8T solution is coming from the additional satellites and not from any differences in the solution algorithms.

As in all my comparisons, this is intended to be one user’s initial experience, and not any kind of rigorous comparison test.  Please interpret these results with that in mind.  If you have experiences that differ from these I would be very interested to hear about them.

Advertisements

Glonass Ambiguity Resolution with RTKLIB Revisited

To get a high precision fixed solution in RTKLIB we need to resolve the integer ambiguities that come from the carrier phase measurements.  Resolving the integer ambiguities for the GLONASS satellites is more challenging than resolving them for the other constellations.  This is because, unlike the other constellations, the GLONASS satellites all transmit on slightly different frequencies.  This introduces an additional bias error in the receiver hardware.

These hardware biases are constant, generally the same for all receivers from the same manufacturer, are proportional to carrier frequency and are similar between L1 and L2.

In the demo5 version of RTKLIB, there are four choices for how to handle GLONASS ambiguity resolution (AR). I will cover all four briefly, but then focus on the “autocal” setting which I have enhanced in the most recent version (b29c) of the demo5 code.

Off:  If Glonass  AR is set to “Off”, then the raw measurements from the Glonass satellites will be used for the float solution but ambiguity resolution will be done only with satellites from the other constellations.  If you are not using the demo5 version of RTKLIB, this is usually your only choice when using receivers from different manufacturers for the rover and the base.  However, you are giving up a significant amount of information by ignoring the GLONASS ambiguities and so I would not recommend this setting if you are using the demo5 code, unless of course your receivers don’t support the Glonass satellites.

On:  If Glonass AR is set to “On” then RTKLIB will treat the Glonass ambiguities the same as the ambiguities from the other constellations and will not make any attempt to account for the additional hardware biases.  Use this setting if your base and rover receivers are from the same manufacturer, since in this case, the biases will cancel and can be ignored.  There are also some cases in which different manufacturers have equal or nearly equal biases as we will see later, in which case you can also use this setting.  This is your best solution for dealing with Glonass ambiguities.  I always try to use matched receivers for base and rover if possible.

Fix-and-Hold: This is an option I have added to the demo5 code for Glonass AR.  It is an extension to the “fix-and-hold” method used for other constellations but instead of using the additional feedback to track the ambiguities, it uses it to null out the hardware biases.  I recommend this setting when using the demo5 code with unmatched receivers.  It takes advantage of the additional information in the Glonass ambiguites most of the time.  However, fix-and-hold is not enabled until after a first fix has been achieved, and so the Glonass ambiguities are not available until then.  This can mean longer time to first fix and less robustness compared to the “On” option, so don’t use this option for matched receivers.

Auto-cal:  This option adds additional states to the kalman filter to estimate the receiver hardware biases as a function of carrier frequency, one state for L1, another for L2.  In previous experiments I had not had any success with it.  Recently, however, I discovered that if I adjusted the filter settings, it can be effective for a zero baseline case, where base and rover are both connected to the same antenna so that almost all other errors are completely cancelled.  With a little more experimentation I also found that for short baselines it can also be effective if the kalman filter state is pre-set to something close to the final value before the solution is started.  It will then usually converge to the correct bias value.  However, there is currently no mechanism in the code to adjust any of these values, so I have not found this mode to be useful in its current implementation.

To make the auto-cal option more flexible, and hopefully more useful, I made a few modifications to it in the b29c code.  I added the capability to pre-set the initial state value and also to adjust the internal filter settings, specifically the initial variance and process noise for this state.  The units for the state, and hence for the initial value are in meters per frequency channel and values generally are within +/-5 cm per channel.  I used some existing config parameters that are currently unused to reduce the amount of code I needed to change.  Unfortunately it means that the names are not as descriptive as they could be.  The new config parameters are:

pos2-arthres2 = relative GLONASS hardware bias in meters per frequency slot
pos2-arthres3 = initial variance of GLONASS hardware bias states
pos-arthres4 = process noise for GLONASS hardware bias states

Bias values have been published for some of the most popular geodetic quality receivers but are generally not available for lower-cost or less popular receivers.  Here is a table of values from a paper published by Lambert Wanninger in 2011 for nine receiver manufacturers.

biases

I was able to verify these results for Trimble, Leica, and Novatel, but I found a much lower value for Septentrio so I suspect the biases may have changed in their newer receivers.

To demonstrate the modified autocal option, I will start with a zero baseline case between a ComNav receiver and a Tersus receiver.  It is easiest to measure the hardware biases in the zero baseline case because most other errors will cancel and the hardware biases will be the dominant error.  In this case, I have significantly reduced the initial variance setting from the original value of 1.0 to 1E-7 and increased the process noise from 1E-6 to 1E-3.

I have run the solution several times with the initial bias value set to different numbers between -.05 and 0.06.  Here are the results for both L1 and L2.

biases1

The convergence occurs just after first fix is achieved.  If a fix is not achieved, then the state will not converge as you can see above for the 0.06 example.   In this case, the initial value was too far from the correct value and prevented getting a fix.  As you can see, all the other cases converged towards a single value around -.022, both for L1 and for L2.

Another way to visualize the error in the initial value is to look at the GLONASS residuals after first fix is achieved.  The plot below shows the GLONASS L1 carrier phase residuals  for different initial values, for 0.03 on the left, -0.05 in the middle, and what I believe is the correct value for this receiver combination of -.022 on the right.

 

acal1

Here are the same plots for the L2 carrier phase residuals.

acal2

Through a slightly tedious process, I am fairly easily able to iterate the residuals down to near zero for different pairs of receivers in my possession.  Note that this gives me the relative difference in biases for each receiver pair, and not absolute values for each receiver, unlike Wanniger’s table which is for absolute biases.

Extending the table to receivers used in nearby CORS stations is a little more challenging because the initial bias value needs to be fairly close to get a first fix and hence a convergence, but still possible if the base station is not too distant.   I found data sets that included CORS data from Leica, Novatel, Trimble, and Septentrio receivers.  Using the above procedure to iterate the residuals down to near zero, I was then able to extend my table and make the values absolute by choosing the unknown offset to make my bias pairs align with Wanninger’s table.  This is the resulting table I created.

ComNav    =   2.3 cm
Leica          =   2.3 cm
Novatel      =  2.3 cm
Septentrio = -0.3 cm
SwiftNav   = -0.2 cm
Tersus        = -0.1 cm
Trimble      = -0.7 cm
u-blox         = -3.2 cm 

To generate an initial value for the bias state from this table for an RTKLIB solution, subtract the base station bias from the rover bias, then divide by 100 to convert from centimeters to meters.  This value can then be used to set the “pos2-arthres2” config parameter in the config file.  For the RTKPOST and RTKNAVI GUI option menus I have labeled this “Glo HW Bias”.

To test this code on an independent set of data after generating the table, I used a data set recently sent to me by a reader.  It consists of a u-blox  M8T receiver for rover and Leica receiver just a few kilometers away for base, and was collected in Europe.  The rover position was static but I ran the solution in kinematic mode to make the solution a little more challenging and to make any errors in the solution more visible.

To generate the correct config value for RTKLIB I  subtracted the Leica bias of 2.3 cm from the above table from the u-blox bias of -3.2 cm to get a relative bias between receivers of -5.5 cm or -0.055 m.  I added “pos2-arthres2=-0.055” to the config file and then ran the solution four times, with pos2-gloarmode set to “off”,”fix-and-hold”,”autocal”, and “on”.  Although I left the bias value set for all runs it is ignored unless gloarmode is set to autocal.

Here are the times to first fix, the number of satellite pairs used for the initial fix, and the number of satellite pairs being used for fix after 10 minutes.

  Time to # sat pairs used # sat pairs used for
GLO AR mode first fix for initial fix fix after 10 min
OFF 4:10 7 7
Fix&Hold 4:10 7 11
Autocal 1:05 14 14
On 6:47 14 14

As you would expect, the time to first fix for gloarmode=”off” was the same as “fix-and-hold” since “fix-and-hold” does not use the GLONASS satellites for initial fix.  After 10 minutes it was still only including four of the GLONASS satellites in the ambiguity resolution which was a little unusual, typically I would have expected more GLONASS satellites to be included.

With gloarmode=”autocal”, the time to first fix was reduced from 250 seconds to 65 seconds and the number of satellites included in the first fix increased from 7 to 14., both significant improvements.

The most surprising thing in this data is that when gloarmode was set to “on” it acquired a fix at all.  In many similar cases it will never get a fix.  The GLONASS carrier phase residuals after initial fix were very high though as can be seen below.  The left plot is with gloarmode set to “on”, and the right plot is with it set to “autocal”.

biases3

The ambiguity resolution ratio was also much higher when autocal was enabled as can be seen below (yellow/green=autocal, olive/blue=on) which improves robustness.

biases2

The large residuals did not affect the solution position, as the two solution did not differ by more than 2 mm at any time.  The autocal solution however is much more robust in the sense that it is less likely to lose fix.

Although I have found the results with autocal enabled are generally excellent with relatively short baselines (<10 km), I have found the results less encouraging for longer baselines (>25 km).  In these case I have found that I often get better results with pos-gloarmode set to “fix-and-hold” then I do with “autocal”.  I don’t understand exactly why this is, but suspect that the fix-and-hold correction is more general and may be correcting for more than just the GLONASS hardware biases.

The code changes for this feature are included both in my Github repository and in the newest (demo5 b29c) executables available to download from the rtkexplorer website.   If you choose to experiment with this feature, please let me know if you find any errors in my table, or can add values for any additional receivers.

[Note 6/17/18:  I had a issue with uploading the executables to the website.   If you downloaded them prior to 6/17/18, please download again to get the updated version.] 

Improved results with the ComNav K708 receiver

In a recent post, I compared a pair of ublox M8T single frequency receivers to a pair of ComNav K708 dual frequency receivers.  For static rovers, the more expensive ComNav receivers showed a definite advantage with much faster times to first fix.  I was less impressed however with the ComNav results for a moving rover, especially since I have read several very positive reviews of the ComNav K501G receiver.  The K708 is supposed to be a newer model that is similar in capability and price to the K501G.

My comparisons of the internal ComNav real-time solution to an M8T RTKNAVI real-time solution showed very little difference between the two.  Digging into the data a little deeper, the results were actually more disappointing.  If I cut off the beginning and end of the data where the rover wasn’t actually moving, then the comparison between the two solutions looked like this, with the ComNav receivers on the left and the M8T receivers on the right.

k708_1Fix percentage for the ComNav receivers was 73.3% and for the M8T receivers it was 84.5%.  Comparing the two solutions where they were both fixed showed very little difference between the two so I think they were roughly equivalent in accuracy where they had a fix but the single frequency M8T solution was fixed a higher percent of the time.

I sent the results to ComNav and asked if they had any feedback or suggestions.  I got a very detailed answer in reply and a new firmware to try.  My receivers were running firmware version 3.5.7 and they had apparently also seen similar issues with this code.  They sent me firmware version 3.6.5 in a Windows executable form that made it very easy to upload to the receivers.

I then re-ran a repeat of the previous experiment comparing the two receiver pairs with a moving vehicle, shared antennas, and short baseline.  I was very pleased to see that the ComNav results were significantly better this time!  I actually had to deviate from my normal testing route to find some more challenging roads since I was getting near 100% fix rate on both the real-time internal ComNav solution and a RTKNAVI M8T real-time solution.  Fortunately I was able to find some narrower streets with larger trees that was able to differentiate the two solutions.  Here are both solutions for the full route, ComNav on the left, and M8T on the right.  The M8T solution was similar to the previous run with a 87.8% fix rate but the ComNav fix rate jumped to from 73.3% to 95.8%.

k708_2

Focusing on the more challenging part of the route showed an even bigger difference with the ComNav fix rate at 90.0% (left) and the M8T fix rate at 61.1% (right)

k708_3

Comparing the two solutions for the fixed points showed a good match everywhere outside of the most challenging area, so I don’t believe there were any significant false fixes in that part of either solution.  In the more challenging section there were a couple of what looked like false fixes in the M8T data, the longest one lasted for about 6 seconds.  They are visible as the shorter green blips on the right plot in the U-D axis.

Here’s a couple spots from Google map images that show what the more challenging environment looked like.  Of course, the leaves are off the deciduous trees now so it is a little less challenging now than when these pictures were taken.  I am surprised though that the differences between summer and winter are not as great as I would have expected.

k708_7k708_6

 

 

 

 

 

 

 

Post-processing the M8T data using combined mode (running the kalman filter forward and backward over the data) does help some.  Running a post-processed solution this way increased the overall fix rate from 73.3% to 86.9% and eliminated any false fixes over 1 second.   Better, but still not as good as the ComNav solution.

Here is the difference between the real-time ComNav internal solution, and the RTKLIB post-processed M8T solution for the fixed points.  This is the combined error of the two solutions, so the error in each individual solution will be less than this.  The two solutions are quite independent given that they were computed with different software, measured with different receivers, and used different sets of satellites (GPS/GLO L1+L2 vs GPS/GLO/GAL/SBAS L1).    The E-W and N-S errors look quite small, the U-D error is a little bit larger than I would like to see, but it is difficult to know if this error is equally spread out between the two solutions or dominated by one solution.

k708_6

I am not used to seeing this type of low frequency error in the U-D axis.  If I compare the U-D axis between the post-processed M8T and ComNav solutions (different receivers/different satellite sets) , I do not see this slow drift of +/-0.1 meters.  I’ve plotted it below. This makes me a little suspicious that it is coming from the ComNav solution but it is far from convincing proof.

(Note 2/26/18:  It turns out that this difference in the U-D axis is because the ComNav solution uses geodetic height and the RTKLIB solution in this case was set for ellipsoidal height.  The mean difference between geodetic height and ellipsoidal height cancelled out because the base location was specified in ellipsoidal height but the variation between the two still appears as error between the two solutions)

k708_7

To process the ComNav raw observations with RTKLIB I had to make the same edits to the headers of the observation files that I described in my previous post.  This is to prevent RTKLIB from throwing away the L2C data.  After making these edits and running a combined solution on the data, I get this solution.

k708_5

Unfortunately, with only 68.5% fix rate, this is not nearly as good as the ComNav internal solution.  I hope to investigate this further to see if there are any improvements to the config settings or to the code that might help.  For now, though, I would not recommend using RTKLIB to post-process raw ComNav data, at least for more challenging data sets like this.

However, if you can work with the real-time solution, then I will say that this was a significant milestone in that it was the first moving rover experiment where I have compared a low-cost dual frequency receiver to an M8T and found the dual frequency receiver to be significantly better!

I believe that ComNav sells software for post-processing their data so that might be an option as well for those that don’t want the limitations of real-time data processing.

That’s it for the general analysis.  For anyone interested in the details of the experiment setup I should mention a couple things.   I did describe the setup in more detail in my previous post and for most part the setup here was the same.  However, this time, I did change the default dynamics mode from “foot” to “land” using the command “rtkdynamics land”  This is intended for land vehicles with speeds up to 110 km/hr and seemed more appropriate for my experiment.  The manual says this setting is only for advanced users and recommends most users leave it at the default setting of “air” but my receivers seemed to default to “foot”.   Also, the command I used previously to set the rtk quality level, “rtkquality normal” has been changed in the new firmware to “rtkqualitylevel normal”.  This change has not made it to the user manual yet.   ComNav recommends leaving this set to “quick” for moving rovers and only using “normal” if needed to avoid false fixes for static rovers.  For this experiment I left it set to “normal”, mostly because I forgot about it before running the experiment.

The new firmware is not yet available on the ComNav website but they tell me it will be available soon.  In the meantime, you can email them to request it.

 

 

 

 

 

 

Using SBAS satellites with RTKLIB

I’ve had a few SBAS related questions and issues crop up recently so I thought it would make a good topic for a post.  There are a few tips and tricks to using the SBAS satellites in RTKLIB solutions.   I will try to cover the ones I know about here.

SBAS is short for “Satellite Based Augmentation Systems”.  For anyone not familiar with the details, there is a good description of them at Navipedia.  Different parts of the world use different SBAS systems.  In this post I will focus on the WAAS system over North America and the EGNOS system over Europe but the basic ideas should apply to any SBAS system.

First of all, it’s important to understand that the SBAS satellites can be used by RTKLIB in two fundamentally different ways.  One is to use the correction information transmitted by the SBAS satellites to reduce ephemeris, clock, and atmospheric errors.   The other is to use the pseudorange and carrier phase observations from the SBAS satellites as additional measurements.

The correction information is contained in encoded messages from the SBAS satellites.  These messages can be translated from the raw receiver binary file into an *.sbs file using RTKCONV or CONVBIN if working with post-processed solutions or they are available in the raw binary receiver output if working with real-time solutions.  The pseudorange and carrier phase observations are generated for the SBAS satellites from the raw signals just as they are for the other satellites.

Usually in RTKLIB, at least for short baseline RTK solutions, the ephemeris, clock, and atmospheric data come from the broadcast messages provided by the non-SBAS satellites.  The solution sources for this information is selected in RTKLIB with the “pos1-sateph”,  “pos1-ionoopt” and “pos1-tropopt” input parameters.  If “sbas” is chosen for any of these options, then RTKLIB must have access to the SBAS messages.  For post-processing this means that the *.sbs file must be specified in the command line or configuration settings, for real-time solutions it should be available if the receiver is locked to the SBAS satellites and outputting the SBAS messages.

For short baselines, differencing will eliminate most of the errors and there will be little or no advantage to including the SBAS corrections to the broadcast data.  For longer baselines, error cancellation will not be as complete, and there will be an advantage in using the SBAS corrections to directly remove the errors.  However, for the most part, SBAS provides corrections for the GPS satellites only, not for any of the other constellations.  In addition, RTKLIB will not allow use of a mix of corrected and uncorrected observations.  This means that enabling SBAS ephemeris corrections will cause the solution to ignore all non-GPS satellites, usually resulting in a poorer solution, not a better one.

As a general practice, it is always a good idea to look at the measurement residuals with RTKPLOT to quickly verify which satellites were used in a solution and more important, which were not.  The residuals information is in the “out.pos.stat” file.  If you don’t see the “Residuals” option in RTKPLOT or don’t have this file in your output directory then that most likely means that you did not have residuals enabled in your output options.  In this case, another way to verify you did not lose any satellites is to compare RTKPLOT plots of the “number of valid satellites” before and after enabling one of the SBAS options.  By the way, this problem also occurs when using precise ephemeris data downloaded from IGS or other online sources if it does not include data for all of the constellations used in the solution.

I don’t know exactly why RTKLIB doesn’t allow a mix of corrected and uncorrected observations but I suspect that biases between the corrected and uncorrected observations may degrade the solution.

Since I always include all available constellations in my solutions and tend to work with short baselines I have generally not found the SBAS corrections to be particularly useful.  The one exception is for RTKLIB PPP solutions where precise data is very important and SBAS is an easy way to get relatively precise information, especially if internet access is not available (Thanks to JB for pointing this out in a comment to one of my recent posts).

The other way to use the SBAS satellites in RTKLIB solutions is to include their pseudorange and carrier phase measurements in the solution in the same way they are used for the non-SBAS satellites.  The SBAS observations may not be quite as accurate as the other satellites but this is taken into account by the weighting factors RTKLIB uses for measurements from different constellations.  The extra measurements will increase the robustness of the solution, particularly in the case of a moving rover where many satellites may be unusable due to cycle slips.  To enable the SBAS observations to be included in the solution, check the SBAS box in RTKPOST or set bit1 in the “pos1=navsys” input parameter.  I almost always enable this option in my solutions and would recommend others do the same if possible.

This works for the SBAS satellites over North America (WAAS) but unfortunately does not work for the SBAS satellites over Europe (EGNOS).  The EGNOS satellites are marked as unhealthy in their ephemeris data and so RTKLIB ignores them.  In theory, a solution containing EGNOS observations should be identical with SBAS satellites enabled or disabled since RTKLIB is supposed to ignore the unhealthy satellites.  Unfortunately this is not quite true, and RTKLIB does not entirely ignore them.  I think this is a bug rather than a feature but have not looked into the details.  Specifically though, I see that the unhealthy satellites affect the initial phase bias estimates of all the other satellites.  Whenever I find bugs like this, I am always concerned that they are something I have introduced into the demo5 code with my changes, so I always rerun the solution with the 2.4.3 release code.  In this case, I see the same bug (but worse) in the release code.  Here is a comparison of the difference between two solutions for a data set that includes EGNOS observations, one with SBAS enabled, and one with it disabled.   The left plot is for the 2.4.3 release code and the right plot is the demo5 code.  Only GPS satellites are enabled and ambiguity resolution is disabled in both cases to simplify the comparison.

egnosErr

In both cases, enabling the EGNOS satellites caused a transient at 13:06 but as you can see the transient is much larger in the release code.  Both are undesirable though and it is important to turn off SBAS observations in the solution if your receivers are tracking EGNOS satellites no matter which code you are using.  In this particular example, even with the smaller transients in the demo5 code, they were large enough to cause a false fix when ambiguity resolution was enabled.

Since I am located in the U.S. I don’t work much with EGNOS observations but I was curious to understand why they are not usable.  Doing a little research online, I found multiple references to using ranging observations from EGNOS satellites.  Some said it was not possible to use them and others said that if you ignore the unhealthy flag they will work fine.

It turns out that RTKLIB has an option to force unhealthy satellites to be used in the solution.  It is not exactly intuitive, as you force a satellite to be included by putting it in the list of excluded satellites with a”+” in front of the satellite number, but this is documented in the user manual.

The data set above had observations from only one EGNOS satellite but the SBAS satellites are differenced with the GPS satellites so this shouldn’t be an issue.  I went ahead and forced this satellite to be included and re-ran the solution.  Here is the result.  This time I plotted both solutions on top of each other, one in which SBAS observations are disabled (yellow), and one in which they are enabled and forced to be used (green).egnosErr2

Clearly in this case, forcing use of the EGNOS observations made things significantly worse.  Apparently using them requires a little more than just ignoring the unhealthy flag but I don’t know any more than this.  If anyone has successfully included the EGNOS observations in their solutions, I would be curious to know more about how you did it.

That’s about it for tips and tricks I can think of related to SBAS.  If anyone has other tips, or can answer any of my unanswered questions above, or can provide information on some of the SBAS systems I didn’t mention, please leave a comment.

 

 

 

 

 

Initial look at the ComNav K708 receiver

ComNav was kind enough to recently lend me two of their K708 receivers for evaluation.   I also have a Tersus BX306 receiver that was given to me earlier by Tersus for evaluation.  Both of these are relatively low-cost dual frequency receivers that offer full GPS L2 support., unlike the SwiftNav receiver I evaluated in my previous posts which is GPS L2C only.  I have described the Tersus BX306 before in a previous post but last time I was not able to evaluate it with a local base since I did not have a second dual frequency receiver that supported L2.  Tersus has also just recently released their new V1_19 firmware so I included that in this evaluation.   As usual I’ve also included  a pair of u-blox M8T receivers to use as a baseline.

Here’s a photo that shows the three receivers each with their associated serial port and power cabling.  The u-blox M8T is on the left, Tersus BX306 in the center, and ComNav K708 on the right.  The ComNav receiver is actually only the smaller daughter board in the center of the larger board, everything else is part of the very sturdy but rather clunky dev kit.

rcvrs3

The Tersus BX306 is priced at $1699 but lower priced versions are available. For example, the BX305 supports GPS L1/L2 but Glonass G1 only, and the BX316R is GPS L1/L2 and Glonass G1/G2 but provides only raw observations for post-processing.  Both of these options are priced at $999.

The ComNav K708 is similar to the better known K501G but newer and more capable.  ComNav doesn’t list their prices on their website but they have told me that both the K501G and the K708 configured to be equivalent to the K501G (GPS L1/L2 and GLO G1/G2) are available for less than $1000.

Both the Tersus and the ComNav receivers come with GUI console apps which are good for initially getting familiar with the receivers.  However each had their unique quirks and I found myself fairly quickly abandoning them for the more familiar quirks of the RTKLIB apps.  Managing three simultaneous real-time solutions involving five separate receivers while also logging raw observations for all five was actually quite challenging and I made a couple of unsuccessful runs before I got everything working at the same time.

I found that the key to turning this into a manageable and automated process was replacing each of the different manufacturer’s GUIs with an RTKLIB stream server (STRSVR) and a plotter (RTKPLOT) each with it’s own dedicated .ini file.  Eliminating the GUIs also gave me a better understanding of exactly what the receivers were doing and what the GUIs were doing.

STRSVR provides a standardized, always visible red/yellow/green indicator for each stream along with a continuously updated bps number that indicates not only that the connection is alive, but that data is flowing.  This allowed me to tell at a glance that all streams were flowing and that all the log files were being updated.  Using the “-t” option in the command line to specify a title for each window also helped keep things straight.

Both receivers are configured by sending Novatel-like ASCII commands over the serial port and these can be added to the STRSVR Serial “Cmd” window and saved to a “.cmd” file, similar to configuring the u-blox receiver.  Notice in this example, I also sent a reset to the receiver every three minutes which was a convenient way to automate the testing of acquisition times.

strsvr1

I connected both dual frequency rover receivers to my laptop, using two COM ports for each one and using a USB hub to get enough ports.  I set up both receivers to output NMEA solution messages and raw RTCM observation messages on COM1 at 5 Hz and accept RTCM base station data on COM2.  Both receivers have decent reference manuals to describe their command set but I also found this Hackers Guide to the K501G from Deep South Robotics quite useful for getting started.

For reference, here are the commands I used to configure the Tersus rover:

fix none
unlogall
log com1 gpgga ontime 1 nohold
rtkcommand reset
log com1 gpgga ontime 0.2

log com1 rtcm1004 ontime 0.2
log com1 rtcm1012 ontime 0.2
log com1 rtcm1019 ontime 1
log com1 rtcm1020 ontime 1
interfacemode com2 auto auto on

saveconfig

and here are the commands I used for the ComNav rover:

interfacemode compass compass on
unlogall com1
fix none
refautosetup off
set cpufreq 624
rtkobsmode 0
rtkquality normal
set pvtfreq 5
set rtkfreq 5
log com1 gpgga ontime 0.2 0 nohold
log com1 gprmc ontime 2 0 nohold
log com1 rtcm1005b ontime 10
log com1 rtcm1004b ontime 0.2
log com1 rtcm1012b ontime 0.2
log com1 rtcm1019b ontime 2
log com1 rtcm1020b ontime 2
interfacemode com2 auto auto on

saveconfig

My intent was to setup the receivers in default RTK mode with a 5 Hz output for NMEA solution messages and RTCM raw observation and navigation messages.  The one exception to default was that I found the “rtkquality” setting on the ComNav receiver defaulted to “quick” which was giving me false fixes, so I changed this to “normal” and that seemed to fix the problem.

By setting things up this way, I only need to click on the correct combination of icons (each tied to it’s own .ini file) from my RTKLIB menu to bring up the correct windows and a few more clicks to start the streams in a simple and repeatable way.

dualFreq3

I’m jumping ahead a little bit, but here is a screen capture of the rover-connected laptop streaming two NTRIP sets of base station data to the rovers while simultaneously logging and plotting the computed solutions for all three rovers along with raw observations for all five receivers,  and also computing an RTK solution for the M8T receivers with RTKNAVI.

Capture3

I should mention that there was one very annoying bug that was introduced to STRSVR in one of the recent RTKLIB releases that gives an error if a data file already exists instead of an overwrite dialog but I did fix this and add it to a new demo5 b29b code release available at the download page on rtkexplorer.com.  The new release also includes a fix for another bug that prevented the “-i” command line option to specify a config file for RTKPLOT from working properly.

I then setup the second ComNav receiver as a base station for both dual frequency rovers and used a single COM port to stream RTCM messages from the receiver to a PC.  I used an STRSVR window on the PC to stream the messages to a NTRIP caster using the free RTK2GO NTRIP caster service as I have previously described.  I used ComNav AT330 antennas for both the base and rovers with the rover antenna shared by all three rover receivers.   I did not have enough connector hardware to share the base antenna so used a separate u-blox antenna for the M8T base receiver.

The next step was to collect some data.  I started with a relatively simple challenge, a static rover with a reasonably open sky view and a short baseline.  The ComNav and Tersus solutions both assume the rover may be moving so I set up the M8T solution as kinematic as well.

Let’s first look first at the ComNav solution compared to the M8T solution.  Both solutions were computed real-time.  RTKPLOT will plot NMEA data but it did not seem to like the mix of NMEA and RTCM data in the same file.  To deal with this, I wrote a simple matlab script to strip the NMEA messages from the log file and put them in a separate file.  Below I have plotted only the Up/Down axis for both receivers just to avoid too much data,  the M8T is on top, and the ComNav below.  Each of the larger breaks in the fix was caused by me disconnecting then reconnecting the antenna to force a re-acquire.

comnav1

The M8T configuration was identical in the left and right plots, but the ComNav “rtkquality” parameter was set to “quick” in the left plot, and “normal” in the right plot.  It’s not as obvious here as it is in the other axes but the third ComNav fix in the left plot is a false fix and had over 0.2 meters of error in the N/S axis.  Changing the “rtkquality” parameter to “normal” seemed to help and I did not notice any more false fixes after making that change.

The ComNav receiver typically achieved a fix very quickly regardless of the “rtkquality” setting, usually in less than 30 sec although in one case it took a minute and a half.  This was noticeably faster than the M8T receiver, which took from 1 to 3 minutes each time in this example to achieve a first fix.

The scales are the same in the two sets of plots, so as you can see, the ComNav fixes are a fair bit noisier than the M8T fixes.  I don’t know why this is but it is something that I hope to investigate more.

Unfortunately I got a mix of good and not so good results from the Tersus receiver.   I did not see this behavior in my previous evaluation so I’m fairly certain this is not a problem with the hardware.  I suspect it has something to do either with my setup or with the new firmware.  I am going to hold off on sharing any of the Tersus data until I understand better what is going on.

Next, for a more challenging test, I moved the rover antenna to a spot with fairly poor sky views located between several large trees.  The sky view directly above the antenna was clear but a large percent of the overall view was blocked.   Again, I just plotted the Up/Down axis with the M8T position solution on the top and the ComNav solution on the bottom.

comnav2

I disconnected and reconnected the antenna three times in this experiment.  The M8T did not get a fix in the first try before I gave up after 12 minutes, but it did after 13 and 11 minutes in the second two tries after briefly getting a false fix in the second try.  Definitely marginal conditions for the M8T.  The ComNav receiver did significantly better with two fixes in less than 3 minutes and one in 9 minutes.  The errors were relatively large in the first fix but based on the other two axes it was not a false fix.  You can also see that the ComNav third fix was noticeably noisier than any of the other fixes on either receiver, again for unknown reasons.

For the third part of the experiment I moved the receivers into my car and attached the antenna to the roof and collected data for three spins around the neighborhood.  The results are plotted below.  In each case the M8T real-time solution is on the left, and the ComNav is on the right.  In the data in the first row, I shared a single antenna for all three receivers.  For the data in the second and third row I used separate antennas.  I did not change any of the config settings for any of the receivers between these runs and the above runs except that the rtkquality setting was still set to “quick” for the ComNav receiver for the second and third rows.

 

 

 

comnav5

 

comnav6

comnav7

I have not had a chance to look at this data closely but at first glance, from a fix percentage perspective only, I don’t see significant differences between either of the receivers.  The obvious advantages the ComNav receiver demonstrated in faster fixes in the static tests did not seem to carry over to the moving rover case.  I do plan to look at the raw data more carefully to see if I can understand better why this is.  For whatever reason, the Tersus receiver seemed to perform better with a moving rover than it did with a static rover, and was very similar in fix percentage to the other two receivers in this part of the experiment.

Next I planned to post-process the raw data through RTKLIB to better understand what is going on but as usual, nothing is as simple as you hope for, and I ran into another issue.

Both the Tersus and the ComNav receiver report a mix of 2W and 2X  measurements for the raw GPS L2 measurements.  If the satellite supports the newer L2C code it locks to that and reports a 2X code, if not, it locks to the older L2  and reports a 2W code.   You can see this in this example observation epoch from the Rinex conversion of the ComNav receiver RTCM output.  The left three columns are the L1 measurements, the middle three columns are the L2 (2W) measurements and the right three columns are the L2C (2X) measurements.  You can see that all the GLONASS satellites report L2 measurements only but that the GPS satellites are a mix of L2 and L2C measurements.

comnav4

This is new for the Tersus receiver, it did not do this when I evaluated it with the older firmware.  For the ComNav receiver, this is the default behavior but it is possible to change this through a command to specify L2 only, no L2C.  As far as I can tell, the Tersus only supports the mixed L2/L2C mode.  All the data I collected for this experiment was in the mixed L2/L2C mode.

Unfortunately RTKLIB does not like this format and throws away all of the L2C measurements.  It is possible to fool RTKLIB into using all the measurements by changing the 2X’s in the “Obs Types” list in the file header to 2W’s but I haven’t looked yet at to what extent mixing the code types affects the solution or how to avoid throwing away the L2C data without editing the header.

I will leave a more detailed analysis of the data to a future post.  My initial impression from these results though, is that although there are some obvious advantages with the ComNav receivers, replacing a pair of low cost single frequency receivers with a pair of low cost dual frequency receivers does not magically make the challenges of precision GNSS go away and that it will still require close attention to the details and recognition of their limits to get good results with either set of receivers.

 

 

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.

 

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.