RTPK Real Time Processed Kinematic

[APADDEN07]

If I store each point with the "save for post-processing" option in the field, they are all tagged for post processing, correct? I don't see the utility in occupying a point long enough (lets say 5 minutes) to get an RTPK position when RTK isn't fixing, and then NOT storing that raw data along with the RTPK coordinate.

What I'm looking for, is the ability to hold the RTPK as its own solution, like RTK, and then have it adjusted after DPOS processing. AS WELL AS being able to post process the raw data through DPOS for PPK, as one more level of redundancy, because the RTPK and DPOS/PPK solutions are not always the same.

 

[Nate The Surveyor]

I'm wanting RTPK to make buckets, just like RTK.
I'm wanting RTPK to stop at 10 minutes. And start another bucket. And to be available similar to rtk.
I'm wanting RTPK to become capable of pulling through those really impossible shots. With user ability to see grouping and time separated shots and groups.
Nate

 

[Phillip Lancaster]

So the end-user can see what's going on the RTPK side of things. Other than the current "just store or edit point to RTPK". I get it.

 

[Matt Johnson]

If I store each point with the "save for post-processing" option in the field, they are all tagged for post processing, correct?

Yes

I don't see the utility in occupying a point long enough (lets say 5 minutes) to get an RTPK position when RTK isn't fixing, and then NOT storing that raw data along with the RTPK coordinate.

You should enable the option to save the raw data then.

What I'm looking for, is the ability to hold the RTPK as its own solution, like RTK, and then have it adjusted after DPOS processing. AS WELL AS being able to post process the raw data through DPOS for PPK, as one more level of redundancy, because the RTPK and DPOS/PPK solutions are not always the same.

Both RTPK and DPOS use the same Justin engine so there is no redundancy by processing with both. You should use the data splitting feature in RTPK for redundancy. As the number of sessions that agree and the time between the first and last session increases, the probably of a bad solution decreases.

 

[Matt Johnson]

I'm wanting RTPK to make buckets, just like RTK.
I'm wanting RTPK to stop at 10 minutes. And start another bucket. And to be available similar to rtk.
I'm wanting RTPK to become capable of pulling through those really impossible shots. With user ability to see grouping and time separated shots and groups.
Nate

This is what is happening internally. The number of sessions that agree is displayed on the screen along with the final adjusted and averaged solution. If the sessions do not agree then a solution is not returned. I have requested that text report show the coordinates and results and of each session but was told that Justin currently does not have the ability to output this data. Maybe @Alexey Razumovsky can add this feature in the future.

 

[Nate The Surveyor]

What is frequently happening in the field is this:
I press start. At 1 min and a little bit, I get the first RTPK return. It's fixed. A star appears. At 2 min and some seconds, I get a second RTPK return. At this junction, either the star jumps to new location, or stays put. Either way, it at least jumps a little. At this point, I really want and need to know how much it moves. At the 3rd return, 3 min and 20 seconds or so, I desperately want to know how much it jumps. If it jumps 0.03' from the 1st return, and 0.035' from the second, then I have 3 minutes of data in agreement. I need to know this. RTPK 1 is in disagreement with 3, I need to know this.
If I stay for 10 minutes, and get 10 RTPK returns, I need to know which ones agree with each other. I need to know if number 2, number 6 and 10 agree, but the rest are outliers.
I need a way to see what RTPK is doing, so I can decide if it's good enough or not.
And, if I go past 7 minutes, I need to be able to see the difference between rtk and RTPK. If I go for 8 minutes, and RTPK agrees with the 2nd place RTK, that can be significant. Especially if that 2nd place RTK has a significant amount of time separation. I'm in the field. I'm trying to decide,
Done, it's 100%
Done but re observe.
These tools could help me.
Sometimes, I am taking 3 shots on topo shots, because I don't have a good way to evaluate this.
Thank you

 

[Alexey Razumovsky]

Nate, look at solution verification number (2) means 99%, (3) means 99.99%. Set 6 minutes of observation session and 2 minutes for solution in any suspicious locations. It may deals value 3 (3 segments agree within 0.1' in vert and hor). In that case wrong fix happens 1 per 10000.

 

[A.lacey]

What i have found to work for me is a 400 second max that we will take and store as rtpk and repeat until we get 2 that will cluster(only if no rtk solution). We also take 2 shots on all control points. With the prerelease i am doing for my boundary set up is 10 epoc/200 sec, 400 max, 1.3 var. I always hold rtpk unless rtk shots are over 200 sec. or i have a 1.3 or better variable. With doing that i have gone back to a job later and check points before i do new work and always have a good check.

 

[Joe H]

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.

View attachment 11413


Base-Rover processing in DPOS is not splitting the file into sessions so this is why the results are different.

So why is there even the ability to check/un-check "Process All raw GNSS Points" is my question? It seems like even if the base starts from an ambiguous position, the vector to the RTPK is set once the point is recorded and the RTPK point will be shifted appropriately once the base has been DPOS'd. From what I've read here, one should never re-process a RTPK point in DPOS so there shouldn't even be a box to check/un-check, right? What am I missing? Why is the check box there? I read some have experienced significant shifts between a DPOS RTPK point and the original RTPK coordinates (presumably with a known base position?). I haven't seen this in some experiments I've run. I have read many times in this tread that one must un-check the box for RTPK points but haven't seen a satisfactory explanation on why. So why have the check box?
Thank You,
Joe

 

[ken larson]

I suspect it is a function for those that have not purchased the rtpk option

 

[Clay Davidson]

So why is there even the ability to check/un-check "Process All raw GNSS Points" is my question? It seems like even if the base starts from an ambiguous position, the vector to the RTPK is set once the point is recorded and the RTPK point will be shifted appropriately once the base has been DPOS'd. From what I've read here, one should never re-process a RTPK point in DPOS so there shouldn't even be a box to check/un-check, right? What am I missing? Why is the check box there? I read some have experienced significant shifts between a DPOS RTPK point and the original RTPK coordinates (presumably with a known base position?). I haven't seen this in some experiments I've run. I have read many times in this tread that one must un-check the box for RTPK points but haven't seen a satisfactory explanation on why. So why have the check box?
Thank You,

RTPK and DPOS are different types of solutions. If you don't have RTPK then you would need to check the box. I had a job onetime where couple of points that wouldn't process with rtpk. I had several static observations on the same point so I went on and finished the job (Many points in this job). Later when I got back in my office I DEPOS base only, then I cluster averaged the points, exported a backup file and then processed ALL the point via depos. When I deposed I got a good solution on the point I was having trouble with (you can't do this with any other brand on the market). Then I cluster averaged those specific points and then ran them through relative accuracy tool to prove my states min. standards of accuracy. Its a good Idea to backup BEFORE you DEPOS ALL points because it will change your RTPK to a DEPOS static solution. Anyway in short I didn't have to go back out there and reshoot the points. JAVAD was able to get me a good solution with the data I had collected.

Hope this helps,

Clay

 

[Joe H]

So if I understand correctly, I should uncheck this box if I have a RTKP only solution in the field or any point where I want to hold the RTPK solution over the RTK solution, correct? If I don't have any RTPK solutions I should check this box because we want DPOS to process all RTK points, yes? But why? Shouldn't JField or DPOS be able to automatically recognize RTPK solutions and process appropriately? It must be doing so if the box is checked! It seems the check box must be there because sometimes you do want to process an RTPK point!!?? This is different from Clay's example where he's using DPOS to process static data, I think...

 

[Duane Frymire]

So if I understand correctly, I should uncheck this box if I have a RTKP only solution in the field or any point where I want to hold the RTPK solution over the RTK solution, correct? If I don't have any RTPK solutions I should check this box because we want DPOS to process all RTK points, yes? But why? Shouldn't JField or DPOS be able to automatically recognize RTPK solutions and process appropriately? It must be doing so if the box is checked! It seems the check box must be there because sometimes you do want to process an RTPK point!!?? This is different from Clay's example where he's using DPOS to process static data, I think...

You have it sort of backwards I think. Probably, processing static with DPOS came first in the software. Then a capability to process rtk, hence the checkbox added. Then rtpk came along. The fix apparently was to allow process of all failed rtk and base but not rtpk without checking the box, sort of the standard process now. At this point it makes sense to have that unchecked if you want to exclude processing of rtpk; the checkbox says "process all".
I assume DPOS started out as just a submittal process improved by including Glonass; then capability added to field software.
At any rate, in the past (and for those without rtpk) you would check that box in order to try and get a DPOS position for a point that had no rtk solution in the field due to either bad conditions or lack of radio/cell corrections at the point. If you already have repeated rtpk solutions you don't have any reason to try and over-ride those. You can have either a real time DPOS or a post processed DPOS but not both. And sometimes a post processed DPOS would need 30 minutes of occupation, so trying to replace an rtpk with 3 repeats over 10 minutes might result in no solution with post processed DPOS.
Maybe you had a point where rtk would not resolve, and rtpk would maybe get one solution then not repeat; so you let it cook there anyway for 45 minutes or whatever. Then you could check that box in the office and see if it would resolve a DPOS position from 45 minutes of data. In fact I did just that in a black spruce bog a nice mile hike from the base where rtk seemed to resolve after about 30 minutes, post processed DPOS resolved and ended up being the check to make sure that position was correct (in addition to 10 year old survey that point ended up agreeing with).

 

[Joe H]

Thanks Duane! There is now a little light at the end of the tunnel. I'm moving in the right direction, but slow as mole asses this time of year.

I think the answer is, this toggle should almost never be on (checked), especially when you have RTPK data being held over RTK data. It seems a rare case that you would want this box checked. Like maybe if all you have are long occupations of static data and No RTPK solutions, or alternatively, only RTK solutions. So then, why check it even if all you have are RTK solutions? Does it treat that data differently in this case? Seems like it was already handling the RTK data unchecked. I still feel like I'm missing something.

How about "Send to DPOS automatically"? Who does that??? Guess that's a different thread...

 

[Clay Davidson]

Only once this year did I check the box. Almost all the time I get my 3 shots that check with rtk or rtpk. But there is always that one time its just not working. So before rtpk I would do 3 10 min. Static or maybe a 2 5 min and a 10 min static. And almost always I would have a couple or all 3 points check.

You can also rtpk the total observation with different intervals like every 30 sec, or every 10 sec, or every 1min. After you have collected the data and in the office to get a good solution. To do this you go to collect screen and in settings (top center screen button) change your rtpl intercal. The go to the point in ponts, select the point and then tell it to post process (after the base is downloaded) I think you select the pont and then click the three lines and there's an option in there to post process point.

Hope this helps,

Clay

 

[Duane Frymire]

Thanks Duane! There is now a little light at the end of the tunnel. I'm moving in the right direction, but slow as mole asses this time of year.

I think the answer is, this toggle should almost never be on (checked), especially when you have RTPK data being held over RTK data. It seems a rare case that you would want this box checked. Like maybe if all you have are long occupations of static data and No RTPK solutions, or alternatively, only RTK solutions. So then, why check it even if all you have are RTK solutions? Does it treat that data differently in this case? Seems like it was already handling the RTK data unchecked. I still feel like I'm missing something.

How about "Send to DPOS automatically"? Who does that??? Guess that's a different thread...

If you don't have rtpk you would always have that box checked. It is giving a second solution for a check. Still a lot of folks without the rtpk option. Things that already have solutions are being shifted to actual post processed base position by the other checkboxes below (base-rover process), but the rtk solution is not being changed just shifted to actual base position.
So it's especially useful (essential) for those still using older models with only GPS/Glonass and no rtpk.