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?
“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.
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.
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.
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!
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.
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?
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:
Go to RTKPost Options menu and choose Files tab
Add the igs14.atx file to both Satellite/Receiver Antenna PCV File ANTEX/NGS PCV fields: