Getting started with RTKNAVI

[Update 11/25/16:  See here for a more recent version of this post]

Up until now I have used RTKLIB entirely for post-processing previously collected data and have not tried to process any data real-time. Now that RTKNAVI, the real-time GUI version of RTKLIB, is successfully compiling in the 2.4.3 b17 release of RTKLIB, I decided to give it a try.

I first had to update the GUIs to add all of my additional input configuration parameters and options. I started a new “Demo5” branch in my Github repository with these changes. While I was at it, I also updated the RTKPOST GUI for post-processing so both applications now support all of what was available previously in my code only in the RNX2RTKP CUI version. I’ve uploaded the executables and they are available here along with all the input configuration file and receiver startup files I used for this exercise.

As a starting point I chose to connect both M8N receivers directly to my laptop PC. This is not a very useful configuration, since the rover can only travel as far as the USB cable extends, but it greatly simplifies things, avoiding have to deal with radios or other real-time links while getting started. I connected both receivers to my laptop USB ports using FTDI boards to translate from UART to USB as I’ve previously described in this post. We’ll connect a pair of  3DR 915 Mhz radios later to make this a useful setup.

Below I will describe how I set up and ran RTKNAVI in the hope it will be useful to other people just starting out. I will assume you are using M8N receivers and my version of the code but much of this will also apply to the most recent 2.4.3 release version of code and to other receiver types as well.

When you first bring up RTKNAVI it should look something like this:


In the top left corner you will see what version of code you are running. If you are running my code, you should see the demo4 (I need to update this to demo5) tag. In the top right corner are the menus for setting up the input, output, and log streams. We will start here.

Click on the “I” button to bring up the “Input Stream” menu. The red ovals below show what we need to change here. Check the boxes for both the rover and the base station, set both Types to “Serial” and the “Format” for both to “u-blox”. Plug the rover receiver USB cable into the laptop, then click the “Opt” button for the rover to bring up the “Serial Options” menu. Click on the arrow next to the “Port” box and select the com port for the rover. It should be the only choice at this point. Set the baud rate to match the GPS receiver, then click on OK. Plug in the USB cable for the base station receiver and then click the “Opt” button for the “Base Station”. Set the “Port” and baud rate as you did for the rover.


Next, click the “Cmd” button for the rover to specify the commands that RTKNAVI will use to initialize the GPS receiver. Click the “Load” button in the “Serial/TCP Commands” pop-up and select the “m8n_rover_5hz.cmd” file. (You should have downloaded this when you downloaded the executables). Do the same for the base, but choose the “m8n_base_1hz.cmd” file. These files will configure the rover to output raw GPS, GLONASS, and SBAS measurements at 5 Hz, and the base station at 1 Hz. We run the base station at a lower sample rate since it is not moving and later we will need to relay this information over a real-time link which may have limited bandwidth. Check both boxes to enable the “Commands at startup” and the “Commands at shutdown”, then click OK to close the two windows. If you are not using the M8N receivers you will need to provide your own startup files.


Next we’ll configure the output stream to send the solution to a file. Click the “O” button to open the “Output Streams” pop-up. Check the box next to “Solution 1” to enable the ouput stream, set the “Type” to “File” and the “Format” to “E/N/U-Baseline”. This will format the output to give us the distance between rover and base. Enter a file name and path in the “Output File Path” box.


Next we will set up the log files. Although these are not necessary to run RTKNAVI, they are very useful for debugging any issues that may come up later. Check the boxes for both “Rover” and “Base Station”, and set both “Types” to “File”. Enter file names for both logs. They will be in raw ublox format so I give them a “.ubx” extension. If you check the “Time-Tag” box, you will be able to re-run the log files with RTKNAVI. If you don’t check this box, you can still re-run the logs, but only with one of the post-processing apps (RTKPOST or RNX2RTKP)


OK, that should take care of all of the data streams. Next we will set up the solution configuration options. Click on the “Options” button in the bottom row of buttons. Select the “rtknavi_5hz_m8n.conf” file as shown below.


Again, you should have downloaded this file with the demo5 executables. We’ll go over the details of these settings in this file later, for now I’ll just mention that the solution mode is set to “Static-start”. This option is only available in the demo5 code and will assume the rover’s location is stationary (“Static” mode) until a fixed solution is achieved, at which point it will assume the rover is moving (“Kinematic” mode). In this exercise we could use “Static” mode instead of “Static-start” if we didn’t plan to move the rover, or “Kinematic” mode if we did.

There is no need to enter the base station location if we are only concerned with relative distance between the rovers which is what we are doing in this exercise.  The configuration file specifies that we will use the measured “Single” position for the base station location.  I have limited the number of averages for the base station location to one because allowing the base to move while we are running the solution can cause it to converge quite slowly.  If you were trying to calculate absolute position with any accuracy you would need to enter accurate coordinates of the base station in the position sub-menu.

At this point, before we setup all the output windows, it would be a good time to verify the receivers are communicating properly with the laptop. I suggest using the ublox evaluation software, u-center, to do this. Open u-center, connect to each receiver, check it’s baud rate is correct and monitor the packet output window for a few seconds. You should see readable NMEA text messages if everything is working right for each receiver. You can read this post for more details on using u-center. If you need to change a baud rate, don’t forget to save the configuration to the receiver so it will come up correctly after a power-cycle. Also don’t forget to disconnect u-center from both receivers, or close it when you are done or it will prevent access to the com ports when you start RTKNAVI.

Coming back to RTKNAVI, the last thing to set up the output windows. Clicking on the two arrows in the top right corner will cycle through various options for the main display window. The right arrow cycles through plot types and the left arrow through sub-types. I’ve chosen “Rover:Base SYS SNR (db Hz)” here which allows us to see signal strengths for all satellites for both rover and base. Satellites are colored by system (GPS, GLONASS, SBAS) and only satellites with sufficient quality in both receivers to be used in the solution are colored, the others are grayed out. Clicking on the small box above the “Start” button brings up additional monitor windows. Each window allows you to choose what that window will monitor. For this exercise, we will click the box three times to open three windows and set them to “RTK”,“Obs Data”,and “Error/Warning”. You can re-size and move around the windows to make all of them visible at the same time as I have done in the screen capture below.  The  example below shows what the screen looks like after hitting start, at the moment your boxes should be mostly empty.


Once you’ve done this, we are almost ready for the big moment! First check your antennas, make sure both have open views of the sky with no nearby obstructions and you have ground planes under both antennas. If all looks good, go ahead and click the “Start” button in RTKNAVI.  The monitor windows should start to fill with information and hopefully look something like the example above. In this case, the GPS receivers should have had enough time to converge to an internal solution while we were verifying them above and before we pushed “Start”, but if you skipped that step let the receivers run for a minute or two after power-up before clicking the “Start” button.

OK, now let’s check a few things to make sure everything is working right. First look at the main display window, shown in the upper left corner above. If you are in North America you should see colored bars for both receivers for all three systems (GPS, GLONASS, and SBAS). In Europe the SBAS satellites will be grayed out since the EGNOS SBAS satellites don’t broadcast range information.

Next check the observation monitor window, shown on the far right above. You should see valid pseudorange (P1) and carrier-phase (L1) measurements for both receivers (1 and 2). You should see both GPS (Gxx) and GLONASS (Rxx) and possibly SBAS (Ixx) in the list, again for both receivers. The rover observations should update five times per second and the base observations one time per second. If they are not continuously changing, something is wrong with your setup.

Next, check the Error/Warning monitor window shown on the bottom left above. In the first couple minutes you will see “large residual” errors and “position variance too large” errors and maybe a few “slip detected” errors as the solution converges. This should switch to mostly “ambiguity validation failed” errors as the solution converges but before the ambiguities are resolved. If you are getting frequent occurrence of any other message, then something is probably wrong and needs to be investigated. If not, the ambiguity resolution ratio (AR ratio) listed in the main display window and in the Error/Warning messages will fluctuate up and down but eventually should reach 3.0 at which point the solution status in the main window should switch from “Float” to “Fixed” and hopefully stay there. For me, this typically occurs in less than 5 minutes but this number will vary depending on your configuration. At that point the “Positioning mode” in the RTK window should switch from “Static-start” to “Kinematic” and now if you like you should be able to move the rover antenna without losing lock.  Make sure you don’t block the antenna’s view of the sky when moving it.  Of course the movement will have to be pretty limited since both receivers are hard-wired to the laptop.  (Note: while writing this tutorial I noticed that the RTK window is incorrectly displaying“Moving-base” instead of “Static-start” before the switch over. This is a bug I must have created when I added the “Static-start” mode but it only affects the display window and not any functionality. I’ll plan on fixing this in my next code update)

Assuming you’ve got a fix, then I would suggest playing around with all the display options since there are many of them. Below I show a screen capture after achieving a fix. I’ve switched the main display over to baseline so it shows the distance between the two antennas. I’ve also clicked the “Plot” button to start real-time plotting of the solution and let it run for 5 or 10 minutes. You can see the solution is moving around by at least a couple of centimeters. If I had run the solution as “Static” instead of “Static-start” this variation would be much smaller but I would not be able to move the rover around.  I also suspect if I had waited a few more minutes before collecting this data, the errors would be smaller.


Hopefully everything goes well and you quickly get an accurate fix. If you don’t get a fix, I would first check the error/warning window, see if there are any clues there. If not, and all the other checks I mentioned above look good, then the next step would be to look at the log files we enabled in the data stream menus. They will be in raw ublox format but can easily be converted to RINEX observation and navigation files with the RTKCONV GUI. Plot the observation files using RTKPLOT and look for cycle-slip issues or other quality problems with the measurements. Check that there are no missing or extra observations. If they look good, the next step would be to post-process the log files with RTKPOST to see if that makes a difference. If all that looks good and you still can’t get a fix, send me a copy of the raw data files and I’ll take a look.

Good luck!!

In the next post I will add the radios to make this a more useful experiment.

62 thoughts on “Getting started with RTKNAVI”

  1. Hi, rtklibexplorer.
    What you think about introduction of an opportunity switching “Kinematic” to “Static-Start” mode come back after some time (for example, 5 minutes) inactivity base/rover? By my experience it would be very useful opportunity because after ending fist session survey you don’t need to stop/start RTKLib forcibly before start second session survey and so on. Especially it is urgent if RTKLib the application is installed on the remote computer, and the base and rover comunicate on TCP.


    1. Hi Max. It sounds like a good idea. I will add this to my list of things to look into. If I’m understanding you correctly, the goal here is to take advantage of the higher accuracy of static measurements while still being able to move the rover to another measurement location without losing a fix. I’m thinking rather than a discrete switch back and forth between kinematic and static it might make sense to make it a continuous variation between the two by making the rover’s acceleration characteristics in the kalman filter dependent on the current velocity. This could be done by making the input parameters “prnaccelh” and “prnaccelv” a function of current velocity or possibly velocity and acceleration, and possibly switching to true “static” mode when the velocity remains very close to zero for some amount of time.


      1. Switching of the modes comparing values of horizontal and vertical components – it’s good performance too, but I meant another situation. If measurement locations so close, of corse, you can move between them without losing a fix and after first fix rtklib still in the kinematic mode – with fix-and-hold option accuracy is fine in the movement and on standing points.
        If measurement locations so far (2, 3, 10 km) and everything be necessary to switch off (rover, receiving corrections from base, rtklib (stop button)) and everything turn on on new location. But if there was an opportunity auto-switching “Kinematic” to “Static-Start” mode come back after some time inactivity base/rover I could leave working RTKLib and on new location and turn on just rover (RTKLib still worked from last location and receiveng corrections (raw data) from base station too).


  2. Hi,
    I’m using RTKlib 2.4.2 ad u-blox NEO-6M-0-001 receiver. Where can I find configuration and startup files or related information?
    Thanks in advance.


    1. Hi Mancio. RTKLIB 2.4.2 has not been updated in almost 18 months other than removing the binaries and is way behind 2.4.3. I would highly recommend switching to the newer code. If possible, I would also recommend moving from the NEO-6M to the NEO-8MN or NEO-M8T. Getting good results is challenging enough with the latest code and hardware, it’s even harder with the older generation.

      However, the basic formats haven’t changed much and I think you will find most of the configuration and startup file information on this blog will still apply.


  3. Hi rtklilbexplorer

    First of all, thanks so much for your blog. It has helped me tremendously for understanding rtklib in particular and RTK in general!

    As I’m not as successful with my solutions as you are, I’d like to ask you for your configuration files (both the receiver and for the rtknavi) as I don’t seem to find them in your github.

    Thanks a lot!

    Best regards,



    1. Hi Ben. I’m glad to hear you’ve enjoyed the blog! All of my data sets include the config files I used with them. There is also a recent RTKNAVI config file in my demo5 executables folder. The links to both locations are on my Resources page.


  4. Hi, thanks a lot for all this information.
    However I am having problems using the Ublox M8P-2-10 receiver with rtklib.
    With U-center I every thing works fine. But when I apply the same settings as those written on this page to rtknavi, I don’t get any fixed position and the window keeps displaying blank (except flashing green light on top right of the screen).
    Do you have any idea of the probable source of the problem ? Maybe the startup command configuration, that would be different from the M8N you are using?


    1. Hello,

      You need to make sure that ublox is configured for outputting raw data. More precisely, go to CFG and make sure that RAWX and SFRBX msgs are going in the output of USB. If this is not the case, this means that RTKLIB is only receiving nmea msgs at the output and you won’t see anything.


    2. Hi Mansouris. I think Bilal has correctly diagnosed your problem. The settings in the command file in my example will enable raw measurements for the Ublox M8N receiver. You will need different commands for the M8P receiver. I believe they should be the same as for the M8T receiver. You should be able to find them online fairly easily, one place I know you can get them is from the config files on the Emlid Reach Github page, since the Reach uses M8T receivers.


      1. Thank’s a lot to both of you for your help, I really apreciate. However, I am still facing the same problem.
        The RAWX & SFRBX messages are well set (confirmed in UBX-CFG-MSG of ucenter).

        If I have a look at the messages got by RTKLIB (on the RTK Monitor panel), the ASCII tab displays : NMEA message lines (starting with $GNGGA, $GNVTG, etc – even $GNTXT lines which I don’t see on u-center text console …) + ubx (?) lines (for example …b….n…A{.. etc). The ubx tab shows lines such as UBX 0x0213 (504): .

        Is this a normal behavior?

        Thanks a lot


        1. Hello,

          Once you configured the RAWX and SFRBX msgs at the output, also make sure that the USB PORT (CFG-PORT) is also configured for receiving .ubx messages. This can be done either by selecting nmea+ubx option or simply ubx option. If you select only ubx option then you wont see any thing in ucenter, but you will in RTKLIB. I suggest to select ubx+nmea instead of only ubx. After all the configuration, please don’t forget to save configuration.

          Here is a link that you can help

          Please, let me know if it helps.


          1. Thank’s for your reply Bilal. The ports are well configured too :/
            The resolved problem described in the thread you linked is similar but I can’t get it fixed when I apply the same settings…


          2. Hello,

            I did not make any changes to the code. This version is relatively old and I don’t know exactly why it works with M8P and others don’t. One reason could be the .ubx support to ublox M8P msgs.


          3. Hey, now I am facing another issue when I want to use a Rover + base configuration for RTK : I only get a SINGLE solution. Monitor displays the error : “initial base station position error”. The rover mustn’t receive RTCM3 messages from the base, or ? I am confused because it works well under ucenter and I control that RTCM3 messages are authorized on the UART1 receiver port.
            Would it be another problem of RTKnavi version? ^^


          4. Hello,

            I am not quite sure, but I think you did not entered base station coordinates in settings.

            Run RTKLIB with single solution for few minutes, and write down the Lat, Lon, and Alt. Enter these coordinates as base station position in settings. After doing that use that receiver as a base and other as a rover.


          5. But the base should be able to survey itself it’s position, no? Its position is likely to move, tipically when the “moving base” mode is chosen I think.
            Anyway it doesn’t work even if I set a static position for the base…


  5. Hello,

    Referring to .pos file generated by RTKNAVI, I see that there are sdn, sde and sdu columns that indicate to RMS error in the north, east and up direction respectively. When this file is plot by RTKPLOT enabling the “Statistics”option from the settings, I see statistics on the top right corner. The ORI point, which is the location averaged over estimated positions, please correct me if I am wrong. The other indicators such as AVG, STD, and 2D are not clear to me. Please comment on how these are computed, particularly the 2DRMS position from the .pos file. If possible direct me to the code lines where these statistics are computed in RTKLIB source code.


    1. Hi Bilal. That’s interesting, I had never enabled “Statistics” before. I learn something new every day! Looking through the code a bit, I believe the following is true:

      > “ORI” is an abbreviation for origin. How the origin is calculated is set in the “Coordinate Origin” option in RTKPLOT.
      > The statistics are calculated in the CalcStats() function in plotcmn.cpp
      > avg = sum/m
      > std = SQRT((sumsq-2.0*sum*ave+ave*ave*n)/(n-1))
      > rms = SQRT((sumsq-2.0*sum*ref+ref*ref*n)/n) where ref is usually 0 but sometimes ave
      > 2DRMS is the rms of the combined x and y axis. The way it’s calculated is a bit roundabout but you can see by looking at the results that 2DRMS = 2*sqrt(RMSx^2+RMSy^2). I’m not quite sure why the *2 is there, maybe to include the base uncertainty?

      The equations for std and rms are not quite what I would have expected and I would have to look at them closer to fully understand why they are done that way, but hopefully this is enough to point you in the right direction.


      1. Thank you for the information. Thats enough for me to keep me going. To further clarify about the 2 in 2DRMS is that RMS provides 68% probability, whereas 2DRMS is equivalent to 95% confidence level. 2DRMS is the standard notation used for representing 95% horizontal positioning accuracy.


  6. Hy

    i tr4y to download the b23 but without success no fix position probably related to ntrip connection not working properly.
    I check also the set up of ntrip parameters but no changes in the wizard so sorry but I don’t know whats it’s wrong
    …maybe it’s a simple stupid things but I don’t know

    thx anyway for reply



    1. Hy Andreas

      thx for reply
      I download the latest .exe but with rtknavi b22 I’m not able to get fix position using the same parameters that I use with 2.4.2 (I mean ntrip ip and port and mountpoint) Can you help me ?




        1. Hi Francesco. I’m not aware of any problems with the latest release of RTKLIB but I don’t use NTRIP so maybe the issue is there. It sounds like you are on the right track. If you can narrow it down to the particular version that stopped working, the readme.txt file should tell you what changes were made. Maybe you need to update an NTRIP config setting to work with the latest release?


  7. @RTKLLIB explorer:
    1) Thanks for that link!

    2) I will have a close look to that option “Output Single if Solution Outage”

    3) Thanks about your adives for adjustments that will reduce false fixes at the expense of longer acquires! This is really helpful. I also like the FIX and hold feature this is aweasome it makes the solution increadible robust. I even layed a pad of paper over my rover GPS antenna for over 5 minutes and the fix remained constant in RTKNAVI. I also testet up to 25 m/sec^2 acceleration and It never lost the fix even under this high acceleration. I hope I can soon give RTKNAVI with FIX and hold enabled a try on a quadrocopter flight. Lets see how it will behave.



  8. Hy Guys
    I’m new in this forum so first of all I appreciate very much your efforts.
    I have a Ublox lea6t and with rtklib b8 I’m able to get fix in static mode (I put the antenna on the roof of my house) using the correction provided by ntrip from university of padua (MAX3 RTCM3) but with the latest rtknavi I’m not able to receive any coordinates. Sorry whats wrong ? I’m not a programmer so I just download the .exe and copy in my folder with other directory of rtklib.
    Can you help me ?



  9. ok thank you! i have a look!

    how did you get the glo satellites out of my data?
    why glo are not in the rinex files?
    i did also send my data to emild – maybe you can also give feedback.



    1. after the wood (at the end) fix never come back….

      if you have a closer look at time 09:09:14 to 09:10:38 i stop for a while and the solution is drifting away 1 meter….

      i have now tested lates beta … rtklib becomes better and better
      the drifting at this point is now < 20 cm after that i got fix again…


  10. i have uploded a new data set .

    about 20 min only stationary out of my house.

    tomorrow i will make a new one with my car under better conditions..



      1. Hi Andreas. Your latest data looks much better. With the demo5 code and config file, it gives a fix very quickly and stays fixed until you drive into the trees (according to a Google map). With the GPS-only solution, it loses fix almost immediately as you go into the trees. With GPS and GLONASS, it does not lose fix until you are almost all the way through the first area of forest. I posted the solutions I got here. If the trees were only on one side (which I think was your original goal) instead of both sides of the road, I think you would have very likely kept a fix all the way through.


  11. strange for me! normaly reach does the converting the files into obs…

    i think this is the problem why i did not get different solutions when i
    compared with rtkpost..?
    hmmm…. i think you have found another problem with reach.?


    1. Hi Andreas. You said you saw all the satellites in the Reachview so Reach is probably converting the data OK.

      I am not getting good results with your data, but not sure why. Part of the problem is that your rover is only stationary for a very short time at the beginning (2 min in one data set, and 5 in the other). Are you getting a fix before you start moving? If you have some data where the rover is stationary for at least 15 minutes, that would make it easier for me to analyze.


      1. yes i got a fix before i started.

        today i did power off my base and restart new.

        i put my gps out of the window only for getting data to look for glo satellite in my data.
        i did not find any glo sat in my obs files of base station…
        is that the reason why i never got other solution when i used rtkpost and compared gps or glonass modes?

        but i can see glo in my reach view
        after 2 minutes i got this strange thing:

        fix with so less coverage? all is in standard settings from reach_kinematic…

        you can contact my also per email

        i will also record a new data set for you…




    1. Hi Andreas. I don’t see any GLONASS measurements in your base data. Does your base station support GLONASS? The GLONASS measurements in the rover data won’t help much if there are no corresponding measurements to difference against in the base data.


        1. Sorry, my mistake, I see the GLONASS observations now. I’m not that familiar with converting RTCM data. It doesn’t seem to work if I choose a 3.xx version of RINEX in RTKCONV but everything is OK if I choose a 2.xx version. I see a couple of comments about similar problems on the Emlid forum with SBAS observations.


  12. @rtklibexplorer

    first i say thank you for your work – i use reach from emlid – with your improvements reach works much better for me.

    i also use the software from cesar for parallel driving.

    at the moment i work with 1hz gps at the base (for less internet data)
    and with 10hz gps at rover – cerea (software from ceasar) likes 10hz data output.. (there is no setting in reach for 10hz gps&glonass).

    at the other side reach works at the moment really good for me with gps only.i get a fix after 2-5 minutes and a stable fix&hold under good conditions.

    if i switch to gps&glonass i can´t get so good solutions.

    cerea has also a feature to decrease jumpings in float mode – for me a question is:

    how can i improve to hold the fix solution with poor quality of signal. i often have trees at one side of my fields and
    rtklib often falls back to float/single…

    i know from other rtk system (especially from john deere) that they can hold rtk for a longer time….

    can i play with some settings to get longer continuous fix solutions?

    i am happy that you now work with realtime gps processing – maybe you can help reach/emlid also for a better work.


    1. Hello Andreas, indeed I would like that rtklib had a kind of restriction, Fix->Float->Dgps, with a restriction of position ( a limited jump). With the kalman filter it would be possible program it. . I have added to autosteer software a condition for avoiding big input jumps from rtklib ( because autosteer would go to the new false position). Well , All this stuff are ideas and wishes.


    2. Hi Andreas. You can try modifying the 5 Hz GPS-GLONASS .cmd file to run at 10 Hz by changing the “!UBX CFG-RATE 200 1 1” command to “!UBX CFG-RATE 100 1 1” but I don’t know if the rcvr will run that fast or if there is a bandwidth limitation downstream. You also might need to increase the baud rate to handle the increase in data. I’d be surprised though if 5 Hz is not fast enough to accurately describe a tractor’s motion since it’s accelerations are going to be relatively low. If you haven’t already enabled the “Receiver Dynamics” input option that should help assuming you use realistic accelerations for the prnaccelh and prnaccelv input parameters. This option should also help prevent abrupt jumps in the receiver location since you now have a crude model of the tractor built into the kalman filter.

      In general, I don’t believe you can afford to throw away all the information from the GLONASS sats and still expect an L1-only receiver to give a reliable answer. I would focus on finding a solution that includes both, even if it means you have to give up sample rate. I suspect the John Deere receiver you are comparing to is a more expensive system that might even be using the L2 signals.

      I’d be interested in looking at any log files where you lost fix when you got near trees on one side of the field if you would be willing to send the raw data logs to me.


  13. Small typo perhaps.
    PRN number of the SBAS satellites are displayed using only digits as 1xx not Ixx.
    Otherwise, well done and keep on!


    1. Hi Octavian. I don’t know why RTKNAVI chooses to display the SBAS satellites that way … whether it’s a bug or intentional. In the observation files, the SBAS sats have “S” prefixes. Either way, it is unrelated to my changes.


  14. Hello, I am curious what changes are necessary to use your cmd file for the NEO-M8T. I have tried various commands, but not sure how to determine if the receiver has responded with a UBX-ACK-ACK or UBX-ACK-NAK. For example, I commented out everything with the exception of turning off the extra messages (NMEA), but I still receive GGA, GSA, etc.

    Excellent work!


  15. Hello, I have tested your demo5 version with the options that you propose in this blog, with a novatel agstar as rover and VRSRTK ( Cors) as base and It works very well. No fase fix, and time to first fix in less than 2 minutes.
    We tested planting almond trees with cerea autosteer software.
    Also i hve tested with other novatel as base and even best.

    If you need data logging for your studies dont hesitate contact me.


    1. Hi Cesar. It’s great to hear somebody is using this for real-world applications and getting good results! There seems like there should be lots of opportunity for low-cost GPS in agriculture. I’d love to get some of your data and to understand better any unique challenges that you see with this application. I will contact you by email.


  16. Hey,
    thanks for that great post again.

    According to: “No need to enter the base station location if we are only concerned with relative distance between the rovers which is what we are doing in this exercise.”
    I would like to mention that for me I got in static start mode a much faster fix if I determine the base stations position quite accurately (for 1000sec) and then entering that position in RTKNAVI – Base station position.
    (You can determine the position with uCenter -UBX-CFC-TMODE3 – works with Neo-M8P-2 receivers)

    One more question: comparing RTKNAVI and RTKPOST what is the main difference? Is there any differnece in your RTKNAVI setup compared toa RTKPOST setup where the Kalman filter is set to work only in Forward direction?



    1. Hi u-Bloxer. When you saw a faster fix with an exact base station position, what did you have the “Base Station” boxes set to on the “Positions” page when you ran without the exact base position? Is it possible that they were not set to “Average of Single Position”, “Max # Ave”=1, and “Init by Restart” checked? I find that if “Max # Ave” is set to anything greater than 1, then the fix does take longer. I believe that happens because any change in the base station location after initializing the kalman filter increases the convergence time.

      To test this, I just reran the same pair of input logs through RTKNAVI four times: once with the exact base position specified as derived from a nearby CORS station, once with the base location specified but with an intentional error of 10 meters added, once with “Average of Single Position” and Max#Ave=1, and once with Average of Single Position” and Max#Ave=300. As I would expect, only the last iteration was noticeably different, the first three solutions were all very similar.

      Regarding your question about RTKNAVI and RTKPOST, I use the same settings for both. Assuming as you mention that you are only running the kalman filter in the forward direction, the solutions should be very similar. The biggest difference I am aware of is that the base/rover sampling will be aligned in RTKPOST, and not in RTKNAVI. For example, if there is a 2 sec delay in the base station data stream to the rover, that will be visible in the “age of differential” in RTKNAVI but in RTKPOST, that real-time delay will be removed. I don’t know how much difference that makes to the solution.


      1. Hey Rtklibexplorer,

        well I first had your default configuration( in the position tab of RTKNAVI the base station position option was set to: “Average of Single Position”, “Max # Ave”=1, and “Init by Restart” checked). With that solution I ran RTKNAVI and I did not saw a fix after 5 minutes. That is why I ran RTKNAVI again with the precise position entered in the position tab of RTKNAVI (base station position) and this time I got in 3 minutes a fix. Hm what you write however seems obvious – I think I just check multiple times again and write you my solution…..

        Thanks for your opinion on comparing RTKNAVI with RTKPOST. I do not quite understand what the age of differential value illustrates or what it stands for. Can you help me out with a short definition of the age of differentials?
        I am very interested in this subject, because I would like to analyse how a delay of the base station data stream impacts the solution of RTKLIB. Therefore I would simply delete some raw data packages in the base.ubx file and then see what happens if I use the modified base.ubx file in RTKPOST. From what you wrote does that mean that I will not see any difference if I analyse that with RTKPOST?

        I also found another interesting issue I do not understand. In another experiment I collected RAWX+SFRBX+GNGGA NMEA sentences with a Rover at 8Hz Rate. Moreover I collected RAWX+GNGGA NMEA sentences with a Base station. Therefore I used two C94-M8P application boards. The rover of these application boards sends its RTCM3 correction steram to the base which thereby tries to solve the ambiguities and puts out its RTK solution.
        So If I now analyse the rover.ubx and base.ubx file (after converion of course) with RTKPOST and have a look at the generated .pos file I found that the first entry is at time 17:55:48.126 …. and so on. However If I have a look at the GNGGA sentences in the rover.ubx file I found that the first valid GNGGA sentence (containing lat, long values) is at 17:55:31:13.
        To sum it up that means that the RTKPOST solution starts almost 17 seconds later than the solution generated by uBlox. And what I also found is that RTKPOST directly starts with a FLOAT solution, whereas the uBlox solution first outputs values with a quality indicator of SINGLE. I would be glad if you could help me to find out why the RTKPOST solution starts later is that because of the time the algorithm needs….? or what could be an explanation of this?



        1. Hi u-Bloxer. I would suggest doing the comparison by re-running your log files as input into RTKNAVI (change input stream from “serial” to “file”) rather than using fresh data each time, since different runs can vary a lot in acquire time even with the same input parameters.

          The RTKLIB manual defines age of differential as “The time difference between the observation data epochs of the  rover receiver and the base station in second.” It will be a combination of different sample rates between rover and base and, if doing real-time processing, any delay in the transmission of the base data to the rover. In post-processing, the delay in the base data will be removed, so the age of differential will be lower. Keeping the base station delay low should improve your results up to a point, but I haven’t experimented with it myself. I did read recently in a RTK surveying tutorial that good practice was to keep the base data delay to less than 2 seconds.

          I don’t know why you see the different times in your solutions. Looking at one of my solutions I see the first position in the .pos file is one sample later than the first observation in my rover .obs file. I don’t have the GNGGA message enabled in my rcvr output so can’t compare that. Is it possible that your base station data started later, or wasn’t available until later because of a transmission delay?

          Liked by 1 person

      2. Hey RTKLIBexplorer,

        one comment on your implementation of RTKNAVI (static start). What I think I found out is that after powering on the rover and starting RTKNAVI right afterwards it takes up to 35 seconds in one of my experiments until it shows the first float value. However If I look closely at the Rover I saw, that the TTFF (hot start) was only 18seconds long. Within the rest of the time I guess RTKNAVI tries to compare the data of the ROver and the RTCM3 correction data of the base until it is able to output a float solution afer 35 seconds. Now a small improvement of your implementation might be, that within the meantime a single solution is outputed until RTKNAVI successfully aligned the rover and base solution time and puts out a float solution. This is just what I came across. If you like I also can send you my raw files from this experiment.
        According to: ” Is it possible that your base station data started later, or wasn’t available until later because of a transmission delay?” -> No, I alwayse start first my base station and do the observation. Next I connect the rover to power and start RTKNAVI.

        Anyway what I am much more interested in is the behaviour of RTKNAVI in case of delays of the base data correction stream. You wrote:
        “I did read recently in a RTK surveying tutorial that good practice was to keep the base data delay to less than 2 seconds. ”
        -> Could you send me a link to that tutorial?
        I will also do a little bit of testing this cicumstance today.

        I also did some other experiments with FIX and hold enabled for GLONASS and GPS. What I found was even though it takes sometimes up to 7 minutes until the Ratio is going over 3.0, once this threshold is exeeded for longer than 20 seconds, the ratio is kind of exploding (increasing very fast up to 999). However in one of 10 experiments I also saw a great problem: RTNKAVI showed me a baseline of 15 meters (the true baseline I measured before however was 1meter) then after 6 mintues RTKNAVI exeeded the threshold of 3.0 and again the confidence in that wrong solution exploded(the ratio was increasing very fast to around 500). This brings me to the question: What parameters in RTKNAVI options do I have to change so that this case wont happen? I guess the min hold and min fix satellites.


        PS: I will do a little bit of testing your implementation of RTKNAVI. Cause afterwards we will probably use your software within a quadrocopter application. That is why I compare your solution with a solution provided by uBlox. However according to my experiments your solution works a lot better (I think the reason therefore are mainly that uBlox does not have a FIX and HOLD opportunity as well as a static start option, moreover it does not use GLONASS data to solve the Integer Ambiguity Problem)


        1. Hi u-Bloxer. The RTK tutorial I was referring to was the “National Geodetic Survey (NGS) User Guidelines for Single Base Realtime GNSS Positioning”. The recommendation to keep base station delays to no greater than 2 seconds is on page 39.

          There is an option “Output Single if Solution Outage” on the position options page of RTKNAVI. I’m not sure if that is exactly what you are asking for to output the single solutions?

          The “hold” of “fix-and-hold” is what causes the AR ratio to increase rapidly since it is adjusting the phase-bias states directly. The best way to avoid false initial acquires is to have both rover and base stationary with wide open skies and good ground planes during that initial acquisition but there are some adjustments that will reduce false fixes at the expense of longer acquires. In order of which I would adjust first they are:

          1) arminfix: number of fix samples needed before enabling hold: effectively keeps AR in continuous mode for this long before switching to fix-and-hold
          2) eratio1: the ratio of stdevs for pseudorange and phase measurements. Lowering this increases acquire time but may reduce false acquires
          3) arthres1: max position variance allowed for AR: holds off fix-and-hold while kalman filter is still converging, smaller value will hold off longer
          4) arthres: threshold for AR ratio – I always leave this at 3.0 but increasing it will make it more difficult to acquire
          5) minfixsats, minholdsats: generally you should have plenty of sats during acquire, I adjust these for when the rover is moving and many sats may be lost to cycle slips

          If you think false fixes are coming from low elevation sats or low SNR sats you can also try to filter those out with “snrmask” or the elevation masks (elmask,arelmask,elmaskhold).


          1. Hey all there,
            I just saw that there is a new beta release of the Japanese guy who developed RTKLIB.
            The new release is avilable since today (2016/09/06 2.4.3 b22). Unforunately all the beta folder do not contain any .exe file (btw. I did not found any one). However luckyly it now contains QT files and with Qt everyone can build it as there is already a free Qt version avilable. I would be very glad if someone can build the exe files of 2.4.3 b22 that would be great so we can compare it with the DEMO5 code of RTKLIB explorer.



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