Running into trouble, with "10 buckets maximum"

[Nate The Surveyor]

I am running a confidence counter of 25, and consistency of 30.
Today, I had a situation where the confidence counter got to 20, then it maxed out the 10 buckets, and threw out all my good data. (No likey!) and started over.
This was a problem, because I had gotten a previous observation, and it ran to 200 seconds, and I stored it. And, this second observation was about a tenth from the first one, and I really wanted to SAVE it.
So, what I'd like is, when it gets to 10 buckets, it automatically dumps the poorest one, and keeps on going. It keeps doing dumping the poorest one, automatically. I'm thinking of setting my confidence counter up at 50 or the like... (It goes all the way to 60) but, I am going to have trouble, in areas of high multi path. Due to too many bad buckets.

So, can we change the behaviour, of the LS, when it runs out of buckets, (groups) and it now simply dumps and keeps dumping the worst one, until the confidence counter is reached?
It would not hurt, to place a number somewhere, to keep track of how many groups, or buckets of points were dumped, before it held to a certain one, and went to phase 2.
Also... is there a way to change any settings in VERIFY? Or, maybe, what are the exact settings in verify? I will admit, I push the limits of most things.

Thanks everybody, for the best GPS on earth!

N

 

[Adam]

I am running a confidence counter of 25, and consistency of 30.
Today, I had a situation where the confidence counter got to 20, then it maxed out the 10 buckets, and threw out all my good data. (No likey!) and started over.
This was a problem, because I had gotten a previous observation, and it ran to 200 seconds, and I stored it. And, this second observation was about a tenth from the first one, and I really wanted to SAVE it.
So, what I'd like is, when it gets to 10 buckets, it automatically dumps the poorest one, and keeps on going. It keeps doing dumping the poorest one, automatically. I'm thinking of setting my confidence counter up at 50 or the like... (It goes all the way to 60) but, I am going to have trouble, in areas of high multi path. Due to too many bad buckets.

So, can we change the behaviour, of the LS, when it runs out of buckets, (groups) and it now simply dumps and keeps dumping the worst one, until the confidence counter is reached?
It would not hurt, to place a number somewhere, to keep track of how many groups, or buckets of points were dumped, before it held to a certain one, and went to phase 2.
Also... is there a way to change any settings in VERIFY? Or, maybe, what are the exact settings in verify? I will admit, I push the limits of most things.

Thanks everybody, for the best GPS on earth!

N

Nate, I think something similar to what you recommend will be added soon, Matt Johnson had suggested deleting the worst 5 buckets. Anyway it would be more effective to keep the measurement going and do away with failing based on groups.

 

[Darren Clemons]

Nate,
The confidence and consistency are definitely a "users choice" kind of thing with this LS. It's all about what you get comfortable with but I've settled on 9 consistency and 20 confidence. I found, if I set the consistency any higher I had a lot of what you're describing - 10 full buckets and start over. By having to get phase one all the way up to 25 or higher it resets itself so many times it allows for many, many more "bad" buckets to come into play. If it's set at say, 7, 9 maybe up to 12, then it will kick to phase 2. If that group turns out to be bad then it will either find it in phase 2, if 30% of the epochs fall outside of the group, or almost definitely kick it out in phase 3. I'd say 90% of what we've seen throw out is in the final validation stage. If it doesn't validate almost immediately you may have a bad group. Also if the entire group "sticks" on 2 fixed engines through the entire phase 2 the chances are much, much higher that it will get kicked out. We've used these for probably six months now and may have gotten 3 or 4 bad shots total (and those were ones that completed under the recommended two minute separation between phase 1 and phase 3). Then once we store the verified/validated shot, while the bi-pod is still plumbed up I immediately reset tracking and hit start again. I have distance to last white box on top left and as soon as I see several epochs going in a group that gives me basically all zeros on distance to last to verify again my stored shot I just stop, reject and I'm gone.

I do love the idea of throwing out the "worst" bucket though, that would be very helpful. So many times we see one particular group with say 5 epochs and they're 75 seconds apart, but it's moved on to bucket, bucket, bucket and its up to 9. I'd bet quite a lot on that 5/75 being the "good" point but the only option is stopping and storing that as is (if it's the heaviest weighted at the time of stoppage) and that's just not comfy to do with this unit. Getting rid of some of the buckets that are lets say, the farthest apart horizontally from the one currently in the top line would be awesome. Then it could keep working and hopefully get back to the one that is most likely correct.

 

[Matt Johnson]

Nate, here is the logic I had proposed.

Phase 1

A “Phase 1 Duration” setting is added – During Phase 1 engines will continue to reset until some group meets the Phase 1 Duration. As I have found and mentioned many times, the duration between initiations is a much better predictor of a correct initiation than the number of times the engines are reset. For example I would always consider a (2,90,1) group better than (10,13,9).

Groups will now be sorted and reordered by duration; the 1st group will always display the group with the longest duration and it will always be considered the best group:

The maximum groups will be always fixed to 10. When the 11 group is reached, instead of resetting everything and losing all the epochs collected, reset groups 6 through 10. The epoch that would have been in the 11th group now gets placed in the 6th group.


Phase 2

During Phase 2 epochs that do not fall into the current displayed best group will be placed in the groups from Phase 1. This will happen in the background following the same logic as is used during Phase 1. A user will be able to toggle the plots to display all the groups by tapping on the plots.

Jumps will no longer cause the process to reset. When some other group exceeds the duration of the current group, it will become the new current group.

 

[Darren Clemons]

Nate, here is the logic I had proposed.

Phase 1

A “Phase 1 Duration” setting is added – During Phase 1 engines will continue to reset until some group meets the Phase 1 Duration. As I have found and mentioned many times, the duration between initiations is a much better predictor of a correct initiation than the number of times the engines are reset. For example I would always consider a (2,90,1) group better than (10,13,9).

Groups will now be sorted and reordered by duration; the 1st group will always display the group with the longest duration and it will always be considered the best group:

The maximum groups will be always fixed to 10. When the 11 group is reached, instead of resetting everything and losing all the epochs collected, reset groups 6 through 10. The epoch that would have been in the 11th group now gets placed in the 6th group.


Phase 2

During Phase 2 epochs that do not fall into the current displayed best group will be placed in the groups from Phase 1. This will happen in the background following the same logic as is used during Phase 1. A user will be able to toggle the plots to display all the groups by tapping on the plots.

Jumps will no longer cause the process to reset. When some other group exceeds the duration of the current group, it will become the new current group.

I'd second, third and fourth this proposal!! These are exactly the things we can "see" and know it's patterns but as of now, we can't do anything about it. I have also seen groups exactly as you describe and are 95% certain that the (2,90,1) is the correct point. Even talking to the LS and telling it "get back over to that one"....doesn't work though.

 

[Adam]

Darren, great feedback. I agree with Matt's logic.

 

[Darren Clemons]

Nate, here is the logic I had proposed.

Matt, any idea when we could actually see this in play?

 

[Matt Johnson]

Matt, any idea when we could actually see this in play?

It would be up to Michael Stazhkov to implement (assuming Javad approves). I wouldn't think it should take too long to make these changes.

 

[Nate The Surveyor]

Matt, I think you are on to something, there. I always wanted to slowly consider those numbers.... but it looks like you have done it. It would be ok with me if it kept on doing it like that... ie, not jumping, and failing.
Matt, you are a smart guy. Thanks for taking the time to figure this stuff out.

N

 

[Darren Clemons]

Nate, here is the logic I had proposed.

Phase 1

A “Phase 1 Duration” setting is added – During Phase 1 engines will continue to reset until some group meets the Phase 1 Duration. As I have found and mentioned many times, the duration between initiations is a much better predictor of a correct initiation than the number of times the engines are reset. For example I would always consider a (2,90,1) group better than (10,13,9).

Groups will now be sorted and reordered by duration; the 1st group will always display the group with the longest duration and it will always be considered the best group:

The maximum groups will be always fixed to 10. When the 11 group is reached, instead of resetting everything and losing all the epochs collected, reset groups 6 through 10. The epoch that would have been in the 11th group now gets placed in the 6th group.


Phase 2

During Phase 2 epochs that do not fall into the current displayed best group will be placed in the groups from Phase 1. This will happen in the background following the same logic as is used during Phase 1. A user will be able to toggle the plots to display all the groups by tapping on the plots.

Jumps will no longer cause the process to reset. When some other group exceeds the duration of the current group, it will become the new current group.

Had another great example of why what Matt is proposing here would be great.
Here is the screen shot

This (3,132,2) ended up getting thrown out because of 10 buckets maximum but I'd a bet my lunch money it was my correct crd. I could've just stopped and accepted the point as is, but I'd rather do something like this.
If we could, in certain areas, toggle on this and immediately send it to phase 2 and override our current profile setting for confidence it could save some frustration. Agreed, it's best to most times "let it do its thing" but in this instance I was only shooting fence line shots, not property corners. If options were available by clicking on the bucket it would be totally up to the user whether they wanted to use that option or not.

 

[Adam]

Had another great example of why what Matt is proposing here would be great.
Here is the screen shot
View attachment 4979
This (3,132,2) ended up getting thrown out because of 10 buckets maximum but I'd a bet my lunch money it was my correct crd. I could've just stopped and accepted the point as is, but I'd rather do something like this.
If we could, in certain areas, toggle on this and immediately send it to phase 2 and override our current profile setting for confidence it could save some frustration. Agreed, it's best to most times "let it do its thing" but in this instance I was only shooting fence line shots, not property corners. If options were available by clicking on the bucket it would be totally up to the user whether they wanted to use that option or not.

I will usually stop accept if I know the current group is correct and back it up with another observation. I think Matt's idea will greatly increase efficiency in the woods. I like your idea of being able to override the fail and go with the group with the most time. This would be up to the users judgement, once they have learned to read the LS.By the way, How cool is it to be able to look at the info given and say right there is the right fix, or say I know this one is bad?

 

[Darren Clemons]

I will usually stop accept if I know the current group is correct and back it up with another observation. I think Matt's idea will greatly increase efficiency in the woods. I like your idea of being able to override the fail and go with the group with the most time. This would be up to the users judgement, once they have learned to read the LS.By the way, How cool is it to be able to look at the info given and say right there is the right fix, or say I know this one is bad?

Oh it's great! I usually do as you say, stop, accept and then check it.
Knowing when one's "bad" is almost as good as knowing when one's good. I took a buddy of mine out Saturday to show him what this beast will do (he's still using the yellow brand). We were in a monster hole he'd spent two trips to to check his shot. I got two validated shots in 15 minutes total on both and they checked at 0.04 so I knew they were good. We were then going through the stake screen to the first of those two and the LS flew through phase one and phase two and was staking us "off" 0.8'. He said "looks like you got a bad shot too". I said "just wait a sec it's gonna throw this all out in phase three". About a minute later - kachink - reset and start over. Locked back in and staked us within 0.03'.