PPK tips and tricks with far CORS data

Hello Emlid community,
I am a marine biologist (totally foreign to these issues before discovering Emlid) and since about two years I started working with aerial UAS mapping.
I would like to ask you some opinion and suggestion about PPK data deriving from my Reach Rs+ units and Rinex files from a CORS. I apologize in advance because maybe I will ask some trivial questions but since previously I was able to get awesome results thanks to your suggestions, I am really motivated to ask again :slight_smile:

My scenario is the following:

  • Two Reach RS+ units used to collect GCPs before aerial mapping in RTK mode
  • A CORS station very far from me 150 Km but without particular obstruction because I work on an Island.

My trials gave to me some difficult results to understand given my poor knowledge. So please help me to better understand this odd word_:slight_smile:

So by using RtkPost, I processed the data deriving from my Rover unit against CORS Rinex and I achieved a very good result (with 99.8% FIX solutions which is quite unexpected given the long baseline) but only when I use the following settings regarding Ionosphere and Ephemeris.

However, I learned that with Precise Ephemerids available at ftp://igs.ensg.ign.fr/pub/igs/products/ the results should be improved, so I downloaded rapid ephemeris file (igr-number of the GPS day-.sp3) some day after my survey (igu, that is ultra rapid are available almost immediately but rapid should be better from my knowledge). I changed only these settings in Rtkpost and the results seemed to get worse. As you can see below the Fixed solution percentage dropped at 88.9%

Moreover when I tried to compare both results (green e blue points are the fixed solution) in RTkPlot I noticed that the my tracks along which I collected GCPs are shifted more than 1 m each other.

Now my thoughts are that with rapid effemerid the ambiguities are resolved differently and probably the correct absolute coordinates of both my track and then of the GCPs are stored in the second .pos file derived from PPK with precise ephemerids.

Someone could confirm this idea ? What I am missing?

The second step I tried was a trial to work with a shorter baseline during PPK in order to avoid using the CORS data to process directly Reach rs Rover track to get its absolute positions.

My workflow is the following:

  1. I put my Reach Base unit on a tripod and recorded raw UBX logs for three hours, before starting my operation with the rover unit . Subsequently, I collect in RTK mode the track and GCPs (remaining on the point for 5 minutes) with my rover unit (so in the field I collected with Reachview App only relative coordinates because I averaged position of my base unit on a unknow point).

  2. At home I processed the raw log of my base against rinex file from the CORS to estimate absolute coordinates of my base unit (also in this case I noticed a shift in my data when using rapid Ephemeris so the same problem as before). However, beside this aspect I choose one result (namely that derived from PPK with ephemerids) and I was able to filtering it according time in order to preserve only fix solutions on my static point (the base). I noted the ORI coordinates displayed in the top right corner of Rtkplot.

  3. Finally, in RtkPost I uploaded .obs files of both rover and base, .nav of the base, precise ephemerids and in the base position tab I manually entered the absolute coordinates estimated before.

In such way I supposed that by adding the absolute coordinates also the rover positions will be changed from relative (linked to cumulating and averaging processes of base unit in the field) to absolute (linked to the PPK with CORS). However, the results reported below was no so good because many float (Q2) solutions, even in the parts where fixed (Q1) solution was achieved before (when I processed rover data directly against the rinex from the CORS).

Again what I am missing ? I need to change some settings or my workflow is absolutely wrong?

Sorry for this long post and I hope that someone else will find it useful for other similar questions.


1 Like

Hi @Dan86,
In my opinion, you should distinguish baselines processing between Base-CORS and Base-GCPs observations.

Surely, you had to do a long time observation for this long baseline. Perhaps 3 hours is minimum for ideal result. After calculating the definitive coordinate of Base, you should simply calculate the coordinate differences between it and the Base coordinate that you used in field (in dN, dE, dU).

Finally, you only have to do a simple correction by adding the Base coordinate differences (dN, dE, dU) to this GCPs coordinates to get the definitive GCPs coordinates. You may recheck the results by doing static survey on several GCPs tied directly to CORS station. I hope this will help.


Most times, as Fanani describes, I usually just set up my base and keep it running and logging a position while locating points using radio RTK. When I get back at the office, I PP the base with surrounding CORS to get an accurate position either using Javad Justin 3 or NGS OPUS for the base. I then translate all points to the new base position using Carlson software. If you have any rover points that didn’t have RTK, you need to PP the static rover points with the new base position. Using 150 km baselines with the rover locations will not work with any gurantee of accuracy as there’s not enough time in the rover locations.

I have manually PP long baselines before (100 km) just out of curiosity, but you really need a long occupation to resolve any ionosphere effects. Usually, the long baselines, with enough time, are within 2 cm horizontal and vertical compared with shorter baselines of around 30-50 km.

To really verify the base using 150 km lengths, it would be wise to re-observe on another day. I’d recommend a minimum of 4 hours per session. That way, you would be confident in the base position.


Many Thanks Fanani and Bryan for for your suggestions which have clarified me how I should work in future.
So to summarize:

  1. I have to keep separated Base-CORS and Base-GCPs observation during PP, keeping in mind that for such long baseline I need a long static survey on each GCPs because 5 minutes are non sufficient to get an accurate positioning. At least for hours of raw logging are recommended for estimating the Base coordinate against a long baseline >10 km CORS.
  2. Estimate absolute coordinates of my GCPs by adding to them the shift from Base coordinates (dN, dE, dU). I suppose that I can easily do this step in Excel.

Regarding the software mentioned by Bryan I am quite afraid about trying them because I learned to use RTKlib thanks to this forum and Emlid Docs and I suppose that could be difficult to do the same with other software due to my poor knowledge on PPK.

Finally, I would just ask you again if is it correct to use during PPK rapid ephemeris .sp3 files instead of Broadcast ephemeris even if I get apparently much better results ?

Thank you again for your time and support.
I wish you a very happy new year!

1 Like


RTKLIB is good software, I wish I had more time and energy to really dive into the processing of using it. I’ve used it maybe 5 times just out of curiosity. If you’re comfortable using it, keep on with the software. It’s great for what it does (single baseline processor), T. Takasu was and still is a genius for the development of the software. Emlid and others wouldn’t be where they are now without it. The software I mentioned is used by most professional land surveyors and isn’t cheap. However, both are excellent to use and have various adjustment routines, multi baseline processing and CAD capabilities.

It sounds like you have a good solid base on the methodology of processing before Fanani and I commented. There really isn’t much difference using the broadcast versus precise ephemerides. I’ve used precise before for projects submitted to NGS, you might see maybe 1-2 cm difference. If you’ve got no time limits on your project, you could use precise and determine the difference.

Keep up the good work in your project. The project sounds very interesting. One of these days, I’ll jump into the world of UAV mapping. I’m jealous that you’re on an island surveying !!

Hi Daniele,
probably, it would be more convenient for you to use
a nearest CORS station. In Italy there are several GNSS networks that distribute the Rinex data of their CORS stations; the INGV, where I work, also has a national coverage network (http://ring.gm.ingv.it/); take a look if there are stations you might be interested in (… maybe MAON http://ring.gm.ingv.it/?page_id=726&site=MAON). The 30s Rinex data are free (see Credits & Disclaimer http://ring.gm.ingv.it/?page_id=1223), but if the purpose of use is related to scientific research, I could check if 1s data is available.
Best wishes for your research.

I love this forum for this reason because: there is always something new to learn !
Dear Giampaolo,
thank you so much for your great suggestion and YES, the CORS of Monte Argentario would be perfect for my needs. I used 1s as time acquisition with my reach rover but, to be honest, I don’t really understand what this implies if I would use 30sec rinex data for post processing. This could affect the final accuracy of my measurements? In this case is it possible to avoid this issue by acquiring the positions for a longer period ? I have no rush so I can remain on my points for days :slight_smile:
I am a PostDoc researcher and I would collect some accurate GCPs along the coast with their absolute coordinates in order to use them as check points to check the accuracy of my orthomosaics generated with a small UAS (DJI mavic 2) equipped with a GNSS antenna. Any advices is more than welcome, as you have understood.

Thank you again for your time and valuable suggestions.

If you are going to do long measurement sessions (of hours), the answer is likely yes. Be careful, however, to assign the coordinates to the base, which will affect the position of the rover.
If you need more information, you can contact me privately.
Gianpaolo (https://orcid.org/0000-0003-3610-2650)

Thank you again Giampaolo for taking the time to answer my concerns.
I have tried PP the same point (the position of my base unit after 4hours of logging) with 30 sec rinex data from the MAON station you suggested. As you can see I got much better results with a 99.8% of fixed (Q1) solution compared to the 60% achieved with the CORS of Firenze from EUREF.

I suppose that for my needs this accuracy could be sufficient and I may use this coordinates as input for my base unit the next survey. I will try to avoid to bother you for 1s data but many thanks again for sharing your contact, the mine is the following: https://orcid.org/0000-0002-3548-360X
Next week I will make some other trials and let you know, hoping our discussion would be useful also for the others.

Thanks so much again.
All the best,

Hi Daniele,

Looking forward to hearing your results!

I’d like to comment on a few points:

We’ve checked that Fix can be achieved in PPK with Reach RS+ on up to 20 km baseline. We can hardly predict the result’s accuracy on such a long baseline as 150 km. However, if RTKLib can get Fix fine with our pre-configured settings, I’d suggest processing the data using them.

As Fanani and Bryan suggested, you can try a longer static survey to improve your result. Please note that the difference between known and calculated base coordinates depends on atmospheric conditions. As the rover atmospheric conditions may differ, I would not recommend correcting the rover coordinates on a long baseline by adding the shift.

Dear Giampaolo,
sorry again for the bother.
Yesterday I tried to make another static point acquisition in Giglio Island to check mine previous PPK errors achieved with the very long baseline of Firenze. However, when I tried to find the files, I noticed that the MAON station which is very good for me, seems stopped delivering Rinex from 5th of January . Do you have some information about this ? Could be something linked to the website or the station have enotere some problems ? I really hope that the rinex file for yesterday can be recovered because otherwise I have a raw log of 8 hours to put into the bin :sob: :sob: :sob:

Best regards,

If you don’t find any associated files with your observation, you could use NRCan or AUSPOS PPP service. Many commercial PP packages can do this such as Javad Justin and I think RTKLIB. I wouldn’t toss the file in the bin !

Hi Daniele,
I’m sorry if I didn’t answer you before … I checked and in fact the MAON station has been stopped since the beginning of the year. Alternatively, I would suggest using the data from the PSTE station (Porto S. Stefano) of the Italpos network very close to MAON. So I am attaching the RINEX to 30s of DOY 5. If you need anything else let me know.
GianpaoloPSTE00ITA_U_20210050000_01D_30S_MO.zip (1.0 MB)

Hello Gianpaolo,
thanks a lot again as before you saved me a lot of time with your suggestions.
There is a way to access to PSTE station of Italpos for other Rinex data ? Because I have done the acquisition on the 26th of January…
Thanks a lot and have a good Sunday.


Hello Fanani,
I would like to share my tests just to have a confirmation from you that I have well understood your suggestions.

This is my workflow:

  1. I have averaged (with a single solution) my Reach RS+ base position for 15 min and used it as base coordinates. Raw UBX logging set to on.

  2. I started to collect some GCPs on the ground with my rover unit. The whole session lasted 3 hours.

  1. I returned to the office I downloaded the raw files from my base (3 h raw log) and the GCPs position recorded with reach ViewApp.
  1. I used RTKlib to estimate the absolute coordinates of the base by performing PPK on the 3h raw log. I used Rinex files from a near (40 km) CORS. The following coordinates in WGS 84 are the averaged and the postprocessed, respectively:

Averaged 15 min: 42.3616661361 N|10.9195931875 E|53.242 U|
PPK_3h: 42.361644604 N|10.919586979 E|51.4765 U|

  1. I calculate the coordinate difference (dN, dE, dU) between PPK base coordinates and the averaged cooridnates used in the field, obtaining the following results:

Difference_Base: dn= -0.00002153 N; dE = -0.00000621 E; dU= -1.76550000 U

  1. Being the first GCP coordinates recorded in the field:
    GCP1: 42.36170776 N; 10.9195776 E 52.59036333 U

I applied the correction by adding the Base coordinate differences to this GCP coordinates:

GCP1 absolute corrected coordinates = 42.36170776 N + ( -0.00002153) = 42.36168623 N
10.9195776 E + (-0.00000621) = 10.91957139 E
52.59036333 U + (-1.76550000) = 50.82486333 U

Do you think that these processing steps are corrected?

Moreover, if without moving my base unit and keeping on the recording of the raw log, I also perform a mapping grid by using a drone equipped with an L1 antenna, in your opinion, could I use the same approach to correct also the coordinates of each image obtained after post-processing raw logs from the L1 antenna mounted on the drone against raw logs of my reach RS base?

Hello Daniele,
Yes, that what I meant. For a small area the method is practical and will give you centimeter accuracy.

However, if you want to improve the accuracy, you may use geocentric coordinate system (X,Y,Z) instead of geodetic (latitude, longitude, height) as it doesn’t be affected by earth’s curvature. Also, you may use static differential observation rather than PPK, as it will give you sub-centimeter accuracy (need a little change in processing parameter in RTKLib). But this all depends on the needs in your work (not mandatory).

Yes, you can use same approachment.

And don’t forget to double check the result by doing PPK observation (40km) in one or two of your GCPs only to confirm that your measurement is right.

Good luck with your project.

1 Like

Many many thanks again Fanani for your quick answer and valuable suggestions!
Yes, for larger areas I will use a geocentric coordinate system to reduce the effects of the earth’s curvature.
I read that by setting to static and continuos integer ambiguity resolution more reliable results could be achieved in PPK for static acquisition. Therefore, concerning the static differential observation which required a little change in processing parameter in RTKLib, are you referring to change the settings of RTKpost maybe as follows?

Thank you for your time!

Yes, Daniele. That is what I meant.

No problem Daniele. Happy to help :blush:

Hi Daniele,

I just wanted to add that Reach RS+ should provide you with accurate coordinates in both ECEF XYZ and LLH.

In most cases, we recommend using the RTKLib settings from our GPS post-processing guide, as we’ve tested that they work fine. In our tests, the Continuous and Fix-and-Hold modes provided similar results, so we can hardly judge that one of the modes is not as good as another one. Other factors such as environmental conditions or satellite systems used usually influence the result to a greater extent.

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