UTM Coordinates with Emlid Studio Stop and Go


We are using RS2’s in Nicaragua for drinking water project topographic surveys and am very happy with how well they are working!

We are using the WGS 84 / UTM Zone 16N coordinate system for our surveys. I am attaching sample files that contain a simple test of measuring two points with the rover, one with corrections from the base and a Fix solution, the other with real time corrections turned off. When processing the data with Emlid Studio, I have two issues:

  1. The corrected file contains a Fix solution for both measurement points. However, the corrected file does not contain the UTM Easting and Northing positions. This means I would need to convert the data using another tool to end up with the data I need for the surveys. I have tried selecting different options in Emlid Studio for Solution Format (e.g., E/N/U-Baseline) but it does not seem to have any effect. I was expecting Emlid Studio to use the same coordinate system as the survey as this included in the survey csv file.

  2. In the corrected file, both the point that had an RTK Fix and the point without the Fix are moved by Emlid Studio. For example, the height of Point 1 (with RTK fix) changes from 287.747 to 293.725. The height of Point 2 changes from 289.179 to 298.729. The good news is that the two points are very close. What I don’t understand is why the Fix point moves. I suspect it has to do with the coordinate system.


1 Like

Hi Charlie,

I’m happy to hear that you’re satisfied with the devices’ performance! Let’s try to resolve issues you’ve met.

Unfortunately, I don’t see any attached files in the post. Most likely, they weren’t attached when you created the thread. You can share them via PM or send to support@emlid.com.

As I see from your description, you perform Stop & Go with the CSV from Emlid Flow. Emlid Studio doesn’t output projected UTM coordinates, only geographical ones. However, you can import back resulting Stop & Go CSV file into Emlid Flow. The app will convert geographical coordinates into WGS 84 / UTM Zone 16N. Please note that you need to select this coordinate system while creating the project.

Here I need to check your files for analyzing. But indeed, it looks like your assumption about coordinate system is correct. You likely compare orthometric heights from Emlid Flow with ellipsoidal heights from Emlid Studio.

1 Like

Kirill - Thanks so much for your reply. I was able to successfully import the corrected output from Studio into Flow 360 to get the coordinates into UTM format. When I originally created the post, I did not see an option to attach the file. doing so now and it would be great if you can take a look at the second question.
Emlid Studio Test.zip (2.6 MB)

Hi Charlie,

Thank you for the files!

It happened because you likely took Base coordinates in Studio from the RINEX header. Coordinates from the header are last averaged epoch coordinates, and they have relative accuracy. Hence, the resulting pos file coordinates are calculated with those base coordinates, and the entire dataset had relative accuracy as well.

If you replace the RINEX header position by coordinates from the CSV file shown in the screenshot below,

you’ll obtain resulting coordinates close to the FIX solution. Those base coordinates are transmitted by the NTRIP provider in RTCM3 messages, and commonly have an absolute accuracy.

UPD: fixed some wording

Ok, this works. But why is the RINEX header so different than the base coordinates in the CSV file? The base is another RS2 unit.

Hi Charlie,

Due to the RINEX standard, the header coordinates are approximate receiver’s position in geocentric coordinates.

How do you set the base coordinates? Do you average in single, fix, or place the base over a known point?

average single…

Averaging in SINGLE considers all observation epochs and calculates base coordinates, whereas header coordinates are the last averaged epoch’s coordinates. Hence, there may be such difference: the base position fluctuates within several meters.

A post was split to a new topic: CS in Stop&Go