Getting started with RTKNAVI

This tutorial assumes you have both base and rover receiver connected directly to your laptop,  and that you have an appropriate command (xxx.cmd) and config files for your receiver (xxx.conf).   If you are not at this point yet, please see the previous tutorial or tutorials.  You can download sample command and config files for the M8N and M8T as part of the demo5 binaries from here.

Also be sure both antennas are mounted on ground planes.  The ground planes don't need to be large but they should be flat and can be made of ferrous or non-ferrous metal.  The ground planes will minimize multi-path interference and improve the quality of your position solutions.  For more details on ground planes and why they are important, you can read this app note and this white paper from u-blox.

Your setup should look something like this:

From a practical standpoint this is not a very useful configuration, since both base and rover are tethered to the laptop but it greatly simplifies things by avoiding to have to deal with radios or other real-time links while getting started.  

Please do not try to run this tutorial while sitting at your dining room table like I am here.  It will be a frustrating experience and you will be very disappointed in the results.  Instead you will want to be outside in a location with unobstructed views of the skies and as far away as possible from any buildings or trees.   Later you can experiment to find out how close to buildings and trees you can get and still get good data, but for your first run I strongly recommend choosing as optimal location as you can find.  After you've collected the data, you can rerun RTKNAVI using the saved data logs from anywhere you like. 

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 latest code, you should see the 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”. 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. Set the baud rate to match the GPS receiver, then click on OK. Then click the “Opt” button for the “Base Station”. Set the “Port” and baud rate as you did for the rover.  If you're not sure which com port is which receiver it doesn't matter at this point as long as you select one as base and one as 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 correct command file for your receiver (e.g. m8n_gpsglonass_5hz.cmd). (You should have downloaded this when you downloaded the executables). Do the same for the base.  Typically,you would pick a different command file for the base that runs at a lower sample rate than the rover, but for this exercise it does not matter. These files will configure the rover to output raw data at the desired sample rates. We normally 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 or M8T 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 output 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 or to allow you to re-run RTKNAVI in the convenience of your home with saved data. 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 your chosen configuration file as shown below.  If you are using my code I would recommend the "m8n_demo5.conf" or the "m8t_demo5.conf" files at least as a starting point.  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 you could use “Static” mode instead of "Static-start" if you don't plan to move the rover, or “Kinematic” mode if you do.  Be aware that the "Static" or "Static-Start" modes will not work well if either antenna is moved after you click on the "Start" button in RTKNAVI.  If you think you may have accidentally bumped an antenna, go ahead and click on the "Stop" button, then the "Start" button again to re-initialize the solution.

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, if you haven't already done it, 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. Leave the RTKNAVI window open and open u-center in another window.  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.  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. 

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.