RTKLIB post-processed rover elevation dependency on base station reference height (ARP)

Hello,
I am trying to find a definitive answer of whether RTKLIB is handling the Antenna Reference Point (ARP) values entered in the Delta-E/N/U (m) fields correctly?

RTKLIBbase_roverARP

I am recording static data with a base station and rover using the same models of tripod and antenna so heights are both the same at 2.083 m. When I post-process the logs in RTKLIB (ver.2.4.3 b28) the ARP vaule for the base station adds elevation to the rover solution and the rover ARP subtracts from the solution (see below).

##################################
Elevation [m]; ARP; diff [m]
######### ############### ######
2290.626; none; n/a
2290.625; both base and rover; 0.000
2292.710; base only; 2.084
2288.541; rover only; -2.084
##################################

It makes sense for the rover ARP value to be subtracted from the solution, though I am not so sure why the base ARP value adds to the rover solution for DGPS. I could see it making sense for RTK but this is static data and no LoRa. What am I missing?

Thanks in advance for any valuable insight on this.

Cheers,
Christian

As a follow up,

is there a good/recommended guide for PPP methodology?

Thanks

Hi Cristian,

Thank you for your patience.

The Delta-E/N/U (m) fields are required to determine the antenna offset from a desirable coordinate. For example, it could be used in aerial mapping, where drone’s camera and the GNSS antenna could be situated on the opposite sides of the drone. In your application scenario, you can keep it at 0,0,0.

The variation in the height occurs here just because you try to average the single position of the RS2, and for that, you do not need to input any antenna height values. The position derived straight away by computation. So, static positioning does not require the antenna height corrections in RTKLib.

As for the PPP guide, I recommend checking one on our site.