This is an article on using a base station with the xNAV650 or Survey+ INS device.
This article will focus on the Reach Emlid RS2 which offers an economical solution (about $2000) to achieving RTK accuracy. You can find a web page for the RS2 here.
Public base stations often make their correction services free to access or on a subscription service. Free correction files can be downloaded automatically in NAVsolve on the Base Stations tab of the Process section. This is often what users will go for as the most efficient and economical approach. However, a private base station allows for more flexibility and can achieve greater accuracy. Furthermore, it is sometimes the case that public base station files are not available in the region you are working in, or are too far away to get the best data, or do not provide all the required channels. In these cases a private base station can help considerably.
Base station corrections are required to get the RTK specification of the device which will be 1 or 2cm in position accuracy or better. Without these, the system will have a reduced absolute accuracy of something like 30cm. However, the further away the base station is from the device the lower the accuracy that can be achieved. As a general rule, the system loses 1cm of accuracy per 10km of distance between the INS and base station. This means that a private base station that can be setup nearby can be the better option.
A base station simply works by acting as another GNSS receiver to the one that is in the INS and the difference between the two can be used to calculate atmospheric effects on GNSS signals such that they can then be corrected for.
It is important that you consider where you will receive your corrections from. If you are using a public CORS network then it would be good to know where the stations are around your surveying region and if they are not suitable, it is also good to understand the limitations of a private base station, namely that the private base station does not have its own position corrected for and so will have an error in absolute positioning (absolute global position, not position relative to other measurements taken).
You will need the gxRTK feature code to process rinex files into your navigation data.
The following is for the RS2 but the same settings will apply to other base stations.
The RS2 is very easy to use. After following the instructions for getting the device started for the first time, you will be able to use it each time you survey and set it up in less than a minute.
When the device is placed, ensure that the RS2 does not move either by people or wind and make sure that the GNSS conditions are as good as possible with minimum obstructions. This is particularly important in the first 2 minutes after powering up when the device is honing in on its location. Ensure people do not crowd the device when it first turns on. Any signals that the base station misses during use are signals that cannot be corrected.
Connecting to the RS2 via wi-fi allows you to visit the web interface by typing the IP address into a web browser. You can change how long the base station is situating its position for on the Base Mode tab:
With NAVsuite 3.3 you can use Rinex 3 files in your processing (not currently available in NAVsolve CMD). We recommend that you select Rinex 3.03. In the Raw Data settings on the Logging tab, set the format to Rinex 3.03 and using GPS, GLONASS, Galileo and Beidou.
Base station files can then be downloaded after the data collection from this same tab. Download the RINEX 3.03 Raw data files for your timeframe and you can use these straight in NAVsolve after directing it to their location. You want to have a rinex file that covers or exceeds the length of time you are navigating for.
You can also receive your corrections in real time. This means that you achieve RTK in real time (as opposed to PPK) and do not need to download the rinex files for processing. The corrections will be stored in the RD file of the INS. The RS2 has a number of different ways for transmitting the corrections including bluetooth, serial RS232, wi-fi and radio.
Receiving real time corrections does have the benefit of making the most use of every constellation. The Survey+ and xNAV650 use GPS, GLONASS, Galileo and Beidou however only GPS and partially GLONASS and Galileo (before early 2022) are used in gxix processing which has to be used when using rinex files. However in real time the standard GNSS receiver algorithm is used which does not have the power of the gxix algorithm but it can help with the higher number of tracked satellites. In 2022 all of the constellations will be used in gxix to provide the most powerful navigation engine possible.
Radio connection is a common way to receive corrections as it offers a long range and works efficiently. You can set up a radio connection easily by purchasing a radio antenna for reception and connecting it to the INS via serial RS232. We do sell radio antennas. This antenna will be on your vehicle. The RS2 can then send the corrections over its own radio antenna which is included.
Alternatively you can use a 4G modem to receive the corrections and pass them via ethernet to the xNAV. This will require the network differential corrections feature code.
Reception of corrections can be configured in the GNSS differential corrections tab in Hardware Setup in NAVconfig.
We have carried out some LiDAR surveys and processed the data with both public base station files and the RS2 files. The test is simple, set up an xNAV650 and LiDAR on a car and record a survey including a boresight calibration. The RS2 is set up at the beginning and left on throughout the survey, rinex files are retrieved from it at the end. Immediately we see a benefit of the private base station which can be set up within 5km of the entire survey whereas the closest public base station, the Oxford base station, is about 10km away (and this is fairly close for a public base station).
The orange pin is location of the RS2 and the blue pins are public base stations. The white is the survey trajectory.
The RS2 delivers exactly the performance you can achieve from public base station networks but gives you more flexibility on setting up which can improve data generally and give access to corrections in areas where public base stations are not available, however the caveat is that absolute accuracy will take a hit especially in height. A public base station will be 1cm or better accurate in absolute height position whereas the private base station, if its position is not surveyed, will be on the order of a meter off. This does not make relative accuracy worse. Meaning that if you are working in local coordinates for a pointcloud survey for example there will only be an improvement from using the private base station.
We look at the navigation NCOM data first. The single RD file from the survey is retrieved from the INS and opened in NAVsolve. We simply process the data using combined processing and advanced smoothing firstly with public base stations and secondly with the RS2.
The following are graphs made in NAVgraph which compare the two NCOM datasets. You may have to open these images in a new tab to view them closely. Blue will represent the RS2 dataset and red the public base stations. The same raw data is used but is processed with the different base stations.
For example, the first graph here is a plot of the Kalman Filter estimation of the position accuracy East in metres. You can see that there is a baseline accuracy and then spikes when the GNSS data degrades from the conditions. The RS2 dataset has a baseline at 3mm whereas the public base station's baseline is at 5mm. Both are excellent position accuracies but the RS2 being closer to the INS makes a small improvement. The RS2 dataset also generally has better performance with the spikes. The same is true of the altitude accuracy (Figure 2) where both have a baseline hovering around 1cm.
Figure 1: Position accuracy East comparison. Red is the public base station data and blue is the RS2.
Figure 2: Altitude accuracy.
Figure 3: Heading accuracy (degrees). The datasets largely overlap.
Figure 4: Pitch accuracy (degrees).
Figure 3 shows the heading accuracy. For surveying this is much more important that position accuracy as the error gets exacerbated over range. You can see that both datasets largely agree with just a small improvement in the RS2 dataset. The same is true for roll and pitch shown in Figure 4. The orientation errors are mainly dependent on the IMU and not GNSS and so are less dependent on the base station used.
A final check to make is the absolute position localisation of the dataset. This is where we should see some difference as the public base station will have its location surveyed to millimetre precision whereas the RS2 is working out its position with uncorrected GNSS which accurate to about half a metre. We would therefore not expect any significant displacement (for example on the order of metres) between the two datasets. This is exactly what we do find. If we plot the absolute horizontal position, the latitude and the longitude of both datasets against one another we find that there is very close overlap.
Figure 5: Plot of latitude for both the RS2 and the OS station datasets. There is very close overlap hence it appears as a single line.
The only major difference is in altitude. This might be expected as altitude is the hardest for GNSS to measure precisely. In this there is a semi constant offset of almost half a meter. We would expect the OS base station to have its altitude accurately known and so the error is in the RS2 position localisation.
Figure 6: Altitude accuracy in meters. Below is part of the plot zoomed in. A 50 cm offset can be seen consistently.
This means that both absolute and relative positioning precision are good for the RS2. Relative accuracy is higher using the RS2 but absolute accuracy is lower. If you are looking at your pointcloud in local coordinates then relative accuracy is the more important. All of this combines to give survey data of an equal and better quality using the RS2 base station but with a generally worse absolute precision particularly in altitude, as opposed to the public CORS networks. This can be corrected for if you had your RS2 position surveyed to millimetre precision or corrected with another GNSS service and kept that position for future use.
Figure 7: Pointcloud screenshot from the survey using a Livox Avia LiDAR. For the most part the two datasets are indistinguishable, as expected (above OS station, below RS2).
In many countries public base stations will be sufficient and you won't need a private base station. However some regions and countries will not have the rinex files you need to achieve the centimetre accuracy desired for high precision surveying. Ensure you know the CORS network in your area before surveying if you are relying on it.
It is possible to manually change the position of your base station in NAVsolve if you get it precisely known. For example, in the case above we can look at the altitude offset and account for it by changing the altitude by selecting 'Modify' in the files section of the Base Stations tab.
Another way to do this that also works in real time is to use an advanced command in NAVconfig:
-station_"ttt"_xx.x_yy.y_zz.z[_datum] Specifies the X,Y,Z position (with respect to specified datum) to be associated with base station with marker name ttt (inside quotation marks)
For a private base station of course you do not have to use the Reach RS2. Base stations are generally very simple and you only need to check the GNSS receiver that is used in it is compatible with that of the INS. This means that the same signals and constellations are being received so that they can be corrected. Generally, this will be the case but it is worth checking. If the same GNSS receiver is used then there will definitely be a match. The xNAV650 uses the Ublox F9P receiver and the Survey+ uses the Novatel OEM7. These are both quad constellation GNSS receivers and you can check their datasheets for the number of channels accepted.