I recently started using two Reach RS units set up to perform RTK corrections over LoRa in order to collect ground control points for aerial photo survey. I have set the base station to average its location over 15 minutes before beginning RTK. I typically let the base sit for 5-10 minutes once I’ve turned it on before restarting the base station’s point averaging, and I record the time at which the position averaging began.
In order to improve the absolute accuracy of the rover-collected points, I have been conducting PPK corrections on the base raw logs using a local CORS station (located within 10-15km of all locations surveyed).
After PPK, I’ve been taking the average of the CORS-corrected logs over the same time period that the base was averaging its position and taking the difference between the position used by the base in RTK and the base position calculated from CORS PPK correction. I then use those XYZ values to offset the rover points by the same distance.
When running those calculations today, I was shocked to get wildly different elevation values for my corrected base coordinates than I’m accustomed to seeing. I usually see values between -5 to -25m on a WGS84 ellipsoid for the area I’ve been surveying, but I was seeing numbers between -50 to -120 m, which makes no sense! I was performing these corrections in RTK POST using Static positioning, which I thought made sense for the base station as it is a static object.
I re-ran the corrections in RTK POST using Kinematic positioning and saw much more normal results.
After that long and convoluted explanation, the question I’d like to ask is: what is the underlying difference between how RTK POST handles Kinematic and Static processing, and what setting makes the most sense for performing PPK with CORS on a base station?
I have 10 files of survey data taken over seven days along 5 miles of coast. In order to try to discern a pattern of which positioning method (kinematic v static) would yield better results, I ran all of my files through RTK Post, once using static and once using kinematic positioning (all other settings the same).
I looked at the results in RTK Plot and was somewhat bewildered. About half of the files were able to obtain a higher percentage of “fix” points following CORS-based PPK in RTK POST using kinematic positioning, and the other half obtained a higher percentage of “fix” points using static positioning.
There was really no rhyme or reason to which files had better results, or how much the fix vs kinematic results varied.
The problem I identified with the initial question likely stemmed from the fact that, when running RTK POST in static mode for that file, less than 4% of points were able to obtain a fix with CORS post-processing. However, using kinematic positioning, 96% of points obtained a fix! This pattern was reversed in other files, and the difference between the two methods was generally not as large.
@TB_RTK is helping you with the specifics. I’ll answer in a general sense.
For your static GCP observations, use static processing, not kinematic.
With regard to correction types, in all cases you should see the most precision of position with post-processing of raw logs, a bit less with RTK (using radios and an RTCM3 stream) between two Reach units, and further less with an RTCM3 stream from a CORS.
It should also go without saying that for coordinate accuracy (presumably for your base coordinate), occupying a known point is the best, static processing with CORS a bit less, and averaging single-mode coordinates is the least. There are also PPP services which could be useful if you didn’t have access to a CORS.
I’ll send you a message with files from a field test we conducted a few days ago - since the area we’ve been surveying does not have many accessible control points (and very few vertical control points), we took the Reach out to a known monument, allowed it to determine its position over 15 minutes, and collected data with the rover after that.
I figure that “static” processing with CORS data should yield the best results for our nonmoving base, but when I ran RTK POST using “static” positioning, only 15% of points ended up with “fix” status. Conversely, when I ran RTK POST using “kinematic” positioning on the base points, 98% of base points got a “fix.”
Thanks for your feedback. I understand that, in theory, static processing should work the best. However, it’s a mystery to me why, about half of the time, I see better PPK correction results from CORS using static positioning, and the other half of the time, I get better results using kinematic positioning. The difference between the results isn’t consistent either. On one of the segments I surveyed, static processing with CORS yielded only 19.2% fix points, while kinematic processing yielded 36.6% fix points. For the next segment, kinematic yielded 96.7%, and static yielded 96.9%! On yet another segment, the difference between static and kinematic correction of my base was 96.4% kinematic, and 3.7% static. Given those inconsistencies, I don’t feel comfortable using static positioning in exclusivity, but I don’t know enough about the underlying calculations to know why this variability occurs. Have you encountered this before?
I think if you presented your log files TB_RTK or one of us may be able to help give you some insight.
Kinematic mode naturally allows for some movement, so naturally you can expect to see more % fix in that mode. However, when you see less fixes in static mode, then one could almost assume that smaller number of fixes will be of better quality.
Nothing is for certain though. If there are problems or inconsistencies with the result then it is best to analyze the log files and decide if it good enough, or if post-processing settings must be adjusted, or if the point must be occupied again to compare results.
