RTPK Real Time Processed Kinematic

Sergey Gaydukov

Member
JAVAD GNSS
I tried to do this and I get the message "Map downloading is disabled by user". How do I enable map downloading?
Go to "Action" | "View" and set Map Download to Always.

Screenshot from 2021-06-02 19-03-41.png
 

APADDEN07

Member
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.
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.

For #3, do we have any other workaround, or plans for this improvement? Or, even an explanation as to how the same raw data from RTPK, when DPOS'd returns a float solution instead of a fix? Either would be helpful. It's wildly frustrating not having the rtpk coordinate to compare to the ppk float and rtk (fixed, but not a fully phased fix) positions after post-processing.
 

Matt Johnson

Well-Known Member
5PLS
For #3, do we have any other workaround, or plans for this improvement?

If you are using RTPK then you should not do Base-Rover processing with DPOS. You need to uncheck the "Process All raw GNSS Points" options.

BASE-SETUP-DPOS_20210609-18.04.04.png


Or, even an explanation as to how the same raw data from RTPK, when DPOS'd returns a float solution instead of a fix?
Base-Rover processing in DPOS is not splitting the file into sessions so this is why the results are different.
 

Nate The Surveyor

Well-Known Member
At the terrible risk of stating the obvious....
We need an evaluation device, for RTPK, much like RTK has.
If we sit on a wide open place, for 100 minutes, then we should get 100 minutes of RTPK, all good.
If we move into a bad spot, and stay for 100 minutes, and we then get 30% or 30 RTPK observations, that agree with each other, within some tolerance.
Now, if we move into a "Nathan place". That's a real bad place, when sat configuration is poorest, and sit for 100 minutes, and of these RTPK shots, only 5 agree with each other, but....
One is at 10 minutes, one is at 60 minute mark, and the rest are at the 90 minute mark. This is where we quit.
We need a way to evaluate this data.
We need an overall time, and, spacing, and tolerance.
This is something I'd use.
And, of course. The RTK thrown in.
In these holes, I've been known to set it up, AND go to get a burger. Come back, to good data.
Nate
 

Nate The Surveyor

Well-Known Member
Ok, this is preliminary.
A black box, on the collect screen, that takes the user over to RTPK details.
Over here, we have basic numbers,

Total time on point.
X number of RTPK that are within x tolerance or proximity of each other.
Overall time, between points that agree with each other. This is the time from first to last point in this group. This is spacing, like over at rtk.
And an ellipse graphic, to indicate quality of observations.
For starters, just the numbers.
Go back to rtk screen, and the star shows up, as the best average of RTPK. From RTPK screen.
I've not spent much time figuring this out, but this is the GENERAL idea.
This allows one point to be generated, with practical error analysis.
Nate
 
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.
 

Nate The Surveyor

Well-Known Member
@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.
Nate
 

Matt Johnson

Well-Known Member
5PLS
Preliminary data filtering, outlier rejection and cycle slips detection is done on the entire file and then it is split into segments for ambiguity fixing. This is why the whole file is processed each time it processes.
 

Nate The Surveyor

Well-Known Member
Then why does RTPK work better than DPOS based post processing?
Is the DPOS one "out of date"?
DPOS (as I understand it) takes a "whole file" approach.
N
 
@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.
Nate
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.
 

Matthew D. Sibole

Well-Known Member
5PLS
If you see a (2) or more in front of the RTPK solution that means the static solution had repeat solutions that agree. I would store it and shoot it again for verification.
 

Nate The Surveyor

Well-Known Member
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. Similar to the 180 seconds in RTK.
Nate
 

Matt Johnson

Well-Known Member
5PLS
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.

This is what it already does with the exception of displaying the time between sessions but this can be calculated based upon the number of sessions that agree and their duration. I recommend at least 6 minutes of time separation between the first and last session. I posted the instructions on how to configure this:

https://support.javad.com/index.php...mend-sessions-over-7-minutes.4933/#post-46218
 

Steve Douty

Well-Known Member
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.
Tom,

I am old enough to understand and enjoy your Alice's Restaurant reference. You made me smile; Thank You!
 
Top