Collect Screen Color Significance

[Jim Frame]

What's the significance of the red positions in the collect screen pictured? In the past the dot colors have always corresponded with group colors, so I'm wondering what's different about this example.

[I tried to upload a file, but got a "there was a problem uploading your file" error message. Is this a problem on my end, or yours?]

 

[Sean Joyce]

Jim
I don't know if this is the cause of your upload problem but this is my post when I had a problem uploading a file and fixed it.


"Problem fixed, it was in my account settings, had flash based upload checked for some reason.
I had uploaded files before, don't know how the setting changed, thanks."

 

[Jim Frame]

I had the Flash option checked as well, but unchecking it didn't fix the problem. I was trying to upload using Firefox ESR 52.0.2 64-bit. When I switched over to Chrome, I was able to upload the file without trouble.

So back to my question: what's with the red dots?

 

[Shawn Billings]

Looks like you have two groups that are very close to one another and the red dots are epochs that were within the tolerance (confidence guard) to the center of both groups.

So you have group blue and group green. Group blue started because the elevation was just a bit too far from the average position of group green (mostly in vertical difference it looks like, but the horizontal was probably also pushing the tolerance). Subsequent epochs were within the tolerance (confidence guard) of both the blue group and the green group, so it was shown in a different color.

In actuality both blue and green were agreeable fixes, but were just outside of the default tolerance (confidence guard) 4cm/0.131' (horizontal) and 8cm/0.23' (vertical).

 

[Jim Frame]

Got it, thanks. Since red generally denotes a problem (e.g. the red warning LED on the left hardware panel), I wonder if duplicate epoch markers ought to be a more benign color.

 

[John Evers]

Shawn,
That is an awesome explanation.

Jim,
I like the fact that it is red. This is an incredibly rare occurrence you captured. I have never seen it. I would really have liked to have had multiple points there for comparison. I would not be happy with that shot for a property corner or control. I am guessing that you are looking at a 50% chance of a "bad fix" at one half the confidence guard distance. I would liken this to the times during a long duration shot where you are seeing two defined groups of points within 0.12 feet of one another on the Hz scatter plot during collection, just slightly more extreme.

I see that your epochs is set to 900, which is great for DPOS. I like to use a different strategy, which actually involves quite a few more RTK resets overall. I like the ratio of 7 resets, to 45 epochs. My profile just automatically repeats this over and over until I stop it. In the open, for control, I collect 5 of the above shots for each monument, and use cluster averaging. This results in at least 35 re-initializations and 225 epochs per monument. I am seeing absolutely stunning results. I feel that going 900 epoch, without re-initializing the engines is too long.

Because of the above, and my desire for the longest possible file for DPOS, I would like to have an option to Verify with resets, at user definable intervals during a RTK shot. As an example, Once Verify Phase One ends, i want to perform 50 epochs of Phase 2, then begin the Verify Phase 1 process again, when completed, perform 50 more epochs of Phase 2, then Verify Phase 1 again, and on and on.

I seem to remember a comment that Javad made regarding the relationship between engine resets and accuracy. Something along the lines of the solution drifts from the truth the longer the engine remains fixed. I may be mistaken, but that is what I remember.

 

[Matt Johnson]

I seem to remember a comment that Javad made regarding the relationship between engine resets and accuracy. Something along the lines of the solution drifts from the truth the longer the engine remains fixed. I may be mistaken, but that is what I remember.

If the initiation is bad, the solution will drift with time. Multipath will cause solution to drift too but in a cyclical pattern. Personally I don't see value in adding resets during Phase 2.

 

[Jim Frame]

I would really have liked to have had multiple points there for comparison.

Me too. If you'll note the description, it's CHK 11, a check shot on point 11 that I shot with 900 epochs the day before. Here are the adjusted vector components and residuals:


Adjusted GPS Vector Observations (FeetUS)

From Component Adj Value Residual StdErr StdRes
To
(V1 Day100 16:57 1280-088-170411.ngs)
UCD1 Delta-N 4085.8196 0.0082 0.0550 0.1
11 Delta-E 1609.7462 -0.0116 0.0568 0.2
Delta-U -58.0686 0.0137 0.1992 0.1
Length 4391.8762
(V7 Day101 21:09 1280-088-170411.ngs)
UCD1 Delta-N 4085.8196 -0.0047 0.0437 0.1
11 Delta-E 1609.7462 0.0072 0.0456 0.2
Delta-U -58.0686 -0.0016 0.0661 0.0
Length 4391.8762

(Hmmm...neither the CODE nor the PRE tag works to preserve the formatting.)

Here's an image of it:

 

[Shawn Billings]

Just to be clear there was no bad fix in Jims screen capture. This is an example of why you don't want confidence guard to be too restrictive. It appears that there are two groups within one fix region.

Jim didn't do anything wrong. These are default values. But it may be worth while to open conference guard a bit. I see this a lot when I work in canopy.

 

[Matthew D. Sibole]

I do not like the idea of adding resets to phase 2 either.

 

[Matt Johnson]

John, if you want to try many resets you could set Minimum Phase-1 Duration to 180 seconds. This way it would continuously reset.

 

[Jim Frame]

By the way, here's how that shot finished up, with the green fix getting tossed and holding the blue:

 

[Shawn Billings]

Looks like you are working from your GPS only RTN station (8+10 satellite count). Also looks like there may have been a little bit of obstruction at this point judging by the interference numbers 4.6 for L1 GPS and 4.5 for L2 GPS. Those aren't horrible numbers, but I usually see 2's in the wide open. Above 6 and you're probably going to be camping out getting through Phase 1.

 

[Shawn Billings]

The horizontal spread is also a little wider than I would expect in an open area, but the shape of the pattern looks pretty good. From your vector analysis, the base is less than a mile away. So this is a short baseline. I would expect in the open that the size of the horizontal box would be about 0.07 instead of 0.111. I look for dot plots in the shape of a thumb print in the horizontal box which is what I see in your dot plot. On the vertical, you have a pretty decent sinusoidal pattern, which is what I also look for. I'd generally expect peak to peak to be about 0.12 in the open, but occasional outliers can change that even in the open. Other pattern shapes would not indicate a bad fix, but can indicate the influence of multipath. The horizontal will string instead of looking elliptical. The vertical will string instead of producing a periodic pattern.

 

[Jim Frame]

It isn't wide open, there's an overhanging tree. The point is at the back of sidewalk, approximately at the tip of the arrow as shown below:

 

[Shawn Billings]

My point in sharing all of that is that with some experience, there is a great deal you can tell from those screen shots. I'm solo, like you, so it isn't as big of a deal, but for someone sending out a crew, he can review the screen shots and tell a lot about how the point was collected and what the conditions might have been like.

 

[Shawn Billings]

And even for a solo guy, it's nice to be able to look at a screen shot some time later and be able to judge the quality of the shot from the screen capture, beyond simple RMS values.