Measuring a survey marker with the DataGNSS D302-RTK

 

In my last post I reviewed the D302-RTK receiver from DataGNSS.

datagnss1

Since the unit is designed for surveying, I thought it would be fun to use it to actually try and measure an actual survey marker, something I’ve never done before.

So, to find an official marker I went to the NGSDataExplorer website from the U.S. National Geodetic Survey group and brought up an easy-to-use interactive map of the local area with different types of survey markers marked.   Here’s a zoom in of the map showing a nearby marker I found with easy access and a decent sky view.

survey3

Clicking on “Datasheet” brings up the following information about the marker.

survey2

About halfway down, you can see that the NAD83 (2011) coordinates for this site are:

latitude               =   40 05 14.86880 N
longitude           = 105 09 01.68689 W
ellipsoidal height = 1613.737 meters

So let’s see how close we get to these numbers with the D302-RTK.  The D302-RTK uses a u-blox M8T receiver and a version of the demo5 RTKLIB code, so any results from this experiment should be valid not just for the D302-RTK, but for any M8T/RTKLIB based solution.

The survey marker is just over 1 km from my house and so I will use the antenna mounted on my roof connected to another M8T receiver as the base station.  The base observations are then broadcast to the internet with an RTK2GO.com NTRIP caster as I described in this post.  Using an M8T receiver for the base station allows me to enable GLONASS ambiguity resolution in the solution since both receivers are using identical hardware.

Since I am doing a real-time solution, I need internet service at the site of the measurement to get the base observations.  I got this by enabling a hot spot on my cell phone and connecting the D302-RTK to that.  I have surveyed the base station antenna with both RTK solutions from nearby CORS stations as well as online PPP solutions so I have a fairly good idea of it’s location, maybe within a cm or so.

The clamp and surveying pole in the top photo look nice but I don’t own anything like that, so instead I used a $20 camera tripod, a piece of wood, two rubber bands, a wood clamp, a piece of string, and a carriage bolt.  Here is the resulting setup aligned over the survey marker.  Note that I am using the optional helix antenna which was included with the receiver that was sent to me rather than an external antenna.

survey1

Here’s a close-up of the marker itself with the carriage bolt and string aligned over the top of the marker pin.   The other end of the string is fastened directly underneath the D302-RTK, making it easy to align the receiver directly over the marker and measure the vertical distance between the two.    If you’re wondering about the film canister at the bottom of the well, it seems that the marker is also serving as a local geocache location.

survey4

At this point everything is ready to go.  I powered on the receiver, enabled the RTK service for a static solution, waited five minutes and then recorded the position.  I did this three times to get three different measurements.  Here are some not-so-good photos from the screen of the D302-RTK for the three runs.  It is possible to store these values to the unit using an additional Android app, then uploading with a USB cable later, but in my case I just copied the values manually to my computer.

datagnss_screen123

The numbers are a little hard to read but are very consistent between results so I’ll just use the middle values.  The indicated height is the height of the base of the antenna, not the survey marker so I need to subtract the difference which I got by adding the length of string and bolt to the height of the receiver, in this case 1.49 meters.

latitude              =   40 05 14.8870 N
longitude           = 105 09 01.7374 W
ellipsoidal height = 1614.393 – 1.49 = 1612.903 meters

Comparing to the published survey numbers, we are not very close.  It’s a little less intuitive to compare degrees of latitude and longitude but the height is obviously off by almost a meter, so something is wrong.

Usually this kind of large error suggests there may be a mismatch between coordinates.  Sure enough, when I double-checked the base location that I had entered into the D302-RTK, I realized that I had used WGS84 coordinates, not NAD83.  As I mentioned earlier I had computed the base position using both RTK solutions from nearby CORS stations as well as online PPP solutions.  RTK solutions are always relative to the base station so will be in the same coordinate system as the base.  CORS stations locations in the U.S are normally specified in NAD 83 so using those coordinates would have been fine, but instead I had used coordinates from the online PPP solution which were in WGS-84 coordinates.  Since the RTK solution will be in the units of the base station, my results are in WGS-84 coordinates, and the published survey coordinates are in NAD83.

Fortunately there is another easy-to-use tool from the U.S. National Geodetic Survey that will translate from one coordinate system to another.  Entering the WGS84 coordinates from the measurement and translating to NAD83 gave the following:

survey3

You can see the WGS-84 coordinates on the left and the NAD83 translations on the right.  The translated coordinates from above are:

latitude                =   40 05 14.86828 N
longitude             = 105 09 01.68627 W
ellipsoidal height = 1614.393 – 1.49 = 1613.759 meters

Compare these to the marker coordinates we got from the NGS website earlier:

latitude              =   40 05 14.86880 N
longitude           = 105 09 01.68689 W
ellipsoidal height = 1613.737 meters

That’s looking much better.  The heights now differ by only about 2 cm, well within the expected vertical accuracy given the fact that my base station location was not exact, both antennas were uncalibrated, and my tripod setup was a little imprecise.

How about latitude and longitude?  The error in latitude is 0.00052 arc seconds and in longitude is 0.00062 arc seconds.  Those seem small, but unless you are a professional surveyor these numbers are probably not very meaningful to you, they certainly are not to me.

Meters would be much easier to interpret.  I usually use a free matlab geodetic toolbox, available on the Matlab file exchange to do these sorts of translations, but this time, let’s do it by hand.

At the equator, one arc second of longitude or latitude is approximately equal to the circumference of the earth divided by 360 degrees, then by 60 min/degree, then 60 sec/min.  A quick google search finds that the equatorial circumference of the earth is about 40.07 million meters.  Divide that by 360*60*60 gives 30.92 meters per arc second.  This is not exact but good enough for our exercise.  Arc-seconds of latitude remain nearly constant with location but arc-seconds of longitude will get smaller as we approach the poles of the earth by the cosine of the latitude.  I am located at approximately 40 degrees latitude, so 30.92*cos(40 degrees)=23.68 meters per arc second of longitude.

The error in latitude in our measurement from above was 0.0052 arc seconds.  Multiply this by 30.92 meters/arcsec gives an error in meters of 0.016 or 1.6 cm.  For longitude, multiplying 0.000062*23.68 meters/arcsec gives 0.0015 meters or 0.15 cm.

So total error in this exercise was 2.2 cm of vertical error and 1.6 cm of combined horizontal error.  Not too bad for two rubber bands, a piece of string, a bolt, and a wood clamp (as well as a nice low-cost receiver)!

Although I used the D302-RTK for this experiment, I believe the results would be very similar for any solution using a pair of M8T receivers and RTKLIB.

Advertisements

A look at the new DataGNSS D302-RTK single frequency receiver

DataGNSS recently introduced an Android-based single frequency GNSS receiver and gave me one of their units for evaluation.  It is based on the u-blox M8T and RTKLIB and appears to be aimed primarily at the surveying market.  Here’s a photo of it from their website.

datagnss1

First of all, let me say this is the most user-friendly receiver I have worked with.  From opening the box to getting a first RTK fix took less than half an hour.  If it were not for a bug in the user interface that they have since fixed, I would have had it working even quicker.  They have found a good balance between being easy-to-use and being configurable. Several of the user options are directly from my demo5 version of RTKLIB and it has an acknowledgment on the About screen for “Rtklibexplorer” so  it looks like they are using at least a derivative of the demo5 code.

I won’t go over all the technical details, you can read the datasheet here.  I also did not do any sort of extensive testing of the unit.  I will just give my initial impressions of playing around with for a short time.

To get my initial RTK fix, I first needed to connect the unit to wireless and then configure it to use the NTRIP caster on my roof as base station.  Both tasks were very easy and intuitive, an advantage of having a built in screen and leveraging off the Android platform.  Once I had done this, I turned on the default RTK service, and had a fix in just a few minutes.

The D302-RTK can be used either with an external antenna or with an optional helix antenna.  This photo from the DataGNSS website shows the helix antenna attached to the top of the unit.  This can be quite convenient.  Helix antennas are more omni-directional than patch antennas so are considered a good choice for handheld applications and are often used without ground planes as in this case.

d302

The lack of a ground plane does concern me though for RTK measurements.  In their antenna application notes, u-blox has some good information about the advantages and disadvantages of patch vs helix antennas including the following passage:

ant_text1That said, in my limited testing I used the helix antenna exclusively and seemed to be getting reliable fixes as quickly as I usually do with patch antennas.  However, I was not in an environment that would have particularly large amounts of multipath.  Of course, it is also very easy to switch to using an external antenna if multipath is an issue.

The RTK solution defaults to using GPS and GLONASS but it is easy to add Galileo or Beidou.  Configuring the basic settings is quite intuitive.  The advanced settings are much less intuitive and unfortunately not documented.  In most cases they are labelled with the same names as in RTKLIB and so can be just as cryptic.

As far as performance goes, since I believe it is using the demo5 version of RTKLIB, I would expect similar performance as you would get with any M8T receiver and the demo5 code, and my limited testing was consistent with that.

The biggest disadvantage I found was that there doesn’t appear to be an easy way to transfer solutions from the unit to a computer or other device for post-processing.  I found myself taking photos of the screen to record locations.  It does come with the SuperSurv application pre-loaded which will record tracks but I could not find an easy way to then download these to my computer.  I imagine this is something they are working on and hopefully will improve soon.  Or it may be already available in the SuperSurv app and just not obvious enough for me to find.  It may also be that there is another Android app that can be downloaded to serve this purpose.

It did have a few other issues that made it feel like an early production unit which I am fairly sure is the case, presumably they will get these issues ironed out over time.  In particular I found power management a problem, not when using the unit, but after you are done, it requires separate steps from different menus to stop the RTK solution and then power down the RTK module.  Even after doing both, it seemed like the battery ran out quite quickly when not being used.  I also experienced annoying screen flicker at times, at other times it was fine.  In the first version they sent me there were also several minor menu issues which when I brought them to their attention, they fixed quite quickly and sent me a new version of firmware.  My expectation is that they are working on the other issues as well and will hopefully have improvements soon.

The list price for the unit is $1199.  This is a lot for a hobbyist or casual user but if it meets the needs of anyone using it in their work on a regular basis, I imagine it could be quite affordable, especially compared to other such easy to use options.

In my next post, I will describe my experience using the D302-RTK to measure an actual survey marker, something I’ve never done before.

[Update 3/17/18:   DataGNSS responded to my post with a couple of updates:  First of all, the SuperSurv recorded tracks are available in the SuperSurv folder on the D302-RTK and can be downloaded by connecting a USB cable between the PC and the receiver.  They also suggest MapItGIS as another Android app that can be downloaded to the D302-RTK for recording tracks.  Also, they have just released a new version of firmware which improves the power management during sleep mode ]

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.

comnav2_1

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.

comnav2_2

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.

comnav2_3

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.

comnav2_4

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.

k708_6

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.

geoid1

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

geoid2

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.

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

comnav4

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

comnav8

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.

comnav9

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.

comnav10

Here is the M8T RTKLIB solution for comparison.  Fix rate was 81.8%, just slightly higher than the ComNav RTKLIB solution.

comnav12

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.

comnav11

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.

comnav13

comnav14

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.