Rtk vs postprocess

tigre5000i, post: 430100, member: 7350 wrote: a difference of 1 yard in location

Is one giving you IGS / WGS84 and the other NAD83?

Run it a few times and compare your results. RTK can give as good of a coordinate as static sometimes. Sometimes must be emphasized.
Run, test, compare and know what tool to use for the job.
Bueno suerte.

Sent from my SM-G930V using Tapatalk

Bill93, post: 430102, member: 87 wrote: Is one giving you IGS / WGS84 and the other NAD83?

is WGS 84

spledeus, post: 430107, member: 3579 wrote: Run it a few times and compare your results. RTK can give as good of a coordinate as static sometimes. Sometimes must be emphasized.
Run, test, compare and know what tool to use for the job.
Bueno suerte.

Sent from my SM-G930V using Tapatalk

But, 1 yard difference? Is not it much?

Well it's hard to trouble shoot something like this without REALLY knowing exactly how the data is being collected AND processed.

If EVERYTHING (RTK/Static) is being solved in "WGS84," then the most likely "problem," is that the RTK software is using a DIFFERENT WGS84 Coordinate Estimate at the BASE, than the Post Processing software is using. This is actually a rather common situation.

Basically a "fixed/published/Network/whatever" WGS84 coordinate is ENTERED into the RTK [data collector], but when the static data is computed, the "approximate" (RINEX/fugarewe) coordinate is used in the post processing.

There are of course MANY OTHER possible scenarios...

Loyal

I suggest small data sample.
Use a LARGER data sample.

N

Is the .91m difference in the location of one point, or the distance between two points?

aliquot, post: 430124, member: 2486 wrote: Is the .91m difference in the location of one point, or the distance between two points?

in the location of one point

aliquot, post: 430124, member: 2486 wrote: Is the .91m difference in the location of one point, or the distance between two points?

in the location of one point

.3' is a terrible fix, I would assume it's a bad fix to begin with, so 1 yard is to be expected.

MightyMoe, post: 430129, member: 700 wrote: .3' is a terrible fix, I would assume it's a bad fix to begin with, so 1 yard is to be expected.

I was going to suggest the same thing. That's a very high RMS value for RTK. RTK tends to be either good (1m) but not generally in between.

Is it a point you shot with the rover, or the position of the base. If it is a rover shot, how did you determine the coordinates of the base ?

That looks consistent with a too small data sample.
I'd trust neither rtk, nor post process. Larger data sample needed. The more tree cover, the larger data sample needed.
Maybe even do it 2x. Or 3x. Now you start getting a statistical analysis, with error elipse.
N

tigre5000i, post: 430128, member: 7350 wrote: in the location of one point

Now locate 2 traverse points or 2 points where you have a distance. Heck, they can be 1 meter apart for all I care. Then post process and check that inverse.
Now compare the RTK and the static.

System
Auto vs fixed
Input error
Something else.

Change one variable and see the results

Sent from my SM-G930V using Tapatalk

An autonomous position on the base would give you a meter, also as already mentioned .3 feet is not a good fix. Are you sure you were fixed and not on float. I have my RTK setup to not store any fix over .1 without alerting me.

Sounds like he is setting up a base, and then setting setting up a rover. When it says tells him he is fixed, he starts "rovering" without using a localization. In which case a meter is fairly expected. I sometimes do that to stake out my localization to get me close to my monument if its not apparent.

Surveying is a science. And there are many different methods to any one task. Each with its own characteristics and source of blunder and error.

Your question shows that you need much training in the science and methodology. There's a lot of details that are involved.

Hire some one who is trained.

The "HERE" button (Trimble terminology) can be a very useful thing, but also very dangerous. I have seen people go out and setup their base on the same point day after day, and hit "HERE" each day...then the problems begin. Of course, that can all be remedied if you know what you are doing in the office, but the fact that they used "HERE" each day implies that they DON'T know what they are doing in the office. Then they call me for help and i get to bill $$$...

I rarely use RTK for stakeout (hardly ever do any stakeout at all). If I am just collecting topo data or photo control, i am fine with using HERE (don't need coordinates while in the field). Then I post process the data collected at the base, and apply the post processed position as the base position instead of here. The only warning I would give is that the HERE position should be within a few meters of the "true" position in order to avoid introducing a distance dependent bias into the RTK observations, that cannot be remedied in the office. But typically a C/A autonomous position is within a meter or two nowadays. Before SA was removed, the C/A position could be up to 100 meters off, and that was definitely a problem. Now that I have RTX available on my R10, I let it converge to a few cm or a dm before starting the base when i can. Using the RTX ITRF position as a "seed" for the base is theoretically better than using a known NAD83 position, but the difference is negligible.

John Hamilton, post: 430345, member: 640 wrote: I have seen people go out and setup their base on the same point day after day, and hit "HERE" each day...then the problems begin.

Wow. Sad, but true.
I've seen it too.
Nate