Feature request : Antenna phase offset in RTK settings

[igor.vereninov]

Thank you for providing such detailed descriptions. We studied your log files and we really can’t see the reason for the difference that you are seeing. It is a very interesting case and we want to study it more to understand what is actually happening.

How Reach handles offsets
I understand the hypothesis about the misconfiguration of M2 as RS2, but it is not the case. Reach does not add any offsets internally. All Reach receivers output position at phase center, without any vertical offsets. Vertical phase center offset is only taken into account in Survey projects, not for status or position outputs or logs.

This is very easy to verify by conducting a zero-baseline experiment. You can connect Correction output of Reach M2 to Correction input of the same Reach M2. If there was any kind of offset added, you would be seeing that.

We also tried to imitate the setup that you have and conducted an additional experiment just to double check. We verified that ReachView and RTKNAVI results match with our NTRIP provider.

In normal operation the expected result is benchmark height + LEIAX1202GG, so about 63mm higher than the benchmark. While what you are observing is a shift of about 14-15cm. So there must be something that account for extra ~80mm of vertical shift. Having taken the rover height into account we should look at the base station offsets.

Reach assumes that base station position received in RTCM3 stream is at the phase center, which in our experience is the norm with the correction providers that we encountered. So Reach assumes null antenna for base and for rover.

Leica AR10 antenna vertical offset is about 88mm. And if this antenna is specified during post-processing the height seems to match. What is interesting here is the reply that you got from the network operator:

@zipang

The provider explained me that broadcast (RTK) corrections are adjusted for a theoretical base NULL antenna. So customers don’t have to configure a base antenna in their rovers while doing RTK surveys. And indeed the antenna is declared as null in RTCM3 received files.

So this makes total sense and it is exactly what Reach expects from a base station. But why do the heights in the RINEX file and RTCM3 match? If RINEX height requires the application of antenna model and RTCM3 height is for null antenna, then how could they be the same? I would expect to see a difference of about 88mm between the two for Leica AR10 antenna.

Here is what we got by transforming ECEF from the RINEX of your base to LLH to get ellipsoidal height.
XYZ:

LLH:

Which makes the SNPL RINEX height 15.888 m, this must be the ARP height as extra 88mm for Leica AR10 is applied with the antenna model during processing.
What we see in RTCM3 messages is the same 15.888 m, which are also visible on your screenshots of ReachView interface.

At this point I think that these steps could give us more info about what is going on:

• Could you please confirm with the operator of your network why do the two heights match?
• Could you please record a raw log with “raw data debug” option set? (you can enable it in the settings, which are marked with a gear shaped button). Please also provide a matching RTCM3 log.

[wizprod (Christian Grüner)]

Dang that’s a fine, detailed answer! Looking forward to seeing what this all end up with.

[zipang]

Hi @igor.vereninov,

Thanks for your detailed answer.

@igor.vereninov

This is very easy to verify by conducting a zero-baseline experiment. You can connect Correction output of Reach M2 to Correction input of the same Reach M2. If there was any kind of offset added, you would be seeing that.

I did that and indeed rover height is exactly base height.

@igor.vereninov

We also tried to imitate the setup that you have and conducted an additional experiment just to double check. We verified that ReachView and RTKNAVI results match with our NTRIP provider.

This, and the fact that no offset seems to be applied, make the issue more puzzling, as I observe here a difference between the two programs (and that is RTKNAVI who matchs true benchmark height).

@igor.vereninov

Could you please confirm with the operator of your network why do the two heights match?

It’s because broadcasted corrections are different than downloaded ones. the former are adjusted to match ARP. The provider can’t change station coordinates in RTCM, as antenna phase center offsets are not simply a delta height. There is also E and N component. Even if practically, PCO are close to a delta height, they should be applied during phase-range calculations and not as pole height (cf RTKLIB Manual p.139). It’s the reason you should consider to add to Reachview a parameter to use antenna files (a function already included in RTKLIB).

@igor.vereninov

Could you please record a raw log with “raw data debug” option set? (you can enable it in the settings, which are marked with a gear shaped button). Please also provide a matching RTCM3 log.

Here :
https://framadrive.org/s/YAZX2Dazs7yXJ9A

My results for height from these files :

• Post processing : 326.324 m (with RTKPOST, NULL antenna for base and rover)
• Reachview RTK : 326.429 m (averaged from 5191 observations at 1 Hz)
• Difference : 0.105

[igor.vereninov]

Thank you for providing additional logs.

I think that we should compare the output of Reach to the benchmark height, rather than to RTKPost or RTKNavi. What we see from the log files is that the errors that Reach and RTKPOST give are almost identical, but have a different sign.

(326.42 - 0.063) - 326.31 = 0.047 m ReachView error relative to the benchmark height
(326.32 - 0.063) - 326.31 = -0.049 m RTKPost error relative to the benchmark height

From the initial screenshots I can see that you only use GPS for processing, enabling more satellite systems should make the results more robust. Please also check that your elevation and SNR mask settings are not too restrictive. The defaults of 35 and 15 should work just fine. Please also try the Kinematic mode.

Maybe you could record a log file where the height difference is more visible? It seems like in this particular case RTKPost and Reach give similar errors.

Thank you for your help so far, we really can’t reproduce this with our corrections provider, so your logs are the only way for us to learn more about the issue.

[Gabriel_C (GCG)]

I went ahead and read through the entire thread again because I found it really interesting since the beginning. If I can summarize the issue and feature request correctly @zipang:

The correction provider forces a false antenna height corresponding to the ARP, in the RTCM stream, expecting that users are able to enter phase offsets manually in their surveying software, which is not possible in Reachview.

Is it as simple as that?

[zipang]

Hi,

@Gabriel_C

The correction provider forces a false antenna height corresponding to the ARP, in the RTCM stream, expecting that users are able to enter phase offsets manually in their surveying software, which is not possible in Reachview

No, the provider force a false NULL antenna so users don’t need to declare base antenna type or phase offsets in their software (a NULL antenna has all phase center offsets equal zero).

@igor.vereninov

From the initial screenshots I can see that you only use GPS for processing, enabling more satellite systems should make the results more robust

I use GPS, Glonass and Beidou. But for the first screenshots I didn’t know at that time how to feed RTKNAVI with M2 nav data so I used an external provider, which was GPS only.

@igor.vereninov

What we see from the log files is that the errors that Reach and RTKPOST give are almost identical, but have a different sign.

Heights from this session were quite low. I compiled all my RTK observations of this benchmark, a total of 26h43’ from 14 sessions, and the average height is 326.453 m. Max error is 8 cm, and 95% of observations are within 4 cm :

Benchmark known height is 326.30 and receiver antenna phase Z offset is 0.063, so height measured at ARP is 326.453 - 0.063 = 326.39. That is 9 cm above benchmark.

@igor.vereninov

I think that we should compare the output of Reach to the benchmark height, rather than to RTKPost or RTKNavi

I thing that the comparison with RTKNavi is interesting because as levelling with GNSS is quite inaccurate, you need very long measures to conclude when comparing to a benchmark height. From the graph I posted above, you see that RTKNAVI follow the same variations than Reachview, but 10 cm below. As both softwares use the same engine, It would be interesting to find the cause of this difference. Could you provide rtklib parameters used by Reachview for RTK processing ?

[Gabriel_C (GCG)]

@zipang

No, the provider force a false NULL antenna so users don’t need to declare base antenna type or phase offsets in their software (a NULL antenna has all phase center offsets equal zero).

I might have misunderstood, but what I gathered from your explanation was that the antenna type was set to NULL but the antenna height used to compute the correction stream was also reduced to the ARP (which would be true monument height?). That sounds strange to me but it could explain why there is an offset in RTK but not in PPK where the base antenna parameters can be described in the RINEX file. This quote from @igor.vereninov is what makes me wonder if the provider is doing something counterintuitive:

@igor.vereninov

So this makes total sense and it is exactly what Reach expects from a base station. But why do the heights in the RINEX file and RTCM3 match? If RINEX height requires the application of antenna model and RTCM3 height is for null antenna, then how could they be the same? I would expect to see a difference of about 88mm between the two for Leica AR10 antenna.

What would happen if you entered the base’s APC offset as a negative value for PPK? Would it match RTK?

[zipang]

Hi @Gabriel_C

@Gabriel_C

it could explain why there is an offset in RTK but not in PPK where the base antenna parameters can be described in the RINEX file

There is no offset in PPK, I got the good height value.

@Gabriel_C

What would happen if you entered the base’s APC offset as a negative value for PPK? Would it match RTK?

No this will lower the result (RTK is above PPK).

Just to clarify :

• PPK with antenna parameters Base=LEIAR10 / Rover=LEIAX1202GG gives an height of 326.30
• RTK with antenna parameters Base=NULL / Rover=LEIAX1202GG with LEICA GNSS1200, LEICA GS14 and Emlid M2/RTKNAVI gives also an height of 326.30
• RTK without antenna parameters (NULL/NULL) with Emlid M2/Reachview gives an height of 326.45 (it should give 326.36)

This remains a mystery, as @igor find the same results with Reachview and RTKNAVI…

[igor.vereninov]

@zipang Could you please collect two more datasets? It will help us collect more statistics on the issue. Please set raw data debug to on and provide a matching RTCM3 log.

[zipang]

Here is at least one. If it is not enough I will record another next week.
https://framadrive.org/s/tFfDQzgdeBCGrtL

[tatiana.andreeva]

Hi @zipang,

Thank you! We’re looking into this dataset. If we need more data or have any updates, I’ll get back.