As far as I know, we've got 1 and 2 covered from above, and the new prefer rtk/rtpk and the delta numbers/greenbar/thumbs up are a great solution. Great job from the developers.So, we're still waiting on 1) accept RTPK/accept RTK after collecting 2) better difference between RTK/RTPK beyond the graphical comparison 3) RTPK getting overwritten when points are DPOS'd
Any idea when/if we'll be seeing these updates?
Is there any way to 'UN-DPOS' if I overwrote shots that were 'fixed rtpk' and are now 'float ppk'? I haven't had this problem much, but it happened yesterday where everything was fixed rtk/rtpk and had multiple shots to confirm. Today after post-processing, I've got 3 solutions that are floating, that the rtk doesn't agree with either rtk/ppk for the check shots.
In the future I can export the points and save those before I process, but that's just ONE MORE THING, to add to the list of stuff that goes into the workflow. It's getting to the point where I have to give an hour long lecture just to collect a point properly if I want to show someone else how to use thor's mighty hammer.
For #3, do we have any other workaround, or plans for this improvement?
Base-Rover processing in DPOS is not splitting the file into sessions so this is why the results are different.Or, even an explanation as to how the same raw data from RTPK, when DPOS'd returns a float solution instead of a fix?
It would scare me a little to store an RTPK shot without an accompanying RTK shot for verification. I do use the "prefer RTPK" when RTK seems sketchy and RTPK agrees with previous shots but not all by itself. I like a warm fuzzy feeling.@Matt Johnson , I'm probably making a mistake in my thinking.... But...
If RTPK were also allowed to process each segment (1 minute) individuallly, NOT collectively, (cumulatively), then RTPK would run faster. And then review each minute, against each other, then we may be able to accomplish my goals. This would /could allow the system to run for longer times. Would/could allow a comparative of all those 1 minute vectors.
As it is, I can do this manually.... I'm sitting on a hard place, and I run RTPK until it says fixed. Then, I write down (prefer RTPK if there are no rtk clicks) the coords. The, let RTPK run for another minute. If it agrees, store it. And, repeat. After 2-3 of these, I'm done. I'm suggesting an automation of what I'm doing.
Maybe it would be good if RTPK sessions were internally stopped from going over a set time limit. And, then internally, restart, 1 minute, 2 minutes etc. It could display total number of fixed observations, (an observation is a 1 minute period) and total number within some tolerance of each other, and total time, where fixes agree.
Tom,My understanding of RTPK calculations is that the answer is a cumulative total of all of the information received and being processed as a sum total of all of that information and the RTK calculations involve small segments of data that burst into a fabulous epoch when the parameters have been met, over and over. Each of those epochs are compared to each other and similar epochs are grouped until you are satisfied.
I am starting to feel comfortable reading all of the RTK information and knowing whether or not the shot is reliable. The data to compute an RTPK shot as a cumulative of all of the collected information must be very different and mathematic PHD level stuff. Above my capabilities.
As parallel story, I spent twenty minutes in court this morning trying to explain the difference between N 88 E and S 88 E. Pictures with circles and diagrams explaining each one on the back. That was rocket science to the lawyers and judge. A surveyor mistakenly switched quadrants years ago on a 90 degree angle and I was accused of not knowing what the surveyor did back then.