Reasons for a coordinate mismatch and how to fix it

Let’s say you carried out a survey, compared the results, and realized that you have a coordinates mismatch. Today, we share with you possible reasons and how you can resolve this issue.

  1. Solution status

    The first possible reason for inaccurate results is that you have collected points with the FLOAT or even SINGLE solution. In such cases, the accuracy is usually meter-level.

    How to fix: Collect the point with FIX solution status.

  2. Antenna height

    To obtain the coordinates of the point on the ground, it’s important to set the correct antenna height for the receiver. Check the value you have set. You can learn more about this in our previous posts on antenna height setup for RTK and PPK.

    How to fix: If you have entered the wrong value, you can recalculate the heights of your points manually.

  3. Base placement

    When you do a survey, you always need to keep in mind whether you need absolute or relative accuracy.

  • Relative accuracy

    The relative accuracy and the Average SINGLE coordinates entry method used for this provide only meter-level results. However, if you have a FIX on the rover, the position of the points relative to the base and each other is precise to centimeters. To get consistent results in this case, be sure to set up the base in the same location and use the same coordinates for it in successive surveys.

    How to fix: If you have carried out the measurements with different Average SINGLE positions of the base and have the points measured in both surveys, you could superimpose the data.

  • Absolute accuracy

    To obtain centimeter-accurate coordinates in a particular coordinate system, you need to place the base over a known point or use an Average FIX entry method.

    How to fix: If you have carried out the survey with the base placed using Average SINGLE, but you have precise coordinates of it (for example, after uploading the log to the PPP service), you can shift the survey results following the steps from this tip.

  1. Coordinate system
  • Horizontal datum

    Another reason for a coordinates mismatch is a difference between the required and used horizontal datums. The geographic coordinates you have in Emlid Flow are in the datum of the base position. So make sure that your own or the NTRIP service’s base send position in the datum specified in your Emlid Flow project. This way, the projection can be applied properly:

    How to fix: If this is not the datum you need, you can convert the geographic coordinates from Emlid Flow to the required datum in 3rd-party software. After that, you can also apply a projection to them if necessary.

  • Projection

    If you work with the projected coordinates, check that the coordinates you’re comparing are in the same projection.

    How to fix: If not, you can follow these steps to convert the data:

    1. Export your project in CSV format from Emlid Flow.
    2. Manually remove the data from the columns Easting, Northing, Elevation, Base Easting, Base Northing, and Base Elevation. You can do that in Google Sheets or any text editor.
    3. Create a project with the correct projection.
    4. Upload the CSV to it. Emlid Flow will automatically recalculate the data.
  • Height (vertical datum)

    The main issue with heights is usually attributed to the use of ellipsoidal and orthometric heights. First, verify which type of height you need for your project. For orthometric heights, check that you have specified the geoid model when creating a survey project.

    How to fix: If you didn’t use a geoid model or used the wrong one, you can follow the same steps as for the wrong projection.

That’s it! We hope these tips will help you out! If you have any questions or need further help, do not hesitate to contact us at

P.S. Our last post was about creating an orthomosaic for Emlid Flow.


Does the absolute accuracy of the Base’s coordinates impact the relative accuracy of the rover, in a pure Base/Rover RTK-over-LoRa configuration?

I.e. is the relative rover/base accuracy going to be affected if the Base averages its location (in Single mode) for just 10 seconds, vs. the Base averaging its Single location for 10 minutes before it starts providing corrections to the Rover? (Assume the Base has no other way besides an Averaged Single fix to find its own location. (No NTRIP available, no time and/or internet connection avaialble to acquire an OPUS/PPP coordinate solution, no surveyed benchmarks available.)

I would think the answer is “it doesn’t matter” because ~3m (meter) absolute static location coordinate accuracy the Base achieves within just 5-10 seconds of SINGLE fix, is more than enough for purposes of correcting the relatively short baseline between Rover and Base?

You would need to log a sufficient time if you are planning to eventually post process the base using either AUSPOS, OPUS or PP yourself. You can log data at the base as your rover collects points. Your time on station at the base will depend on baseline lengths and post processing services.

It’s good practice to log a sufficient time at the base, you might need it one day . Just an old surveyor’s opinion.

1 Like

I know it’s hard for a professional surveyor to appreciate, but there are some use-cases for GPS surveying that don’t call for any kind of absolute reference points or accuracy with respect to outside grid coordinates, ellipsoids, etc.

My main use case is quickly & accurately mapping small sites (usually less than 1 acre) for doing local, small-scale building construction plans (not civil engineering.)

In these cases, all I want to do is get to a site, set up a base station, & start surveying as quickly as possible.

If there is no difference in the rover’s RTK relative accuracy, receiving its corrections from a base that only took a 10-second SINGLE averaging for its own fixed coordinate, vs. a 5-minute or 10-minute SINGLE average, then that saves me valuable time.

Hi Manscuto,

Sorry for the late comments!

Yes, a longer averaging time will still result in several meters’ accuracy for the base (when it’s in SINGLE). So there is no need to keep the base averaging for 5–10 minutes. Our default time for it is 2 minutes. But shorter intervals should also be okay for your use case.

Speaking of relative accuracy, if you have a fix on the rover, the position of the collected points/lines will be precise relative to the base and each other. However, their absolute accuracy will be about the base placement accuracy (several meters).