Carlson SurvNET GPS Adjustment

Two state plane coordinates? From where did you obtain them?

Did you press "here" for your Base position on the first survey?

We located with state plane using a wifi connection and mifi set up in our state. ?ÿWe were tied into the local state plane and shot the GPS coordinates with the mobile Rover. ?ÿWe shot each point twice and averaged the points.

When we set up the base it was not over a known point. ?ÿWe shot in the base using satellites. ?ÿWe then localized on the two mifi coordinates we had set.

I guess I posted on the wrong duplicate thread.

Did you use a Combined Scale Factor to scale your total station distance measurements to state plane??ÿ Failing to do that will give serious residuals in most areas.

We didn't use the total station in this survey, only GPS. ?ÿI know, confusing, two posts. ?ÿTwo different jobs. ?ÿThe other post is about the combination of the total station and GPS files. ?ÿI replied to that post.

You are being asked about the source of your base position because 6 feet is a typical distance between an autonomous position and a corrected one. And even if your base position is correct, rover positions that are not "fixed", and are therefore autonomous, may be recorded.?ÿ Another possible source of error is a mixup with international foot / US Survey Foot settings.?ÿ?ÿ

DGPS that's your answer.

Differential GPS.

If you set up a lone gps, 100x, and store data, on the same point, for 2 hrs each time, (shut it down, and restart each time) you will wind up with 100 coords, inside a circle, of varying sizes, but typically having a diameter of 10-15 ft.

What do we learn from this?

That gps, by itself is good to 10 or so feet.

Now, set out 2 receivers, and process together, and we have DGPS. It's good at determining the DIFFERENCE between two receivers.

Now, repeat this setting out of 2 receivers.?ÿ 100x. The difference between them, (2 hr observations) is quite good. But, now both receivers are bouncing around 10-15 ft, but they bounce together.?ÿ

What do we learn from this?

We need other receivers, such as opus, cors, or a known point, with a receiver on it, to "stop the bounce".

DGPS. That's your answer.

The satellites only give you 10-15 ft.

There's your 6 ft.

Nate

I'm confused. If you used a mifi(VRS) RTK solution, As Norman mentioned, the shots should be more accurate than 6 ft unless you were in some really crap canopy or deep canyons with poor horizons. Base not being on shouldn't be that much of a factor because you have a solution for the new data on the new satellite constellations for that epoch. I say go shoot them again with the VRS, make sure you're showing fixed positions with good residuals, and compare the new shots.

Sorry. ?ÿTo get back to this 2 weeks later. ?ÿI think the problem with the data is with the adjustment process in SurvNET. ?ÿWhen I simply put in the unadjusted coordinates into the drawing, it all matches. ?ÿIn that case, the Base/Rover and MiFi shots will line up. ?ÿBut if I adjust my Base/Rover shots using SurvNET and then try to drop in the MiFi shots, it jags. ?ÿI guess I am unsure what the adjustment is doing to the vectors to cause this to happen.

It relates to the old "precise vs accurate" consideration.

If the base in the base rover combination was properly localized to the mi fi points?ÿ than your base/rover measurements should be reasonably precise because of the short baseline, but not highly accurate because they are based on two points with a longer baseline.?ÿ It's not reasonable to see a 6 foot residual.

But if you used "here" or an averaging method to determine the base position the base/rover points will only be as accurate as if you have set up a single GPS receiver...about 10 to 15 feet.?ÿ But precise within the overall network.?ÿ A residual of 6 feet would be reasonable if comparing to the mi-fi points.?ÿ It would be a consistent residual over the whole network.

When you described your procedure...shooting two points with mi-fi, then localizing the base/rover points to those two points and continuing the survey, it sounded like you were doing the right thing.

?ÿ

Trying to follow what I think was the chain of events...

1. Posted by: NeilRick
   We located with state plane using a wifi connection and mifi set up in our state. ?ÿWe were tied into the local state plane and shot the GPS coordinates with the mobile Rover. ?ÿWe shot each point twice and averaged the points.

2. Posted by: NeilRick
   When we set up the base it was not over a known point. ?ÿWe shot in the base using satellites. ?ÿWe then localized on the two mifi coordinates we had set.

3. Posted by: NeilRick
   We didn't use the total station in this survey, only GPS.

4. Posted by: NeilRick
   After realizing we had left out some road shots, we went back and shot in the road using the State Plane Mifi system without the Base set up.

I believe the secret here is item #2 "When we set up the base it was not over a known point. ?ÿWe shot in the base using satellites." Since the base was likely over an arbitrary unknown position and in an Autonomous GPS solution (typically with a 2-meter accuracy range), I suspect it is accounting for the discrepancy you're describing because SurvNET is examining the processed results of?ÿraw file observations (e.g. lat/long/ellip. elev.) against your specified coordinate system rather than?ÿ "localized" results. Working backwards:

1. The road points shot with step #4 should match the?ÿlocal?ÿcontrol shot with step #1 above because you used your?ÿwifi connection and mifi set up in your State in both situations.
2. The base position shot with step #2 was (say) Autonomous so points collected from it wouldn't normally match anything other than itself.
3. To correct this, you localized the first round of data for the job on the?ÿlocal?ÿcontrol shot with step #1 above.
4. The result is:
   • Processed coordinates that should properly align, but,
   • Positions that have been derived from two different GPS base station locations (a network provided base and your autonomous base)
5. Presuming that you let your field software derive the State Plane coordinates shot in step #1 (in other words, non-localized), the mixing of localized and non-localized data is probably at the root of the problem.
6. I'll defer to those here with the much more vast field and practical experience than I but one recommendation would be to consider (if practical) the placement of your base on one of the two?ÿState Plane coordinates shot in step #1 after they've been located or locating a temporary?ÿState Plane coordinate for the base using the same methodology as you used in step #1. This would help minimize the error you're seeing.

However, all is not lost (at least I don't think it would be). If you have Carlson Survey, you might explore the Survey -- Edit-Process Raw Data command. Import the raw file. Once imported, explore the Process (Compute Pts) -- GPS routine. With this routine, you could explore the option of re-incorporating the localization option you might have used in the field.

I hope this information helps.