As I mentioned in my last couple of posts, I have recently been exploring the use of RTKLIB with a couple of different low-cost dual frequency receivers. Low-cost is a relative term here. At $600 to $1700 for the receivers, plus the cost of the antenna, these configurations are significantly more expensive than the u-blox based single frequency versions I usually work with. Still, they are quite a bit less expensive than models from the more traditional manufacturers.

The first receiver I have is a Piksi Multi from Swift Navigation.

It is available from their website for $595 for the receiver board, or $1995 for a complete evaluation kit including two receivers, antennas, and radios. This receiver relies on the new L2C codes for the second (L2) frequency and so does not support the traditional P2 codes. L2C is an unencrypted code that is only available on the newer GPS satellites. Roughly half the GPS satellites are currently broadcasting these codes but this number will increase as newer satellites are launched. This does mean that the Multi can only make dual frequency measurements on the satellites that have L2C capability. Also, although the receiver hardware is capable of supporting GLONASS G1/G2, BeiDou B1/B2, Galileo E1/E5b, QZSS L1/L2 and SBAS signals, these constellations are not supported in the current firmware. This means that the current capability of this receiver is somewhat limited, but it should improve as they release new firmware and more satellites are launched.

The second receiver I have been evaluating is a more expensive option, the Precis-BX306 from Tersus which is available from their website for $1699.

This receiver does support the P2 codes on the L2 frequency and therefore is able to receive dual frequency signals from all the GPS satellites. It also supports Glonass G1/G2 and Beidou B1/B2 in the current hardware and firmware. Tersus also has similar receivers that are less expensive but also less capable than this one. The Precis-BX305 fully supports GPS L1/L2 but only has support for GLONASS G1 and Beidou B1/B3. The Precis-BX316R supports all the same constellations as the BX306 but only provides raw measurements, it has no internal RTK engine. Both of these models sell for $999.

In the spirit of full disclosure, I should mention that Tersus gave me the BX306 receiver to evaluate and one of my consulting clients gave me permission to use their Piksi Multi receiver for this evaluation. I appreciate both of them for their generosity.

Before digging into the details of the receivers, it’s worth first discussing what the advantages of a dual frequency receiver are over a single frequency receiver and also to what extent RTKLIB is capable of exploiting these advantages. All of this is fairly new to me so the following analysis is based on my somewhat limited understanding. If I get anything wrong, I am hoping one of my more experienced readers will jump in and correct me.

The most obvious advantage of the dual frequency receiver is that it provides more measurements than the single frequency receiver for the same satellite constellation. However, if this were the only advantage, then the Piksi Multi, with GPS support only, would still be less capable than the u-blox M8T when the additional GLONASS, SBAS, and Galileo measurements are all taken into account. Dual frequency receivers do also tend to have more high-end circuitry and tend to be paired with more expensive antennas.

The biggest advantage, though, comes from having multiple measurement of the same path through the atmosphere made with different frequencies. Using linear combinations of these pairs of measurements in different ways we can glean information that is just not available with the single frequency measurements. Two linear combinations that are particularly useful are the ionosphere-free combination and the wide lane combination.

The ionosphere-free combination takes advantage of the fact that the ionospheric delay is inversely proportional to the square of the frequency. By taking the difference of the squares of the two phase measurements, more than 99% of the ionospheric delay error can be eliminated. The ionosphere-free combination provides the ability to deal with much longer baselines between the two receivers and also makes possible accurate PPP measurements.

The wide lane combination is simply the difference of the phase measurements made at the two frequencies and the advantage of this combination is that the effective wavelength of this measurement is a function of the difference in frequencies between the two measurements. In the L1/L2 case, the difference in frequencies is 348 Mhz and the wavelength is 86 cms. Resolving integer cycle ambiguities over an 86 cm cycle is significantly easier than resolving them over the much shorter L1 wavelength of 19 cm, the only option available with the single frequency receivers. Once the wide lane ambiguities have been resolved, they can be used to assist in resolving the shorter cycle L1 and L2 ambiguities. This can lead to much faster times to first fix with the dual frequency receivers.

Of course, these additional opportunities are only valuable if the solution algorithm takes advantage of them. Unfortunately RTKLIB appears to be quite disappointing in this regard. For the most part, the default configuration of RTKLIB for RTK handles the two frequency measurements independently and takes very little advantage of the linear combinations. This makes them no more valuable than if they were two measurements from different satellites. There is an option to enable ionosphere free combinations (pos1-ionoopt =dual-freq) in the config file which uses the ionosphere-free combinations to estimate the phase biases instead of the individual measurements. The user manual indicates, though, that the ionosphere-free model is not applied for the RTK solution modes and I have found that setting this option when running an RTK solution breaks the ambiguity resolution. There is also an option in the code for a wide lane ambiguity resolution but this option is not mentioned in the user manual and if set it attempts to call an external function that is not included with the RTKLIB source code. There may be a little more support for dual frequency in the PPP solution modes. However, the current RTKLIB version does not make any attempt at ambiguity resolution in the PPP modes. The 2.4.2 release of RTKLIB does include what the manual describes as a beta version of ambiguity resolution but that has been removed in the 2.4.3 release. Without ambiguity resolution, my experience with PPP solutions has been that I can get much better solutions using some of the free online PPP services that do use ambiguity resolution than I can get with RTKLIB. I am hoping someone can prove me wrong and provide a config file that generates an RTK or PPP solution with RTKLIB that takes full advantage of the linear combinations of the dual frequency measurements but from everything I can see, there is not much code to support this capability.

Fortunately, both receivers do include the capability to calculate their own RTK solutions without RTKLIB. So the goal in the following experiments will be to both compare the two receivers against an M8T single frequency receiver and also to compare their internal solutions to the RTKLIB solutions. Unfortunately, neither receiver is set up to handle the post-processing of previously collected measurements and so all of the internal RTK solutions need to be done in real-time. In my last post I described how I configured the receivers to receive real-time base station data over a cell phone link.

So, let’s start by taking a look at some actual measurement data.

Here is a set of measurement observations collected simultaneously from two receivers on a moving car. The observations on the left are from a u-blox M8T receiver and on the right are from the Tersus receiver. Satellites with lock to L1 only are indicated in yellow, those locked to L1 and L2 are in green.

At the start of the data set, the M8T is locked to 8 GPS, 7 Glonass, 4 Galileo satellites, and 3 SBAS, for a total of 21 measurements. The Tersus receiver is locked to 8 GPS L1, 7 GPS L2, 6 Glonass L1 and 5 Glonass L2 for a total of 26 measurements. The greater number of satellites should give the Tersus an advantage over the M8T even before considering the extra advantages of the L1/L2 combinations or the more expensive electronics and antenna.

Here is a similar set of data. The M8T receiver is on the left again, this time the Swift is on the right. Again yellow is a single frequency measurement, green is for measurements at two frequencies.

This time there were a few less satellites in the sky. At the start of the data set the M8T is locked to 7 GPS, 7 Glonass, 2 Galileo, and 3 SBAS for a total of 19 measurements. The Swift receiver has 6 GPS L1, and 4 GPS L2 for a total of only 10 measurements. Particularly for RTKLIB which does not take advantage of the extra information in the L1/L2 combinations, it will be difficult to make up for the small number of measurements.

As mentioned before, this should improve as Swift releases firmware to support GLONASS, BeiDou, Galileo, QZSS, and SBAS, and as more GPS satellites are launched with L2C capability.

In my next post I will compare solutions generated with these different measurements, both from RTKLIB and from the internal RTK engines.

Do you have any good information about Sapcorda, wich will give Europe centimeter precision from EGNOS?

LikeLike

Hi Jan. Sorry, I don’t have much info on Sapcorda other than I believe it is an SSR based corrections similar to what I describe in my post on SSR solutions but with higher density atmospheric corrections than the free SSR stream that I used

LikeLike

I have bought a dualfrekvensy Xiaomi Mi 8 before chritmas and are looking for surveing program to run on the unit! I already since several years have a Leica GG-03 and CS-10 handunit! The Mi-8 has come down to 43 cm so far, but they promised 10 cm. This Sapcorda should send corrections via the mobil, but ESA writes that SBAS should do the same with 10 cm! Trimble have advertizements about 10 cm via WAAS systems!

LikeLike

Are you going to test Emlid REACH RS2?

LikeLike

Hi Jan. I’d be happy to evaluate a Reach-RS2 if anyone wants to send me one.

LikeLike

Have you tested Ublox FP9 as basestation ?

LikeLike

Hi Jan. I prefer using matched receivers for rover and base, both to maximize satellite pairs, and to eliminate any Glonass HW bias issues. Most of my F9P testing is done with F9P as base and rover, especially when using moving rovers, including the testing in this post

LikeLike

Hi,

Do you have any idea about PIKSI accuracy and stability for 1PPS

I need to use dual freq receiver for time and frequency standard

LikeLike

Hi Hendra. The SwiftNav Multi spec specifies 60 nsec accuracy for PPS but I have not tested this myself.

LikeLike

Hi, I’m curious about the fix time when you using M8T, for me, always greater than 80s~90s with GPS+BEIDOU, I dont know if it’s RTKLI’s limit performance?

LikeLike

Hi Roger. Time to first fix will vary depending on many factors (distance between base and rover, # of constellations, matched vs. unmatched receivers, multipath, etc) but 80-90 seconds does not sound unreasonable for the M8T.

LikeLike

I have to decide on PIKSI but the issue you mentioned regarding communication on GPS L2 band only using L2C codes being only compatible with the new satellites. Has this been resolved in the newer firmware updates? I have been through the release notes and it says improved L2C performance but nothing explicitly about the P2 codes.

Any guidance would be highly appreciated.

LikeLike

Hi Hassananrauf. I don’t believe Swift has any plans to add support for the P2 codes. About 60% of the GPS satellites now broadcast L2C and that will increase with time as the older satellites are replaced.

LikeLike

Hi. Is it possible in RTKPOST to observe the solution from L2 only (instead of L1+L2)? Thanks 🙂

LikeLike

Hi Tao. No, RTKLIB only supports frequency choices of L1, L1+L2, L1+L2+L5 or L1+L5. As far as I know, that is due to architectural issues with the code rather than any inherent reason you couldn’t solve for L2 only.

LikeLike

Hi there. I think your statement that RTKLIB is not using any double frequency linear combinations is totally incorect. RTKLIB manual says that it uses LAMBDA method which is far more efficient that older wide-lane, narrow-lane techniques. There is nice FAQ about LAMBDA at this link: http://www.utdallas.edu/~aiken/GPSCLASS/lambdaambigfulltext.pdf. Nevertheless great article, cheers.

LikeLike

Hi George. I read the FAQ you linked to and mostly I thought it was excellent, but I did find the reference to wide-laning and LAMBDA confusing if not misleading. In a basic dual frequency ambiguity resolution implementation, I believe the wide-lane float estimates are calculated and then resolved to integers using LAMBDA. The wide-lane results are then used to improve the L1 float estimates which are then resolved using LAMBDA again. This is referred to as a cascaded solution. I believe the point the author was trying to make is that this has been shown to be sub-optimal and that incorporating the wide-laning directly into the LAMBDA solution is optimal. However, I don’t believe that the LAMBDA algorithm intrinsically includes wide-laning, and specifically I don’t believe that the RTKLIB implementation does. This is just my understanding. As always, if anyone believes this is wrong or could be explained better, please chip in.

LikeLike

There is not really any benefit to forming linear combinations. Estimating the L1/L2 ambiguities and using the full covariance matrix to do the search is optimal. Perhaps the following explanations can help:

1) Linear combinations: https://www.blackdotgnss.com/2015/03/23/a-note-on-optimal-linear-combinations/

2) LAMBDA

https://www.blackdotgnss.com/2015/03/29/lambda/

I am curious to see the results! Keep us updated!

LikeLike

Hi Simon. OK, clearly I need to do some more homework on this one. Your links were very helpful but I do have a question about the following statement you make:

“Other than speeding up the search process, LAMBDA could be beneficial when … doing partial fixing since it allows identifying a subset of decorrelated ambiguities that are more easily fixable. (For example, we all know that fixing only the widelane ambiguities is usually more likely to succeed than fixing all ambiguities on L1/L2.)”

You agree that fixing the widelane ambiguities with LAMBDA is easier than fixing the L1/L2 ambiguities. My impression though was that the resolved widelane ambiguities could then be used to improve the L1/L2 float estimates and by then feeding the improved L1/L2 float estimates into LAMBDA you could improve your chances of getting a good L1/L2 fix over using the raw L1/L2 float estimates. Thus a cascaded implementation of LAMBDA would give a better answer than a single iteration. Is that not true? From your posts, it sounds like I may be falling into a common trap with this assumption.

By the way, for those of you not familiar with Simon’s blog (where his links came from), it is a great source of information for some of the more technical aspects of GNSS.

LikeLike

Fixing the widelane ambiguities can provide you with a better positioning accuracy than the code solution and it is therefore beneficial when fixing the L1/L2 ambiguities is not successful.

Even though, intuitively, you may think that the improved position estimates from the fixed widelanes will help you fix the L1/L2 ambiguities, I don’t think that it is the case. Here is my justification:

Let us make a transformation from L1/L2 ambiguities to L1/WL ambiguities. It can be easily shown mathematically that this transformation will have no impact on the ambiguity fixing success rate. (But it will help with my justification!)

If the proper widelane integers could be identified in a widelane-only search, the same integer values will also come out as the only valid widelane candidates in the L1/WL system (it makes sense since the WL-only system is only a partition of the L1/WL system)

By means of the correlations in the ambiguity covariance matrix, the L1 ambiguities will be constrained within the search by the valid WL candidates. This correlation effectively plays the same role as explicitly fixing the widelane ambiguities to adjust the position.

I hope this is convincing enough!

LikeLike