PPK coordinates overriding RTK coordinates??

[Darren Clemons]

Had some interesting and concerning instances on a job I was doing this week regarding collecting Dpos sessions at the rover and then processing them. I had approx 15 to 20 points total I collected in moderate to heavy coverage on this site. I had initially set my boundary profile to store PPK data after 5 minutes, so what we've been doing is storing that raw along with our verified/validated RTK shot. The theory is, I think, it doesn't hurt to have another check (against a known good verified/validated RTK shot).

What we've found though, and this may have been talked about and I missed it, but 5 minutes does not seem nearly long enough data set to get an accurate PPK point in coverage. I went back through this file today and it changed about 8 to 10 of my coordinates from RTK to PPK - automatically . Seven of them were around 0.02 - no issue there which solution it "picked". One of the points was moved 0.14' - easily could be a better post processed solution considering the RTK three phases took quite a while here. The one that surprised me was a rebar shot it moved 0.52'. The original two RTK shots I had checked with a surveyed line within 0.02'. Then my coordinates in cad (after doing the dpos) were off 0.5' on that line. I got to thinking "I checked that in the field when I shot it and I know it was good" so I investigated as to why it was different.

I, personally think the "automatic" changing of the coordinates needs an "ok", a bell alert or something like that to notify us as to when something is being changed.
I'm curious as to what the parameters would have been for it to select a 5 minutes raw data session over a good verified/validated RTK shot that I was 100% positive was correct?
We've spent many months getting confident on our settings we're comfortable with including confidence, consistently and like Matt and most have suggested, a two minute minimum separation from start of phase one to completion of phase three of RTK. If all that completes, we've yet to see one bad shot stored that way. Hard to think a 5 minute raw data post processed file would be correct over that.
This may be due to my lack of knowledge of the proper settings as five minutes could/should only be used for completely open areas? We used Opus for years and the file minimum on Opus-RS was 15 minutes so we're, at this point, going to collect a minimum of 15 in coverage. This way, if we get our RTK validated in 3 to 6 minutes we'll just store/recheck it as normal without attaching a dpos session. If it hasn't gotten an RTK in 15 minutes then the raw data would be useful and stored. For instance, we had one last week where we just couldn't get RTK on the point (yes it's very rare with the LS). It was right up against the face of a cliff. We collected two separate dpos sessions back/back and stored two different point numbers. After CORS processing they came back to check within each other at 0.03'!
The question then is, if I have "what to store" set to store raw data on every point it will still have that 3 to 6 minutes of raw attached to the point. Does that still process when I send to dpos or will I need to uncheck "process all points with raw data" in the dpos settings?

Curious if anyone else has tried any other combinations of using this new PPK option and what everyone's opinion is on the LS automatically "selecting" which point it thinks is best.

 

[Nate The Surveyor]

Darren, you are running into some of the same things I am. PPK, is not always as good as RTK. Particularly in the woods.
You and I are seeing some of the same things.

N

 

[Matt Johnson]

I was always against having the selection of coordinate being automatic or at least I wanted an option that would have to be checked for it to be automatic. This is needed until a reliable method can be determined as to when post-processed results can always be trusted. When I have post-processed observations under tree canopy with other software in the past, I used a minimum of 10 minute observations but prefered 20 minutes.

The question then is, if I have "what to store" set to store raw data on every point it will still have that 3 to 6 minutes of raw attached to the point. Does that still process when I send to dpos or will I need to uncheck "process all points with raw data" in the dpos settings?

You need to uncheck this option for it not to be processed.

 

[Wes Cole]

I have also had it auto pick the PPK solution over my 3 phase rtk shot. I wondered the exact same thing, why did it pick the 3 minute static over the rtk?

On a project yesterday I was using the precise topo profile for a shot on a fence line, and when I DPOS'd it was 4 feet different horizontal than the rtk and it picked the PPK. I caught it when reviewing the points but my preference would be that it never use the PPK over a verified and stored rtk point. Not sure that I've encountered a significant difference between PPK and rtk when using the boundary profile, maybe once.

 

[Darren Clemons]

I have also had it auto pick the PPK solution over my 3 phase rtk shot. I wondered the exact same thing, why did it pick the 3 minute static over the rtk?

On a project yesterday I was using the precise topo profile for a shot on a fence line, and when I DPOS'd it was 4 feet different horizontal than the rtk and it picked the PPK. I caught it when reviewing the points but my preference would be that it never use the PPK over a verified and stored rtk point. Not sure that I've encountered a significant difference between PPK and rtk when using the boundary profile, maybe once.

I would agree that a full validated RTK shot never ever be overwritten. It is too good and solid of a process to simply throw away with a 3 or 5 minute static session. The PPK results should only be for checks and validation processes when you get an RTK shot. When you can't, then have the minimum time set to 15 minutes instead of 5 and when you store the raw data do NOT force you to store an "incorrect" RTK coordinate that you know is not right. This will then be easily recognizable as a point you need processed because it will not have a n,e,z even stored at first.
We now only have the option to process all points with raw data or none (I think). It would probably be helpful to have the option of just picking one or two rover points to include in processing (the ones with 15 minutes of data but no RTK).

 

[Shawn Billings]

I've had excellent results with as little as 3 minutes even under light to moderate canopy. Under heavy canopy all bets are off. More is better, but there are no guarantees.

Alexey has mentioned problems with an "ephemeris leak". It's caused some poor results without warning on occasion. I hope they find the source of this error and correct it or at least identify it.

For now, the first thing I do after getting DPOS results for Base>Rover, I look at the number of solutions column and I look for red text. If I see a blue 2, then I know that there is agreement between RTK and PPK. If I see a red 2, then I need to investigate to see why there was a disagreement between RTK and PPK and how severe it is. Many times it's simply that the elevation is slightly outside of my tolerance. I also look at the solution type column to identify BP solutions. I look at them to see if the BP actually seems better than RTK. If not, then I switch it back to RTK.

The Hybrid RTK process is the most automated post processing scheme I've ever seen and it produces incredibly good results. But it doesn't remove the user's need to review the results before exporting.

I'm in agreement with your assessment of how we select which is better, RTK or PPK. I also agree with the storing a likely bad point for the raw data. I believe we are soon going to have a special designation for these points.