When I went to enter my first HI this morning for the RX in Emlid Flow v8.6 for Android, I found this disturbing illustration:
Then I started searching this forum only to see that I’m not alone in being concerned about the “antenna height”. So many posts on this subject and they appear to not be limited to the RX by any means.
Antenna calibration services such as Geoscience Australia, Geo++, NGS are provided to GNSS antenna manufacturers involving rigorous testing resulting in very precise measurements of the antenna’s various and multiple phase center variations and offsets from which all relate to 1) the true north reference point and 2) the antenna reference point (ARP) for any given particular antenna make and model.
The height of the instrument, or HI, is an old school term dating back long before GNSS, but in the context of GNSS surveying, is immediately understood to be the ARP. Surveyors are trained to be hyper aware of their HI because they know of the consequences from getting a wrong HI.
Why on Earth is the Emlid Flow illustration:
- not appropriately labeling the ARP?, and
- why should we be shown “antenna height” in the first place?
Related to this discussion is how this height information is being written as an attribute of the point. In particular, the HI is not being recorded at all, but the “antenna height” is recorded. For example, in the first point recorded for this morning; note that this 5-second FIX only measurement had the wrong (1.8 m) HI; should have been 1.436 m.
NGS indicates the bottom of antenna mount (BAM) for the antenna reference points (ARP) which I assume is the bottom of the unit attached at the top of the pole. Choosing the receiver/antenna model in the Emlid software accounts for the 0.145 difference. This is my understanding. So entering a rod height of 2.00 m (at the bottom of the unit), Emlid adds this (0.145) to their computation of the phase center, which is immaterial to the user.
This reminds me when we first got out Javad LS/T2’s. NGS first had the ARP at the bottom of the 0.025 tall adapter (5/8’s x 11 female to 1/4 x 20) instead to the bottom of receiver (which is what NGS shows now) So using our LS’s and T2’s, the ARP would be 2.025m with Javad’s adapter. We were one of several that found this error in the beginning due to published elevations being different almost exactly by 0.025 (the height of the adapter).
This is my interpretation of Emlid’s drawing but I may be wrong.
The only sure way to verify the vertical height would be to find some passive control marks with known elevations in the same datum as the RTN.
Just my 2¢ worth.
@EBE111057 I agree with you Bryan. The added layer to the test(s) that you propose for the RX; by the way, I’ve started pronouncing/ personifying this cute little guy as Rex, there are no obs being recorded. Regardless of the measurement interval, an averaged single position gets recorded predicated on 1) the broadcast ephemeris, 2) FIX only, and 3) most critically, in the reference frame used by the corrections’ source. As for the measurement interval, there is a timer that goes up to 60 minutes. Given these considerations, I’ve already started today’s tests. Stay tuned
Well I guess it depends on people. I have never been disturbed by this illustration. The field requires you to input the pole height, you input the pole height you see on your pole, and you are good to go. I guess it is very well suited for a majority of people not familiar with the phase center / ARP topic.
- ARP is by far less understandable by users. I would even bet a lot of surveyors don’t know the term. And I say that as a surveyor myself
- Why not ? I guess it is to show that GNSS coordinates are computed at this location and the app substracts the antenna height to the computed elevation to get the bottom of pole height, which is what you ultimately want.
@Florian You’re absolutely correct Florian, it does depend on people.
- It’s essential that any GNSS surveyor understand what the ARP is. The primary reason to understand what this fundamental reference point means is very much linked to them also knowing which antenna they’re using.
- This is precisely the reason to only show in the Emlid diagram the ARP height entry for anybody that doesn’t understand PCOs. In this instance, the difference of 0.145 m that is shown in the Emlid illustration doesn’t even appear to be representative of the L1 or L2 PCOs, thus making the waters a bit turbid as the published PCOs are 0.1471 m and 0.149 m.
This does make the case and reason for retaining the attribute
Antenna_Height that’s written for the collected point in order to corroborate/ check mathematically what’s taking place. But for the most part, keeping the math transparent to the user on this Emlid diagram to illustrate what exactly they’re expected to measure for the HI I think makes sense, particularly after reading all of the posts here where Antenna Height has been questioned.
Yep, that’s the way it should be… just measure to the NGS referenced ARP. The software takes care of the rest. The common surveyor really doesn’t care about the offsets to the phase centers. It’s good to know though. I haven’t used my Emlid equipment in a while as I’ve been assigned as an office surveyor, my brother thinks I’m too much dead weight in the field ( he’s ten years younger than me and retired from the Army National Guard, he’s always been a “gung ho let’s get it done” guy).
I agree with the rod height being in the output data as this would verify all rod heights and would be a good check if there is a problem with the vertical component.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.