I’m having a bit of a brain fade and just need some input for confidence.
I am doing a PPK of topo collected on foot. The data collection incorporates a couple of established geodetic marks. The base is a CORS station about 20 km away.
I have used both RTKLIB and the new Emlid Studio for this, but the latter brought to my attention the vertical offset of the base in the Rinex header info - not something i have really considered before. In this case it its 0.055 m. See screen shots below. Base position from .pos output file: % ref pos :-37.806755409 175.109198252 69.4554
I have PPK’d using a full range of settings/combinations, some provide fix from start to finish, it but never really get as close as I would have thought to a match with the geodetic marks. The difference is always around 0.06 m +/- 0.005-0.010.
if I switch off this antenna height in the Emlid Studio then the offset to the geodetic mark flicks the other way (positive to negative) but not in an entirely equally way - nor in the desired effect.
I don’t believe i should be switching it off but the effect was quite odd.
Any advice would be appreciated.
No value may be entered in the antenna height, as the antenna height is already shown in the Rinex file and thus already calculated. You have to enter a 0 here, then the height will be calculated correctly. I also have a request for this to be made by Emlid.
Hmm, I assume that you’ve added the antenna height twice in the calculations. As you have toggled “Use antenna height”, antenna offset has already been added. The measured height - the height from the receiver to the known point on the ground, in your case, should be 0.
However, I can’t help noticing that it’s quite unusual that your PPK results using the RINEX header differ from the geodetic marks just on the 0.06 m.
RINEX header usually contains several meters-accurate coordinates. And the height in it, as @dieter.buchholz rightly pointed out, usually includes the antenna height. Did your CORS provider transmit the precise ARP coordinates in the RINEX header?
So I need the antenna height switched on, but set it to 0. Will try that. It doesn’t seem very intuitive though to have data with in the Rinex header that is then queried in the front end…
The Rinex was downloaded after the survey - although I did run in real-time originally, but the match on the geodetic mark was not good enough so I reverted to PPK.
Oh, yes, now it’s clear to me. When you download RINEX from the CORS provider, its header indeed contains precise info about the base position.
To work with these logs in Emlid Studio, you just need to upload them to the corresponding field. The app will automatically read the coordinates and the antenna type from the RINEX header and add the necessary offset. So you don’t need to do any additional configuration for the base antenna.
The Measured height field is useful when you have coordinates of a known point on the ground and need to add the tripod’s height to it.
However, as your logs are from CORS, the coordinates in the RINEX header already include the height of the tripod or survey monument. That’s why you need to leave 0 in this field.
Could you tell me a bit more about your RTK tests? Did you get a fix with your rover? If yes, what was the mismatch over geodetic marks?
Nope, not necessarily. In this case I will argue that you absolutely have to use the height!
The height mention (0.055 m) is the height from the Marker to the Antenna ARP. The antenna is a Zypher 3 Geodetic, which has an L1 offset of 0.0652 m and an L2 offset of 0.0577.
So if you are not using the antenna-profile, the Marker to APC height is 0.055m+((0.0652m+0.0577m)/2)=0.117 m
The problem is simply the name of the different heights. There are 3 elements from top to bottom in my opinion:
1: Antenna parameters from APC to antenna base (is normally taken from the ATX file)
2: A permanently installed spacer at the permanently installed stations from the antenna base to the ARP. In this case the ARP = RSP = coordinate point
3: For mobile base stations, point 2 is the pole height from the antenna base = ARP to the RSP = coordinate point
The problem lies in elements 2 and 3, as these are sometimes specified in the Rinex file and sometimes have to be entered freely.
Even as a surveyor, I find it totally confusing and errors are inevitable.
In addition, Emlid Studio automatically enters the value 2 as a suggested value for 3. In my opinion, this is very problematic and has already cost me hours of research.
Every user naturally thinks the value is correct there and confirms it, as do I and the creator of this thread. The result is a wrong result, unfortunately.
When entering these values, I could imagine a sketch where all parameters that are already used automatically (all from the Rinex file) are already permanently entered. That would explain the whole thing much better and there would be a lot fewer errors.
Thanks everyone for taking the time to think about this.
I guess having knowledge of how the pieces fit together is one part. T
The other is how Emlid Studio handles data/information and whether those bits of info (e.g. antenna height), and how they are presented in files are consistent (which I thought they were meant to be).
Hi again.
Use antenna height = yes
Measured Height == 0
Yields great results with this dataset against geodetic marks.
Another quick question though if you don’t mind.
If I am running in real time and receiving RTCM 3.2 from a CORS station which outputs in a nation specific geodetic datum (in this case NZGD2000), will the *.LLH produced with raw logging be in NZGD2000 or remain in WGS84.
I’ve tried to reproduce this workflow and understood that my previous answer was a bit misleading. Sorry for that!
Christian is absolutely right that 0.055 m is the heigh of the ARP over the marker. So in the standard workflow, it should indeed go to the Measured heigh field. And as Dieter mentioned, it appears there by default - Emlid Studio read it from the RINEX header.
However, I assume that in this case, the CORS provider transmits in the RINEX header the coordinates, which already include the antenna height (0.055 m). At the same time, this value is also added in the RINEX separately in the antenna height field. That’s why it is counted twice and leads to the ~ 0.06 m mismatch.
So the solution, in this case, is just to set the measured height as 0 manually. And as I understand from the @e.atkin update, it has helped.
It’ll be in NZGD2000, as the rover provides the coordinates related to the same datum as the base.
I have some news for this thread. In one of the latest Emlid Studio versions, we’ve fixed the issue with reading the measured height from the RINEX log. So, the workaround with the manual setting measured height as 0 is not needed anymore. This value won’t be applied twice.
