Underpasses and urban canyons

[Update: 4/17/18:  Although I don’t think it changes the results of this experiment significantly, there was an issue with apparent interference from a USB hub and ethernet cable on the rover setup during this testing.  See the next post for more details. ]

In my last post I demonstrated fairly similar fix rates and accuracies between an M8T single-frequency  four-constellation solution and a SwiftNav Piksi dual-frequency two-constellation solution.

One advantage often mentioned for dual frequency solutions for moving rovers is that their faster acquisition times should help when fix is lost due to a complete outage of satellite view caused by an underpass or other obstruction.  This makes sense since the dual frequency measurements should allow the ambiguities to be resolved again more quickly.

Since my last data set included several of these types of obstructions I thought it would be interesting to compare performance specifically for these cases.

To create the Google Earth images below I used the RTKLIB application POS2KML to translate the solution files to KML format files and then opened them with Google Earth.

Here are the raw observations for the first underpass I went under, Swift rover on the left, M8T rover on the right.  In this case there was an overhead sign just before the underpass which caused a momentary outage on all satellites followed by about a two second outage from the underpass, followed by a period of half cycle ambiguity as the receivers re-locked to the carrier phases.

Here’s the internal Swift solution for the sign/underpass combo above at the top of the photo and a second underpass at the bottom of the photo.  For the first underpass, the solution is lost at the sign, achieves a float solution (yellow) after about 9 seconds, then re-fixes (green) after 35 seconds.

Here’s the RTKLIB post-processed solution (forward only) for the Swift receivers with fix-and-hold low tracking gain enabled as described in my previous post.  It looks like a small improvement for both underpasses.  The solution loses fix at the sign but in this case maintains a float solution until the underpass.

Here’s the RTKLIB post-processed solution (same config) for the M8T receivers.  Notice the no-solution gaps after the underpasses are shorter.  In this case, for the upper underpass, a solid fix was re-achieved after about 21 sec.

Here’s a zoom in of the M8T solution (yellow dots) for the lower underpass.  If the position were being used for lane management it looks like the float solution would probably be accurate enough for this.  The other yellow line with no dots is the gap in the Swift solution.

Here’s a little further down the road.  At this point the Swift solution achieves a float position at about the same time the M8T solution switches to fix.  Lane management would clearly be more difficult with the initial Swift float solution.

Next, I’ll show a few images from another underpass.  In this case I drove under the underpass from the left, turned around, then drove under the underpass again from the right.  The Swift internal solution is on the left, the Swift RTKLIB solution in the middle, and the M8T RTKLIB solution on the right.  Notice that the time to re-acquire a fix is fairly similar in all three cases.

Here is zoom in of the two Swift solutions, they are quite similar.

Here is a zoom-in of the M8T RTKLIB solution.  Again, the float solution is achieved very quickly, and appears to be accurate enough for lane management.

My last test case was a combination urban canyon and parking structure.  In the photo below, I drove off the main street to the back of the parking garage, underneath the pedestrian walkway, into the back corner, then underneath the back end of the garage and then back to the main street.  I would consider this a quite challenging case for any receiver.

Here are the raw observations.

Here are the three solutions, again the Swift internal is on the left, the Swift RTKLIB in the center, and the M8T RTKLIB on the right.

 

Here is an image of the Swift internal solution.

Here is an image of the Swift RTKLIB solution

And here is an image of the M8T RTKLIB solution

In this case, the M8T RTKLIB solution appears to be the best.

So, this experiment seems to show that a dual frequency solution will not always handle satellite outages better than single frequency solutions.  In this case, the extra Galileo and SBAS satellites in the M8T solution seem to have helped a fair bit, and the M8T solution is, at least to me, surprisingly good.

If anyone is interested in analyzing this data further, I have uploaded the raw data, real-time solutions, and config files for the post-processed solutions to the sample data sets on my website, available here.  I should mention that there is an unexplained outage in the Swift base station data near the end of the data set.  This could have been caused by many things, most of them unrelated to the Swift receiver, so all the analysis in both this post and the previous post were done only for the data before the outage.

 

 

 

 

 

 

 

 

 

 

Advertisement

Improved results with the new SwiftNav 1.4 firmware

I last took a look at the SwiftNav Piksi Multi low-cost dual-frequency receiver back in November last year when they introduced the 1.2 version of FW.  They are now up to a 1.4 version of firmware so I thought it was time to take another look.  The most significant improvement in this release is the addition of GLONASS ambiguity resolution to the internal RTK solutions but they also have made some improvements in the quality of the raw observations.

I started with a quick spin around the neighborhood on my usual test route.  The initial results looked quite good, so for the next test I expanded my route to include a drive to and around Boulder, Colorado, a small nearby city of just over 100,000.  The route included some new challenges including underpasses, urban canyons, higher velocities, and even a pass underneath a parking structure.  This is the first time I have expanded the driving test outside my local neighborhood.

My test configuration was similar to previous tests.  I used a ComNav  AT330  antenna on my house roof for the base station, and a SwiftNav GPS-500 antenna on top of my car for the rover. I split the antenna signals and in both cases, fed one side to a Piksi receiver and the other side to a  to a u-blox M8T single frequency receiver.   I ran an internal real-time RTK solution on the Piksi rover and an RTKNAVI RTK real-time solution on the M8T rover.  The M8T receivers ran a four constellation single frequency solution (GPS/GLONASS/Galileo/SBAS) to act as a baseline while the Piksi receivers ran a two constellation (GPS/GLONASS) dual frequency solution.  Both rovers were running at a 5 Hz sample rate and both bases were running at a 1 Hz sample rate.  The distance between rover and base varied from 0 to just over 13 km.  The photos below show different parts of the route.

Here are the real-time solutions for the two receiver pairs, internal Swift on the left, and RTKNAVI M8T on the right.

Both solutions had similar fix rates (79.9% for Swift, 82.6% for M8T) and in both cases the float sections occurred for the most part either in the older neighborhood with larger trees (top middle) of after underpasses (bottom left).  The higher velocity (100 km/hour) on the highway (center) did not cause any trouble for either solution.

Based on a comparison of the two solutions, accuracy was relatively good for the fix sections of both solutions.  Below on the left, is the difference between both solutions for points where both solutions had a fix.  In the center and right are plots of both solutions (Swift internal=green,M8T RTKNAVI=blue) for the two locations with the longest duration discrepancies of any magnitude.  Both look like false fixes by the Swift internal solution, based on the discontinuities.  Overall, though the errors between the two were reasonably small and of short duration.

Post-processing the Swift data with RTKLIB produced the solution on the left below with an 85.5% fix rate and a good match to the M8T solution.  The difference between both solutions for the fixed point is shown on the right.  This solution was run with continuous ambiguity resolution.

 

For more challenging environments like this I often add some tracking gain to the ambiguities by enabling “fix-and-hold” for the ambiguity resolution mode but setting the variance  of the feedback (input parameter pos2-varholdamb) to a fairly large number (0.1 or 1.0) to effectively de-weight the feedback and keep the tracking gain low.  For comparison, the default variance for fix-and-hold mode feedback is 0.001 which results in quite a high tracking gain.  I find that with the low tracking gain, I generally do not have an issue with fix-and-hold locking on to false fixes.

Running RTKLIB solutions for Swift and M8T with this change (fix-and-hold AR enabled, pos2-varholdamb=1.0) improved the fix ratio for the Swift RTKLIB solution from 85.5% to 91.1% and the M8T RTKLIB solution from 82.6% to 92.6% with no apparent degradation in accuracy.

Using a combined solution instead of a forward solution (only a choice for post-processing) improved the fix ratios even further, again with no apparent degradation in accuracy.  The Swift RKLIB solution increased to a 96.2% fix rate and the M8T RTKLIB solution increased to 94.1%.

Overall, the Swift RTKLIB solutions were noticeably better and more consistent than in my previous test.  Considering the difficulty of the environment, I consider all of these solutions to be very good.

In my next post, I will look specifically at how the two receivers handled going through a narrow urban canyon, underneath three underpasses and underneath a parking structure.

Measuring a survey marker with the DataGNSS D302-RTK

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

Since the unit is designed for surveying, I thought it would be fun to use it to 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.

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

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.

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.

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.

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:

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.

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.

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.

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:

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

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.