CSG Shop is now shipping all of their M8N and M8T u-blox receivers with the latest version 3 firmware. This is not such good news for the M8N units since the raw measurements are scrambled and these receivers need to be downgraded to the previous firmware version before using with RTKLIB. For the M8T receivers though, the new firmware is good news because it contains support for the Galileo satellite system.
I now have two of their M8T receivers with the new firmware and did a little testing to see how RTKLIB works with the Galileo measurements. I did have to make a couple small changes to get things working.
First of all, the RNX2RTKP compile options for including the Galileo code was not enabled. For some reason, all the other apps did have this option enabled. To enable it, I had to add “ENAGAL” to the “Preprocessor Defintions” for C/C++ in the Project menu in Visual Studio.
The second issue I ran into was in the decode_rxmrawx() function that decodes the raw u-blox RXM-RAWX messages. There is a line of code in this function that sets the code type based on the system.
This line sets the code to L1X for Galileo, but that code type doesn’t seem to be supported by RTKLIB and the measurements in the RINEX file for the Galileo satellites get left blank. Changing the “L1X” in the above statement to “L1C” resolves the problem. That leaves an unnecessary check in the code but I will leave it there at least until I understand what it was supposed to do. After that everything else worked fine including ambiguity resolution with the Galileo satellites, so that was quite encouraging.
Next, I put the two receivers outside in the front yard to collect a longer set of data. Not an ideal environment because they were close to the house but fairly open skies otherwise. In an hour of data collection I got measurements from 11 GPS satellites, 8 GLONASS satellites, 5 Galileo satellites, and 3 SBAS satellites. After collecting the data, I processed it with various constellation options to see how they compared. For all the solutions, I set ambiguity resolution mode to “continuous”, position mode to “kinematic”, and opened up the position variance threshold for AR (arthres1) to allow the solution to lock up as early as possible. I also enabled all constellations for ambiguity resolution in each case. Here’s how they compared:
Note that the time scale on the GPS-only plot is very different than the others since it took much longer to lock up than any of the other combinations. With the GPS satellites only, there was an initial short false fix after 14 minutes, then a good fix at 27 minutes that lasted a few minutes but it did not get a solid fix until 43 minutes after it started. That’s a long time to wait! Adding a second constellation significantly improved the results, with solid fixes coming after two minutes with GLONASS added, five minutes with SBAS added, and 7 minutes with Galileo added. Adding a third consellation improved things even more, with times to first solid fix varying from 12 secs for GPS+SBAS+GLO, 3.5 min for GPS+GAL+GLO, and 6 min for GPS+SBAS+GAL. Using all four constellations gave a time to first solid fix of 2 minutes, not the fastest time, but better than two out of three of the three constellation answers.
It is risky to conclude too much from one data set, but these results are consistent with other data I’ve looked at (for three constellations) that show the more satellites you use the better the answer. This seems to make sense to me since more information should be better than less information. However, I often hear or read recommendations to use only the GPS data for better results which I don’t understand. If anyone has data to support that recommendation I would like to see it to understand it better.
I do sometimes see that one bad satellite can prevent or delay a solution no matter how many good satellites there are and this may be part of the answer. The more satellites you use, the higher chance there is of having a bad one and RTKLIB is not great at rejecting a bad satellite. The “arlockcnt” and “ARFilter” features do help prevent bad satellites from getting into the AR solution but they do not reject a satellite if it goes bad after being accepted into the solution. I have added a new feature starting with the demo5 b26a code that does try to reject bad satellites after they have been accepted into the AR solution but have not had a chance to do a lot of testing on it yet. It was enabled for the test above and may possibly have helped, I did not look into the details. The feature is enabled by setting the “pos2-mindropsats” to a value lower than the number of satellites in the solution, in which case it will cycle through dropping all the satellites, one by one, one each epoch, and reject a satellite that has a large negative effect on the AR ratio. If you try this feature, be careful not to set the minimum satellite threshold too low or you will increase the chances of a false fix. I would recommend values no lower than 10 satellites.
I have released a new version of the demo 5 code (b26b) with the fixes for Galileo, a couple of new features and fixes, and GUI updates for RTKPOST and RTKNAVI for all the new input parameters for both b26a and b26b codes. The binaries and a list of the changes are available here. The source code is available on my Github page.