Question about using Survey .CSV to apply offset to rover points using OPUS-corrected base position

Hi folks,

I have a question regarding the correction of my rover’s points collected in a Reachview Survey.

I used two RS2s in a base-rover setup. I set up my base station over an unknown point, using “Average single” averaged its position for 5 minutes, then wrote this position down. I verified my rover unit was receiving RTK corrections and surveyed each point for 60 sec using FIX only. I successfully uploaded my filtered GPS-only observation file to OPUS for a corrected base position, and now I’m at the point where I need to apply the offset between my averaged base position and my OPUS-corrected base position. From there I will correct the rover points to match this calculated absolute position.

This is my averaged base position:
339935.924 143905.965 10.671

This is my OPUS-corrected base position:
339938.818 143902.406 7.417

Specifically, what is the math I should use to apply the offset? I haven’t found a clear answer on this in other threads and while I feel like it should be obvious I’m not coming to a confident conclusion.


1 Like

Are these cords geographic or some kind of local (linear) projection system ? i.e., state plane or UTM. If the latter, it’s a simple matter of subtraction from north coords and east coords from the OPUS solution. You cans do this in CAD in a linear system but not in geographic. If they are in geographic form, you need to convert the coords to some kind of local projection system.

Ex:. OPUS coords 500,000.00m N. 1,500,000.00m E
Field Average pt coords 500,005.00m N,
1,500,010.00m E
Difference = 5.00m N, 10.00m E

Simply apply the sift to all field points including elevations. You can do this in Excel or use professional software for the translations. This is assuming that this a small area of location. Larger areas will require professional software as simple translations do not consider scale/elevation factors for the projection used and will result in grid distances, not true ground surface distances.


Hi, thanks for the response. Yeah, the coords are in NJ state plane.

So if I’m understanding your example correctly, the shift that would be applied to the collected rover positions would actually be 5m south and 10m to the west? Since the averaged position was 5m north and 10m east of the actual (OPUS) position? This is the part that I’m getting stuck at.

As for the last sentence, what would you consider a large area? The project I’m working with is about 90 acres in area. Thanks again!

Hi Theo ! I’m talking county wide projects or larger.

To simplify your shift issue, plot your averaged base coords on graph paper or even in AutoCAD. Then also plot your base’s OPUS derived coords. This way you can actually see the shift values. So whatever the difference in North, East and elevation values between the OPUS and field base, simply apply the delta values to your averaged base and rover points. If done correctly, the difference in the base coords should be “0”.

There’s several ways to do this as others here in the forum may chime in on this. The simple way is to use Excel or any kind of COGO surveying software.

If you’re not familiar with AutoCAD, keep in mind that in AutoCAD world X(E) and Y(N) are backwards. To place a circle at your OPUS or averaged base coords, you would type command “C” then enter your east(X), north(Y) coords.


Thanks much Bryan, I appreciate it.

1 Like

Since you’re here - one more question:

Is the elevation from the OPUS readout the elevation of the Emlid receiver itself, or of the mark you set the receiver on top of? Wasn’t sure, since antenna height is included in the calculation.

1 Like

If you entered the distance from the mark to the ARP (antenna reference point) and used the correct antenna model or receiver, the OPUS solution gives the computed position of the mark.

1 Like

Hi Theo,

Did you make it all work out? :slightly_smiling_face:

Bryan’s comments cover all the process but still want to ask, just in case.


Hi - I’m checking on this thread for confirmation of exactly how to do this conversion. The one piece that seems to be missing in this discussion is that the “averaged base position” listed at the beginning is actually referring to the antenna position of the Reach RS2 base instrument and NOT the point on the ground below the instrument (during base setup with the “average single” method, you do not enter in the instrument height…so it is estimating the elevation of the antenna position on the instrument). If you entered in an antenna reference point (ARP) height into OPUS, then the solution that it returns is the position of the ground below your instrument. If you want to calculate the offset in order to correct your rover survey, you need to make sure that you are calculating it for the exact same point. So what I have done is added the ARP height plus the antenna height (0.134 m) to the OPUS-corrected base position elevation (note that this only matters for elevation, not X and Y) so that then the offset can be calculated for the two position estimates of the actual antenna position of the instrument. That offset can then be applied to the rest of the rover survey points.
If this is not correct, then I hope someone can jump in here to correct me.

1 Like

Hi Eric,

You’re right! And that’s a good point. While calculating an offset between two base positions you have, you need to remember that averaged position includes the tripod height, unlike the position from OPUS.

1 Like

Hi Svetlana,

Yes, I found Bryan’s solution worked great for me. Thank you for following up!


Hi Svetlana,

Thanks again for the confirmation on this question. I have one additional question regarding this base+rover setup using OPUS corrections during post-processing. I just noticed that the “Logging” menu for setting up the Raw data collection settings within Reachview 3 has a “Measured height, m To the bottom of the receiver” user-entry box. Apparently, I have been using a value of 1.42 for recent surveys (which I didn’t realize since I don’t typically click on the Raw data settings; I just hit “start recording” when I set up my base). I’m wondering how exactly that value gets used in the OPUS processing (if at all). I am already specifying the ARP height when I upload the RINEX file to OPUS. Why would I also need to have the measured height to the bottom of the receiver (the ARP height) specified along with the raw RINEX file? I just assumed that the RINEX file didn’t have an antenna height associated with it. Thanks for any info you can provide.

1 Like

OPUS ignores any antenna heights in the rinex file. When you submit the rinex file, it asks you for the antenna model or receiver. It also asks for the antenna height. If you’re measuring to the control mark or your own mark, enter the antenna height from the mark to the ARP of the antenna or receiver.

If you’re not using a ground mark, just select antenna model or receiver and enter “0”. OPUS will warn you about this.


So essentially the entered antenna height in the Reachview logging settings has no effect on the OPUS output? I encountered the same thing as @egbooth during a recent survey and was wondering if it was going to affect my calculated position, but after measuring the same spot a few days in a row I got the same result back from OPUS, including the days I unknowingly had an incorrect antenna height in the logging settings.

It’s good to always use a physical mark or reference mark in the ground. You can always go back to verify any errors. The only time I use a “0” HI is when I’m using my magnetic mount with the base on the truck. When using this method for RTK, make sure you locate enough permanent control marks that you can re-observe the site using one of the reference marks for a base. I use this method for the base if I’m in an area of possible theft. Most people don’t look for a base on top of the truck.

We only use 2 m tripods/bipods for observations submitted to any online processor or for PP in house. It keeps things simple. If you use a tripod with tribrachs, it’s kinda hard to get an accurate HI to the ARP.

Thanks for the confirmation, Bryan!

1 Like

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.