Reach M+: RTK vs. PPK Error

Hi folks,

I am new to the emlid forum and I would need some advice concerning PPK.
I work as archaeologist and I try to use reach m+ for geotagging my terrestrial close range photos taken by an DSLR (with hs adapter etc.). My target is to avoid using expensive and big equipment for georeferencing features at archaeological sites but to use SfM georeferenced models.
However, everytime I calculated a model in agisoft photoscan with the geotagged photos, I got big positioning errors (I checked the combination of event file with photos several times, so that should work).
That’s why we did a test to find out how precise the reach m+ with the tallysman antenna is like. We took some points with a Leica RTK GNSS and then used that RTK account for emlid reach m+ RTK. And it worked well, error is about 2-5 cm. But when I use PPK correction data from German SAPOS CORS system, I have at least around 20 cm errors, although the next station is about 5 km. Sometimes the position error is much bigger. And the distribution of points does not fit well to what we measured. I would present some *.obs files, pictures etc., but I am not allowed to upload yet.
I used the recommended settings (emlid docs) for rtkconv and rtkpost. Does anyone have an idea what I am doing wrong?

Hi and welcome on Emlid forum!

Could you try uploading files now? If it still doesn’t work, then please use cloud storage to share hardware setup images and raw data.

Thanks!

Hi, thanks, upload does not work yet, but please find attached a dropbox link with raw data, cors data and in compare rtk reach and rtk Leica:

Maybe anyone has tried out the data?
Regards!

Sure thing! We’ll be back once we check the logs

I looked into your logs, it’s a bit hard to understand what should be compared. There’re some issues with .shp file, I think. Also, Leica’s points are in another coordinate system.

Let’s focus on any one point with a “shift”.
Can you provide me with the following info about it, please?

  • logging time period (from/to)
  • Reach point coordinates collected in RTK (in WGS84)
  • Leica point coordinates collected in RTK (in WGS84)

Thanks.

1 Like

Thank you, Andrew. Just to mention once more, what I’d like to understand: We did a compare RTK Leica vs RTK Emlid Reach M+. All fine. Then, we raw logged once more those RTK measured points to do PPK.
Please find my data in a better overview here:

It contains as point shape files:
Leica RTK; Emlid Reach M+ RTK; Emlid Reach M+ PPK, all in WGS84.

And the raw data:
Rover (raw data logging for PPK by Emlid Reach M+)
Base (German SAPOS Station Dresden)
Logging time Emlid Reach M+ (from *.obs file):
obs start : 2019/07/29 12:36:54.6 GPST (week2064 131814.6s)
obs end : 2019/07/29 12:53:13.6 GPST (week2064 132793.6s)

Here a screenshot:


Thanks a lot for your help!

1 Like

My settings:
grafik
grafik
grafik setupfiles

The Rinex-header of the data from the German SAPOS Station Dresden is being used, according to your screenshot. That CORS station must have some different choices for base coordinates, differing by the coordinate system being used?

A quick Google Search reveals this:

Hi wizprod, that might be the point - you are thinking about WGS84 in difference to ETRS89/UTM33 system?
This is what is written in the rinex header of Dresden Base station, I have to admit I do not know which coordinate system that is:

 2.11           OBSERVATION DATA    M (MIXED)           RINEX VERSION / TYPE

NetR9 5.37 Receiver Operator 20190729 120000 UTC PGM / RUN BY / DATE
0157 MARKER NAME
DRESDEN4 MARKER NUMBER
SAPOS GEOSN OBSERVER / AGENCY
5602R50365 TRIMBLE NETR9 5.37 REC # / TYPE / VERS
09400006 LEIAR25.R3 LEIT ANT # / TYPE
3900264.7076 955081.6091 4939083.4934 APPROX POSITION XYZ
0.0550 0.0000 0.0000 ANTENNA: DELTA H/E/N
9 C1 L1 S1 P2 L2 S2 C5 L5 S5# / TYPES OF OBSERV
1 INTERVAL
2019 07 29 12 36 0.0000000 GPS TIME OF FIRST OBS
2019 07 29 12 53 59.0000000 GPS TIME OF LAST OBS

The coordinates in the Rinex are in ECEF format. Many online tools can convert this, like this tool: Redirecting…

Ok, thanks for that information! After conversion with the tool you recommended, I think coordinates of the CORS are OK, conf. to the screenshot, you have posted:

WGS84 13.759603511472°E 51.0769464079611°N

UTM33: 413107.340m 5659113.482m (plus 33 starting for UTM Zone)

Do you still have an issue with processing, @Cap?

Hi, it seems, that I have found a major mistake in my workflow: If I convert the SAPOS observation file (RINEX 2.11, *.19o) to *.obs in RINEX 3.03 and do PPK, points measured by Reach M+ seem to fit to points measured by the Leica device.

I changed two more options:

In Setting1, filter type shall be combined:
grafik
In Setting2, integer ambiguity res is now ‘continuos’:
grafik

When I do that, I get reasonable results.
Does anybody know, specially for the file format conversion, why is that?

And two more questions:

  1. Do I have to write manually in RTKPOST Delta H/E/N of the antenna of CORS or does RTKPOST recognize that automatically from SAPOS data?

  2. When I collect points by HS adapter with an DSLR and I use these points for georeferencing in agisoft photoscan, I get much better results but still I have to uncheck photos with major errors, otherwise it looks like that:


    I know that the model is coarse and not well done (focal length is constant, but probably to little photos), but georeference should have a smaller error. If I uncheck some references, error decreases to about 0.1m:

    I took photos with a tripod, so the antenna of Emlid Reach should produce no errors by different angles with equal coordinates, by the way.
    Is there a difference in terrestrial photogrammetry in compare to UAV models?

Hi @Cap,

Sorry for the delayed reply!

I believe if you choose the “RINEX Header position”, the antenna delta data should be counted. However, if you enter the base position manually, you also should enter these data.

May I ask you to share your *_event.pos file, please?

Hi Tatiana,

thanks for your reply and information about antenna height. I will not be able to share that event.pos file before beginning of september, but I will upload it then!

1 Like

Hi everybody, please find attached the _event.pos file.
raw_201907241328_events.pos (4.0 KB)

Hi @Cap,

Sorry for the delayed response!

From your _events.pos file I can see that the solution status of your survey was Float for the most part. It means that the maximum accuracy that you could reach is submeter-level. This may be the reason why your PPK results differ so much from the RTK results from other devices.

This might happen because of the low quality of the observation data or inaccurate settings in RTKPOST. For improving your solution, I’d recommend checking our guides on how to analyze the observation data quality and improve the post-processing result.

1 Like