Base Position from logged data

[e.atkin]

Hi all,

I know this has been discussed fairly extensively, but would like some final clarification as I came away from reading the links below more confused by the different approaches/opinions than I started with. So don’t get angry
Discussions:

ReachView v2.9.3 - RTK performance boost

Use the Rinex saved on base. Had it explained to me. The Rinex saved on the rover ( of base observations) will have the averaged position in it. But I use the Rinex saved directly on the base as my comms between base and rover are spotty, hence PPK. The base RINEX does not have the averaged position in the header.

Retrieving the base coordinates

@TB_RTK I just checked this again. I am getting the same problem. This time I used manual mode and set the coordinates on the base. When I process, the ref pos is different! I don’t know what I am doing wrong. [image] [image] Logs

I’m a base over known position person…usually.
If a base is set up to collect and average n minutes of data before establishing itself as a base, in which file is the base location that is transmitted to a rover stored??

My understanding is that this position is stored in the RTCM3 file logged by the rover. This file is converted (RTKCONV) from RTCM3 to a .obs, and the location or “APPROX POSITION XYZ” is given in the header in ECEF coordinates. Is this correct? Bearing in mind the .obs file created from converting the .UBX logged at the base also has a set of ECEF coordinates (which I assume is the product of averaging for n minutes).

A comparison between the two sources of base location in my case (lat, lon, elp, X, Y, Z):

Rover logged RTCM3 to .obs:
-16.8038377, -179.7822333, 56.261, -6107509.9512, -23213.1962, -1832078.4976
Base logged .UBX to .obs:
-16.8038347, -179.7822344, 54.239, -6107508.1108, -23212.7469, -1832077.6033

Not massively different but certainly different enough to cause errors.

You may be asking in what way do I care…well I have corrected the base (Static PPK) and would really like to know what the dX, dY, and dZ are from what the rover thought it was.
Lastly, why are they different???

Thanks in advance, don’t want to open a can of worms!

[bide]

Ha! I wrote a huge stubborn thread hijack in reply to your post, but I found the sense to step back and delete it. ( You’re welcome. )

[e.atkin]

Well good on you for holding it in.
Any ideas on the above then?

[Lars (Lars Holst Hansen)]

Hello!
I am also intrigued by this APPROX POSITION XYZ.
In the tutorial on post processing @ Kinematic processing | Emlid Studio it just states:

Select “Base Station”. Choose “Average of Single Position” for any log to average single point solution or “RINEX Header Position” to use approximate position in RINEX .obs header.

Should best practice (and therefore the thing suggested in the tutorial) not be input the location of the base station manually - same as was entered or resulted from averaging in REachView?

The RTKLIB manual mentions an option:

RTCM Station Position
http://www.rtklib.com/prog/manual_2.4.2.pdf page 44

but this option is only available in RTKNAVI and not in RTKPOST according to the note marked with *.

I can not find anywhere what the sample size is for “Average of Single Position”.
Will RTKPOST average over the full base log?

Cheers,
Lars

[egor.fedorov]

Yes, RTKPOST will average over a full base log.

RTKPOST does not have the option to take base coordinates from RTCM because it works with RINEX files, not RTCM3.

Best practises often depends on your setup and available data. If you have an option to put your base on a well known position, it is the best and easiest choice. Our doc is just tutorial and can not cover all cases.

Hope this answers your questions.

[bide]

I’m not sure if this is helpful or not, but RTKCONV will convert RTCM3 to RINEX, and then you can use that with RTKPOST to post-process.

I wouldn’t recommend planning to do it that way, but if all you have is an RTCM3 correction file, just know that it is possible to post-process with it. Of course, your result may suffer because you don’t get as much data out of an RTCM3 file as you do from a raw data log file. I think it is a fair statement to say that RTCM3 data is purposely minimized for transmission over low bandwidth networks.