Ublox M8N vs M8T

Thanks to the generosity of Emlid, I am now the proud owner of two of their Reach precision GPS units. At a list price of $570 for a pair, these fall more into the category of low-cost rather than the ultra-low cost receivers I have been working with, but they do allow me to do some comparisons between the two. Their units use the more capable (and more expensive) Ublox M8T receivers rather than my Ublox M8N receivers and also have higher quality (and more expensive) Tallysman 4721 antennas, rather than the cheap antennas that were included with my receivers.

To compare the two I collected a fairly challenging data set, with maximum distances from the base station of over two kilometers and maximum velocities of over 70 km/hr, with relatively unobstructed rovers, but partially obstructed base stations. I mounted one of my receivers and a Reach unit on top of my car and also one of each at the base location. Here is a Google earth plot of the ground track. The Google Earth plots are a really nice feature of RTKPLOT I have not used until now but have quickly become a fan of. I could not make this feature work with the 2.4.3 version of RTKPLOT so had to go back to the 2.4.2 version. I also found I had to specify the solution format (out-solformat) as “xyz” instead of the “enu” that I usually use to get the solution in a format Google can use. The track was over a mix of dirt and paved roads running through agricultural fields and next to residential areas.


Here is a plot of the base station location, marked in red below. It is somewhat obstructed by the sheds and boats around it. I selected this location in part because it was very windy that day and this spot was fairly sheltered from the wind, but also thought it would make the solution a bit more challenging and therefore help differentiate the two receiver sets.


Most of the rover’s route was relatively unobstructed, but there were a few scattered trees near the road in some locations. The plot below shows an example of one of these spots. Note also, that the ground track goes off the road a bit at the end of the loop. I suspect this is due to inaccuracies in the base station location (and maybe the Google maps) rather than the RTKLIB solution since I did not make any attempt to calibrate the base station against any known reference.


Here’s the base station observation data, the M8N is on the left, the Reach M8T data on the right. From a cycle slip perspective they are fairly similar but we see a few of the satellites (G15, R16, and R18) are noticeably better with the Reach. This is most likely because of the higher quality antenna.

                                  M8N                                                              Reach M8Tunion4

Looking at the SNR vs elevation for both receivers, we see the Reach has noticeably higher signal strength especially in the lower elevation (10-20 degrees) region where it is most important. Again, this is to be expected with the higher quality antenna.  For some reason, the M8T SNR numbers are rounded off to the nearest integer. I don’t know why that is, but that is what makes the plots look like they are formatted differently.

                                 M8N                                                                       Reach M8Tunion5

Looking next at the rover data, here are the observations for the two receivers.

     M8N                                                                              Reach M8Tunion6a

The rovers were stationary until 00:34 and then moving till 00:57, then stationary again. While they were moving and at the end when they were stationary, the two look fairly similar from a cycle-slip perspective with maybe a slight advantage for the Reach. However, during the initial stationary period, there were several slips that occurred simultaneously on every satellite in the M8N data. I’ve circled one of them in blue above.  I believe these must be caused by some sort of discontinuity in the receiver and have nothing to do with the satellite signals themselves. My best guess is that they were caused by temperature fluctuations in the chip. It was a very hot day, with an intense sun heating the dark car roof, combined with a strong wind that would create a cooling effect. Because the antenna that was connected to the M8N receiver has only a one inch lead, it was mounted on top of the car in the sun, while the M8T receiver, with a longer antenna lead, was mounted inside the car and not subject to the same temperature fluctuations. Also, notice that the simultaneous slips all occurred near the beginning of the data set, possibly while the receiver was still reaching some sort of thermal equilibrium. To try and avoid this in the future, I will either switch to another inexpensive antenna I have with a longer lead, or let the receiver sit longer before starting to collect data.

Unfortunately these slips occurred during the initial stationary period I use for the first acquire and prevented that acquire from occurring. Rather than give up on the data, though, I decided to try running a solution with the M8N rover and the M8T base. I don’t know if it was because of the better signal strength, or because I just got lucky, but I was able to get an initial acquire with that combination. So for this exercise, the rest of the data is all based on a comparison between the M8N rover and the Reach M8T rover, both referenced to the M8T base station. It turns out that having a single base station also makes the accuracy analysis a little easier as I will describe later. This is not exactly the comparison I wanted to make, but one I think is still worth doing.

So how did they do? Here’s the solutions using my demo4 code. The input configurations were identical with one exception. Since with the M8T receivers, RTKLIB can resolve the GLONASS integer ambiguities without assistance, while with the M8N receivers, it can not, I set the input parameter “gloarmode” to “on” for the M8Ts and to “fix-and-hold” for the M8Ns. This enables my extension to the fix-and-hold feature to adjust for the additional errors on the GLONASS and SBAS satellites.

                             M8N                                                                        Reach M8Tunion7

The Reach solution (on the right) looks very clean with a very fast acquire and then 100% fixed values after that. The M8N solution (on the left) also acquired quickly but then ran into the simultaneous cycle-slips, causing problems until it re-acquired at 00:40. After that it stayed fixed for nearly 100% of the time with a short dropout around 00:49.

The next questions, of course, are: Do the solutions match? And are the fixes all accurate? To check this, I will use a similar technique I did earlier when I had only two receivers, both mounted on the rover. For that case, I solved for the distance between the two receivers which forms a circle equal to the distance between the receivers. In this case, I will solve for the distance between each rover and the base, then difference the two. This should also give us a circle with radius equal to the distance between the two rover receivers. Having only one base simplifies things by avoiding addition of a second term caused by the separation between the two base receivers. Here’s the result of that operation, plotted only for the fixed solution points since those are the ones we are counting on to be accurate. On the left is the position difference (x,y,z) and on the right is the ground track difference.

                           M8N                                                                            Reach M8Tunion8

The separation between the two receivers on the car roof was 15 cm and we see here that most of the points fall on the circle of that radius. However, there are several deviations, up to half a meter in error. They are also easy to see as spikes in the z-axis on the left plot. These are unexpected and quite concerning since we really rely on the fix status to let us know which points are valid and accurate.

Zooming in on the observation data for the largest of these spikes at around 00:51 shows that both rover receivers saw cycle slips on satellites G02 and G13 at this time, presumably from passing a tree or other obstruction.

                                   M8N                                                                Reach M8Tunion9

Zooming in on the position data for this point, shows discontinuities in the Reach data but not the M8N data which is surprising, I had expected the opposite. As the driver of the car, I am certain that I did not drive over any meter high cliffs during the test, so the Reach M8T data must be wrong.

                                 M8N                                                                          Reach M8Tunion10

Looking at other error samples shows the same thing. It is more easily seen as spikes in the accelerations as shown here, especially the z-axis accelerations which only occur on the M8T data and not the M8N data

                               M8N                                                                       Reach M8Tunion11

So what could be causing these errors? The two solutions used identical code and input parameters except for the fix-and-hold for GLONASS integer ambiguities setting. I reran the M8T solution with this parameter enabled to make them completely identical but this did not fix the problem. With the code being identical we have to suspect the difference is in the receivers themselves or at least in their setup. The next step I took was to use the Ublox u-center evaluation software to examine all the registers for both receivers. It’s a little trickier to do this with the Reach receiver since we don’t have direct access to the M8T chip, but there are instructions on setting up a tcp port in the Reach documentation, which is what I did.

For the most part, the differences between the two receiver setups were slight but I did find one significant difference. The receiver dynamic platform model settings are quite different. I have my M8N receivers set up for a “Pedestrian” model, while the Reach M8T receivers are set up for the “Airborne <4g” setting. According to the Ublox M8 Receiver Description document, that setting is only recommended for extremely dynamic environments. Here’s the details from the manual.


I have heard differing opinions on whether this setting affects the front-end of the receiver or whether it only affects the back-end position calculations. If it only affected the back-end, then this setting would not matter since we use only the raw GPS measurements from the receiver. However, if it does affect the front-end, we might expect it to have an effect like this since it would most likely be opening up the bandwidths of the phase lock loops tracking the carrier-phases and thus minimizing any filtering effects.

So that’s where things stand at the moment with this data set. I see issues with both receiver sets and have speculated on what may be causing the problems but have not had time to verify that either one of my guesses is correct. I had hoped to do that before posting this article but it’s been almost two weeks since my last post, so I’ve decided to just go ahead and post what I have.

This also gives me the chance to ask if anybody else has seen similar issues and/or might have other possible explanations for what is going on?

I have also uploaded this data to my data set library.


28 thoughts on “Ublox M8N vs M8T”

  1. M8T is a timing module and M8N is a Standard Precision module. The firmware in the M8T module will be optimized to provided accurate TIMEPULSE.

    With this information, I feel we can use M8T for stationary purpose like base. Will this have any effect if we mount in on a moving object like drone ?


    1. If you are using just the raw observations from the M8T as input to an RTKLIB solution, then it should not matter that it is designed for timing use. The M8P is designed for position use and includes an internal RTK solution engine.


  2. Hello,
    I’m doing some testing. Do you know what would be the cause that
    airborne <4 nav5 mode is not working ok on M8N?
    I don’t get none or just one observation when I convert with rtkconv.
    I have 10Hz setting and 230400 baud.



    1. Hi Bene. I don’t know but I have seen similar problems when trying to configure the M8N when it is set to a high sample rate. I always reduce the sample rate to 1 Hz, then configure it, then increase the sample rate. Maybe this will help in your case.


    1. Hi Andreas,

      I took a quick look at your data and my latest version of RTKLIB code gives almost no fixes as well. If I get time I will take a closer look, but a couple things I notice right away. Your data starts with the rover moving. I always start my data collection with the rover stationary for at least 15 minutes to assure a clean initial acquire. I don’t have much experience trying to do the initial acquire on a moving rover but what I have seen with my setup is it tends to lead to false fixes. I don’t know if that will help in your case but it would be worth a try if it’s possible in your application.

      The other thing I notice is that there are lots of missing pseduorange messages for the GLONASS satellites in the trace file although the observation file looks OK. I don’t understand this and have not seen it before. I am not used to generating the observation files from .rtcm3 data files since all my raw data files are .ubx and wonder if it could be a formatting issue related to this.


      1. Thank you for the tipp with stationary starting! I will do this so in future!

        You can give my data/feedback also to emlid.
        I look forward to new reach view version with better possibilities for setting.



  3. Could you please upload the configuration file for GPS+ GNSS for UBLOX M8 module which can be work in RTKlib! because I have tried several times to configure that and I couldn’t get any data for processing in library, Can someone explain me why?


  4. Ok! Thanks you for your work – and your help for emlid.

    i use 2 identical reach devices, one as fixed base one as rover.



  5. Great blog rtklibexplorer. Congrats and thanks for sharing.
    Similar to James, my understanding is that platform dynamics do affect the solution quality in terms of satellite signal processing and integration (and thus raw measurement generation) as well as the position solution generated by the receiver itself. In addition, let’s keep in mind that phase observations are very sensible and thus rather not robust although accurate (and at high resolution). Furthermore, 8T provides documented carrier phases compared to 8N from which there was no documentation for the raw phase measurements. Have you asked Emlid how they explain their default parameter setting choice?
    Bottom line, from my personal experience with 6T and 8N models choosing the appropriate platform dynamic is significantly important. And 6T raw phases seemed to me more reliable than the ones from 8N. No experience with 8T though so far.


    1. Hi Octavian. Thanks for the feedback and confirmation on the platform dynamics. It’s great to get comments from expert users … I rely on you guys to keep me from going too far astray.

      I have been in communication with Emlid, they are aware of the issue and I believe they are going to add a user configuration setting for the platform dynamics.

      I’d like to better understand the difference between the M8N and M8T and now that I have both, hope to be able to more accurately quantify what they are. I suspect that at least some observations of differences between the two may be attributable to the fact that until the very recent B13 release, RTKLIB supported the half-cycle valid bit for the M8T but not for the M8N.


  6. Today i wont to test nav5 in gps_glonass_5hz at rover and base set to 4 (automotive)

    but i did not have clear sky to clouds are coming an going…. (yesterday the same)

    what i not unterstand:

    if i have a clear sky i can get fix with gps only..
    when it is cloudy it works not because of less satellites with good signal

    but when i switch to gps&glonass i got 8-10 satellites with good signal >45 but it´s very hard to get fix..

    if it is possible please can you upload a .conf file of your reach?

    regards Andreas


      1. Ok thanks!

        The difference is: i work real time and want to use reach for agricultural driving.
        your data sets are great, but you work with postprozessing and your betas.. 🙂
        maybe emlid will use some of them… or you can provide the code to upload to reach.

        but now i find a good setup – with the change to nav5 to 4.

        what i dont understand is i have only fix with gps. if i postprozess the file i can turn on/off glonass with no effect to fix %..



        1. Hi Andreas. All my work so far has been done with post-processing, so I really can’t help with implementing the changes in real-time. For the most part, the changes themselves should be just as applicable to real-time processing as they are to post-processing. I have been keeping in contact with Emlid and know that they read my posts and have included some of my changes in their code although I don’t know all the details.

          Are both your receivers M8Ts? If not, that might explain why you see fixes with the post-process solution and not the real-time solution. The real-time code does not have my extension to “fix-and-hold” to deal with the GLONASS biases between non-identical receivers. If this is the case, you would only see fixes in the post-process solution if you had set “gloarmode” to “fix-and-hold” and not if you had it set to “on”.


  7. Do the spikes also exist in vertical velocity for the Reach M8T? I’d also suggest taking a look at the position formal precision — maybe it could be used to discard unreliable epochs, instead of using just the ambiguities status.


    1. Hi Felipe. Yes, the spikes in the M8T velocity data are quite large as well, although they are most obvious in the acceleration data I show in the last plot in the post. I’m not sure what you mean by the position formal precision, is that an output from the receiver or from RTKLIB?


      1. Sorry, I didn’t notice the acceleration plots. Undifferenced velocities or accelerations serve to isolate the culprit for the spikes in the position differences.

        As for the formal precision, that’s just the sigmas output by rtkpost. An equivalent metric or two would be to check both VDOP and the RMS of residuals. The product of the latter two equals the formal vertical precision.

        If the precision also shows spikes, then I’d look at residuals, to check if there’s an individual satellite worse than others.


        1. Hi Felipe. What you say makes sense and could be one way to deal with the erroneous positions. However, I did not see any similar issues in the position data from the M8N receiver, and I believe the M8T should be able to get as good or better solution than the M8N. My goal was to eliminate the bad fixes in the M8T data rather than to flag them as bad. I suspect that modifying the dynamic platform model on the M8T receiver will accomplish that since it was the only obvious difference in configurations between the two receivers. I still haven’t had time to try that yet but hope to do it soon.


  8. hi!

    i did try to change nav5 in gps_glonass_5hz at rover and base to 4 (automotive) and took a test ride.

    i got very good results and a fast fix with less float between.

    if i postprozess the data with rtkpost i cant see my good results?



  9. Great stuff as ever, Tim. Particularly interested in this “dynamic platform model” setting as I also use Reach modules, and not on a drone! Although I do get pretty good results, if I could improve them further by changing this mode to something more appropriate (marine, in my case), then that has to be a good thing. Looking forward to more investigations on this.. also, how easy is it to change this mode on a Reach? I would quite like to try it myself.


    1. Hi Matt. I haven’t tried changing the dynamic platform model setting on a Reach unit yet but based on a quick look my guess is the easiest way to do it would be to enter the command in the “misc-startcmd” option in the advanced settings on the config page. The format for the commands are described in the u-blox M8 Receiver Description document. This setting is part of the CFG-NAV5 command. It’s actually a little tricky to put the command together just from the document. I prefer to bring up the messages window in u-center (the Ublox eval software), select the CFG-NAV5 command, choose the settings you want, then click the “Show Hex Toggle” button on the bottom of the window. This will give you the payload values but you will still need to put the command into RTKLIB format. You can look at one of the Reach config files (e.g. GPS_GLONASS_5Hz.cmd) for examples. Adding the command to one of these files instead of using the “misc-startcmd” would be another option.

      There may be an easier way to do this, maybe someone more familiar with Reach can help.


      1. Hi Matt. I just found this in the GPS_GLONASS_5Hz.cmd file (I assume it’s in the other config files as well):

        # change NAV5 stationary mode to airborne <4g
        !UBX CFG-NAV5 1 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

        "8" is the airborne<4g model, so I suspect if you change the second byte in the command from 8 to 5 it will set the model to "At Sea" or to 3 for "Pedestrian".

        I don't know if it is the easiest way or not, but you can modify that file by SSH'ing into the unit over the USB cable and finding the file in the /ReachView/rtklib_configs folder. If you try it, let me know if it works or not.


      2. Thanks Tim – sounds like this is definitely worth a go. What I might do is go out and do my typical “fore and aft” configuration on the kayak, and set one of them to the sea model. It would be interesting to then compare the results. Although my results are generally good, I do get issues as soon as I get near obstructions (the pier, usually), and I wonder if this might help with that? I know that Reach was initially targeted at drone users, but the platform model they have selected is the most extreme, so if changing it really does affect the raw data then this could be quite a valuable find by you!
        I will report back (although probably not for a few weeks).


    1. fine that you now own two reach devices!!
      i am a newbie to rtk gps and bought the devices with thinking they are plug and play! 🙂
      but now i a become a rtk advanced newbie..

      your blog is very interesting but i have to learn much more to understand the basic in rtklib.
      i cant find nowhere a small and easy description of rtklib with words that a newbie can follow.
      it is also hard to understand if if English is not your native tongue..

      i have started a tread in https://community.emlid.com/t/reach-guide-to-fix/3301
      maybe you can help with some basic informations or post a screenshot (or. the conf files of your settings).



      1. Hi Andreas. I understand where you are coming from, getting started with RTKLIB can be quite challenging. I have put all my posts that I think would be useful for someone just getting started into the “Getting Started” category. If you scroll down on my home page to the list of categories and click on “Getting Started” it will bring all these posts up. Some of what you are asking for is there including screen shots and config file settings (although not specifically for the Reach units) The posts are in reverse order, so scroll to the bottom, start there, and work your way up.


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 )

Twitter picture

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

Facebook photo

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

Connecting to %s

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

%d bloggers like this: