Back in November last year, I wrote a post on my first experiments with a dual frequency u-blox F9P based receiver. At the time it was quite difficult for those without good connections to u-blox to get a hold of the F9P and even now, nearly three months later, it still is not readily available. Ardusimple, the lowest price provider of F9P receivers still has all their receivers on back order till next month and low cost dual frequency antennas are even harder to get. Hopefully all that will change fairly soon though.
Meanwhile, thanks to “clive1” and “cynfab” from the u-blox forum, I have been lucky enough to have been given a prototype receiver based on the dual frequency u-blox F9T, the next product from u-blox in the Generation 9 series. Like the previous generation M8T, this is intended for timing uses and does not include an internal RTK engine. Otherwise I believe the F9T hardware is nearly identical to the F9P. In theory it should be less expensive than the F9P, just as the M8T is less expensive than the M8P but meaningful pricing is not yet available.
In many of my posts, I have focused on post-processing short baseline data sets using a local base station and identical receivers for base and rover. For this particular combination, I have shown that the differences between a single frequency solution and a dual frequency solution are typically fairly small. This assumes that the single frequency solution includes Galileo and possibly SBAS while the dual-frequency solution includes only GPS and Glonass. This makes the total number of observations fairly similar between the two cases. At least until very recently this has been a reasonable assumption given that most existing CORS or other reference base stations and reasonably priced dual frequency receivers offered only GPS and Glonass. It’s also true that time to first fix is longer in the single frequency solutions but post-processing with a combined solution generally eliminates the need for a fast fix.
However there are many other cases where there are definite advantages to using a dual frequency solution. In particular the most important advantages occur for:
Longer baselines where linear combinations of L1 and L2 can cancel ionospheric errors
Use of an existing CORS or other reference base station which typically has only GPS and Glonass and hence is not an ideal match-up with a single frequency receiver using additional constellations
Real-time solutions where time to first fix is more critical
PPP (Precise Point Positioning) solutions for the same reasons as the long baseline cases.
So for my initial experiments with the F9T I focused on including some of these conditions. In particular I ran two experiments, the first a real-time RTK solution with an existing UNAVCO reference base (P041) located 17 km away. For the second experiment I compared an online PPP solution from the Canadian Spatial Reference System (CSRS) with an RTKLIB SSR based PPP solution.
For the first experiment, I connected the F9T receiver to the dual frequency antenna on my roof and ran a quick five minute RTKLIB real-time solution against the UNAVCO base station using the demo5 b31 RTKLIB code. Other than changing the frequency mode from L1 to L1+L2 I used the exact same configuration file I normally use for the u-blox M8T single frequency receiver. Even though the rover was stationary in this case, I ran the solution as kinematic for better visibility to any variation in the solution. Here’s the result.
Overall the solution looked excellent. First fix occurred within a few seconds, fix rate was 100% after first fix, horizontal variation was roughly +/-0.5 cm and vertical variation was roughly +/-1 cm.
The solution residuals, both pseudorange and carrier-phase also looked very clean.
I only made a brief look at the raw observations but did not see anything unusual there either. At only five minutes of data, it is not much more than a quick sanity check, but so far, so good.
For the second experiment I collected four hours of raw observations, again with the F9T receiver and my rooftop antenna, a ComNav AT330. I then submitted this data to CSRS for their online PPP solution as well as running an RTKLIB SSR solution as I described in this post. Below are the results for both solutions. The plots are all relative to my best estimate of the location of the rooftop antenna based on previous PPP solutions with Swift and ComNav receivers as well as RTK solutions from nearby CORS stations. The left plots shows the first hour of solution with a +/-0.25 meter vertical scale. The right plot shows the second through fourth hours with a +/-0.06 meter vertical scale.
Both solutions get to below 6 cm of error in each axis after 1 hour and below 3 cm of error after four hours. The CSRS solution gets down to almost zero error in all three axes after four hours but I don’t believe my reference is this accurate so I think this was partially luck. The reported accuracies (95%) for the CSRS solution were 1 cm, 4 cm, and 5 cm for latitude, longitude, and height respectively. My previous experience running RTKLIB SSR PPP solutions with other low cost dual frequency receivers is that after running many solutions, they generally all fall within +/-6 cm accuracies in all axes after four hours. Both solutions include only GPS and Glonass observations because both the SSR correction stream I used from the CLK93 source, and the CSRS online PPP algorithm use only GPS and Glonass.
Being able to run accurate PPP static solutions can be a big advantage since it can make it much simpler to precisely locate a base station for RTK solutions with a dynamic rover, especially in more remote areas where there may not be any nearby CORS or other reference stations to run an RTK solution against.
As always, this post is intended to be just a quick snapshot and not an extended analysis of any type, but so far I have been very impressed with both the F9P and F9T and with their compatibility with RTKLIB.
The new low cost dual frequency receiver from u-blox, the ZED-F9P, is just now becoming available for purchase for those not lucky enough to get early eval samples from u-blox. CSGShop has a ZED-F9P receiver in stock for $260 which seems quite reasonable, given that it is only $20 more than their NEO-M8P single frequency receiver.
Even better, Ardusimple is advertising an F9P receiver for 158 euros (~$180) + 20 euros shipping , although their boards won’t ship until January. As far as I’m aware of, this is actually less than anybody today is selling the M8P receiver for today!
Of course, this is still a fair bit more than a u-blox M8T single frequency receiver without an internal RTK engine, which is available from CSGShop for $75, but the F9T will be coming out next year also without internal RTK engine, which should bring down the price for the lowest cost dual frequency receivers.
Unfortunately I am not one of the lucky ones who got eval boards directly from u-blox yet. However, I do have two prototype boards from Gumstix, given to me by them for evaluation. Gumstix offers both off-the-shelf boards and semi-custom boards designed from their libraries of circuits. I haven’t worked with them directly but it looks like an interesting and useful concept. The F9P boards from Gumstix won’t be available for sale until at least Feburary next year but I thought I would share the results of some initial testing. From a performance perspective, I would expect these boards to be similar to F9P boards from other suppliers.
For a first look, I chose to compare the F9P to an M8T for one of my typical driving-around-the-neighborhood exercises. I looked at both the internal real-time F9P solution and the RTKLIB solutions, both real-time and post-processed.
For the base stations, I connected a CSGShop M8T receiver and a Gumstix F9P receiver through an antenna splitter to a ComNav AT330 dual frequency antenna on my roof. Since RTKLIB doesn’t yet fully support the receiver commands needed to setup the F9P, I used the most recent version (18.08) of the u-blox u-Center app run on a Windows laptop to configure the F9P receiver using the documentation on the u-blox website. I then saved the settings to flash. The receivers were connected to a laptop with USB cables and I broadcast the base observations over the internet on a couple of NTRIP streams using STRSVR and RTK2GO.com as I’ve described previously. I configured the F9P to send RTCM3 1005, 1077, 1087, 1097, 1127, and 1230 messages which include base location, raw observations, and GLONASS biases.
For the most part the u-blox documentation is well written and this exercise was fairly straightforward, but I did run into a couple of issues. First of all, when I plugged the F9P receiver into the laptop, Windows chose the standard Windows COM port driver instead of the u-blox GNSS COM port driver that it chose for the M8T receiver. You can see this in the screen snapshot below where COM17 is the M8T and COM21 is the F9P.
Both drivers allow the user to set the baudrate in the properties menu available by right clicking on the device name. With the u-blox driver, the baudrate setting doesn’t seem to matter which makes sense since it is a USB connection. I have always left the u-blox driver baudrate at the default of 9600 baud without any issue. With the windows driver, however, I found that I had to increase the baudrate setting to 115200 to avoid data loss issues. I have run into a similar problem before for sample rates greater than 5 Hz when the M8T is accessed through it’s UART interface and an FTDI converter is used to translate to USB, rather than communicating directly through it’s USB interface. I verified though, that in this case the board is using the USB interface on the receiver and not the UART interface. Not a big deal, and it may be unique to this board, but something to be aware of in case you run into a similar problem.
The second problem I ran into is that the F9P module seems to be sensitive to my antenna splitter, a standard SMA DC block and tee which I have used on many other receivers before without issue. It works fine if the F9P power is blocked but if the M8T power is blocked, the F9P seems to detect the tee and shut off the antenna power. Again, not a big deal, but something to be aware of.
For the rovers, I used a u-blox ANN-MB-00 dual-frequency antenna for the F9P receiver. This is the antenna u-blox provides with its F9P eval units. I had planned to split this antenna signal to both receivers as I usually do, but I ran into the problem described above, and not fully understanding the issue yet, ended up using a separate Tallysman TW4721 L1 antenna for the M8T receiver. Both antennas were attached directly to the car roof which acted as a large ground plane.
I used a hot spot on my cellphone to stream the NTRIP base station observations from the phone to a laptop and then to the F9P receiver and to two instances of RTKNAVI, one for each rover receiver.
Streaming the base observations to the F9P, while simultaneously logging the internal RTK solution and the raw rover observations, and also sending the raw rover observations to RTKNAVI, all over a single serial port can be challenging since only a single application can be connected to the serial port at one time. Fortunately RTKLIB has a little trick to deal with this. If the “Output Received Stream to TCP Port” box is checked in STRSVR and a port number specified as shown below, all data coming from the other direction on the serial port will be redirected to a local TCP/IP port. This data can then be accessed by any of the other RTKLIB apps as a TCP Client with server address “localhost” using the specified port number.
I set up the F9P rover to output both raw observation and navigation messages (UBX-RXM-RAWX/ UBX-RXM-SFRBX) and solution position messages( NMEA-GNGGA). RTKNAVI then logged all of these messages to a single log file. RTKCONV and RTKPLOT can both extract the messages they need from this file and ignore the rest so combining them was not an issue.
The NMEA-GNGGA messages from the F9P default to a resolution of 1e-7 degrees of latitude and longitude which works out to roughly 1 cm. For higher resolution you can increase the resolution of the GNGGA message by setting a bit in the UBX-CFG-NMEA message. Unfortunately I did not realize the resolution issue until after I collected the data and so my results for the internal F9P solution for this experiment were slightly deteriorated by the lower resolution.
I used the most recent demo5 b31 code to calculate all of the RTKLIB solutions. Both the demo5 and the 2.4.3 versions of RTKLIB have been updated to translate the new dual frequency u-blox binary messages. The demo5 solution code will process all the dual frequency observations but I don’t believe 2.4.3 code is able to process the E5b Galileo measurements yet. The RTKLIB 2.4.2 code however does not have any of these updates.
The demo5 code updates made in the recent B30/B31 versions are based on the updates from the 2.4.3 B30 code but include some modifications to the u-blox cycle slip handling that I had previously added to the demo5 code for the M8T. Since the demo5 code is primarily aimed at low cost receivers I also made some changes to make the E5b frequency a little easier to specify and faster to process.
To run the RTKNAVI F9P real-time solution, the only significant change I needed to make to the default M8T config file was to change the frequency option from “L1” to “L1+L2+E5b”. I should have also changed the base station position to “RTCM Antenna Position” to take advantage of the F9 base station RTCM 1005 base location messages but neglected to do this. This caused the RTKNAVI solution to differ from the F9P solution by small constant values due to the approximate base location used in the RTKNAVI solution. I later used exact base locations for the RTKLIB post-processing solutions to verify that the different solutions did in fact all match.
Once I had everything set up, I then drove around the local neighborhood, emphasizing the streets with most challenging sky views since I knew both receivers would perform well and be difficult to distinguish if the conditions were not challenging enough.
I first converted the binary log files to observation files using RTKCONV and verified that the F9P was logging both L1 and L2 measurements for GPS, GLONASS, and Galileo. I had the Bediou constellation enabled as well but as I verified later, there were no fully operational Bediou satellites overhead when I collected the data.
Here is an plot of the L1 observations for the M8T on the left and the F9P on the right. I have zoomed into just two minutes during some of the more difficult conditions to compare the two. The red ticks are cycle slips and the grey ticks are half cycle ambiguities.
First, notice that the F9P does not log observations for the SBAS satellites, while the M8T does, giving the M8T a couple more satellites to work with. However, what’s also interesting, and I don’t know why, is that the F9P collected quite good measurements from the Galileo E27 satellite, while the M8T did not pick up this one at all. Of course the F9P also got a second set of measurements from the second frequency on each satellite and so overall ended up with nearly twice as many raw observations as the M8T.
Also notice that the F9P reports somewhat less cycle slips and many less half cycle ambiguities than the M8T. Some of this might be because of the different antennas, but particularly the large difference in half cycle ambiguities suggests that u-blox has made other improvements to the new module besides just adding the second frequencies.
Another thing to notice is the number of Galileo satellites. If you compare these plots to earlier experiments I’ve posted, you’ll notice there are more Galileo satellites now as more and more of them are starting to come online. The extra satellites really help the M8T solutions because as you can see, they tend to have the highest quality observations through the most difficult times. Again I don’t know why this is. It doesn’t appear to be as true for the F9P though.
Next I looked at the real-time solutions. First, the RTKLIB solutions with RTKNAVI for both receivers. For the full driving route, the M8T solution had a 77.3% fix rate and the F9P solution had a 96.4% fix rate. Here is a zoom into the most challenging part of the drive, an older neighborhood with narrower streets and larger trees, the M8T is on the left, and the F9P on the right. Fixed solutions are in green and float in yellow. Clearly here the F9P significantly outperformed the M8T.
The F9P internal solution did even better with a 99.2% fix rate, as shown in the plot below. All three solutions agreed within 2 cm horizontal, a little more in vertical, and none of them showed any sign of any false fixes.
I didn’t do any static testing to characterize time to first fix as I sometimes do, but for this one run the RTKLIB time to first fix for the M8T was 18 seconds while the RTKLIB F9P solution reached first fix in 6 seconds. In both cases, RTKLIB was started after the hardware had time to lock to the satellites and acquire navigation data for all satellites. The demo5 RTKLIB code has an additional fix constraint based on the kalman filter position variance to minimize false fixes while the filter is converging and so this can sometimes affect time to first fix. I had increased this parameter to 0.1 meter for this experiment since the large number of measurements reduces the chance of a false fix. This constraint did not limit the M8T time to first fix but it did so for the F9P, meaning the F9P would have reached first fix even faster if this constraint were opened up more. I can’t tell what the equivalent number would be for the internal F9P solution from this data since it had already been running and achieved a fix before I started logging the data but generally the F9P seems to acquire first fix very quickly.
Next I post-processed both data sets with RTKLIB using the combined-mode setting to run the kalman filter both forwards and backwards over the data. This noticeably improved the results, bringing the fix rate for the M8T up from 77.3% to 96.1% and the F9P fix rate from 96.4% to 98.8%.
Obviously this is not enough data to make any definitive conclusions, but so far I am very impressed with the F9P! Both the raw observations and the internal RTK solutions for the F9P look as good as anything I’ve seen from receivers costing many times what this one cost.
If anybody would like to look at the data from this experiment more closely, I have uploaded it to here. I should mention that all the fix rates I specify in this post and other posts won’t exactly match the fix rates in the raw solutions, since I adjust the data start and end times to be consistent between data sets and to start after all solutions have achieved first fix. I believe this is the fairest way to compare multiple solutions, especially when there is a mix of internal and RTKLIB solutions
Also, I’d like to thank Gumstix again for making these modules available to me for evaluation!
Reviewing the config files I used for this experiment I discovered that, while I had intended the real-time and post-processing config files to be identical, there were in fact some small differences between them. One difference in particular, that appears to have affected the results as described above, is that I reduced the minimum number of consecutive samples required to hold ambiguities (pos2-arminfix) from 100 to 20 for the post-processed config files. A value of 100 corresponds to 20 seconds at the experiment’s 5 Hz sample rate which is a value I have typically used. However, with lower ambiguity tracking gain (pos2-varholdamb=0.1) and the increase in observations coming from including Galileo, the chances of false fixes is reduced and I have been tending to use lower values of arminfix in more recent experiments. Reducing this value appears to explain a large part of the jump in percent fix for the M8T between real-time and post-processing, rather than the switch from forward-only to combined that I attribute it to above. These differences only affect the comparisons between RTKLIB real-time and post-processed results, and not between the M8T and the F9P since the config files were consistent between the two receivers.
This was only intended to be a quick first look at the F9P. It will require more data and more analysis to properly characterize the F9P so I won’t try to do that here but I will share the table shown below which includes a few cases I have run since the original post. I hope to dig into the details in future posts.
One last point worth making is that while at first glance the post-process fix percent increase from M8T=96.0% to F9P=99.3% may not sound that significant, it is in fact a factor of nearly six if you consider it as a decrease in float from 4.0% to 0.7%.
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.
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.
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.
Swift internal RTK
Swift RTKLIB PPK
U-blox RTKLIB RTK
U-blox RTKLIB PPK
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.
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.
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.
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.
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 ]
ComNav was kind enough to recently lend me two of their K708 receivers for evaluation. I also have a Tersus BX306 receiver that was given to me earlier by Tersus for evaluation. Both of these are relatively low-cost dual frequency receivers that offer full GPS L2 support., unlike the SwiftNav receiver I evaluated in my previous posts which is GPS L2C only. I have described the Tersus BX306 before in a previous post but last time I was not able to evaluate it with a local base since I did not have a second dual frequency receiver that supported L2. Tersus has also just recently released their new V1_19 firmware so I included that in this evaluation. As usual I’ve also included a pair of u-blox M8T receivers to use as a baseline.
Here’s a photo that shows the three receivers each with their associated serial port and power cabling. The u-blox M8T is on the left, Tersus BX306 in the center, and ComNav K708 on the right. The ComNav receiver is actually only the smaller daughter board in the center of the larger board, everything else is part of the very sturdy but rather clunky dev kit.
The Tersus BX306 is priced at $1699 but lower priced versions are available. For example, the BX305 supports GPS L1/L2 but Glonass G1 only, and the BX316R is GPS L1/L2 and Glonass G1/G2 but provides only raw observations for post-processing. Both of these options are priced at $999.
The ComNav K708 is similar to the better known K501G but newer and more capable. ComNav doesn’t list their prices on their website but they have told me that both the K501G and the K708 configured to be equivalent to the K501G (GPS L1/L2 and GLO G1/G2) are available for less than $1000.
Both the Tersus and the ComNav receivers come with GUI console apps which are good for initially getting familiar with the receivers. However each had their unique quirks and I found myself fairly quickly abandoning them for the more familiar quirks of the RTKLIB apps. Managing three simultaneous real-time solutions involving five separate receivers while also logging raw observations for all five was actually quite challenging and I made a couple of unsuccessful runs before I got everything working at the same time.
I found that the key to turning this into a manageable and automated process was replacing each of the different manufacturer’s GUIs with an RTKLIB stream server (STRSVR) and a plotter (RTKPLOT) each with it’s own dedicated .ini file. Eliminating the GUIs also gave me a better understanding of exactly what the receivers were doing and what the GUIs were doing.
STRSVR provides a standardized, always visible red/yellow/green indicator for each stream along with a continuously updated bps number that indicates not only that the connection is alive, but that data is flowing. This allowed me to tell at a glance that all streams were flowing and that all the log files were being updated. Using the “-t” option in the command line to specify a title for each window also helped keep things straight.
Both receivers are configured by sending Novatel-like ASCII commands over the serial port and these can be added to the STRSVR Serial “Cmd” window and saved to a “.cmd” file, similar to configuring the u-blox receiver. Notice in this example, I also sent a reset to the receiver every three minutes which was a convenient way to automate the testing of acquisition times.
I connected both dual frequency rover receivers to my laptop, using two COM ports for each one and using a USB hub to get enough ports. I set up both receivers to output NMEA solution messages and raw RTCM observation messages on COM1 at 5 Hz and accept RTCM base station data on COM2. Both receivers have decent reference manuals to describe their command set but I also found this Hackers Guide to the K501G from Deep South Robotics quite useful for getting started.
For reference, here are the commands I used to configure the Tersus rover:
and here are the commands I used for the ComNav rover:
interfacemode compass compass on unlogall com1 fix none refautosetup off set cpufreq 624 rtkobsmode 0 rtkquality normal set pvtfreq 5 set rtkfreq 5 log com1 gpgga ontime 0.2 0 nohold log com1 gprmc ontime 2 0 nohold log com1 rtcm1005b ontime 10 log com1 rtcm1004b ontime 0.2 log com1 rtcm1012b ontime 0.2 log com1 rtcm1019b ontime 2 log com1 rtcm1020b ontime 2
interfacemode com2 auto auto on saveconfig
My intent was to setup the receivers in default RTK mode with a 5 Hz output for NMEA solution messages and RTCM raw observation and navigation messages. The one exception to default was that I found the “rtkquality” setting on the ComNav receiver defaulted to “quick” which was giving me false fixes, so I changed this to “normal” and that seemed to fix the problem.
By setting things up this way, I only need to click on the correct combination of icons (each tied to it’s own .ini file) from my RTKLIB menu to bring up the correct windows and a few more clicks to start the streams in a simple and repeatable way.
I’m jumping ahead a little bit, but here is a screen capture of the rover-connected laptop streaming two NTRIP sets of base station data to the rovers while simultaneously logging and plotting the computed solutions for all three rovers along with raw observations for all five receivers, and also computing an RTK solution for the M8T receivers with RTKNAVI.
I should mention that there was one very annoying bug that was introduced to STRSVR in one of the recent RTKLIB releases that gives an error if a data file already exists instead of an overwrite dialog but I did fix this and add it to a new demo5 b29b code release available at the download page on rtkexplorer.com. The new release also includes a fix for another bug that prevented the “-i” command line option to specify a config file for RTKPLOT from working properly.
I then setup the second ComNav receiver as a base station for both dual frequency rovers and used a single COM port to stream RTCM messages from the receiver to a PC. I used an STRSVR window on the PC to stream the messages to a NTRIP caster using the free RTK2GO NTRIP caster service as I have previously described. I used ComNav AT330 antennas for both the base and rovers with the rover antenna shared by all three rover receivers. I did not have enough connector hardware to share the base antenna so used a separate u-blox antenna for the M8T base receiver.
The next step was to collect some data. I started with a relatively simple challenge, a static rover with a reasonably open sky view and a short baseline. The ComNav and Tersus solutions both assume the rover may be moving so I set up the M8T solution as kinematic as well.
Let’s first look first at the ComNav solution compared to the M8T solution. Both solutions were computed real-time. RTKPLOT will plot NMEA data but it did not seem to like the mix of NMEA and RTCM data in the same file. To deal with this, I wrote a simple matlab script to strip the NMEA messages from the log file and put them in a separate file. Below I have plotted only the Up/Down axis for both receivers just to avoid too much data, the M8T is on top, and the ComNav below. Each of the larger breaks in the fix was caused by me disconnecting then reconnecting the antenna to force a re-acquire.
The M8T configuration was identical in the left and right plots, but the ComNav “rtkquality” parameter was set to “quick” in the left plot, and “normal” in the right plot. It’s not as obvious here as it is in the other axes but the third ComNav fix in the left plot is a false fix and had over 0.2 meters of error in the N/S axis. Changing the “rtkquality” parameter to “normal” seemed to help and I did not notice any more false fixes after making that change.
The ComNav receiver typically achieved a fix very quickly regardless of the “rtkquality” setting, usually in less than 30 sec although in one case it took a minute and a half. This was noticeably faster than the M8T receiver, which took from 1 to 3 minutes each time in this example to achieve a first fix.
The scales are the same in the two sets of plots, so as you can see, the ComNav fixes are a fair bit noisier than the M8T fixes. I don’t know why this is but it is something that I hope to investigate more.
Unfortunately I got a mix of good and not so good results from the Tersus receiver. I did not see this behavior in my previous evaluation so I’m fairly certain this is not a problem with the hardware. I suspect it has something to do either with my setup or with the new firmware. I am going to hold off on sharing any of the Tersus data until I understand better what is going on.
Next, for a more challenging test, I moved the rover antenna to a spot with fairly poor sky views located between several large trees. The sky view directly above the antenna was clear but a large percent of the overall view was blocked. Again, I just plotted the Up/Down axis with the M8T position solution on the top and the ComNav solution on the bottom.
I disconnected and reconnected the antenna three times in this experiment. The M8T did not get a fix in the first try before I gave up after 12 minutes, but it did after 13 and 11 minutes in the second two tries after briefly getting a false fix in the second try. Definitely marginal conditions for the M8T. The ComNav receiver did significantly better with two fixes in less than 3 minutes and one in 9 minutes. The errors were relatively large in the first fix but based on the other two axes it was not a false fix. You can also see that the ComNav third fix was noticeably noisier than any of the other fixes on either receiver, again for unknown reasons.
For the third part of the experiment I moved the receivers into my car and attached the antenna to the roof and collected data for three spins around the neighborhood. The results are plotted below. In each case the M8T real-time solution is on the left, and the ComNav is on the right. In the data in the first row, I shared a single antenna for all three receivers. For the data in the second and third row I used separate antennas. I did not change any of the config settings for any of the receivers between these runs and the above runs except that the rtkquality setting was still set to “quick” for the ComNav receiver for the second and third rows.
I have not had a chance to look at this data closely but at first glance, from a fix percentage perspective only, I don’t see significant differences between either of the receivers. The obvious advantages the ComNav receiver demonstrated in faster fixes in the static tests did not seem to carry over to the moving rover case. I do plan to look at the raw data more carefully to see if I can understand better why this is. For whatever reason, the Tersus receiver seemed to perform better with a moving rover than it did with a static rover, and was very similar in fix percentage to the other two receivers in this part of the experiment.
Next I planned to post-process the raw data through RTKLIB to better understand what is going on but as usual, nothing is as simple as you hope for, and I ran into another issue.
Both the Tersus and the ComNav receiver report a mix of 2W and 2X measurements for the raw GPS L2 measurements. If the satellite supports the newer L2C code it locks to that and reports a 2X code, if not, it locks to the older L2 and reports a 2W code. You can see this in this example observation epoch from the Rinex conversion of the ComNav receiver RTCM output. The left three columns are the L1 measurements, the middle three columns are the L2 (2W) measurements and the right three columns are the L2C (2X) measurements. You can see that all the GLONASS satellites report L2 measurements only but that the GPS satellites are a mix of L2 and L2C measurements.
This is new for the Tersus receiver, it did not do this when I evaluated it with the older firmware. For the ComNav receiver, this is the default behavior but it is possible to change this through a command to specify L2 only, no L2C. As far as I can tell, the Tersus only supports the mixed L2/L2C mode. All the data I collected for this experiment was in the mixed L2/L2C mode.
Unfortunately RTKLIB does not like this format and throws away all of the L2C measurements. It is possible to fool RTKLIB into using all the measurements by changing the 2X’s in the “Obs Types” list in the file header to 2W’s but I haven’t looked yet at to what extent mixing the code types affects the solution or how to avoid throwing away the L2C data without editing the header.
I will leave a more detailed analysis of the data to a future post. My initial impression from these results though, is that although there are some obvious advantages with the ComNav receivers, replacing a pair of low cost single frequency receivers with a pair of low cost dual frequency receivers does not magically make the challenges of precision GNSS go away and that it will still require close attention to the details and recognition of their limits to get good results with either set of receivers.
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.
It looks like it is no longer possible to access the raw GPS measurements on the newest version of the u-blox M8N receiver. Access to these raw measurements on the M8N has always been through debug messages not officially supported by u-blox. Last year, when they migrated from the 2.01 version of firmware to the 3.01, version they scrambled the output of these messages so they were no longer readable by RTKLIB.
Until recently though, the units they were shipping still had an older 2.01 version of ROM. With these units it is possible to downgrade the firmware to 2.01 using the instructions on their website. With the older firmware loaded, the receivers revert to their previous behavior and the debug messages are no longer scrambled.
Apparently their newest units are shipping with a 3.01 version of ROM and this ROM is not compatible with the older 2.01 version of firmware. If you attempt to load the older firmware it will appear to succeed but will still be running the newer code.
You can see what version of ROM and firmware your receiver is running using the UBX-MON-VER message from the u-center console. The example below shows the message output for one of the newer modules with the 3.01 ROM after attempting to download the older firmware. I believe the firmware listed under “Extension(s)” is the ROM version and the firmware listed under “Software Version” is the version of firmware loaded to flash. In this case you can see that the ROM is version 3.01 and that the flash is still running version 3.01 even though it was attempted to load the 2.01 firmware.
In an older version of the M8N module, the ROM code listed under “Extension(s)” would have been 2.01 and the firmware listed under “Software Version” could be either 2.01 or 3.01 depending on how old the module was and what firmware had been downloaded to it.
There are a few more details about the issue on the u-blox forum in this thread. Thanks to Marco for making me aware of the issue and Clive and Helge for providing a detailed explanation of what is going on.
If you are using the u-blox M8T, and not the M8N, then you will be using the officially supported raw measurement messages and would normally not care about access to the debug messages. The only exception I know of is that the resolution of the SNR measurements are 0.2 dB in the debug messages and 1.0 in the official messages. I have not confirmed that the debug messages on the 3.01 M8T firmware are scrambled but it is likely that they are.
[Note 6/25/17: A couple of readers have pointed out that this is not the whole story. It would have been more correct to say that the newest M8N modules are not usable with the publicly available versions of u-blox firmware and RTKLIB. It turns out that u-blox did not use a particularly sophisticated method to scramble the debug messages and there are now several modified versions of u-blox firmware and RTKLIB floating around that have been hacked to unscramble the messages. I don’t want to get into the question of ethics or legality of using these codes but just say that I personally am less comfortable using the debug messages in the modules where u-blox has made an obvious attempt to prevent this and have avoided any use of them at least for the time being.]