Over the past few months of playing with the DIY RTK system I built using a pair of ublox NEO-M8T modules, I have wondered what would happen if I left the system to run for long periods of time. Classes went on spring break, so I figured it would be a great opportunity to test the idea while I was out of town.
Local Base Corrections
Testing Procedure
To start off, I wanted to see how well the RTK system would perform using the local base corrections. I set the system up using RTKNAVI with all settings set for default with the exception of the following:
- Positioning Mode: Kinematic
- Frequency set to L1
- Enable GPS, GLO, Galileo, QZSS, and SBAS constellations
My hopes are that since the GPS module will choose which constellations to use based on firmware settings, I should be able to enable all of them in RTKNAVI with no negative effects. Since the NEO-M8T modules are single frequency receivers, I used L1 frequencies only in RTKNAVI. I also set the positioning mode to Kinematic since the final use case of this system will be on a moving aerial vehicle where static positioning modes will be impractical.
To make sure the comparisons between CORS corrections and local corrections are fair, I decided I would give both systems a test by giving each one a 1 hour period for convergence. The data gathered during convergence tends to be very prone to drift since the Kalman filter has not properly initialized, so it will not be used to compare the two systems.
Once the system had an hour to reach convergence, I cleared the plots and allowed each system to run for another hour. During this period, the ground track showed the drifting that occurred over time. This was the deciding factor between the two systems to see which one would be run over break.
Results
1 hour ground track for local base corrections
The above screenshot of the 1 hour ground track shows the natural drift in the position solution. Some of the older position fixes had a lot of difficulty in maintaining a steady position but the later ones were a bit more consistent. A significant amount of the data was also not good enough to get an RTK fix shown in green, so it had to use the more error prone float values which can be seen in yellow. It did however start to slowly drift off to the north which makes me wonder about what could cause such an error. I believe a large amount of it could be explained by the fact that the GPS antennas are located indoors with relatively little ground plane to help their reception.
CORS Corrections
1 hour ground track made using corrections from the CORS network
Next up was the CORS correction. I followed the exact same procedure as before and got much more respectable results. The natural drift was much more confined and shows a lot more promise than the local base corrections. I believe this could be related to the CORS network having much more capable GPS receivers than my system and much better surveyed base station locations. The solution did however remain a float for a significant amount of time but once again I believe this was related to the indoor operation of these tests.
Long Term Testing
Since the CORS network corrections were obviously winning by a significant margin, I decided to leave it running over the break and log in occasionally to take screen shots of each of the windows. The settings remained unchanged and the antennas were not moved. Since the CORS experiment was the last one to run, I decided to leave it running instead of stopping and restarting.
Ground track made 19 hours after convergence using CORS network
Nsat page of RTKLIB made after 19 hours on the CORS network.
My first check in happened 19 hours after convergence and I was completely surprised by the data being gathered. Not only was there a lot of time spent with a float fix, the drift between the furthest east and furthest west positions on the ground track was over 1.4 km apart! This got me wondering if it lost sight of too many satellites, so I checked the Nsat page of RTKPLOT. Unfortunately it doesn’t appear to be an issue with the number of satellites. Despite the error, I chose to continue on with the experiment.
Ground track created after 95 hours using the CORS network
I will skip some of the more boring details and jump to the last screenshot I made. This one was taken after 95 hours of continuous operation. The drifting has definitely gone down a significant amount but is still not great. Instead of getting a handful of RTK fix solutions, it is instead getting frequent fixes that last only a few seconds before going back to float.
Conclusions
Before this experiment I had known that RTK systems need a period of convergence to get better positioning accuracy but it eventually reaches a point of diminishing returns. My experiments however appear to be too noisy to make any such conclusions. I do believe most of these errors could be attributed to multipathing caused by being indoors but further testing is needed.