Errors Across Multiple Surveys

First off, not a professional. I am using an RS+ as base and rover to survey my own property in NE Arizona. I have chosen NAD83 and NAVD88 for this particular project but I don’t think that matters too much. I am not really concerned about where I am at in the world, just that I am accurate to local benchmarks (property corners). I have setup 3 times to collect points. The first time I collected existing property corners and other features on the land which needed to be incorporated into my design constraints. The second and third time I was simply picking up changes (trench lines, new structures, etc.). Each time I set up I used the same base point (a property corner). The height of both base and rover has stayed consistent across the three surveys. In fact, right or wrong, I’ve just added the points in the initial survey in Emlid Flow so those project settings have remained consistent. Each time I survey, I pickup one existing point (property corner) from that first survey to give myself some confidence.

It appears I am not allowed to upload an attachment here or I’d attach the CSV file. Looking at the contents the Base Easting/Northing/Elevation are significantly different between the three surveys. See below. I would not expect that big of a difference.

Base easting,Base northing,Base elevation
1029860.225,1029446.091,7956.382
1029870.678,1029463.914,7974.378
1029856.231,1029462.454,8010.102

So, two questions. First, how can I prevent this (what did I do wrong?). Second, is there anyway to correct the data I have? The property is 10 hours away . I suppose I didn’t do my self any favors by only checking one point. If I had checked a few more I think I could shift and rotate this data into place.

Perhaps you could expand on this comment:

Does that mean:

  1. the base was accurately centered over the property corner, AND
  2. the base-coordinates for survey2 and survey3 were manually set in Emlid Flow to be identical to when you did survey1?
2 Likes

Are you doing any postprocessing? If you just get a single GPS observation or even average for a few minutes without correction, it will have that much error.

You can download a log from a CORS station and use it to correct your data.

Where are you setting up your base station? If you have a fixed point you want to use, just leave the unit in place for several hours. Then use Emlid Studio to apply CORS correction. Then every time you set up the base, you will enter those coordinates.

Correct, set up on the same point, instrument height the same and leveled up. I suppose the only thing that could be different is the instrument being rotated but I assume that is baked in.

No, I didn’t manually adjust anything here. I simply setup on the same point, waited for a fix, opened the previous project and started picking up points. My assumption was that the base knows where it is in the world.

I can’t post the file but here is a link to it.

The base is calculating its own position but that isn’t submeter or even 1 meter accuracy. It’s more like 10 meters similar to the GPS on a cell phone or a drone.

Here is what I did-- I set my RS+ on an old abandoned rain gauge where I work. After fixing it in place I turned it on. Then after a few minutes I stopped the log and started a new one. Then 6 hours later I stopped logging.

Then I downloaded data from the public base station 13km away run by National Park Service at their Pearl Harbor National Memorial. It was in 1 hour blocks so I had to get all the right files. It’s also in UTC which makes it kind of confusing.

I loaded all the base station files into Emlid Studio, then I loaded my 6 hour log. I chose the settings in the screenshot below, all solutions, fix & hold and combined forward/backward.

Seeing that “all solutions” look pretty good and are in a tight cluster, THEN I switched to single solution and calculated that. I now have an accurate location I can use for my base station. There’s a setting in Emlid Flow where you type in the coordinates.

If you don’t get a tight cluster of points, or if you see green points scattered around, you may need to the averaging.

First, @daygeckoart has a good point about finding a more-accurate base coordinate, however, in your original post you said:

So let me put this idea to you: If you assumed that the base would know where it is in the world, then with that line of thinking, you should be able to assume the rover knows where it is in the world. Because the base and rover are the the exact same model (RS+), right? One is no better than the other. Going further with that thinking, then why have a base at all?

OK, you might have already spotted the error in that logic, but let me talk about it a bit:

The base actually does not know where it is in the world (well it does, but not “accurately”). In this surveying methodology, the surveyor always places the base on a known point. If there is no known point, then the surveyor creates one. The default method with Emlid units is at boot-up, the base waits for a few minutes and takes an average of the single solution, and that becomes your new “known-point” for the base. This point is not “accurate” but, working alone, this is the best the base can do, and it lets you start working productively, within a few minutes.

Afterward, and EVERY time you place the base on that exact spot, you must re-use those exact same coordinates for your “known-point.”

But by default, as @daygeckoart mentioned, every time the base boots up it does another averaging (because the base assumes you are in a new spot, and that you will be looking for new base coordinates). It is up to you to disable the averaging in the base and set the coordinates of the known-point manually. That is how you get accurate repeatability between surveys: the same base coordinates are re-used each time the base is used over the same spot.

Now, with regard to salvaging surveys 2 and 3, if you know the base-coordinate that was used for those, you could do a simple difference calculation between survey 1 and 2 (long/lat/elev.) and apply the offset to each surveyed point. Then repeat using the difference between base-coordinates of survey 1 and 3. …or just start over.

Once you have this sorted out, then investigate “base-shift,” which is another methodology for obtaining repeatability between surveys.

2 Likes

That all makes sense and the correction of existing data seems straight forward. I suppose I could probably do that correction in the CSV output and then import to a new fresh project and export back out to a DXF (that’s mainly what I am interested in). That would be pretty easy.

I just glanced at the project in Emlid Flow and don’t see anywhere to adjust the base. I assume that’s not a project option. I’ll have to connect to the base and manually set that. Unfortunately I don’t have it with me to investigate that.

I was anticipating setting up on that corner marker every time which would be my known point. Recently I realized that’s not going to work long term as the new fence and gate will prevent me from setting a tripod over that corner. I ended up buying brass benchmark to concrete in place for a new base point at better location but then I got to thinking it would be ideal if I just placed a pole in concrete with a 5/8" stub at the top to attach the RS+ every time.

If that base does its averaging on power up then that’s probably what’s contributing to the problem as well. I am not powering it up when on the base point because pushing that button usually bumps you out of plumb. I think I powered it up about 25’ from the actual base point on this last survey.

Sure, and even if you power up 25’ away, you can still go in to the app and tell the base to re-average its coordinate after it is in-place.

And I’ll reiterate just to be crystal-clear:
doing that or using any other method to determine the coordinate of the known-point is something that should be done only once, ever. From then on, just re-use and manually enter that same base-coordinate for each subsequent survey.

Lastly, some caution about base-height: Make sure the coordinate that you write down for the known-point is not dependent on a height that can change.

i.e. don’t use the antenna-height for the known-point if the antenna was on an adjustable tripod - record the height of the known-point at the ground-level marker or at the top of the property pin. Or if you make that 5/8" post in concrete, then you won’t have to worry about it.

I agree 95% with ceith except for shifting the coordinates. That would make sense if the devices were just recording relative positions but they aren’t.

The way differential correction works is that all the signals from all the satellites are logged in the base station and the rover. Because the base station knows what its position is and where the satellites are, it can calculate how much the signals are being delayed as they move through the atmosphere. Those delay estimations are used to correct the readings at the rover.

If your base station’s assumed location is 10 meters from the actual coordinates, the system is just assuming that there are massive delays in some signals and accelerations in other signals. That might show up as an offset in the data but it’s not really.

So what you should do is take your base station and log files and process them again in Emlid Studio with the correct coordinates entered. You can use my method above to calculate correct coordinates.

Also I suggest using GCS WGS84 and Ellipsoid heights. You can convert to whatever coordinate system y ou want later. I did a bunch of data collection in UTM and then realized coordinates weren’t being converted correctly by Emlid software.

Also, even if you have difficulty bringing your 3 separate surveys into alignment, your devices likely still contain the log-files from those surveys. I’m not suggesting that you do this now, just know that this is possible:

With Emlid Studio or RTKLIB software, you can re-process your surveys from the log-files. In doing that you also have the opportunity of entering a base-coordinate. You could use an old base-coordinate or a new coordinate of your choosing, or let the post-processing software average a base-coordinate for you.

Finally, even though post-processing (PPK) is more of a hassle, it has at least two advantages:

  • results can be a bit more accurate than RTK
  • the base and rover do not need to communicate at all
    (meaning no LoRa required; and no cellular/NTRIP required)
1 Like

@daygeckoart you beat me to it

1 Like

@jorsborn , all things considered (with the drive to go back again, unfamiliarity, etc.), I’d be thinking a simple “base shift” on your co-ordinates in excel should be suitable for where you are at. I say this assuming that you’ve set your base up the same way (location, height, plumb, etc.) each time, regardless of the averaging.

Of the three times you set up, do you know which one the sessions the base was set up for the longest? If so, how long and was the logs running for?

My thinking is you could run this log through Emlid Studio (or OPUS if position in XYZ is really important?) to hopefully get a much more precise base position (there is currently a bit of variance of this between sessions, otherwise I think your second session is kind of in the middle) to then adopt and shift all of the other co-ordinates across. This “adopted” base position is then used going forward to manually set on the base for further survey work picking up or staking out.

As it seems all this work was done with RTK, it should just be this simple shift. Hopefully this at least saves you the effort of collecting some 300 points again.

I’m happy to be shot down somehow on this, but I think it might be the best result for this situation. At the very least, at least it’s worth a shot for when you revisit to check.

Joel

I am going to have to re-visit this when I can make it back to the property and get that base. For now, it sounds like I could be ok with a simple difference calc. The items I am shooting are pretty rough. I was loosely picking up points which form the edge of a roadway which snakes around. If I was within 2-3’ on those points that would be just fine. There are a few points there that I will want to re-shoot or correct. I need to be within a few inches on those. I’ll bump the thread when I can get my hands on that base.

You don’t have to wait until you go back to the property. You can take your base station logs and process them as rover logs using a CORS station in your area. You could even process each day separately and compare the results.

Then take the calculated coordinates and put that in manually for your base station location, and rerun everything you did previously in Emlid Studio

The logs are stored on the phone (where Emlid Flow runs)? I assumed they are stored on the base.

Yes they’re on the unit. Sorry, I thought by “get that base” you meant get the location

Hi Jason! I think the guys did a good job answering your questions. I just wanted to make sure you were able to post-process your data or revisit your site using the proper configurations. Do you need any additional help?

I likely still need help and I will have the base/rover in my hands this evening so I can attempt corrections.

Hi Jason! Have you been able to post-process your data successfully? How did it go?