Streamlining the 3 phase system

Nate The Surveyor

Well-Known Member
First off, let me thank Mr Ashjaee, and his fellow workers, who allow us, the end users to influence the direction that this whole project is going.
Phase 1, confidence counter
Phase 2, smoothing
Phase 3, a semi return to parts of phase 1, to confirm that it has the correct initialization. After 180 " has expired. This time separation is critical, because it allows enough change in satelite geometry, to discover a bad init.

In field practice, in challenging environments, we can be in phase one, for an extended time.
Resulting in phase 1 lasting for 3 to 10 minutes.
Sometimes we see 3 to 5 epochs, in the same group, over a time span of 180", or longer. Once we see this, we have very high confidence that phase one has the correct group, or init.
It could then be allowed to jump directly to phase 2. (when my confidence counter is set to 15)
As it is, it can spend another extended period of time (5 or 10, or 15 min) achieving the 15, to go on to phase 2.
For now, I'd like it if we had a mechanism (user discretion) to tell it to jump to phase 2. Perhaps a white box, or a U button.
This would allow us all to study behaviour, and effeciency of a "manual user jump from phase 1, to phase 2 button".
Maybe later, this could be automated, with the parameters that allow a jump (phase one, to phase two), if we could input the parameters.
There are other things this could do, such as skipping phase 3, IF enough verification (time and epoch count)
However, this needs more careful thought.
Thank you,
Nate
 

Darren Clemons

Well-Known Member
If I remember correctly, Matt Johnson mentioned quite a while back that phase 1 was being “re-worked” to where time will be the heaviest weighted factor. In other words, with what you describe, when you get the second click in phase one, and the time separation is over 240 seconds (or whatever the setting becomes) it will immediately kick to phase 2. Basically confidence increases by a multiplier based on time.

Also I believe there were to be some major re-working of the fail/jump process where it wouldn’t kick it out so quickly. I would venture to say in the last year, probably 95% of fail/jumps I’m seeing are where a “good” set of data is quickly kicked out by a “bad” - quick set of pop, pop, pop epochs - which puts us back to starting over with our phase one confidence. Epochs and time hold, but will not go back to phase 2 again until confidence gets all way back to your default setting. That definitely needs to be changed.
 

Nate The Surveyor

Well-Known Member
Mechanism to move phase 1, to phase 2:
3 epochs, + 180"
So that:
x epochs + xx seconds
And, we can check a check box, for including this method.
And, we can set both epoch count, and time, then I think that would do it...
 

Clay Davidson

Active Member
How many solutions can the LS hold. My concern is that it throws a good solution away and makes the process longer. Does it keep all the solutions or could it? I think it should store all solutions until one meets the criteria we are after.
 

Darren Clemons

Well-Known Member
How many solutions can the LS hold. My concern is that it throws a good solution away and makes the process longer. Does it keep all the solutions or could it? I think it should store all solutions until one meets the criteria we are after.
As it’s now configured Clay, it keeps many, many of the one epoch solutions in the “background” and will only show you the “top 6”. You’ll many times notice if it’s in a tough spot, that when you hear a single “click” nothing on the screen changes, but those are being held internally (not sure if the capacity is unlimited but it’s large).

If, later in the process one of those “internal” solutions gets another “hit”, and the time separation beats the rest, it will immediately take the “lead” in your group of six buckets. Many of our most difficult shots will end up with maybe only 2 or 3 epochs in the lead group, with a time separation of 240 seconds or more. Once our 15 or 20 minute PPK criteria is met, just store the RTK then process and check the PPK back at the office and you most always will have a match. Depending on scenarios, what I’m following and other situations, I may or may not take a second PPK. Myself and most others have about a 99% confidence in any RTK with multiple epochs and a time separation of over 240 seconds.
 

Clay Davidson

Active Member
I pretty much run it the same way. If I get 3 to 4 epochs 180 seconds or more apart. I store it. In a bad arra here lately thats usually 3 to 10 minutes. Then I'll start another one to check it. Same process. Then I post process when I get to the office. So technically the second rtk shot that matches the first is way over 240 epochs because it doesn't acount for the first solution (it would be nice to know this, i think thats what y'all are getting at with phase 1, 2, and 3). Thanks for answering my question.
 

Nate The Surveyor

Well-Known Member
Another event I've encountered, is:
Group 1 has 450 seconds and 10 epochs, and group 2 has 200 seconds, and 12 epochs.
The two groups are very close to each other.
Having a button to go to phase 2, and combine the top 2 groups... Seems good.
 

Nate The Surveyor

Well-Known Member
For the immediate, a simple "Advance to Phase 2" button will help alot.
Recently, I had some 450 seconds, and about 5 on the confidence. I could not get it to advance. I wanted it to advance. It just kept making more phase one observations. I finally stored it. But, it only had 5 epochs. I wish I could have advanced it. And, gotten more epochs. My confidence counter was set to 15. Since then, I reduced it to 10. This has helped some... however a simple advance to next phase would have helped.
Nate
 

Nate The Surveyor

Well-Known Member
Another event is where we have been on a particular spot for 30 min. Still in phase 1. Finally, it gets confidence filled. (15)
Then, starts getting epochs. (mine is set to 120 epochs minimum), at 118 epochs, it does a jump/fail. BUMMER!
It'd be nice if the same button ALSO allowed us to manually move back to phase 2, and store it, with its epochs. For these challenging shots, almost always we shoot 2x or 3x, and average it.
So, that serves as a check.
N
 

Darren Clemons

Well-Known Member
Also I believe there were to be some major re-working of the fail/jump process where it wouldn’t kick it out so quickly. I would venture to say in the last year, probably 95% of fail/jumps I’m seeing are where a “good” set of data is quickly kicked out by a “bad” - quick set of pop, pop, pop epochs - which puts us back to starting over with our phase one confidence. Epochs and time hold, but will not go back to phase 2 again until confidence gets all way back to your default setting. That definitely needs to be changed.

Bringing this back to the front. Was hoping there’d been a much different process implemented in the Linux whereas the fail/jump didn’t occur so easily but it appears it’s no different. I had one today where I was working on a “good” bucket - had several epochs over 240 seconds apart and all of the sudden, pop,pop,pop, ching- 5 quick epochs threw me out of phase two and back into phase one. Sure it holds the epochs, but it makes me get 10 resets before I even get back to phase 2. Is the criteria for a set of very quick epochs to “override” a good, long set of epochs still being worked on? It really shouldn’t do this. It seems as though it could just be the same as phase one - no secondary set of epochs will do a fail/jump until its time factor passes the set of epochs that is currently in phase 2.
 

Darren Clemons

Well-Known Member
This has not been touched yet. Improving the confidence level calculation (VSAPP-3562) and not clearing confidence levels when switching back to Phase-1 (VSAPP-3666) are still on @Michael Stazhkov list. Hopefully these things can be done soon.
Can @Michael Stazhkov weigh in on when this may be worked on? Seems as though eliminating “not clearing confidence levels when switching back to Phase 1” might not be too difficult of a fix??

Many users may not see this kind of issue that often as it only happens in the deepest, darkest of places where “no other GPS should go”, but it is extremely counterproductive in these spots - because - the spots where this happens are so extreme, every epoch and every increase in confidence is SO critical that when a confidence of 9,10 or 20 - whatever the users setting is - is reset, we very well may have lost all confidence level in 15-25 minutes of work. Of course, epochs are still there and the shot is still available to stop/store (as I almost always do), but now the chances of a completed phase 2, much less phase 3 are drastically reduced.

I just wanted to re emphasize the importance of this little “bug” and how much time it costs us in those “can only enter with Javad GPS “ points. Probably one of, if not THE most frustrating things right now is being solidly in phase 2 with a 210 seconds or more set of epochs and all of the sudden here that, pop, pop, pop and the epochs aren’t changing. It’s an immediate...NOOOOO...don’t do that!!!
 

Nate The Surveyor

Well-Known Member
I have a question. What exactly is happening in Phase 3? Especially, after a jump fail. What kind of numbers is it trying to come up with, before storing the shot? and, Would it be a good idea, if the USER could adjust any of those numbers?
A number of ideas come to mind. Like a button that allows"Go back to before Jump Fail".
Or, a button "User believes the jump fail was false." RESET to before Jump fail, and continue. This could allow the user to keep using this button, and never come to the end or completion of sequence, if the Jump fail was VALID.

N
 

Darren Clemons

Well-Known Member
The RTK engines are reset once and then it is attempting to collect 10 epochs that agree with the solution.


I do not think it is a good idea to add more settings or options that most users would not understand.
I get what Nate is saying here and I would love that kind of setting, but I definitely agree that in most cases that kind of “power” to all users would not be the solution.

Heck, I would like a “move onto phase 2” button and the ability to “toggle” through the six individual groups separately while in phase 1 so as to see each of their positions related to my DTL white box or to my calculated design point I’m staking to, but again, that would most likely put a bit too much control in the users hands.

It would probably be too easy to get those kinds of settings changed where some of the dynamics of how the LS does what it does would become inconsistent. I would doubt a very high percentage of users ever even see this type of behavior happen, so it wouldn’t be something they’d even want to learn about. The LS is designed brilliantly to go through its three phase process to give you an absolutely confident coordinate when it’s finished. For the most part it needs to be allowed to “cook” for a while. It’s just that here, in the situation we’re discussing, it needs a couple of tweaks.

Simply, as both the VSAPP tags Matt mentioned above note - improving the confidence level calculation and not clearing confidence levels when switching back to phase 1 would fix this.

IF, the unfortunate fail/jump does happen and you’re kicked back to phase 1, your initial accumulated confidence remains. Then, on the very next epoch that falls into the initial group comes in, you’re immediately sent back to phase 2 to resume.
 
Top