Old rtpk vs. New rtpk

Darren Clemons

Well-Known Member
I didn't use the pre release version of Jfield as much as I usually do this last update that was, for the most part, a lot of changes in the way rtpk operates.

All comments below are from using T3/LS+ with all 4 constellations.

We've only been using it for a couple weeks now and there are definitely a lot of good improvements, but some that are, I guess, just going to take some getting used to. It certainly "works differently" than what we were used to.

Best of all the improvements is just the overall speed of processing the results has diminished dramatically. Solution #1 after 120 seconds comes back in about 10 seconds compared to probably 35-45 seconds previously, with each increasing solution also completing faster - IF we get a solution.

We work in a lot of very challenging environments and have always pushed this equipment as far as it will go. With our updates to a T3 and an LS+, there aren't many places we don't get very good, reliable, matching rtk shots - when the leaves are off. But, in the summer months, will full leaf coverage it's a bit of a different story. This is where the rtpk addition has made the most difference - getting "those shots" where we can't/don't necessarily get much, if any, rtk at all.

Before the last update, we probably only saw an rtpk result say "float" 1 out of 20 times, even in the roughest of spots. Now, that didn't mean every one of the solutions it gave us that said "fixed" were accurate, they still had to be verified with matching data. That is what this last update has tried to accomplish with the (2), (3) that appears next to matching rtpk solutions.

The issue we are having is, we get a solution on the 1st processing (after 120 seconds), but almost any time we're in much coverage, the next several solutions ALL come back saying "no solution for this vector". Only on a couple occasions have we seen it "come back" after the 2nd, 3rd, 4th, etc. solution keeps giving that no solution message. We are seeing this on 90% of ANY points collected in coverage. Is this supposed to be happening that often? Are there any adjustments that could make our LS do this?


Another issue with it doing this is, the data is "taken away" after the 2nd solution fails removing the readings from distance to last or a Pdelta boxes that were using that 1st solution. That solution needs to stay even if the 2nd, 3rd, etc fails to give one....

As I said, maybe this is just us needing to get used to this different way that the rtpk is working and obviously the goal is for it to only give more fixed solutions and not show us float solutions, which we don't need to see anyway.

I have, however, tested ours in several spots and have seen quite a few of the (2) locations, which is supposed to indicate 2 matching rtpk solutions, turn out to be incorrect. I have also saw one that gave me a (3) in the rtpk that turned out to be incorrect as well, so the rule still stands, as it always will, ALL data needs to still be verified and checked in these types of locations.
 

Matt Johnson

Well-Known Member
5PLS
The issue we are having is, we get a solution on the 1st processing (after 120 seconds), but almost any time we're in much coverage, the next several solutions ALL come back saying "no solution for this vector".
It returns a no solution message if there are multiple sessions without any sessions in agreement.


Another issue with it doing this is, the data is "taken away" after the 2nd solution fails
This is desired behavior. If the first 2 solutions don’t agree then a solution should not be displayed.


I have, however, tested ours in several spots and have seen quite a few of the (2) locations, which is supposed to indicate 2 matching rtpk solutions, turn out to be incorrect.
Yes this is possible. As the time separation between solutions increases the likelihood of it being wrong decreases. I recommend 6 minutes between the first and last session when relying only on RTPK.
 

Darren Clemons

Well-Known Member
It returns a no solution message if there are multiple sessions without any sessions in agreement.



This is desired behavior. If the first 2 solutions don’t agree then a solution should not be displayed.



Yes this is possible. As the time separation between solutions increases the likelihood of it being wrong decreases. I recommend 6 minutes between the first and last session when relying only on RTPK.
Ok I understand a bit better now. So the reason we are getting the no solution very often is not that it didn’t “get” a solution, it is that the 2nd didn’t match the 1st.

I had a point a couple days ago where I had 2 rtpk solutions match - so I stored it. I then started a 2nd session on that same point and the 1st solution came back and matched the stored point via the DTL white box statistics. That solution then “went away” starting with the 2nd solution and after 15-20 minutes it never returned another rtpk solution. In that rare scenario I “had” what appeared to be a match and then lost it. After I gave up on the 2nd solution, I checked the 1st point from 2 different locations out away from the giant cedar tree I was directly under and right up against the trunk and verified the 1st session that did get 2 matching rtpk solutions was correct.
 

Darren Clemons

Well-Known Member
It returns a no solution message if there are multiple sessions without any sessions in agreement.



This is desired behavior. If the first 2 solutions don’t agree then a solution should not be displayed.



Yes this is possible. As the time separation between solutions increases the likelihood of it being wrong decreases. I recommend 6 minutes between the first and last session when relying only on RTPK.
Okay - after thinking a bit more……The one thing this “way of doing it” has taken away from us however, is using the varying rtpk solutions for comparisons along with the 6 buckets of rtk. Many, many times in the old way, we could be quite certain an rtpk was correct if it “landed on” either the lead bucket square or any of the other dots in the horizontal location box. The odds of that happening and not being correct were very, very high. When we saw that we’d definitely store a 1st point and then start another session for verification. The ability for us to do that using some of our own judgement and experience has been taken away now. Most times, in some of the very tough places we go, after the 1st rtpk solution we have no data at all on rtpk.

What we had hoped to see on the new version of rtpk is actually some way to see ALL the rtpk solutions it returns and use them along with any/all rtk pops to hopefully get a match. That’s basically what our rtk buckets are doing, why can’t the rtpk have “buckets” or ”ghost” asterisks as well? It seems with this new format, there’s a lot of data “inside” the LS that we aren’t seeing that experienced users, I believe, could make use of. Getting the 1st solution and then having nothing on solutions 2 through 8 or whatever - unless two match - seems like a bit of a waste to me. What’s the harm in leaving at least one solution on the screen? If the LS eventually gets a 2nd to match, great, but if not I still have some kind of solution to compare to my rtk pops.

Just my 2 cents.
 

nusouthsc

Active Member
Okay - after thinking a bit more……The one thing this “way of doing it” has taken away from us however, is using the varying rtpk solutions for comparisons along with the 6 buckets of rtk. Many, many times in the old way, we could be quite certain an rtpk was correct if it “landed on” either the lead bucket square or any of the other dots in the horizontal location box. The odds of that happening and not being correct were very, very high. When we saw that we’d definitely store a 1st point and then start another session for verification. The ability for us to do that using some of our own judgement and experience has been taken away now. Most times, in some of the very tough places we go, after the 1st rtpk solution we have no data at all on rtpk.

What we had hoped to see on the new version of rtpk is actually some way to see ALL the rtpk solutions it returns and use them along with any/all rtk pops to hopefully get a match. That’s basically what our rtk buckets are doing, why can’t the rtpk have “buckets” or ”ghost” asterisks as well? It seems with this new format, there’s a lot of data “inside” the LS that we aren’t seeing that experienced users, I believe, could make use of. Getting the 1st solution and then having nothing on solutions 2 through 8 or whatever - unless two match - seems like a bit of a waste to me. What’s the harm in leaving at least one solution on the screen? If the LS eventually gets a 2nd to match, great, but if not I still have some kind of solution to compare to my rtk pops.

Just my 2 cents.
Darren,
I agree. We have gotten many points by the RTPK landing on a non-leading bucket. I have also had the same questions. Just because 2 RTPK solutions don’t agree doesn’t mean that one of them isn’t correct. Most of the time I have computed points that are fairly tight that I use to know which RTK/RTPK solution is correct. On really tough shots we may only get 1 RTPK to match our computed point before we start a new shot. It does seem the new setup restricts that ability somewhat. It would be nice to visually and numerically see the RTPK solutions no matter what to maximize that potential.
My 2 cents also.
 

Nate The Surveyor

Well-Known Member
What we had hoped to see on the new version of rtpk is actually some way to see ALL the rtpk solutions it returns and use them along with any/all rtk pops to hopefully get a match. That’s basically what our rtk buckets are doing, why can’t the rtpk have “buckets” or ”ghost” asterisks as well? It seems with this new format, there’s a lot of data “inside” the LS that we aren’t seeing that experienced users, I believe, could make use of
I'm using the 2 engine firmware in the LS - (minus), but I think the RTPK is the same. We want and need to be able to review RTPK data. Storing pre maturely is the "work around" and we sometimes end up storing bad shots, to avoid the "over parenting" that seems to be there.
I also would like a "start RTPK over" button. So that it does not process such huge files. When starting over, it stores a graphic, showing all the positions it generated. Then, when a later RTPK agrees with one from a previous iteration of RTPK, (by some tolerance) it lets you know... My 3 cents...
Nate
 

Darren Clemons

Well-Known Member
Okay - after thinking a bit more……The one thing this “way of doing it” has taken away from us however, is using the varying rtpk solutions for comparisons along with the 6 buckets of rtk. Many, many times in the old way, we could be quite certain an rtpk was correct if it “landed on” either the lead bucket square or any of the other dots in the horizontal location box. The odds of that happening and not being correct were very, very high. When we saw that we’d definitely store a 1st point and then start another session for verification. The ability for us to do that using some of our own judgement and experience has been taken away now. Most times, in some of the very tough places we go, after the 1st rtpk solution we have no data at all on rtpk.

What we had hoped to see on the new version of rtpk is actually some way to see ALL the rtpk solutions it returns and use them along with any/all rtk pops to hopefully get a match. That’s basically what our rtk buckets are doing, why can’t the rtpk have “buckets” or ”ghost” asterisks as well? It seems with this new format, there’s a lot of data “inside” the LS that we aren’t seeing that experienced users, I believe, could make use of. Getting the 1st solution and then having nothing on solutions 2 through 8 or whatever - unless two match - seems like a bit of a waste to me. What’s the harm in leaving at least one solution on the screen? If the LS eventually gets a 2nd to match, great, but if not I still have some kind of solution to compare to my rtk pops.

Just my 2 cents.
Is there any discussions ongoing to get the rtpk somewhat "back to how it used to be", in that we can, at a minimum, at least keep one of the rtpk solutions on the screen at all times? We are definitely NOT getting near as much use out of this "new version" as we did the old version.

As I stated in my previous post, even if the rtpk asterisk "moved" to different spots on the H & V location boxes, we were very accustomed to watching the asterisk and catching the ones that landed on TOP OF an already located rtk square or dot on the screens. This was a very, very solid tool to speed up time and now we have completely lost it.

As soon as we'd get an rtpk asterisk and an rtk square or dot in the same spot, we'd immediately store that point and start a new session. We would then have the ability to use both "new" rtk and new rtpk to verify that last position via the distance to last box. We could very commonly get 3 or more matching coordinates in a matter of 12 to 15 minutes using this method. Now, by losing the ability to do some of this ourselves, we are spending 30+ minutes on the same "types" of points before getting all the information we need. Most of this time now is spent seeing "no solution for this vector". This is frustrating because the data we need to do some "on the fly" verification is being collected, processed and is IN the LS, we just can't use it because it's not being shown.

Could there not be some way to have rtpk "groups" similar to what we have with rtk? We see up to 6 different groups of the rtk solutions but now with this new version of rtpk, we spend most of our time with zero rtpk solutions. Allow us to see ALL the solutions the LS gets from rtpk and use that data as possibly "coming in" on top of some of our rtk solutions as verification. Just about the greatest thing about the LS from day one is that it has allowed the user to learn "tricks" and methods as their experience level grows to increase productivity. In my opinion, this new version of rtpk compared to the previous version has taken a good bit of that away.
 

Matt Johnson

Well-Known Member
5PLS
Is there any discussions ongoing to get the rtpk somewhat "back to how it used to be", in that we can, at a minimum, at least keep one of the rtpk solutions on the screen at all times? We are definitely NOT getting near as much use out of this "new version" as we did the old version.

You can set the the data split interval to up 15 minutes if you don't want it to split the data.

QUICKSETUP-VERIFY-RTPK-ENVIRONMENT_20210727-16.00.16.png


What RTPK settings are you using? I find the data splitting is very useful and eliminates all the need guesswork, thinking and observing the point multiple times.

Could there not be some way to have rtpk "groups" similar to what we have with rtk?
I believe the issue is that the Justin engine does not currently have the ability to output the coordinates of each session.
 

Darren Clemons

Well-Known Member
You can set the the data split interval to up 15 minutes if you don't want it to split the data.

View attachment 11651

What RTPK settings are you using? I find the data splitting is very useful and eliminates all the need guesswork, thinking and observing the point multiple times.


I believe the issue is that the Justin engine does not currently have the ability to output the coordinates of each session.
We have it set on the default maximum of 2 minutes, which seemed to work very well in the previous version. We never expected a “good” rtpk on the first 2 minute solution, but we got extremely good results with solution 2 (after 4 minutes) and solution 3 (6 minutes). Now we’re not getting anything most times as each 2 minute session after the first just gives us the ”no solution” message.

We will try increasing it to 4 or 6 minutes on the rougher spots to see if that helps. The premise would be I guess that two different solutions at 6 minutes and 12 minutes may likely agree more than any two of six solutions in that same 12 minutes?

I still argue why NOT always give us at least the “current” rtpk solution the LS has on the screen and let us use/decide if it’s useable/viable information? The same process can still keep working and show us the (2) if/when it gets a match.
 

Matt Johnson

Well-Known Member
5PLS
We have it set on the default maximum of 2 minutes, which seemed to work very well in the previous version.
The previous version did not split the data, it only started processing after some period of time. If you do not want it to split the data set the period to 15 minutes (no data splitting until there is 15 minutes of data) and then manually command it to process whenever you want it to be processed.
 

Darren Clemons

Well-Known Member
The previous version did not split the data, it only started processing after some period of time. If you do not want it to split the data set the period to 15 minutes (no data splitting until there is 15 minutes of data) and then manually command it to process whenever you want it to be processed.
So in the previous version it would process at 2 minutes, 4 minutes, 6 minutes, etc. So, was it RE processing the same data set, just with longer times?
If that is so, this new version is processing a NEW, split data set every 2 minutes? That completely makes sense as to why it’s not working anywhere near how it was in the previous version (and why it’s processing so much faster).

There‘s not much chance of us getting what we want on a whole bunch of “separate” 2 minute sessions in some of the places we go. I had no idea that’s what it was doing and if it was explained anywhere, I sure missed it.
 

Darren Clemons

Well-Known Member
Completely answers all my questions as to why it’s so different. No wonder we’re not “getting anything “ out of the new version.
So, I need to set the data split interval up to 15 minutes like you said. Then we can just tap the rtpk counter anytime we want to get a “1st solution”, then after say, two or three more minutes, we can tap it again. It’ll reprocess using the entire data set and if the 2nd solution is different than the 1st, it’ll just “move the asterisk” like it did before.

There won’t be any matching (2) rtpk solutions unless we observe multiple 15 minute sessions
 

nusouthsc

Active Member
So if you have the session set to 15 minutes and you force a process at 5 min and 10 min is it also forcing a split in the data? Or is it doing it the old way as one continuous data set until it reaches 15 min?
 

Adam

Well-Known Member
5PLS
I like the new version because it doesn't yeild near as many false solutions. Remember those quick ones could agree with a quick rtk and still be wrong. I have seen no rtpk that I remember that were wrong and had a verification of 3.
 

nusouthsc

Active Member
I like the new version because it doesn't yeild near as many false solutions. Remember those quick ones could agree with a quick rtk and still be wrong. I have seen no rtpk that I remember that were wrong and had a verification of 3.
Adam,
Just to be clear, the verification you’re referring to is a RTPK FIX of (3) ?
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
Darren, next time when you get "no solution for the vector" in 15 minutes send a project to support.
We are doing a lot of test in different locations but Ive never seen this for 15 minutes session. I believe it will be helpful. RTPK is not so mature as RTK is. We might to find best approach together.
My point for challenge locations is 2 minutes data split interval for LS+, 6 minutes for standard LS. Am I correct?
 
Top