Can I "Correct" a .CSV file with GCPs from a Survey Project in Emlid Studio and get OPUS level accurate Points?

I have been having a heck of struggle getting Applanix PosPac and YellowScan CloudStation to accept my GCPs recorded with my RS2+. Each time I try to run Strip Adjustment, I get a No Overlap error between my Area of Interest and my GCPs.

The one time I was able to get Strip Adjustment to run successfully was when I was using GCPs that were recorded by a local surveyor using a Trimble receiver.

I need to learn how to “process” my .CSV files from my Survey Projects in Emlid Studio so my GCPs are OPUS level accurate. If I am able to do this I think I will be able to get Strip Adjustment in YellowScan CloudStation to work. I really hope this is possible? Is Stop & Go the right way to go about this? As far as I can tell, it’s the only function in Emlid Studio that outputs a .CSV file?

Thank You!

This .CSV file from Emlid Studio that says corrected in the title resulted in a No Overlap Error in YS CloudStation

Is it possible to see an example of the Trimble data that had worked before? I know some software do not like header rows, or require specific formatting to work.

1 Like

Hi @joelbladen,

Here is the .csv file of the GCPs that were recorded using a Trimble receiver that I was able to successfully use in YellowScan CloudStation: (note this is a different project than the one I am currently working on)

Here is the accuracy level I was able to get with it. In this case I used an OPUS corrected Ellipsoidal Height in the base station coordinates.

I have been able to successfully run Strip Adjustment in CloudStation using GCPs collected with my Emlid receiver, but only if I use uncorrected base station coordinates, meaning the raw .23O file. When I do this this the accuracy level I got:

This is the raw base station coordinate straight from my .23O file:

I discovered I need to use the Orthometric Height in column D and the raw .23O file from my Reach RS2+ in order to successfully run Strip Adjustment without getting a No Overlap error:

Screenshot 2023-11-12 at 3.43.23 PM

However, when I try to run Strip Adjustment using an OPUS corrected Ellipsoidal Height for my base station and this same .CSV files I got the No Overlap error again. I do think I need to be able to “process” or correct my .CSV file that comes from Emlid Flow so I can use OPUS corrected coordinates for my base station to maximize my accuracy. Any help or ideas you have are greatly appreciated!

Thank You!

@dronemapper23 , It looks like an easy fix.
Looks like you need to convert your Lat/Lon/Height into Grid Datum. It looks like perhaps you’ve removed them from your corrected CSV?
Once you’ve got the Grid Coordinates, just make sure they are in the right CSV format (PENZ) without a header row. When you then import them, it should work. Just remember, Ellipsoidal Height and Elevation are not the same, so whatever program you use will need to calculate this value.
Hope this helps.

1 Like

Are your coordinate systems and units matching?

Hi @joelbladen,

It does help, now I need to learn how to do the stuff you prescribed.

It sounds like I still need to use the Stop & Go function in Emlid Studio to “correct” my .csv file? I didn’t remove anything from my corrected .csv file. After I ran the Stop & Go process in Emlid Studio it returned a .csv file with empty columns for Easting, Northing, & Elevation and the first GCP was also blank because apparently it was not averaged in FIX.

I am not sure why Emlid Studio output a “corrected” .csv file with nothing in the Easting, Northing, and Elevation columns. So what I did was use the NCAT tool on the NGS / NOAA website to convert the Long / Lat in columns E and F to SPC NV W 2703. I also removed the first GCP since it wasn’t averaged in FIX.

Unfortunately that didn’t work so I am going to re-run the Stop & Go process in Emlid Studio and see if I have better luck the second time around.



Yes I believe so. I am using SPC NV W 2703. I created my Survey Project in NAD83(2011) / Nevada West and NAVD88(GEOID18) for height.


1 Like

@dronemapper23, I wonder if perhaps you might be over complicating things for this project?
Without knowing your specific requirements, or the size of the job, I would just use the one benchmark for your site and use it every time you set up your base and use the calculated “Fixed” points for each observation thereafter.
Do the duration required in Static Mode to then run through OPUS to get your Easting, Northing and Elevation (unless it is a published mark, then use its published information), propagate this information from your base through LoRA (I assume that is what you’re using?), then your Rover/Drone will populate the resulting Easting, Northing and Elevation for each point collected thereafter. You should then be able to just dump this CSV into your program.
If your working within a couple of kilometres from your base, these fixed points should be more than precise enough for your application. You should also find then each time you set up (using the same base coordinates) that your GCP’s should still be “Green” in Flow.
Something to consider.

1 Like

Hi @joelbladen,

There are no specific requirements for this job. I bought a YellowScan Mapper and two Emlid Reach RS2+s without really knowing anything about surveying. I am trying to learn how to use them so I can produce professional quality deliverables for a client, most likely a surveyor, engineering, or construction company. All of the stuff I’ve been doing so far are tests to make sure I know how to use my equipment.

I think I am really close to figuring out the process. I think and hope the last step is to figure out how to get my Emlids to output a .csv file that YellowScan CloudStation will accept with my .23O file so I don’t get a No Overlap error every time.

I understand that a lot if not most of the time, a client will provide a known point for me and possibly even the GCPs, but I want and need to be able to execute the entire process just in case they don’t.

I have tested and used LoRa radio to connect my base and rover, but most of the time I use Emlid Caster. I think what you’re suggesting above is that I collect all my GCPs in Static mode by logging over them and submitting them to OPUS individually, instead of creating a survey project in Emlid Flow? I definitely could and would do this if I had to, but I want to learn how to use the Survey Project feature of Emlid Flow and believe it should be able to output a .csv file that I can use in Applanix PosPac and YellowScan CloudStation.

In any case, I really appreciate your help and the help others have offered in this community forum! Thanks so much!

@dronemapper23 If the purpose of the .23O file for CloudStation is to simply pull a coordinate out for the base, could this not be manually entered (when you know it)?
In relation to the other other GCP’s, I don’t think running them through OPUS is necessary, only the one (or another mark) which is where you establish your base for the project. You set your project up with the Base and collect all your GCP’s. Nothing more is really needed from here. If a GCP gets damaged or destroyed, you then then just re-stake it from this data.

1 Like


Yes, I think I can manually enter the coordinates of a known point for my base in YellowScan CloudStation to generate an SBET file. I would still need the .23O file, but I think the software would use the coordinates I entered manually. An Emlid tech support rep (Kirill P.) told me I should always submit my .23O file to OPUS to “correct” or refine the base coordinates, but this becomes a moot point if my client gives me the coordinates of a known point.

As for the GCPs, obviously the best scenario would be if the client provides these as well, but I want to be prepared and know how to collect / record my own if necessary in such a format that Applanix PosPac and YellowScan CloudStation can reconcile them with my base position so I don’t get the No Overlap error.

This is my big hurdle at the moment. There is something I’m doing wrong or something I’m missing that is causing the No Overlap fail. So far I’ve been able to successfully run Strip Adjustment using an OPUS corrected base position and GCPs that were recorded using a Trimble receiver. And I’ve been able to run Strip Adjustment with a non-OPUS corrected base position and GCPs that were collected with my Emlid receivers. What I haven’t been able to do is run Strip Adjustment with an OPUS corrected base position and GCPs that were collected with my RS2+s.

Therefore, I think I need to “correct” my GCP locations in Emlid Studio using the Stop & Go feature and that will output a .csv file that PosPac & CloudStation can use for Strip Adjustment. But this remains to be seen. I have tried this once, but it didn’t work, soI am going to try again with a different survey project of the same site and see if I have better luck. I will know tomorrow.

Thanks again for all your help and suggestions. Believe me, I really appreciate your willingness to share your knowledge and expertise! Once I clear this hurdle I think I will be good to go and I will be able share my experience to hopefully help others.


We are in touch regarding this issue in this thread:

Let’s continue the investigation and keep all the details there to avoid confusion.