RTKPOST ignores RINEX edits and still automatically detects receiver phase offset?

[antun008]

Hi everyone!

I'm dealing with an interesting situation in RTKLIB (specifically RTKPOST) and I’m hoping someone might recognize the issue and help clarify what’s going on.

I'm performing classic static GNSS processing using RTKPOST, no RTK or PPK in real time. I’m working with .obs and .nav files, setting all options manually. The observation sessions are several hours long.

For the base station, I’m using the CROPOS VRS system – a virtual reference station generated through the national network. On the rover side, I’m using a Stonex S900 receiver, which is placed on an unknown point, and I’m using its navigation messages.

I wanted to test how RTKPOST behaves if it's prevented from recognizing the actual receiver model. So in the .obs file, I:

deleted all lines containing REC #, ANT #, SYS / PHASE SHIFT, ANTENNA: DELTA, etc.

manually replaced the actual receiver model (STXS900) with TRM115000.00 as the antenna name

But RTKPOST still identifies the receiver as STXS900 and computes the correct height of the point — as if nothing had been changed. This suggests that the software still somehow "knows" what receiver it’s dealing with. So changing the metadata in the .obs file has no effect on the result.

Moreover:

When I manually add ngs_abs.pcv in Options → Files → Antenna PCV File, the height of the point drops by exactly 0.0701 m, which matches the vertical phase center offset (PCO) of the STXS900.

Without the .pcv file, the height remains “correct,” which means RTKPOST automatically applies an internal offset.

This raises a few questions for me:

How does RTKPOST identify the receiver/antenna as STXS900 even when all metadata has been removed or altered in the .obs file?

Is there any “hidden” tag or value in the .obs file that reveals the model?

Does RTKPOST ignore the antenna name in the .obs file and rely on some internal database instead?

Is there a way to fully disable automatic offset application in RTKPOST?

Could RTKLIB somehow infer the phase offset from the satellite observations themselves, e.g. from ambiguities or vertical differences?

If anyone has encountered something similar, I’d really appreciate any insight. I can share the .obs file if needed.

I’ve also included all the necessary files for processing. Could someone please run an independent calculation and let me know what the correct height is? I’m really stuck — I’ve been struggling with this for days.

Here’s what’s included:

V180144E.25o – observation file from the CROPOS VRS base station

10mi1441.25O – observation file from the Stonex S900 (unknown point)

20mi1441.25G, 20mi1441.25L, 20mi1441.25N – navigation message files

The 2-meter height is measured from the ground-stabilized point up to the base of the antenna "dome" (receiver head). From the base of the dome to the phase center, there is a vertical offset of 0.0701 meters

link for downloading: https://geofhr-my.sharepoint.com/:u:/g/personal/ajakopec_geof_hr/EZiYqWOMGBhBjPzt4lEUwt8ByNStD4GwukE9Xme3ZfmAgw?e=qsJ08d

Thanks in advance!

[szymon2024]

I'm not sure I understood you correctly.

Phase vertical offset is not a simple vertical correction like antenna height. Antenna Phase Center is explained here https://gssc.esa.int/navipedia/index.php/Antenna_Phase_Centre. Specifying a pcv or atx file in RTKLIB allows for a more accurate measurement result because phase center variations are taken into account.

Select the file with the atx extension, which is in the RTKLIB program directory by Options...->Files->Reciver Antenna PCV File ANTEX/NGS PCV. This is a file with PCO corrections for multiple antenna models. Click OK to close Options.
Now you can reopen Options...->Positions and select the antenna model for Rover and Base Station.

Additionally, for Base Station antenna you must provide the position and not the one from the Base Station RINEX file. The data in the RINEX file is approximate. When providing the position of the base station antenna it is sometimes necessary to provide an offset (delta), but not all base stations antennas have such an offset. This offset has nothing to do with PCO.

It would be good if you started the tests with a real base station and not VRS because I am not sure the VRS position from base station RINEX file is accurate.

If you provide the coordinates of the base station I can try to perform the calculations.

[antun008]

Thank you very much for your response.

I’d like to further clarify the issue I’m experiencing when using RTKLIB Explorer (version b34L), especially in relation to the use of antenna calibration files – .atx and .pcv.

It seems that RTKLIB Explorer might already have some internal ATX file embedded within the .exe binary. Regardless of whether I:

manually load the .atx file (igs20_2353.atx) via Options → Files → Satellite/Receiver Antenna PCV File,

leave that field empty,

or even completely delete the .atx file from the RTKLIB directory,

I always get the same result – most notably, the ellipsoidal height does not change at all.

I’ve tested several scenarios. For example, when I use a .pcv file (e.g. from NGS), only then does RTKLIB show a list of antennas in the “Positions” tab. I select my GNSS receiver (STONEX S900), leave the base antenna field empty, and uncheck the base antenna checkbox. In that case, the ellipsoidal height result is slightly different – specifically, I get about 7 cm lower value.

Here are the results for my unknown point measured with STONEX S900:

1. When using an .atx file, or without any file, or even when the .atx file is deleted from the RTKLIB directory – in all three cases I get:
   2025/05/24 06:17:40.000 46.304901957 16.326608672 216.8516

2. When using a .pcv file, with selected antenna for the rover (STXS900), base left empty and checkbox disabled:
   2025/05/24 06:17:40.000 46.304901863 16.326608495 216.7768

3. When using a .pcv file and defining both rover (STXS900) and base (TRM115000.00) antennas, with both checkboxes enabled:
   2025/05/24 06:17:40.000 46.304901865 16.326608496 216.8429

As you can see, the height changes only when using the .pcv file. When using .atx (or no file at all), the results are always the same.

Pictures for solution 1)

Picture for solution 2)

Picture for solution 3)

My main questions are:

Does RTKLIB Explorer (b34L) have a built-in .atx file inside the executable?

Since .atx and .pcv behave differently, which one provides more accurate or correct results?

Which of these ellipsoidal heights is actually closest to the true value? In which case is RTKLIB truly applying antenna phase center offsets?

What’s most confusing to me is that I cannot get RTKLIB to give me a clearly wrong height – even when I intentionally remove or disable all antenna calibration files. I understand that applying phase center offsets is a complex task, but I still expected at least some change in the results. The only logical conclusion I can come to is that RTKLIB has a built-in ATX file compiled into the .exe – and this is what’s confusing me the most.

Just for context: This time I used the CORS station CAKO (not VRS). The official coordinates of CAKO are:

CAKO – TRIMBLE ALLOY
Lat: N 46° 23' 13.55597"
Lon: E 16° 26' 20.65979"
Ellipsoidal Height: 222.086 m

Thank you in advance for your help and explanation. I hope this message gives a clearer picture of my situation. Also, if anyone is able to run the same calculation and tell me which of these height values is actually correct, I’d be very grateful – I’m honestly quite confused at this point.

I’m also attaching the observation file from CAKO CORS station, as well as the .obs and .nav files from my receiver.
LINK FOR DOWNLOAD: https://geofhr-my.sharepoint.com/:f:/g/personal/ajakopec_geof_hr/EiTjnfBTbHRMltOh6YZUUtABrkNKpuFifnAN8Jrkd35sDQ?e=FvTZPz

CAKO144G.25o - BASE STATION (KNOWN COORDINATES)
10mi1441.25O - ROVER UNKOWN COORDINATES
20mi1441.25G NAVIGATION FILE
20mi1441.25L NAVIGATION FILE
20mi1441.25N - NAVIGATION FILE

[ourairquality]

Setting the antenna type to * has it use the value in the rinex file, along with the delta in the rinex file. Otherwise the antenna type and delta come from the config options.

ant1-postype =4 ant1-anttype =* ant2-postype =4 ant2-anttype =*
2025/05/24 06:28:32.000 46.304901821 16.326608470 216.8529 1 16 0.0002 0.0002 0.0005 0.0001 -0.0001 0.0002 0.000 14.1

If a base antenna type is not defined then its phase center offset is not applied so the solved rover height also drops.
ant1-postype =4 ant1-anttype =* ant2-postype =4 ant2-anttype =
2025/05/24 06:28:32.000 46.304901826 16.326608467 216.7927 1 16 0.0002 0.0002 0.0005 0.0001 -0.0001 0.0002 0.000 14.1

If the rover antenna type is also not defined then its offset is also not applied and if the antenna are matched then the offset largely cancels.
ant1-postype =4 ant1-anttype = ant2-postype =4 ant2-anttype =
2025/05/24 06:28:32.000 46.304901813 16.326608476 218.8578 1 16 0.0002 0.0002 0.0005 0.0001 -0.0001 0.0002 0.000 16.7

Not sure what is in that pcv file. STXS900 appears to be listed in the igs atx file so perhaps just copy that for both, which is what is used in the above solutions. The receiver atx file needs to be defined in order for the base atx entry to be found too. If you have a particular calibration then perhaps make a combined file for the receivers.

RTKLIB does not have any hard coded antenna definitions. If the solution is using one then it is either coming from the config options or the rinex input file (when the type is *).

The antenna delta is the offset from the marker to the antenna ARP. The APR is typically defined on a label on the antenna, or perhaps in the documentation. The delta is expected to be always applied, even if there is no atx entry. The atx entry defines a phase center offset which depends on the frequency (not yet properly handled), and this is often noted on the label. There is a further phase center variation that depends on the elevation and azimuth (rtklib currently only uses the elevation), and this is only applied when the receiver or satellite PCV box is ticked (the pos1-posopt1 and pos1-posopt2 options). There is still some development work in progress in this area, there is fully support in development including antex 2.

[szymon2024]

@ourairquality

1. There are two fields in rtkpost_qt distinguishing the ANTEX satellite and the ANTEX receiver:
   Options...->Files->Satellite Antenna PCV File ANTEX/NGS PCV
   Options...->Files->Receiver Antenna PCV File ANTEX/NGS PCV
   There are two fields in rtkpost.exe but they are described with one label:
   Options...->Files->Satellite/Receiver Antenna PCV File ANTEX/NGS PCV

2. Checkboxes in rtkpost.exe
   Options...->Setting1->Sat PCV
   Options...->Setting1->Rec PCV
   are still gray.
   In rtkpost_qt not.

[szymon2024]

I performed calculations for the CAKO base station (CAKO00HRV) with manually entered coordinates:

Lat: N 46° 23' 13.55597"
Lon: E 16° 26' 20.65979"
Ellipsoidal Height: 222.086 m

Calculations for Options...->Output->Solution for Static Mode->Single

a) without specifying the rover antenna

% program : RtkPost Qt Version demo5 b34L
% inp file : /OBSERVATIONS/10mi1441.25O
% inp file : /OBSERVATIONS/CAKO144G.25o
% inp file : /OBSERVATIONS/20mi1441.25L
% inp file : /OBSERVATIONS/20mi1441.25N
% inp file : /OBSERVATIONS/20mi1441.25G
% obs start : 2025/05/24 06:17:40.0 GPST (week2367 541060.0s)
% obs end : 2025/05/24 06:28:50.0 GPST (week2367 541730.0s)
% pos mode : Static
% freqs : L1+L2/E5b
% solution : Forward
% elev mask : 15.0 deg
% dynamics : off
% tidecorr :
% ionos opt : Broadcast
% tropo opt : Saastamoinen
% ephemeris : Broadcast
% navi sys : GPS GLONASS Galileo
% amb res : Continuous
% amb glo : OFF
% val thres : 10.0
% antenna1 : ( 0.0000 0.0000 0.0000)
% antenna2 : TRM115000.00 NONE ( 0.0000 0.0000 0.0000)
% ref pos : 46.387098881 16.439072164 222.0860
%
% (lat/lon/height=WGS84/ellipsoidal,Q=1:fix,2:float,3:sbas,4:dgps,5:single,6:ppp,ns=# of satellites)
% GPST latitude(deg) longitude(deg) height(m) Q ns sdn(m) sde(m) sdu(m) sdne(m) sdeu(m) sdun(m) age(s) ratio
2025/05/24 06:17:40.000 46.304902598 16.326606527 218.8202 2 8 0.0081 0.0129 0.0116 -0.0061 0.0072 -0.0073 0.00 3.8

b) selecting a rover antenna Options...->Positions->Rover->Antenna Type->STXS900

% program : RtkPost Qt Version demo5 b34L
% inp file : /OBSERVATIONS/10mi1441.25O
% inp file : /OBSERVATIONS/CAKO144G.25o
% inp file : /OBSERVATIONS/20mi1441.25L
% inp file : /OBSERVATIONS/20mi1441.25N
% inp file : /OBSERVATIONS/20mi1441.25G
% obs start : 2025/05/24 06:17:40.0 GPST (week2367 541060.0s)
% obs end : 2025/05/24 06:28:50.0 GPST (week2367 541730.0s)
% pos mode : Static
% freqs : L1+L2/E5b
% solution : Forward
% elev mask : 15.0 deg
% dynamics : off
% tidecorr :
% ionos opt : Broadcast
% tropo opt : Saastamoinen
% ephemeris : Broadcast
% navi sys : GPS GLONASS Galileo
% amb res : Continuous
% amb glo : OFF
% val thres : 10.0
% antenna1 : STXS900 NONE ( 0.0000 0.0000 0.0000)
% antenna2 : TRM115000.00 NONE ( 0.0000 0.0000 0.0000)
% ref pos : 46.387098881 16.439072164 222.0860
%
% (lat/lon/height=WGS84/ellipsoidal,Q=1:fix,2:float,3:sbas,4:dgps,5:single,6:ppp,ns=# of satellites)
% GPST latitude(deg) longitude(deg) height(m) Q ns sdn(m) sde(m) sdu(m) sdne(m) sdeu(m) sdun(m) age(s) ratio
2025/05/24 06:17:40.000 46.304902608 16.326606533 218.7501 2 8 0.0081 0.0129 0.0116 -0.0061 0.0072 -0.0073 0.00 3.8

Selecting the receiver antenna type changed the resulting position horizontaly and verticaly:
46.304902598 16.326606527 218.8202
46.304902608 16.326606533 218.7501

The atx file with the rover antenna model was therefore included.

It is difficult to analyze the change in height because the rover observation file contains very little data, which probably does not allow obtaining a result of Q=1 fixed solution. In static measurements, almost always the first few minutes are the result of Q=2 float. To obtain a result with the status fixed in a static measurement, a rover file containing at least 15 minutes of observations of the stationary rover antenna is needed.

Personally, I do not use a single solution and that is why I am also posting results for Options...->Output->Solution for Static Mode->All (Result in red frame)

a) without specifying the rover antenna

b) with the definition of the rover antenna

[ourairquality]

1. There are two fields in rtkpost_qt distinguishing the ANTEX satellite and the ANTEX receiver:
   Options...->Files->Satellite Antenna PCV File ANTEX/NGS PCV
   Options...->Files->Receiver Antenna PCV File ANTEX/NGS PCV
   There are two fields in rtkpost.exe but they are described with one label:
   Options...->Files->Satellite/Receiver Antenna PCV File ANTEX/NGS PCV

The secorrespond with the config options file-satantfile and file-rcvantfile.

2. Checkboxes in rtkpost.exe
   Options...->Setting1->Sat PCV
   Options...->Setting1->Rec PCV
   are still gray.
   In rtkpost_qt not.

The Sat and Rec PCV check boxes were only being enabled for selection in PPP modes but work in RTK modes too and that GUI issue is also addressed in #667

[ourairquality]

It is difficult to analyze the change in height because the rover observation file contains very little data, which probably does not allow obtaining a result of Q=1 fixed solution. In static measurements, almost always the first few minutes are the result of Q=2 float. To obtain a result with the status fixed in a static measurement, a rover file containing at least 15 minutes of observations of the stationary rover antenna is needed.

Got an RTK fix relatively easily on your example data. Some suggestions: exclude GLONASS and enable BDS. Config for 4 frequencies rather than 2. Download more complete broadcast nav data, e.g. BRDM00DLR_S_20251440000_01D_MN.rnx from https://cddis.nasa.gov/archive/gnss/data/daily/2025/brdc/ Try using precise data, e.g. GRG0OPSULT_20251431800* from https://cddis.nasa.gov/archive/gnss/products/2367/ and enable precise satellite ephemeris, if only to exclude unhealthy satellites. Check the signals being used, the virtual base offered many signals, best to match them e.g. misc-rnxopt2=-GL1C -GL2W -GL5Q -RL1C -RL2P -RL2C -EL1C -EL5Q -EL7Q -EL8Q -CL2I -CL7I -CL5D. The results obtained above used 16 satellites vs 8 in your results. Static and kinematic forward results below.

[antun008]

Setting the antenna type to * has it use the value in the rinex file, along with the delta in the rinex file. Otherwise the antenna type and delta come from the config options.

ant1-postype =4 ant1-anttype =* ant2-postype =4 ant2-anttype =* 2025/05/24 06:28:32.000 46.304901821 16.326608470 216.8529 1 16 0.0002 0.0002 0.0005 0.0001 -0.0001 0.0002 0.000 14.1

If a base antenna type is not defined then its phase center offset is not applied so the solved rover height also drops. ant1-postype =4 ant1-anttype =* ant2-postype =4 ant2-anttype = 2025/05/24 06:28:32.000 46.304901826 16.326608467 216.7927 1 16 0.0002 0.0002 0.0005 0.0001 -0.0001 0.0002 0.000 14.1

If the rover antenna type is also not defined then its offset is also not applied and if the antenna are matched then the offset largely cancels. ant1-postype =4 ant1-anttype = ant2-postype =4 ant2-anttype = 2025/05/24 06:28:32.000 46.304901813 16.326608476 218.8578 1 16 0.0002 0.0002 0.0005 0.0001 -0.0001 0.0002 0.000 16.7

Not sure what is in that pcv file. STXS900 appears to be listed in the igs atx file so perhaps just copy that for both, which is what is used in the above solutions. The receiver atx file needs to be defined in order for the base atx entry to be found too. If you have a particular calibration then perhaps make a combined file for the receivers.

RTKLIB does not have any hard coded antenna definitions. If the solution is using one then it is either coming from the config options or the rinex input file (when the type is *).

The antenna delta is the offset from the marker to the antenna ARP. The APR is typically defined on a label on the antenna, or perhaps in the documentation. The delta is expected to be always applied, even if there is no atx entry. The atx entry defines a phase center offset which depends on the frequency (not yet properly handled), and this is often noted on the label. There is a further phase center variation that depends on the elevation and azimuth (rtklib currently only uses the elevation), and this is only applied when the receiver or satellite PCV box is ticked (the pos1-posopt1 and pos1-posopt2 options). There is still some development work in progress in this area, there is fully support in development including antex 2.

Can you please give config file? Beacuse I also try with this settings and can't get same results. Did you also use same navigation which I give in link? And thanks for answers, they help me a lot:)

mine pos file after result (with all * for rover and base, and using igs14.atx)
% program : RTKPOST demo5 b34L
% inp file : C:\10mi1441.25O
% inp file : C:\CAKO144G.25o
% inp file : C:\20mi1441.25G
% inp file : C:\20mi1441.25L
% inp file : C:.25N
% obs start : 2025/05/24 06:17:40.0 GPST (week2367 541060.0s)
% obs end : 2025/05/24 06:28:50.0 GPST (week2367 541730.0s)
% pos mode : Static
% freqs : L1+L2/E5b+L5
% solution : Combined-Phase Reset
% elev mask : 15.0 deg
% dynamics : on
% tidecorr :
% ionos opt : Broadcast
% tropo opt : Saastamoinen
% ephemeris : Broadcast
% navi sys : GPS GLONASS Galileo BDS
% amb res : Continuous
% amb glo : OFF
% val thres : 3.0
% antenna1 : STXS900 NONE ( 0.0000 0.0000 2.0000)
% antenna2 : TRM115000.00 TZGD ( 0.0000 0.0000 0.0000)
% ref pos : 46.387098881 16.439072164 222.0855
%
% (lat/lon/height=WGS84/ellipsoidal,Q=1:fix,2:float,3:sbas,4:dgps,5:single,6:ppp,ns=# of satellites)
% GPST latitude(deg) longitude(deg) height(m) Q ns sdn(m) sde(m) sdu(m) sdne(m) sdeu(m) sdun(m) age(s) ratio
2025/05/24 06:17:40.000 46.304901973 16.326608679 216.8459 1 8 0.0004 0.0003 0.0008 0.0001 0.0002 0.0002 0.00 3.8

I also putting config file conf.txt (just rename in txt beacuse github dosent allow to upload .conf)
CONF.TXT

[szymon2024]

It seems that you do not do long-term static measurements only offline short static. Indeed, your measurement is sufficient to obtain a fixed solution. It does not have to be at least 15 min.

I don't know how I missed that your receiver has L5.

The base station is not far from the measurement site, about 12.6 km.

The offset (delta) for the base station antenna is zero in all directions and is described in the station log https://www.epncb.oma.be/pub/station/log/cako00hrv_20250429.log

4.2 Antenna Type : TRM115000.00 TZGD
Serial Number : 1551017208
Antenna Reference Point : BAM
Marker->ARP Up Ecc. (m) : 0.0000
Marker->ARP North Ecc(m) : 0.0000
Marker->ARP East Ecc(m) : 0.0000
Alignment from True N : 0 deg
Antenna Radome Type : TZGD
Radome Serial Number :
Antenna Cable Type : RG 214
Antenna Cable Length : 30 m
Date Installed : 2019-08-13
Date Removed : CCYY-MM-DDThh:mmZ
Additional Information : (multiple lines)

I downloaded the data for the base station CAKO00HRV from https://gnss.bev.gv.at/at.gv.bev.dc/data/obs/2025/144/ (with 30 second intervals) and re-ran the calculations only for GPS and Galileo.

For Options...->Output->Solution for Static Mode->Single (Single is the result) I have:

% program : RtkPost Qt Version demo5 b34L
% inp file : /OBSERVATIONS/10mi1441.25O
% inp file : /OBSERVATIONS/moje/CAKO00HRV_S_20251440000_01D_30S_MO.crx
% inp file : /OBSERVATIONS/moje/CAKO00HRV_S_20251440000_01D_EN.rnx
% inp file : /OBSERVATIONS/moje/CAKO00HRV_S_20251440000_01D_GN.rnx
% obs start : 2025/05/24 06:17:40.0 GPST (week2367 541060.0s)
% obs end : 2025/05/24 06:28:50.0 GPST (week2367 541730.0s)
% pos mode : Static
% freqs : L1+L2/E5b+L5
% solution : Forward
% elev mask : 15.0 deg
% dynamics : off
% tidecorr :
% ionos opt : Broadcast
% tropo opt : Saastamoinen
% ephemeris : Broadcast
% navi sys : GPS Galileo
% amb res : Continuous
% val thres : 10.0
% antenna1 : STXS900 NONE ( 0.0000 0.0000 0.0000)
% antenna2 : TRM115000.00 NONE ( 0.0000 0.0000 0.0000)
% ref pos : 46.387098881 16.439072164 222.0860
%
% (lat/lon/height=WGS84/ellipsoidal,Q=1:fix,2:float,3:sbas,4:dgps,5:single,6:ppp,ns=# of satellites)
% GPST latitude(deg) longitude(deg) height(m) Q ns sdn(m) sde(m) sdu(m) sdne(m) sdeu(m) sdun(m) age(s) ratio
2025/05/24 06:17:40.000 46.304901946 16.326608693 218.8601 1 13 0.0003 0.0002 0.0007 0.0001 -0.0000 0.0002 -10.00 16.6

For Options...->Output->Solution for Static Mode->All (The last point is the result. The second and third photo after shifting the start time view in Edit menu.):

It may be useful to know: If you enter the coordinates of the base station in a specific coordinate system, the result will be in the same coordinate system.

[szymon2024]

Can you please give config file?

My additional settings:
Options...->Setting2->Integer Ambiguity Res (GPS/GLO/BDS)->Continuous
Options...->Setting2->Ratio to Fix Ambiguity Min->10
Options...->Setting2->Ratio to Fix Ambiguity Nom->10
Options...->Setting2->Ratio to Fix Ambiguity Max->15