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.












25 thoughts on “Underpasses and urban canyons”

  1. I just did a quick stationary M8T L1 test with 2 different baselines. Used GPS only with professional CORS stations (GLONASS AR is not working for CORS in RTKLIB). First baseline was 25 km and the first fix (static-start mode) came after about 50 seconds. Second baseline was 50km and fixed solution appeared after about 3 minutes.


    1. Just to add – when I used 2 M8Ts with a baseline of about 10 meters – with GPS+GLO+GAS the fix in “static-start” mode was obtained in about 18 seconds.


  2. I tried to repeat the test but not get good result. The following is what I did:
    – Download Demo5 execute. Run RTKPOST, I can see RTKPOST ver2.4.3 demo5 b29b on title bar.
    – Download Car_0320 convert ubx and sbp files. But only test M8T go through at parking lot section
    – open RTKPOST
    – OBS Rover: rov1_1749.obs. OBS Base: base1_1749.obs
    – NAV: load rov1_1749.nav, rov1_1749.lnav,rov1_1749.gnav and rov1_1749.hnav
    – At Time sections: start: 2018/03/18 18:29:00 end: 2018/03/20 18:33:00
    – Load ubox.CONF
    – Open the options verify:
    setting1: Mode kinematic, Freq L1/Forward, GPS, GLO, Galileo and SBS checked
    setting2: Fix-and-Hold Glonass/ON BD/grayed OFF. Min ratio 3. Min Lock to Fix Amb 0. Min Fix to Amb 100.
    statistics: Code/Carrier-Phase error ratio L1/L2 300 300

    I got pos file with Q=2 (96.8%). Is there any step I am missing?
    Please Advise



    1. Hi Hobbyist. I downloaded the data, config files, and deom5 b29b code from my website and reran the solutions just to make sure there were no discrepancies between what I used and what was posted. I was able to duplicate my previous results, so I am pretty certain they are OK. It looks like you are trying to set up the options yourself, I would recommend using the config file I provided (You can load it from the options menu).

      The other possibility is that you are not correctly converting the raw binary files to RINEX. Be sure to use the demo5 b29b version of RTKCONV and also make sure you enable all relevant constellations (GPS/GLONASS/SBAS/GALILEO for M8T, GPS/GLONASS for Swift) and enable L2 for Swift.


      1. would you please zipped your converted files include exe files and put it at download section? Not sure computer power make sense or not. Really try to resolve this. THANKS!


          1. Hi hobbyist,would you min tell me what the problem you have meet ? I have the same result(Q2= 99.6%) as you posted early. I tried for several times but still didn’t works.


  3. I have been playing with raw data a bit more in the meantime. Tired to run rtkpost for the M8T with various constellations enabled/disabled and forward/combined to see how it performs. Nice experience. I am interested in using CORS stations a lot so that one does not need to hassle with setting up his own base station. The missing GLONASS AR for CORS is a significant drawback though. Tim, dont you want to play with it again and fix it somehow? 🙂 Maybe by using the RTCM 1230 message. Anyways, with Galileo and Beidou now gaining traction (Beidou will get almost 20 new satellites this year!) the option is to use these two from CORS instead of Glonass. The US CORS network does already have several Galileo stations – these can be filtered nicely on the beta site – https://beta.ngs.noaa.gov/corsmap/. The European EUREF is a bit better with many stations having GAL+BDS for post-processing and about ten even in real-time.

    I found one of the US Galileo stations is near your location (TMG2). I downloaded 24-hour 1 second RINEX from the BETA site for March 20th (filename tmg20790.18o) and tried to plug it into rtkpost with your conf with just the position tab edited in options to use the “Rinex header position” for base station. rtkpost runs (takes time with the large cors file) and it looks like the base&rover data overlaps (time goes through in progress bar after a while) but the solution file has only a header and contains no positions. Am I doing something wrong? Tried to process GPS, GPS+GAL, GPS+GAL+SBAS but all the same. I tried to run your Tersus dataset with CORS (niwot_tersus_0606) and that works with its config.


  4. I forgot one thing yet – can RTKLIB resolve integer ambiguities for the Galileo constellation? I thought it can all the time but now I can not see the setting for it in rtknavi/rtkpost, only GPS/GLO/BDS is listed (with BDS greyed out?).


    1. Hi Kozuch. The release version of RTKLIB defaults to always doing GPS and Galileo ambiguity resolution (AR) if AR mode is enabled. I added a switch to the demo5 version to enable/disable GPS AR for educational and debug purposes but Galileo AR is always on if AR Mode is enabled. The option for BDS AR is most likely greyed out because you don’t have the BDS constellation enabled.


  5. One last comment today – maybe it would be interesting to try to evaluate the re-fix abilities of the receivers by more scientific test like blocking the RF signal from the antenna for a given time (to simulate an underpass) on a static rover (in kinematic RTK mode though). One could then easily evaluate the errors. This may be especially interesting in combination with the baseline length test to see how the re-fix time gets longer with longer base (I assume :)).


    1. Hi Kozuch. Yes, I have done some tests as you describe but I am not convinced they accurately simulate a real underpass in which the receiver is moving during the outage, the blocked and then regained satellites occur in a particular sequence, and the multipath effects may be different, especially when the outage times are very short as they usually are with an underpass. I have tended to focus on actual snapshots of the real world rather than more extensive lab or simulated testing, but I do believe both are useful.


  6. Hi Tim, I look at the raw data you posted – so far I had success reproducing your results :). Converted the UBX to RINEX with rtkconv (enabled GPS/GLONASS/Galileo/SBAS) and then used rtkpost with your .conf file. Then pos2kml (in not part of your demo5 Windows binaries though) – nice it works for Swift’s NMEA too. The result looks like your screenshots. Just the included ublox_1749.pos does not seem to contain the same solution I got.

    I would like to do similar test myself. I have a pair of M8T from CSG Shop with integrated antenna and 100 mm round ground plane (NEO-M8T Time & RAW Triple Band EMI protection +HMC5983 PRO version – now at http://www.csgshop.com/product.php?id_product=221). Do you think I will be able to get some good results with this setup or should I rather get a proper Tallysman TW4721 for rover and TW3742 for base (with a new pair of M8Ts)? I can imagine the good results of this your last test may go to the good antennas used – the Swifth and ComNav antennas are probably still a bit better than Tallysman.


      1. Hi Dan. The exact fix rate will depend very much on your input parameter configuration. If you are using the config files included with the download and the latest version of RTKLIB demo5, you should be able to match my results though. To match exactly, you will need to use the same start and end times as I did. In my analysis, I did not include the time to initial fix since it is a very small percent of the total solution and it is difficult to make a fair comparison between the different solutions. Also, as I mentioned in my post, near the end of the data set there is a gap in the Swift base station data for unknown reasons likely unrelated to the Swift receiver, so I ended my analysis for both receiver pairs at the start of that gap.


        1. Hi Tim, I just want make sure this test you still use the released version Demo5 29b not your recently update. Is that right? I thought you updated the demo5 29b code to better handle the tough raw measurement after your ComNav receiver testing. Correct me if I am wrong.


    1. Hi Kozuch. Yes, I became familiar with POS2KML fairly recently which is why it is not part of the demo5 binaries, but I will add it to future releases. The u_blox_1749.pos solution is the real-time u-blox solution so won’t match the post-processed solution exactly. It also ran with a slightly different config which unfortunately I did not save.

      The M8T receivers in my experiment were from CSGShop but I have not tested the ones with built-in antennas. Antenna quality does make a difference, so I would consider buying the units with external antennas go give yourself the flexibility to upgrade if you are not satisfied with the lower cost antennas. For well constrained environments with open skies, the lower cost antennas will work fine, but if you are working with more challenging environments, the higher cost antennas will help. Although the antennas I used in this test are fairly expensive, much of the cost is because they support dual frequencies. Good quality single frequency antennas, such as the ones you suggest, are available for significantly less.


      1. Hi Tim, the real-time and post-processed (forward only) solutions should be identical with the same config file, am I right (meaning a general case)? I used your .conf file for rtkpost as I wrote. Can I use the same file for rtknavi or is the config file format different? I guess I will also need the initialization sequence for the M8T receiver so that it outputs the RAW messages at all – would you mind sharing this sequence too? I guess you have a nice tweaked one :).

        I have one more crazy idea – the M8T is limited to reception of only 3 concurrent constellations (while SBAS does not seem to count for one). So one can not use GPS/GLO/BDS/GAL from a single receiver. Do you think one could “merge” the RTCM messages from two receivers to allow for 4 concurrent constellations? This surely must be doable in software but the question is it the messages need to be in some kind of sync or whatever. Anyways the Emlid Reach allows to configure different RTCM message frequency for various constellations so it looks like RTKLIB can deal with messages that are not “in sync”. The idea is even more interesting given that M8T can do higher frequency when fewer constellations are used (I saw up to 14 Hz for GPS) so then 2 receivers were used one could take advantage if this. Sure, the cost of the receiver setup doubles but for $75/piece it may still be interesting.


        1. Hi Kozuch. With the same config file, the real-time and post-processed solutions will generally be quite similar but not identical. The real-time solution will have a non-zero age of differential (transmission delay of the base data) while the age of differential in the post-processed solution will be zero. Assuming the age of differential is less than a couple seconds, this difference should be very small. Also, depending on initial conditions, the real-time solution may not initially have navigation data for all the satellites. RTKLIB has a feature to save time-tag files along with the raw data which can then be run with RTKNAVI to accurately simulate the real-time run. Unfortunately this feature seems to have been broken by one of the recent updates from the release code.

          I have done an experiment very similar to what you suggest, and yes it did work. I used RTKCONV to convert two simultaneously collected raw data files from two receivers to RINEX with the time-adjust feature enabled to align the time stamps between the two files. I then wrote a simple MATLAB parser to combine the two RINEX files into a single RINEX file which included Galileo measurements from the second receiver. I was then able to run a successful solution with this file. The output rates of the different measurements can be different but they do need to be aligned.

          The same config files can be used for both RTKPOS and RTKNAVI. The receiver setup file (*.cmd) files I use for the M8T are included in the demo5 binaries download.


          1. Hi Tim, I initially thought the “double M8T, 4 x GNSS” setup for real-time but but it looks like post-processing that will be much simpler. I just have a question about the “time-adjust feature” you talk about – do you mean the .tag files that can be created by rtknavi (and are enabled on “Log streams” window by ticking the time-tag) or are you talking about something else (rtkconv setting)? Rinex has its own timestamps, right? These are not enough to sync the two rinex files? Could you please elaborate so that I can try to reproduce your experiment? Sharing your MATLAB code your be great too :).

            Also, do you have a recommendation on which particular GNSS to enable on which receiver? Looking at section “1.5 Supported GNSS Constellations” in M8T datasheet I think GPS+Galileo and GLONASS+BeiDou my be a good combination. The receiver only has 32 satellite channels but that definitely should be enough for today’s 2 x GNSS.


          2. Hi Kozuch. Adjusting the time tags is a receiver option in RTKLIB. Specifying “-TADJ=0.1” for example in the “Reciever option” box in RTKCONV or RTKNAVI will adjust the time tag, pseudorange and carrier phase measurements to move the measurement to the nearest 0.1 sec. This will allow you to align the time stamps between the two receivers.


      2. PS. Have you tried to push the RAW sample rate of M8T to its limits? Emlid’s 14 Hz GPS is undocumented I think and they achieved it by turning off other unnecessary messages (probably to offload the MCU). There may be similar situation for the other constellations, of course the question is whether the efforts are worth it today, maybe the upcoming M9 platform will solve these issues with more powerful CPU. The current 5 Hz of M8T for GPS/GLO/GAL/SBS is very good performance already for the money though :).


        1. Hi Kozuch. I have not tried running the M8T at greater than 5 Hz. I have found for most typical applications that the dynamics of the rover are low enough that interpolating between 5 Hz solution output points gives quite accurate positions.


  7. Great post again. I am also surprised of the L1 performance. The 13 km baseline does not seem to be a big problem to the M8T, right? It would be great to see the baseline length test to be pushed to the limits of both receivers. The usual 1 PPM error (1 cm error every 10 km of baseline) may not be a big problem for some applications even at say 50 km (=5cm error) or more. I would love if you could look at this in the future :).


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.