Z error between different correction inputs

Dear community, dear Emlid

We experienced some Z differences using a new correction input from our service provider.
One is GPS+GLO, the second is GPS+GLONASS+Galileo+Beidou.
Checked back with another (Leica) device and tracked back the experience with the correction provider and found that on the first (correct) input the antenna height is ADVnullantanna (0m), and the second it is 13cm offset by 1006 ARP message.
Exactly the difference we measured on the test.
I made some log files while my RS2 was fixed on a tripod, i will attach it.
System report copied below.
Can somebod examine these to see what can i do, to use the second correction?

base_202104140654_RTCM3.zip (26.7 KB) base_202104140704_RTCM3.zip (75.3 KB) raw_202104140654_UBX.zip (410.1 KB) raw_202104140704_UBX.zip (246.5 KB) solution_202104140654_LLH.zip (5.3 KB) solution_202104140704_LLH.zip (3.3 KB)

System report:

Simple system report
app version: 2.24.2-r0
'wifi_status, interface: wlan0':
- wifi_mode: infrastructure
- ip: 192.168.2.123
  is_added: true
  is_connected: true
  is_visible: false
  mac_address: 6C:21:A2:C0:6E:D6
  security: wpa-psk
  ssid: VentusTech
  uuid: 8b772dd0-aabc-4b03-9521-5f672794d070
base mode:
  base coordinates:
    accumulation: 2.0
    antenna offset:
      east: '0'
      north: '0'
      up: '0'
    coordinates:
    - 0
    - 0
    - 0
    format: llh
    mode: single-and-hold
  output:
    enabled: true
    io_type: tcpsvr
    port: 9000
  rtcm3 messages:
    '1006':
      enabled: true
      frequency: 0.10000000000000001
    '1074':
      enabled: true
      frequency: 1.0
    '1084':
      enabled: true
      frequency: 1.0
    '1094':
      enabled: false
      frequency: 1.0
    '1124':
      enabled: false
      frequency: 1.0
bluetooth:
  discoverable: true
  enabled: true
  pin: '***'
constraints:
  lora:
    frequency:
    - - 863000
      - 870000
correction input:
  input2:
    address: ntripcaster.gnssnet.hu
    enabled: true
    io_type: ntripcli
    mount_point: SGO_VRS-RTCM3.1-GLO
    password: '***'
    port: 2101
    send_position_to_base: true
    username: baukoord03
device:
  night_mode: false
  power_on_bottom_connector: false
  privacy_policy_accepted: true
  usage_analysis_accepted: true
logging:
  base:
    format: RTCM3
    started: false
  correction:
    format: RTCM3
    started: true
  debug: false
  interval: 24
  overwrite: true
  raw:
    format: UBX
    started: false
  solution:
    format: LLH
    started: false
lora:
  air rate: 2.6000000000000001
  frequency: 868000
  output power: 20.0
network:
  tcp_over_modem: false
position output:
  output1:
    enabled: true
    format: NMEA
    io_type: bluetooth
  output2:
    enabled: true
    format: LLH
    io_type: tcpsvr
    port: 9001
rtk settings:
  elevation mask angle: 15
  glonass ar mode: 'off'
  gps ar mode: fix-and-hold
  max horizontal acceleration: 1.0
  max vertical acceleration: 1.0
  positioning mode: kinematic
  positioning systems:
    compass: true
    galileo: true
    glonass: true
    gps: true
    qzss: false
  snr mask: 35
  update rate: 3
sound:
  mute: false
  volume: 100

The RCTM and UBX files are sadly way too short for post-processing.

Given that the messages are sent by your provider, I think the first stop is the NTRIP provider.

“The RCTM and UBX files are sadly way too short for post-processing.”

I understand this. Can you give me a suggestion?

“Given that the messages are sent by your provider, I think the first stop is the NTRIP provider.”
As i wrote, i spoke to the prvider, and the difference between the two sources are the 1006 messages.

Why doesn’t the provider change this? Why should the 2 streams be different in this regard?

I have the exactly same problem with different NTRIP streams.
The first stream is GPS+GLO and the second is GPS+GLO+GAL+BEI.
The difference in Z is about 10cm when switching between the streams.
I have no idea why this happens and i think it is irrelevant of the equipment used.
I have reported the problem to the CORS manager but I had no response.

Are they VRS or exact fixed base resources. GPS+GLO is generated virtual station values for me and GPS+GLO+BDS+GAL is a real base station source.

I don’t know. Both working fine on our Leica giving the same results without any modifications.

Interesting!
Which one was the one with the wrong reading? The one with or without the off-set?

GPS+GLO VRS is the good one without the antenna height correction.

GPS+GLO+BDS+GAL is the wrong one with the separately sent antenna correction.

Ok, let’s try the following to figure where the problem might be:

With the Emlid static over a point with good sky view , log 30-60 min of base correction + ubx from each of the mount points.

Upload the data here, then I’ll take a deeper look.

2 Likes

For my case both streams are from the same fixed base station.

Here are my new logs.
Please note that this time i was a bit further from the fixed base station.
My theoretical error is 13cm based on the informations from the provider.

1 Like

Thanks! I will give them a try!

I see 2 different base-station in your data? One 40 km away, and one 4 km away.

Well 13cm looks a lot like the L2 phase center height of one of Leica’s choke-ring antennae (119.58mm for a LEIAT504GG), when not taken into account.

I am currently trying to decipher this kind of problematic, where the 1007 RTCM (antenna parameters) message from a CORS operator is either nonexistent or else not understood or applied by the EMLID receiver. Too many people here are stuck with the issue of having systematically 10-12cm lower values from CORS they do not know much about. Leica and Trimble users have often tightly integrated functions to address the intricacies of antennae calibration data, while we, with EMLID stuff, have phase centers quite close to each other and pretty much deal with a simple antenna height value that is a mean of those two.

I am currently installing with Tallysman Veraphase antennae for base stations and contrary to many more complex choke ring setups with 2-3cm between phase centers, both are closer to each other at +/- 1mm. ADVnullantenna and phase(s) center(s) mean measured reference is therefore way simpler!

Hi there,

Reach indeed expects ADVnullantanna value from the base since this is the industry standard now. The antenna offset is usually included in the base’s Z-coordinate. So, there is no need to send it additionally in the 1006 RTCM3 message.

It seems we can hardly do much with such mount points. So, I’d suggest using the ones that send null antenna values.

2 Likes

Yes. One is a virtual, another is a fixed source. Both give the same result on post processing.

Thank you Svetlana.
Is this Emlid’s official answer?

I would think ADVnullantenna is the standard for virtual base (VRS), but I do not think it is a coincidence PosPAC or RTKLIB spends that much effort on including ‘‘igs14.atx’’ file for phase center correction, where the antenna characteristics is better captured. I think Emlid also spent significant effot to get the RS2 NOAA certified, so why omit the base station corrections from other sources?

2 Likes

Hi guys,

It seems we misunderstood each other a bit. It’s possible to apply the .atx file and post-process such data in RTKLib. To accomplish it, please do the following:

However, in RTK, Reach still expects a null antenna value.

1 Like