Emlid, can you please check the code and make sure that Emlid Studio is not accounting for the Antenna Offset (.134) twice in the Stop N Go processing? The RV3 App generated the CSV file and it had the antenna height at 7.001’ ft (2.134 meters).
I wanted to verify that Emlid Studio is not also accounting for the antenna height by adding an additional .134 to the results. When comparing the results of ES to another software, ES has a consistent higher elevation very close to the .134m offset.
So that makes me think it is accounting for the offset even though it is already accounted for in the CSV file.
For the base unit, Emlid Studio takes the antenna offset from the RINEX header – there is a tailored field for it so it couldn’t be counted twice. On the rover, it’s taken from a CSV file, so we do not add anything additional.
I’m curious to check your files and the results you get with 3rd-party software. This way, we’d be able to say much more about what’s going on here.
I indeed see the height difference in a range between 12.4 and 13.4 cm. But everything seems to be fine with the data. Let’s check some workflow-related things.
In EZSurv report, I see the base height is determined as 244.455. This is the elevation from RINEX header. But Emlid Studio also adds 12.4 cm to this because it’s LEIAR20 antenna offset. The CORS station uses LEIAR20 antenna, and Emlid Studio reads it from the RINEX header as well.
Does EZSurv defines an antenna type automatically too?
I will let you know what I hear from EZsurv but I have always assumed that all processing from the CORS is based on Phase Center and not the the ARP. It will be interesting to find out if it is normal for all processing software to process from the ARP instead of Phase Center of CORS stations??
But this is very critical because many users may use one software to process the Drone Flight and then use Emlid Studio to do the RS survey of the GCP’s. But both software using the same CORS station. But if one is using phase center of the CORS and another using ARP of the cors there would be an error.
As I know, usually, post-processing software reads the antenna name from RINEX header and applies antenna phase center offset. I’m just confused by the elevation value from EZSurv report. That’s why I’ve asked.
I will find out what Ezsurv says. The Antenna height of the CORS in the report matches exactly the antenna height stated in the NGS Data sheet for that CORS unit, which is the 244.455. I will keep you posted on any details I come up with. Thanks Svetlana for helping on this.
Svetlana,
I was in error to say that CORS are referenced from phase center. All the CORS units are in fact referenced at ARP. So the value used in EZsurv is in fact the ARP antenna height. So I do not think that heigh should be adjusted.
Yes, CORS coordinates are most likely related to the ARP. But all GNSS measurements referred to the phase center. That’s why the antenna phase center offset should be added to the base height during post-processing.
Yes, but the Antenna height for the CORS station is 0 at ARP and therefor it should not be adjusted. I am going to do further digging but I am confident you should not be adjusting the height due to the offset of the CORS. This is causing an error in the elevation results.
With the Reach RS2, the antenna height is .134 at ARP. But with CORS the Antenna height is considered 0 AT ARP. I am going to get in touch with someone with NGS to verify this information.
Sometimes, it happens that APC offset is already included in the CORS station coordinates. But in this case, the antenna name is also listed in the RINEX header. That’s why Emlid Studio adds this offset.
It would be great if you check with CORS if the APC offset should be added additionally or not.
Not sure if it is related, but I am going off a fixed point and havnt changed my settings but my static points were out by Z=0.134m which is the antenna height. I had to adjust my pole height to get it all my fixed points back into tolerance. This happened a few months ago.
Joe
I took one of my RS2 BASE log files. I processed it in OPUS, EZsurv, and Emlid Studio. The difference between EZsurv and OPUS was 4.8 cm vertical. It must be noted that EZsurv is using one CORS (zme1) and OPUS was using 9 base stations. I attached the log file to this post.
When processed in Emlid Studio the difference between Emlid Studio and OPUS is .153 meters and that is why I believe Emlid Studio is making an offset it should not make. This would be consistent on any log file.
Also, when using NAD83 CORS stations to do PPK, the results are NAD83, not WGS84.
Just processed the same files, and got 57.4289 m of height. That really confuses me, cause the settings seem to be the same.
You converted UBX for processing via Emlid Studio too? Or do you also have RINEX from ReachView 3? If so, please share it as well. Maybe something goes wrong at this stage.
Svetlana,
I am traveling for work. But when I get back to the office, I will see what I have. My normal workflow is to only record the UBX file. I have many observations with CSV files, etc. So I will process them and see how each compares. I can then upload them to seperate folders. I will also let you know if I have any where I have original Rinex from RS2 (not converted).
