Comparing the u-blox F9P to the Comnav K803 receiver

In my last post I compared the internal u-blox F9P RTK solution to an RTKLIB demo5 RTK solution for a couple of cases, one with easy and one with moderately challenging conditions. In this post I will extend that comparison to some more difficult conditions, specifically under more dense tree foliage. To make things more interesting I will add a pair of ComNav K803 eval boards to the experiment.

The ComNav K803 is a relatively new module from Comnav that supports triple frequencies, L1, L2 , and L5. It is more expensive than the u-blox F9P at about $1000, but should have higher performance. ComNav generously gave me two of these boards for evaluation purposes.

As far as user interface goes, they are very similar to the older K501G or K708 ComNav boards and I was able to configure the K803 boards using RTKLIB command files very similar to what I previously described for the K708 in this post.

Here is a photo of the ComNav board on the left and the Ardusimple F9P board on the right. The ComNav board is inside a plastic case which is a nice feature. It is supposed to work with just the USB port for power and communication but I did not find this to be reliable and had to fall back to using the RS232 port with USB adapter for communication which is why the photo shows two cables for the K803. ComNav is aware of the issue and hopefully they will sort this out relatively soon.

In my previous experiment, I used a nearby CORS station for the base which limited the solution to GPS L1/L2, GLONASS L1/L2, and Galileo L1 and also extended the baseline to several kilometers . To take full advantage of both receivers available constellations and bands in this experiment, and to minimize the baseline, I used local base receivers for this experiment.

I used two Harxon geodetic GPS-500 antennas, one on the roof as base and one for the rover which was located on a tripod in an area underneath some moderate tree foliage. Both antennas were fed to an antenna splitter and then to an F9P receiver and a ComNav receiver. I tested three locations, each one further under the trees and so more challenging than the previous one. To avoid too much complexity in the experiment, I did not run a real-time RTKLIB solution but logged the F9P and ComNav raw data for post-processing.

Like in the previous experiment, I disconnected the antenna and then reconnected it multiple times to measure the time to first fix (TTFF) for both receivers. The plot below shows only the fixed epoch results for the first two locations. The F9P results are in green, and the ComNav in blue. The constant offset between the two is not real, I accidently configured the ComNav receiver to use a self-surveyed approximate position for the base location instead of an independently determined precise position.

Fix epochs for u-blox F9P (green) and ComNav K308 (blue) for location 1 and 2

In the first and least challenging rover location, both receivers performed well. The average ComNav TTFF was slightly faster, but both were below 20 seconds.

In the second location, both receivers were were still providing usable results but the ComNav receiver started to become noticeably better than the F9P. Average TTFF was 54 seconds for the F9P and 12 seconds for the ComNav receiver. In addition, the F9P had a couple of short false fixes and intermittent float after first fix that were not present in the ComNav data.

Here is the data for the third and most challenging location. Again, the F9P results are green and the ComNav results are blue.

Fix epochs for u-blox F9P (green) and ComNav K308 (blue) for location 3

In this case the differences were quite significant. The ComNav reliably found the same location on each re-acquire but more than 50% of the F9P fix epochs were false fixes, sometimes in error by several meters.

I also ran the RTKLIB demo5 solution with the same config settings as in the previous post. The results are below for the first two locations. The RTKLIB fixed epochs are in green and the ComNav fixed epochs are in blue. The performance at the first (least challenging) location was similar between RTKLIB and the F9P internal solution but the RTKLIB solution struggled with the second location and for the third location did not find any fixes except for a single short false fix. At least in these conditions it looks like there is still some room for improvement in the RTKLIB solution. However, it is also true that it did not get as much false fixes as the F9P solution which is important as well.

Fix epochs for u-blox F9P RTKLIB solution(green) and ComNav K308 (blue) for location 1 and 2

As in my other experiments, this is just a quick comparison of relative performance and is not intended to be any type of in-depth analysis.

To summarize the results, The u-blox F9P is a very capable dual-frequency receiver for easy to moderately challenging conditions, but for the most challenging conditions you will still get better performance from a more expensive receiver.

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.

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.

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.

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

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.

[Note: table updated 3/16/20:]

ComNav               =   2.3 cm
Leica                      =   2.3 cm
Novatel                 =  2.3 cm
Septentrio           = -0.3 cm
Spectra Physics =  0.0 cm
SwiftNav              =  0.0 cm
Tersus                   =  0.0 cm
Topcon                 =  0.0 cm
Trimble                = -0.7 cm
u-blox M8T        = -3.2 cm
u-blox F9P          =  0.0 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”.

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.

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.] 

Using SSR corrections with RTKLIB for PPP solutions

If you have been following recent announcements in precision GNSS, you may have been hearing a lot about SSR (State State Representation).  SwiftNav recently announced their Skylark corrections service, and u-blox announced a partnership with Sapcorda to provide correction service for their upcoming F9 receivers.  Both of these services are based on SSR corrections.

So, what is SSR?  Very briefly, it refers to the form of the corrections.  In traditional RTK with physical base stations or virtual reference stations (VRS), the corrections come in the form of observations in which all of the different error source are lumped together as part of the observation.  This is referred to as OSR (Observation Space Representation).  In SSR corrections, the different error source (satellite clocks,  satellite orbits, satellite signal biases, ionospheric delay, and tropospheric delay) are modeled and distributed separately.  There are many advantages to this form but what seems to be driving industry towards it now is that it allows the current VRS model where each user requires a unique data stream with observations tailored for their location to be replaced with a single universal stream that can be used by all observers.  This is a requirement if the technology is going to be adopted for the mass-market automotive industry for self-driving cars, since it is not practical to provide every car with it’s own data stream.

For more detailed information on SSR, Geo++ has a one page summary here and IGS has an 18 minute video presentation on the topic here.  Both are excellent.

Below is an image I borrowed from the IGS presentation which shows the flexibility of the SSR format.  It is intended to show how the same SSR data stream can be used globally for PPP quality corrections and also regionally for RTK quality corrections but it is also a good visual for understanding the message details I describe below.

The RTCM standards committee is still in the process of finalizing the messages used to send the different correction components.  They have split the work into three phases.  Phase 1 includes the satellite clock, orbit, and code biases.  Phase 2 includes satellite phase biases and vertical ionosphere corrections, and phase 3 includes ionospheric slant corrections and tropospheric corrections.

There are several real-time SSR streams accessible for free today.  Unlike the paid services, they do not contain enough detailed regional atmospheric corrections to use as a replacement for a VRS base but they can easily be used for static PPP solutions.

I used the CLK93 stream from CNES for an experiment to test how well RTKLIB handled the SSR corrections.  It includes the Phase 1 and Phase 2 RTCM messages but not the Phase 3 messages.  Here is the format of the the messages in the CLK93 data stream:

You can register for free access to the CLK93 (and other) streams from any of these locations:

• USA: CDDIS and IGS Central Bureau
• Europe : Bundesamt fuer Kartographie und Geodaesie
• China: The GNSS Research Center, Wuhan University and The ShangHai Astronomical Observatory (SHAO)
• Australia: Geoscience Australia

Unfortunately, RTKLIB currently only supports the Phase 1 RTCM messages and even this is not complete in the release version.  I have gone through the code and made a few changes to make the Phase 1 SSR functional and have checked those changes into the demo5 Github repository.  I also added some code to handle the mixed L2 and L2C observations from the ComNav and Tersus receivers.  After a little more testing I plan to release this code into the demo5 executables, hopefully in the next week or two.

With only phase 1 measurements, the RTKLIB PPP solutions will work much better with dual frequency receivers than with single frequency receivers.  This is because single frequency receivers require ionospheric corrections for longer baselines.  For this reason, I did not bother with collecting any single frequency data.  Instead, I collected both L1/L2C data with a Swiftnav Piksi Multi receiver and L1/L2/L2C data with a ComNav K708 receiver and a Tersus BX306 receiver.

RTKLIB is usually used to calculate PPP solutions without SSR corrections but this requires downloading multiple correction files for orbital errors, clock errors, and code bias errors and it is usually done with post-processing rather than real-time, after the corrections are available.  With SSR, the process is simpler because the solution can be done real-time and there is no need to download any additional files.  It does, however, require access to the internet to receive the real-time SSR data stream from an NTRIP caster.  The solution can be calculated real-time or the SSR corrections and receiver observation streams can be recorded and the solution post-processed.

To enable the use of SSR corrections in RTKLIB, you need to set the “Satellite Ephemeris/Clock (pos1-sateph) input parameter to either “Broadcast+SSR APC” or “Broadcast+SSR CoM”.  Note that CoM stands for Center of Mass and APC for Antenna Phase Center.  They refer to the reference point for the corrections.  The CLK93 corrections are based on antenna phase centers.

To generate my PPP solution I set the solution mode to “PPP-Static”,  ephemeris/clock (pos1-sateph) to “brdc+ssrapc”, ionosphere correction (pos1-ionopt) to “dual-freq”, and troposphere correction (pos1-tropopt) to “est-ztd”.  I also enabled most of the other PPP options including  earth tides,  satellite PCVs, receiver PCVs, phase windup, and eclipse rejection.

RTKLIB PPP solutions don’t support ambiguity resolution so the ambiguity resolution settings are ignored.  I specified the satellite antenna file as “ngs14.atx” which is the standard antenna correction file and is available as part of the demo5 executable package.  I also needed to include the CLK93 data stream as one of the inputs in addition to the receiver observations (and navigation file if post-processing).

I collected a couple hundred hours of observations with the SwiftNav receiver connected to a ComNav AT-330 antenna on my roof with moderately good sky visibility.  I then ran many four hour static solutions over randomly selected data windows.  I also collected a small amount of raw data from a ComNav K708 receiver and a Tersus BX306 receiver.

Below is a typical 12 hour static solution for a SwiftNav and a ComNav receiver.  The SwiftNav solution is in green and the ComNav solution is in purple.  Zero in these plots represents an online PPP solution from CSRS from data collected over a month earlier.  In this particular example, the SwiftNav solution is slightly better but this was not always the case.

 

Here is a shorter data set from a Tersus BX306 receiver.  With the relatively small amount of Tersus and ComNav data I collected, I did not notice any differences in convergence rates or final accuracy between any of the three receivers.

The solutions generally all converged to less than 6 cm of error in each axis after 4 hours with one or two minor exceptions that seemed to involve small anomalies at the day boundary.  Since the RTKLIB PPP solutions don’t include ambiguity resolution they do take longer to converge but the eventual accuracy should be similar.

I’ve uploaded some of the raw observation data for the different receivers and the CLK93 data stream as well as the config file that I used for the solution here.

This seems like a good start and I hope that RTKLIB will support phase 2 and phase 3 corrections in the future.

Post-processing ComNav receiver data with RTKLIB – a more in-depth look

In a couple of my recent posts,  I showed that with the latest firmware from ComNav, the internal RTK solution was very good even for a quite challenging moving rover test, significantly better than a post-processed solution using RTKLIB.   To recap, here are the results side by side, ComNav internal RTK solution on the left, demo5 RTKLIB post-processed solution on the right.  The internal ComNav solution had a 96% fix rate while the RTKLIB solution had only a 68% fix rate.  In the plots below of a drive around the residential streets near my house, green represents a fixed solution and yellow is a float solution.

The RTKLIB solution shown is a forward solution to make it a more direct comparison to the internal solution.  Re-running it as a combined solution helps a little, but still only increased the fix rate to 71%.  Fix rates are only meaningful if the number of false fixes is small, but as I showed previously, the two solutions match quite closely where both are fixed.

Not only is the ComNav RTKLIB solution inferior to the internal ComNav solution, it is also inferior to an RTKLIB solution from a pair of much lower cost single frequency u-blox M8T receivers fed with the same antenna signals as the ComNav receivers.  As I showed in my last post, the RTKLIB M8T solution had an 88% fix rate and again matched the ComNav internal solution very closely when both were fixed.

So why does RTKLIB struggle so much with the ComNav data?  My suspicion is that there is nothing inherently lower quality about the data, it’s just that it’s flaws are different from the flaws of the u-blox data and that RTKLIB, particularly the demo5 version, has evolved to handle the flaws of the u-blox data better than it has for the ComNav data.  Specifically, what I see, is that the u-blox receiver is much better at flagging lower quality observations than ComNav (or other receivers) are.  This puts the burden on the solution code to appropriately handle the lower quality observations, something RTKLIB is not particularly good at.

To test this theory, I ran an experiment with a modified version of RTKLIB.  Usually I like to use the demo5 code for my experiments since it’s available to everyone, but for this exercise I used some experimental code I have been working on for a while now that helps RTKLIB to handle a wider range of measurement quality.  This code doesn’t do anything fundamentally different from the current demo5 version of RTKLIB.  No wide-lane or ionospheric-free linear combinations or any other tricks that are only available with dual frequency measurements.  All it does different is a better job of rejecting or de-weighting lower quality measurements and a more comprehensive search of the integer ambiguity space to find a clean set of ambiguities to use for a fix.

My thinking is that if RTKLIB code with just these changes can match the internal ComNav solution then that would give me confidence that the core mathematical algorithms in RTKLIB are fundamentally sound and capable of handling dual frequency solutions.   If not, then maybe RTKLIB requires some more significant changes to the solution algorithms to take better advantage of the dual frequency measurements.

When I started working with RTKLIB a couple of years ago I found similar performance issues when processing u-blox solutions, and found that relatively minor code changes could made a big difference.  RTKLIB is a fantastic resource but sometimes it is more of an academic toolbox than a true engineering solution.  This is not surprising or unexpected, given that the developers are in fact using it for academic research.

So how did the modified code work?  Here’s a forward solution with the modified RTKLIB code on the left and the difference between this solution and the ComNav internal solution on the right.  The 16.27 meter difference in the vertical axis is due to different handling of the offset between geoid and ellipsoid as I described in my last post.

You can see a big improvement.  The fix rate has increased from 68% to 99% and the vast majority of the differences between the two solutions are still less than 2 cm in the horizontal axes and 4 cm in the vertical axis.  Again, these are combined errors of both solutions, so I consider these numbers quite good.

Of course, the code improvements will affect the M8T single frequency solution too, so I also re-ran that solution to complete the comparison.  And just to make things a little more interesting, I also re-ran the ComNav solution with the modified code using only the L1 observations.  I did this to try and separate how much benefit is coming from the higher cost receiver in general and how much is coming from the L2 measurements specifically.

Here’s the M8T solution on the left with a  94.4% fix rate, and the Comnav L1-only solution on the right with a 98.9% fix rate.  The most challenging measurement environment was in the older neighborhood with larger trees that shows up as the small squares in the far left.  You can see that the ComNav L1 solution is noticeably better than the u-blox M8T solution in this area.

The two receivers did not start collecting data at exactly the same time so I did not include the time to first fix in this comparison.  If I remove that from the ComNav L1/L2 solution above, that increases the fix rate in that solution from 99.0% to 99.1%, slightly better than the 98.9% achieved by the L1 only solution.  The differences in both solutions relative to the internal ComNav solution appeared similar to the errors plotted above for the RTKLIB L1/L2 solution.

So, switching from the u-blox receiver to the ComNav receiver but using only L1 for both solutions improved the fix rate from 94.4% to 98.9% .  Adding L2 to the ComNav solution then increased the fix rate from 98.9% to 99.1%.

This data set is the most challenging I’ve run to date, and so I consider all of these results as quite good.  To provide some level of calibration, here are the observations for the ComNav rover.  You can see there are a significant number of cycle slips and missing data.  There are even more in the M8T observations, but the M8T data does include the Galileo and SBAS satellites as well.

I’ve covered several different results very quickly, so here is a quick summary of all the experiments.

ComNav internal solution:                              Fix rate = 96%
ComNav demo5 RTKLIB L1/L2 solution:      Fix rate = 68%
M8T demo5 RTKLIB L1 solution:                   Fix rate = 88%

ComNav modified RTKLIB L1/L2 solution:  Fix rate=99.1%
ComNav modified RTKLIB L1 solution:        Fix rate=98.9%
M8T modified RTKLIB L1 solution:               Fix rate=94.4%

So what can you conclude from this experiment?  This is what I get from it:

1) The existing core RTKLIB  algorithms are capable of high quality dual frequency solutions if the flaws in the observations are properly handled.

2) The current demo5 RTKLIB code is better matched to the M8T observations, so the opportunity for improvement is smaller than it is for the ComNav observations but there is still some opportunity even with the M8T.

3) A significant fraction of the improvement in the ability to maintain a fix on a moving rover between M8T and ComNav is likely not because of the additional L2 measurements, but simply because the overall quality of the more expensive receiver is higher.  The dual frequency measurements likely have a more significant advantage when it comes to faster first fixes and longer baselines.

The code is experimental only at this point and needs more work before it is ready for release but I do hope to make some form of it available eventually.

Further comparison between ComNav and u-blox RTK solutions

In my last post I showed that the new 3.6.5 ComNav firmware greatly improved the internal ComNav real-time RTK solution.  However there was still a significant discrepancy n the U-D axis results between the ComNav solution and an RTKLIB/M8T solution. Here are the differences between the ComNav internal solution and an RTKLIB solution for two u-blox M8T receivers connected to the same antennas as the ComNav receivers.  In this experiment, the base station was an antenna mounted on my roof and the rover was an antenna mounted on top of my car while driving around a residential neighborhood.

As you can see, the vast majority of the measurements in the horizontal axes (E-W and N-S) differ by less than two centimeters.  This represents the combined error of both solutions, the error in either solution by itself is smaller, so I consider this a good match.  In the U-D axis though, the two solutions often differ by over 10 cm.  The vertical errors will generally be roughly double the horizontal errors, but they should not be this large, so this warrants further investigation.

In the above plot, the errors are plotted as a function of time, and in this perspective, the errors appear to be a random drift.  I noticed however that the largest errors seemed to occur when the rover was most distant from the base, so I plotted the U-D error as a function of distance to base instead of time.  This is what it looks like plotted this way.

Clearly, there is a very strong linear relationship between baseline and error.   This immediately made me suspect an issue with coordinate systems.

I had previously seen a somewhat similar problem in the vertical axis when I had collected data from a sailboat and found that one side of the lake was nearly a meter higher than the other side!  In this case the issue was simply that the plots were in ENU coordinates which represent a plane tangential to the surface of the earth rather than a surface that followed the curvature of the earth.  The surface of the lake of course follows the curvature of the earth so will not appear as equal height when plotted on a flat plane.  With a local base station, the differences between the two tend to be small, but in my case I was using a fairly distant base which magnified the difference.

However, in this case, both solutions were saved in LLH coordinates, and although converted to ENU coordinates by RTKPLOT, any effect from the coordinate transformation should be equal for both solutions.   So that’s not the answer.

After a little digging into the ComNav documentation I found that it reports solution heights in geodetic height, not ellispodial height.  This means they are relative to a geoid model of the earth, rather than a simpler ellipsoid model.   The geoid model approximates a surface with equal gravitational force at all points.  The ellipsoidal model, on the other hand, is simply an ellipsoid that approximates the shape of the earth.  Of course, it would be too simple if there were only one ellipsoid model and one geoid model, and in fact there are multiple different versions of both types of models.  Fortunately RTKLIB and ComNav both default to using the WGS84 ellipsoid and the EGM96 geoid, so this simplifies things at least a little bit.

In RTKLIB, the solution height can be chosen to be outputted in either ellipsoidal or geodetic height using the “out-height” config parameter.  I usually set it to ellipsoidal height and that was what it was set to for this experiment, so this is at least part of the answer.  However, the geoid model and the ellipsoidal model differ by about 16.27 meters in my location, while the two solutions only differed by about 0.1 meters , so the explanation is a little more complicated than just changing this setting.

But first let’s start by doing that.  Here is the difference in U-D measurements after recalculating the RTKLIB solution with the “out-height” config parameter set to “geodetic”.

Interesting, with both solutions calculated in geodetic mode, the time varying error has disappeared completely, but now the DC offset between the two models (16.27 meters) has appeared instead!

This appears to be caused by how the two solutions interpret the base station location.  It seems that RTKLIB is interpreting the base station height as ellipsoidal regardless of the output format of the solution.  This seems reasonable, otherwise you would have to change the base station location when you changed the format of the solution.  ComNav, on the other hand, looks like it always interprets the base station height as geodetic, which isn’t wrong either, as long as you are aware of it.  I can eliminate the difference between the solutions either by specifying the ComNav base station location with geodetic height or, alternatively, the ComNav “UNDULATION” command does have a parameter to specify an offset to the geodetic model which probably would work as well.

So, with this change, I now have a very good match between two quite independent solutions.  The first solution is using ComNav receiver hardware and ComNav solution algorithms with GPS and GLONASS satellites using the L1 and L2 measurements.  The second solution is using u-blox M8T receiver hardware and RTKLIB solution algorithms with GPS, GLONASS, Galileo, and SBAS satellites using only the L1 measurements.   Although it is not impossible that there is some systematic error that affects both solutions, I do find it quite encouraging to see such good matches between two solutions with so many differences in inputs.

If you are interested in reading a more detailed discussion of the challenges of using geoid models in GNSS solutions as well as links to discussions of similar challenges with horizontal coordinate systems, see this article.

 

 

 

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.

Fix 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%.

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)

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.

 

 

 

 

 

 

 

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.

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)

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.

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 RTKLIB to process ComNav receiver data

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.

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.

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.

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.

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.

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.

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.

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.

 

 

 

 

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.

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.