Swiftnav experiment: Improvements to the SNR

In my previous couple of posts, I evaluated the performance of a pair of dual freqeuncy SwiftNav Piksi multi receivers in a moving rover with local base scenario.  I used a pair of single frequency u-blox M8T receivers fed with the same antenna signals as a baseline reference.

It was pointed out to me that the signal to noise ratio (SNR) measurements of the rovers were noticeably lower than the bases, especially the L2 measurements and that this might be affecting the validity of the comparison.  This seemed to be a valid concern so I spent some time digging into this discrepancy and did indeed find some issues.  I will describe the issues as well as the process of tracking them down since I think it could be a useful exercise for any RTK/PPK user to potentially improve their signal quality.

Previously , in another post, I described a somewhat similar exercise tracking down some signal quality issues caused by EMI from the motor controllers on a drone.  In that case, though, the degradation was more severe and I was able to track it down by monitoring cycle slips.  In this case, the degradation is more subtle and does not directly show up in the cycle slips.

Every raw observation from the receiver generally includes a signal strength measurement as well as pseudorange and carrier phase measurements.  The SwiftNav and u-blox receivers both actually report carrier to noise density ratio (C/NO), rather than signal to noise ratio (SNR) but both are measures of signal strength.  They are labelled as SNR in the RTKLIB output, so to avoid confusion I will refer to them as SNR as well.  I will only be using them to compare relative values so the difference isn’t important for this exercise, but for anyone interested, there is a good explanation of the difference between them here.  Both are logarithmic values measured in dB or dB-Hz so 6 dB represents a factor of two in signal strength.

Since the base and rover have very similar configurations we would expect similar SNR numbers between the two, at least when the rover antenna is not obstructed by trees or other objects.  I selected an interval of a few minutes when the rover was on the open highway and plotted SNR by receiver and frequency for base and rover.  Here are the results, base on the left and rover on the right.  The Swift L1 is on the top, L2 in the middle, and the u-blox L1 on the bottom.  To avoid too much clutter on the plots, I show only the GLONASS SNR values, but the other constellations look similar.

snr1

Notice that the L1 SNR for both rovers is at least 6 dB (a factor of 2) lower than the base, and the Swift L2 SNR is more like 10 dB lower.  These are significant enough losses in the rover to possibly affect the quality of the measurement.

The next step was to try and isolate where the losses were coming from.  I set up the receiver configurations as before and used the “Obs Data” selection in the “RTK Monitor” window in RTKNAVI to monitor the SNR values in real time for both base and rover as well as the C/NO tracking window in the Swift console app.  I then started changing the configuration to see if the SNR values changed.  The base and rover antennas were similar but not identical so I first swapped out the rover antenna but this did not make a difference.  I then moved the rover antenna off of the car roof and onto a nearby tripod to see if the large ground plane (car roof) was affecting the antenna but this also did not make a difference.  I then removed the antenna splitter, but again no change.

Next, I started modifying the cable configuration between the receivers and my laptop.  To conveniently be able to both collect solution data and be able to collect and run a real-time solution on the raw Swift observations, I have been connecting both a USB serial cable and an ethernet cable between the Swift board and my laptop.  My laptop is an ultra-slim model and uses an etherent->USB adapter cable to avoid the need for a high profile ethernet connector.  So, with two receivers and my wireless mouse, I end up having more USB cables than USB ports on my computer and had to plug some into a USB hub that was then plugged into my laptop.

The first change in SNR occured when I unplugged the ethernet cable from the laptop and plugged it into the USB hub.  This didn’t affect the L1 measurements much but caused the Swift L2 SNR to drop another 10 dB!  Wrong direction, but at least I had a clue here.

By moving all of the data streams between Swift receiver and laptop (base data to Swift, raw data to laptop, internal solution to laptop) over to the ethernet connection I was able to eliminate one USB serial port cable.  This was enough to eliminate the USB hub entirely and plug both the USB serial cable from the u-blox receiver and the ethernet->USB cable from the Swift receiver directly into the laptop.  I also plugged the two cables into opposite sides of the laptop and wrapped the ethernet->USB adapter with aluminum foil which may have improved things slightly more.

Here is the same plot as above after the changes to the cabling from a drive around the neighborhood.

snr2

I wasn’t able to eliminate the differences entirely, but the results are much closer now.  The biggest difference now between the base configuration and the rover configuration is that I am using a USB serial cable for the base, and a ethernet->USB adapter cable for the rover so I suspect that cable is still generating some interference and that is causing the remaining signal loss in the rover.  Unfortunately I can not run all three streams I need for this experiment over the serial cable, so I am not able to get rid of the ethernet cable.

I did two driving tests with the new configuration, similar to the ones I described in the previous posts.   One was through the city of Boulder and again included going underneath underpasses and a parking garage.  The second run was through the older and more challenging residential neighborhood.  Both runs looked pretty good, a little better than the previous runs but it is not really fair to compare run to run since the satellite geometry and atmospheric conditions will be different between runs.  The relative solutions between Swift and u-blox didn’t change much though, which is probably expected since the cable changes improved both rovers by fairly similar amounts.

Here’s a quick summary of the fix rates for the two runs.  The fix rates for the residential neighborhood look a little low relative to last time but in this run I only included the most difficult neighborhood so it was a more challenging run than last time.

Fix rates

City/highway Residential
Swift internal RTK 93.60% 67.50%
Swift RTKLIB PPK 93.70% 87.90%
U-blox RTKLIB RTK 95.70% 92.80%
U-blox RTKLIB PPK 96.10% 91.10%

Here are the city/highway runs,  real-time on the top, post-process on the bottom with Swift on the left and u-blox on the right.  For the most part all solutions had near 100% fix except when recovering from going underneath the overpasses and parking garage.

snr4

Here are the same sequence of solutions for the older residential neighborhood.  This was more challenging than the city driving because of the overhanging trees and caused some amount of loss of fix in all solutions.

snr5

Here’s the same images of the recovery after driving under an underpass and underneath a parking garage that I showed in the previous post.  Again, the relative differences between Swift and u-blox didn’t change much, although the Swift may have improved a little.

snr1

Overall, the improvements from better SNR were incremental rather than dramatic, but still important for maximizing the robustness of the solutions.  This exercise of comparing base SNR to rover SNR and tracking down any discrepancies could be a useful exercise for anyone trying to improve their RTK or PPK results.

Advertisements

7 thoughts on “Swiftnav experiment: Improvements to the SNR”

  1. With the Swift being multi-channel, why do think it’s not appearing to be more robust? That seems pretty surprising. Also, can you access the Swift measurements via RTKLIB directly, or are you forced to use Swift’s internal RTK solution?

    Like

    1. Hi DK. I show results both for the internal Swift RTK solution and a post-processed RTKLIB solution using the Swift raw measurements. The two are fairly similar. The M8T solutions are using four constellations (GPS,GLONASS,SBAS, and Galileo) while the Swift is only using two frequencies for two constellations (GPS, GLONASS) and so both have a similar number of raw observations. The L1 and L2 measurements from the same satellite tend to be more correlated than measurements from two separate satellites so there is probably more independent information in the M8T raw observations than in the Swift raw observations. The biggest advantage of dual frequency measurements is for longer baseline cases where ionospheric errors start to become a dominant source of errors, which is not the case here.

      Like

  2. The Galileo E20 is missing at M8T rov1_1749.nav but rov1_1749.obs. I checked 2018/3/20 around 17:20 using GNSS Radar at base1 location. I didn’t see E20 but some other Galileo’s. My question is the nav and obs file should be synced or not necessary?

    Like

    1. Hi GNSS hobbyist. E20 (GSAT0104) experienced a failure in 2014 and it’s navigation data has not been broadcast since then. My understanding is that they are working on bringing it back online as an E1 only satellite. RTKLIB will ignore the E20 observations since it does not have valid navigation data for them.

      Like

  3. If the 2 receivers in your rover are connected via a simple “T” with a DC block you will have issues. A proper wideband power splitter should be used, especially if you are dealing with both L1 & L2 (which are separated by ~300MHz).
    See https://www.minicircuits.com/app/AN10-006.pdf for a discussion of microwave power splitters.
    Not using a properly matched 50 ohm system can lead to issues like you are seeing. Increased susceptibility to interference from outside sources being one.

    This is one I use (I added a DC block to one port):
    https://www.ebay.com/itm/Altelix-Wideband-2-Way-Signal-Splitter-for-50-Ohm-Cellular-Boosters-2G-3G-4G-LTE-/152792839853?hash=item239329b6ad

    Like

    1. Hi Cynfab. I agree as a general principle a power splitter would be a good idea but I don’t believe the DC block is a significant issue in this particular experiment. The base station uses the same splitter and is working well. Removing the splitter from the rover setup has only a very small effect on the SNR values. The off-the-shelf DC blocks I am now using are 50 ohm impedence. The other thing to remember is that both receiver pairs are actually working very well. The differences between the Swift 2 freq, 2 constellation solution and the u-blox 1 freq, 4 constellation solution are relatively small and I think can be explained by other factors. The real advantage of dual frequency receivers is when dealing with long baselines and with time to first fix, neither of which comes into play in this experiment.

      Like

      1. It’s probably not enough to argue about, 3db here or there. There is still a lot of black magic involved in microwave practice, which is why some things work for some folks and some things don’t. ;>))

        Like

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 )

w

Connecting to %s

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