New firmware, new satellites, new code

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.





6 thoughts on “New firmware, new satellites, new code”

  1. Yep, the newly downloaded one produces the correct results.
    I looked at the first .zip file I downloaded on or about Feb 23, and the rtkconv.exe was from Feb 9.
    -rw-r–r– 1 kenm kenm 5548032 Feb 9 15:16 rtkconv.exe
    Todays download rtkconv.exe is from Feb 23.
    -rw-r–r– 1 kenm kenm 5548032 Feb 23 12:33 rtkconv.exe

    Problem solved. Thanks again.


  2. Hi Tim,
    Any chance you didn’t include some changes to ublox.c that allow it to work with the .cmd files from your b26b distro?
    Line 1241 from ublox.c –> {FU1,FU1,FU1,FU1,FU1,FU1,FU1,FU1,FU4}, /* GNSS */

    is designed to use a line of the form:

    !UBX CFG-GNSS 0 32 32 1 6 16 16 0 65537


    set GPS 8-16 channels

    !UBX CFG-GNSS 0 32 32 1 0 8 16 0 1 0 1 1

    which should be supported in ublox.c by:

    {FU1,FU1,FU1,FU1,FU1,FU1,FU1,FU1,FU1,FU1,FU1,FU1}, /* GNSS */

    The .cmd files for setting GNSS from b26b binary distro do not work with the current ublox.c code.


    1. Hi Cynfab. Good catch! This is not a problem with b26b, it has been there for a long time. I just updated the .cmd files in the b26b distro to use the correct format. The CFG-GNSS commands in my previous sample .cmd files will not change anything in the ublox configuration. If you had already configured the satellite constellations with u-center before running RTKLIB you would not notice this error and that is why I didn’t catch it.


      1. Thanks Tim,
        Found a problem with rtkconv.exe from your b26b binarys. I recorded a .ubx file with my M8T with Galileo enabled and then processed the file with rtkconv.exe I got no data for the Galileo sats in the resulting .obs file I then processed the same file with my rtkconv_qt on my ARM SBC and got plenty of Galileo data. As the L1X->L1C change is in ublox.c I don’t see how rtkconv.exe could be missing that data unless it didn’t get recompiled or some such… (yes, GAL was checked in the options section)

        A snippet from the .obs file processed with rtkconv.exe
        R19 18427991.517 2 98577327.242 1 2876.703 36.000
        E 1
        R 7 20360689.457 4 108992338.335 2 -2419.549 33.000
        S35 35828209.025 4 188278510.262 2 -253.754 33.000
        G19 23165909.270 4 121737665.815 2 3782.107 35.000
        G17 20938070.701 1 110030285.270 1 2989.383 40.000
        G13 20763142.703 8 109111036.581 4 2024.437 30.000
        R20 22411159.761 4 119842462.748 2 4363.463 29.000

        The same snippet from the .obs file processed with rtkconv_qt
        R19 18427991.517 2 98577327.242 1 2876.703 36.000
        E 1 21728883.601 4 114186063.356 2 541.426 35.000
        R 7 20360689.457 4 108992338.335 2 -2419.549 33.000
        S35 35828209.025 4 188278510.262 2 -253.754 33.000
        E26 20385285.380 8 107125393.004 3 1857.593 31.000
        G19 23165909.270 4 121737665.815 2 3782.107 35.000
        G17 20938070.701 1 110030285.270 1 2989.383 40.000
        G13 20763142.703 8 109111036.58114 2024.437 30.000
        E14 13773364.304 4 72379535.542 2 -1129.627 34.000
        R20 22411159.761 4 119842462.748 2 4363.463 29.000

        The M8Ts work very well…;>))


        1. Hi Cynfab. I can’t duplicate the problem. I downloaded the zip file again just now and ran the unzipped rtkconv on a ubx file with Galileo data and everything seemed to work. Can you try again and send me the ubx file if you still see the problem?


Leave a Reply

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

You are commenting using your 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 )

Google+ photo

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

Connecting to %s