PPK for estimating absolute base coordinates of unknown point from CORS and Raw Reach RS+ data

Hello guys,
I’m very new to RTK GPS systems and since I’m a marine biologist and neither a topographer nor a geologist, first of all I’d like to apologize for some very trivial requests that I may have in this post. However, I recently bought two Reach Rs+ modules in order to collect Ground Control Points (GCPs) during AUVs surveys, along coastal environments to study elevation differences after storms, debris accumulation, etc. Thus, for my purposes I really need to produce accurate DEMs form SfM photogrammetry and so the use of GCPs is mandatory. I choose this way because I’m not a skilled nerd so direct georeferencing techniques with Reach M+ have scared me because to be honest I really don’t know how to connect the camera of my commercial drone (DJI P4ADV) to external systems for geotagging photos.
Anyway, I tried to understand the basics of RTK and PPK by myself by reading the great Emlid Docs. In addition, I have found very useful information in these posts:




Now I would like to summarize what I have understand and I would be grateful to anyone who can confirm or correct my ideas step by step.
It is the moment to better explain my operating scenario. I work in Giglio Island (Tuscany, Italy) and NTRIP services (to get an RTK FIX position of my base) are not free. Also, know points (trig points) to set manually absolute coordinates of base coordinates are quite far from my area of interest (~ 3 km). No so far for Reach LoRa radio connection but quite far to be stolen :sweat_smile:
So, what I would like to do would be to generate a new know point after PPK to set my base near to my area of research and perform my survey. Of course, I have tried to average base position but as well described in Docs in this way I only know a precise position of objects (e.g. GCPs) relatively to the base station but not their accurate absolute position. So, I think that to have absolute positions of my rover unit during GCPs acquisition I have to know the absolute coordinates of my base. It’s true?
After the reading of the aforementioned discussions I believe that I could post-process the raw data acquired from my Reach Rs base with the raw data provided by a Continuously Operating Reference Station (CORS) in order to know the absolute position of my base and then transmit a correct true position to my rover unit (If I’m wrong, stop me!).
Now I try to list the procedure I would like to follow to do this job:

  1. I found this CORS in the Elba Island: http://epncb.oma.be/_networkdata/siteinfo4onestation.php?station=ELBA00ITA
    In the EUREF Permanent GNSS Network. It is relatively near to my area (approximately 75 km) so I suppose that I can use it for PPK. This station provide Rinex 3.03 files daily and from this post (Using crx/17d/rnx files (Germany/Austria)) I learned how to covert .crx into .rnx file with RNXCMP software (http://terras.gsi.go.jp/ja/crx2rnx.html).

  2. Enable the raw data logging on my Reach Rs base [I don’t know what is better: Ubx format to be converted into Rinex with RTKLIB RTKCONV by following this tutorial: https://docs.emlid.com/reachrs/common/tutorials/gps-post-processing/ or directly Rinex 3.03 files ?]

  3. Place my base on a stable tripod over the point that I would like to become a known point (i.e. with true absolute coordinates to be estimated) and start data logging for at least 6 hours (or more?). I set the base with this RTK settings: Position mode: static; GPS AR mode: continuous; GLONASS AR mode: OFF; Elev. mask: 15°; SNR mask: 35°; Max acc.: 1m/s; GNSS selected: GPS+ GLONASS+GALILEO+SBAS; Update rate: 1Hz. It’s ok?
    Under the Base mode tab/ Base coordinates: Average Single; Accumulation time: 30 min or less? After averaging my position I’ll start the data logging.

  4. Download both Ubx and Rinex files from my base and Elba CORS, respectively. Obviously with the same timespan (Day-month-Year) and send them to my laptop.

  5. Start PPK with RTKLIB (THE HARDEST PART OF THE WORK, I SUPPOSE). I noticed some differences from the settings provided and the tutorial on Emlid website (https://docs.emlid.com/reachrs/common/tutorials/gps-post-processing/) so please help me again to better understand and tell me if others settings are more appropriate for my needs.

Below are the settings that I have hypothesized to be used after reading a very useful post on the forum (Setting up Base- Using CORS data in RTKPOST)

RTKLIB RTKCONV: same as reported in the tutorial
RTKLIB RTKPOST: The following snapshots could help the reading

1

In the first field (RINEX OBS: Rover) I chose MyBASE.obs file because in this case my base should be considered as the rover, is it correct?
In the second field (RINEX OBS: Base station) I chose the .rnx file from the ELBA CORS.
In the third field (RINEX NAV/CLK) I chose MYBASE.nav file.
It makes sense?

I have some questions about the “Options” settings, because the situation does not match the GPS Post-Processing Tutorial and I am a little be confused by “Ionosphere Correction”, “Troposphere Correction” and “Satellite Ephemeris”.
2
3
4

Maybe Instead of RINEX HEADER POSITION should I set X/Y/Z (m) and add manually the coordinates of Elba station (from here: http://epncb.oma.be/_productsservices/coordinates/crd4station.php?station=ELBA00ITA) ?

Now, I should be able to get a new pos file which it can be displayed in RTKPLOT. But at this point I have to ask again some trivial/stupid questions:

  1. So, if I’ll get small errors (e.g. <2cm) can I save these new processed coordinates as the absolute coordinates of my point on the field?
  2. How can I choose these coordinates from the plot? For me also the elevation values are very important so how can I check them from the rtkplot?
  3. Finally, the 1-million-dollar question: if I add manually these coordinates on my base placed over the chosen point (I carefully marked its physical position on the ground in order to reuse it for further survey) can I also have absolute coordinates on my rover unit during GCPs acquisition?

Every word of thanks is little for those who want to spend time answering me.
Massive thanks in advance.
P.s.: I’m already preparing a Christmas basket for TB_RTK :rofl:

All the best and greetings from Italy,
Daniele

3 Likes

Hey there,

Great job! It’s an almost ready guide for our docs. :slight_smile:

Yes, it’s correct.

There is almost no practical difference between these formats, however, I recommend you to use .ubx logs because it might be more useful in some cases.

6 hours should be enough. Also, for base station you only need to specify GNSS systems with an update rate, other settings won’t be taken into consideration.

In the scenario you describe, you don’t need to specify anything in “Base mode” tab, you just need to enable logging.

After this great research, I beleive you will be able to do it! Post-processing is rather straightforward procedure and docs descibe all the steps.

It’s all right. Please doublecheck that .rnx files are suitable for RTKPost! Maybe you’ll need to convert it using RTKConv to .obs first.

You can use the default values of these parameters. With the latest RTKLib from our docs, the settings are already pre-configured.

Rinex Header Position should work too.

After post-processing, you will get a solution file. You can get absolute coordinates from it. Then you can enter these absolute coordinates manually next time you set up your base over the measured point. Don’t forget to take antenna height (offset) into account (check this docs entry).

You can hit to “Fix track center” button and get the position below the plot.

Yes! You will have absolute coordinates with fix solution.

Wish you luck with your tests!

3 Likes

Dear Tatiana,
MANY MANY MANY THANKS for your kind and absolute complete reply! Now that you have better explained and confirmed my thoughts I can start my tests on field . Obviously, if a will be able to get good results I’ll be more than happy to provide a more formal workflow regarding this kind of job. I hope this help other new user like me.

All the best and thanks again for you support!

Daniele

3 Likes

Dear Tatiana and Emlid forum,
here I am again with some new results from my tests on field. I have tried to estimate the coordinates of a know points (trig point of Military Geographical Institute or IGM) by recording UBX raw data for 3 hours with my Reach Rs+ in static mode and then I have post-processed the data with the Rinex file of a CORS (Elba Island, 75 km away from the trig point).
I get good results (< 2 cm) for Lat and Long, however when I compare the ellipsoidal height I noticed a difference of more than 2 m with the data reported from IGM. I reported, as follows my workflow, so I would be grateful once again to anyone who could identify some possible error in my process.
Here it is the settings chosen under RTK and base tabs of my Reach RS+ Unit:

image
image

Then I placed my unit on the know point with a photographic tripod and I have measured the antenna height (153 cm + 6.5 cm = 159.5 cm).
image
image

After 3 hours of data acquisition with clear sky I downloaded the UBX file and converted it with RTKCONV (Ublox format, Rinex 3.03), getting the following 3 files:

The next day I have downloaded the .crx file from the CORS of Elba (http://epncb.oma.be/_networkdata/datacalendar.php?station=ELBA00ITA&year=2018&month=09&rv=3&c=any) and I have converted it to .rnx format with RNXCMP software (http://terras.gsi.go.jp/ja/crx2rnx.html)
Thus, I have post-processed the data with RTKPOST with the following settings as confirmed in the previous post, considering my Reach RS as the rover and the CORS as the base:

image

And these are the settings used during post-processing:

image
image
image

Finally, I have obtained the .pos file and I have drag and dropped it into RTKPLOT for visualization and analysis.
First of all, I have sorted out fix from float observation, keeping only Q1 (fix) observations with time span/interval panel, as suggested by TB_RTK (Setting up Base- Using CORS data in RTKPOST).

And I got the following result to be compared with the coordinates of the trig point from IGM:


image

I noticed small errors (much better for lat = 69 mm compared to long = 1 cm, yellow circle) and also the WGS84 geographic coordinates are quite similar to those reported by IGM sheet (differences are only for seconds, red circle).
However, despite the small RMS also for the height (= 2 cm) the reported ellipsoidal height (138.46 m, blue circle) is quite different (~ 2m) from that reported in the IGM sheet (140.56 m).

I converted my ellipsoidal height to orthometric height above msl (I used UNAVCO online converter: http://www.unavco.org/software/geodetic-utilities/geoid-height-calculator/geoid-height-calculator.html) and I got 90.08 meters:

Then I added to this value the height of my antenna (= 1.595 m) and I got 91.67 m above m.s.l. which implied a difference of 80 cm (92.47 m from IGM - 91.67 m from my data).
I suppose that these differences may be due to a different geoid models however if I convert the ellipsoidal height reported in the IGM sheet (140.56 m) I get with UNAVCO online converter a quite similar value of orthometric height of 92.181 which imply only 29 cm of difference. Then above cited 80 cm of difference seem to me too much.
So, my final questions are:

  1. I have committed some mistakes during data collection or post processing that have led to this height differences?
  2. This difference could be linked to the conversion? And if yes there is a more efficient converter/tool/method to know the orthometric height?
  3. Since the trig point has been defined in March 2004, it is possible that now my estimated height is more precise of which estimated at that time?

Again, sorry for this very long post but I have to make much clear as possible my thoughts. I hope that this discussion will be helpful also for other new entries in the amazing word of RTK GPS.

All the best,
Daniele

1 Like

Tick rover and fill in hight you had measured (1.595 METER )
rtkh

Thank you TB_RTK for your quick suggestion. I have just added the measured antenna height as you suggested
1

Anyway after execute the processing I get a value ( = 136.86 m) of ellipsoidal height much lower from that reported by IGM sheet (140.56 m)
2

Do you have another advice to manage this issue regarding the height ?
Thanks in advance for your time.

Regards,
Daniele

What setting did you use for statistic info?
If the point hasnt been updated since 2004, its 14years old and may be outdated.
Edit: Also look for a more recent Geoid/Height refrence modell

Remember that the RMS does not provide you with an absolute error, but the position deviation over the time measured.
I have yet to find a way to indicate the absolution precision, but AR-values (must be high), short baseline, many sats, very good SNR and so on, are all indicators of a trustworthy solution.

In your case I would enter the known coordinate as a waypoint in RTK plot. That way you can see the absolute lateral deviation.

However, as @TB_RTK says, you might not be able to trust old measurements within 10-20 cm.
Your EUREF base station could also have moved some cm since it was last measured, all adding up to more errors.

I used the default settings for statistics tab
1
Yes probably after 14 years their data may be outdated because they have used as geoid model “IGMI grids v. GR2”…

Thank you Wizprod for your observation, in fact me too I was looking for an objective method to asses the absolute precision of my measurements, so as you noted probably I have to take in consideration more aspects. Yes I have alo to take into account that the hearth surface is not a static scenario, so probably since 2004 also the base station could have moved some cm.
Finally, I have tried to add the coordinates as waypoint (CTRL+W) in RTKPLOT (both in decimal degrees and in degree,minutes and seconds) however when I click add, nothing is displayed on the plot…

You have to enable the waypoints in the main window. It is the small solid dot next to the grid icon.

Thank you Christian, I supposed that my question was trivial but not that much:sweat_smile:
Now with your smart suggestion I can check the absolute lateral deviation and seem to me more than acceptable (>5 mm) as you can see.

So now the only my biggest doubt remains for the measured height because even if we should consider that the trig point is quite old (14 years) as well as the geoid model used for transformation, I suppose that 2.1 m (=140.56-138.46) of difference is still too much. What do you think about it ?

Thanks again
Daniele

Rinex header, does it contain offset for the antenna at the refrence station?
If not you need to fill in that as well. Tick antenna type of base station and fill in U value (Up)

Is this the right station?
In the new pictures it seems they have added a concrete pillar?
http://epncb.oma.be/_networkdata/siteinfo4onestation.php?station=ELBA00ITA

Good Morning TB_RTK,
YEAAHHHH you have find the problem, definitely ! THANKS A LOT TB_RTK!
I have checked the RINEX file of the ELBA CORS station and I have find the antenna type (LEIAR 20) and its approx position (XYZ)

However, the word “approx” don’t sounds good to me when ones tries to find accurate measurements so I have checked also on the website to got more precise information and I found updated information regarding its position. In fact, their are a little bit different from that reported in the Rinex header.

Thus, I have added this coordinates under the “base position” tab of RTKPOST, as you suggested, and I finally get very good results.

Now these coordinates estimated in RTKPLOT are very close to that reported for the old (2004) trig point of IGM, which it was surveyed with my REACH RS+ three days ago.

So I believe that few centimeters of shift are more than reasonable also considering the observation of Wizprod!

Thanks again to TB_RTK, Christian and Tatiana for your valuable suggestions and big support ! You and Emlid forum are amazing!

All the best,
Daniele

6 Likes

Dan86,

I have been trying the similar experiment. I tried two different CORS base station within 100 km from my location, but end up with quit significant offset btw the two results. if possible can
you process your data but use a different CORS station and compare the result?

Hi Jwang,
I have tried with another CORS (Rome, http://www.epncb.oma.be/_networkdata/siteinfo4onestation.php?station=M0SE00ITA) but it is far from my location more than 100 km. So I get different results (a lot of Q2=float and just few Q1=fix solutions leading to a less accuracy in determing XYZ of my surveyed trig point). Results are the following:

Maybe precise ephemeris and clock files from the IGS could help in getting similar results to the other CORS station (ELBA) within 100 km, but for now I don’t know how and where IGS file can be downloaded…

sp3
note that the address in the manual is slightly different (and not working)
tested with 50 km baseline
faster fix aquisition time
and solution x-y very near to the result obtained with closer stations (5km)
z is less precise

Thank you Dan,
I have downloaded RTKLIB 2.4.2 to get access to RTKGET. In fact, this tool was not present in the WINX64 (2.4.3). However, after set my time window and downloaded IGS EPH I was not able to find were this file (it should be a .sp3 extension, right?) was created. The directory in the path displayed below (C:\GNSS_DATA\product%W) seems to be invisible on my laptop, any suggestions?
Cattura

suggestion: use 2.4.3b29
you have to edit the ftp path like this

Thank you Dan for your reply,
I changed the URL_LIST and now the ftp address seems like yours!
Cattura|553x431>
However, after click the download button nothing happens so I can’t see any sp3 file in any of my directory
What’s I’m going wrong ?