I am a college student working on an embedded systems project that requires outdoor localization accurate to within a foot or so. It looks as if my group and I are going to be using RTK, and we are looking at making our own base station since we are not in range of any free services.
However, for our application the rover will be on a moving object that has potential to be moving at the pace of a person running, and we are hoping to be able to know where it is with the desired accuracy within a second at any given time. I’ve been looking through the ZED-F9P integration manual and the NEO-M8P-2 data sheet for some time now, and the clearest answer I’ve found to what their capable of updating location based on correction data is “less than 60 seconds” (and we were hoping for 1-3 seconds). We have the capability of sending RTCM correction data from our base station via radio link or through NTRIP (although is the NEO-M8P-2 capable of this? it was only mentioned in the ZED-F9P manual).
So my big question is if our hope to process correction data and achieve sub 1ft accuracy every 1-3 seconds even realistic? If so, is there something I’m missing/are there settings that can be set to minimize the convergence time? (we dont care about vertical coordinates if that makes any difference)
The convergence time is related to the survey for RTCM correction data from the base station. Once the survey is complete, the base station will start sending RTCM correction data to the rover and the rover will start trying to get an RTK lock. Once that has happened, your base station will then send RTCM data every second or so (usually a 1Hz) and your rover’s position will be capable of updating at the same rate so long as the RTCM data is coming in at a constant rate and the rover maintains an RTK lock. Depending on how you are sending the correction data and the viability of the RTK lock, you should be able to achieve the positional updates you are hoping for with this project. The largest limitation here is how you are transmitting RTCM data. A WiFi, Cellular or Bluetooth option will work great since you can send large packets quickly but if you are using say, a LoRa device, RTCM correction data is right at the upper limits of the transmission rate so you would need to play around with your LoRa settings to get the right throughput for RTK.
One other really neat thing I just learned about talking with the engineer who designed these boards is u-blox released this [application note about roving bases. So, technically, you can have two RTK modules on a single vehicle spaced far enough apart (at least roughly 1m) where one is your “base” feeding correction data to the “rover” but it is all on a single vehicle. I am not sure if this would be a reasonable option for your project depending on the size of your rover but it’s a really cool application and we hope to have a tutorial written for this using the SparkFun ZED-F9P Breakout when we get the time.