Simplify entering HAE into Fixed Base coordinates by incorporating HI and APC offset (enhancement request)

[tonycanike]

Subject of the issue

Allow optionally entering pole height (HI) and Antenna Phase Center offset for Fixed RTK Base to eliminate manual field calculations and potential sources of error.

Enhancement Request

Allow the user to separately enter (1) the HAE of the survey mark, (2) the height of the instrument (HI), and (3) the antenna offset and automatically calculate the HAE of the antenna phase center for the RTK Base.

In the Base Configuration -> Fixed -> Geodetic Coordinates menus/forms (both the serial and WiFi entry.) -Add an entry field for pole height (or HI, height of instrument). (usually X.xx meters) -Add an entry field for the antenna phase center offset. (usually cm or mm) -Calculate antenna phase center height as the sum of the entered HAE + entered HI + entered antenna phase center offset -display the result of the calculation so it's clear to the user what is happening. An attentive surveyor would look at it and go "that looks good." An especially careful surveyor, or a surveyor learning their new equipment, would do the math manually and compare to the display to double-check the base configuration. (The manual calculation is optional but redundant and worthwhile step. Surveyors like redundant data and double-checks.)

Consider: -The Facet and L-Facet could know their offset, so the antenna offset could be pre-populated. -It's common to use the same antenna over and over so the antenna offset could be saved in the profile settings. (eg for Explorer and Surveyor). -It's common to use fixed pole lengths (some survey crew chiefs give fixed 2m poles to their crew so HI is one less blunder waiting to happen), so the pole height/HI could be saved in profile settings.

Industry Example

Go to about 1:25 in the video on this to see how Emlid does it. Emlid apparently hard-codes the antenna offset. https://docs.emlid.com/reachrs/rtk-quickstart/placing-the-base/

Note that the video isn't exceptionally clear about whether the user has to add the ARP-APC offset, but the text on the page is clearer.

> "Measure the distance between the mark and the bottom of your Reach (h on Figure 5).
> 
> Specify the measured distance in ReachView 3. It will automatically calculate the antenna height.
> Reach RS/RS+ antenna height
> 
> For Reach RS/RS+, the antenna height is the distance between the mark and the bottom 
of the receiver (h on Figure 5) plus the receiver's height to the antenna reference point (ARP) 
which is equal to 65 mm and automatically added by ReachView 3."

Note the bottom of the Reach, like the bottom of the Facet and the bottom of the TOP106, is the Antenna Reference Point. The antenna offset is from the ARP (bottom) to the Antenna Phase Center.

Discussion

Surveyors generally know and work with the coordinates of the survey mark the survey pole is resting on, aka the pole tip. Converting from the height of the survey mark to the height of the antenna phase center is an inconvenience and a source of error that could be eliminated.

The elevation (Height above WGS84 Ellipsoid) of the Antenna Phase Center is the sum of

• HAE of the survey mark
• the height of the pole or tripod, and
• the offset from the bottom of the antenna (Explorer, Surveyor) or receiver (Facet, L-Facet).

Currently this math needs to be done on the fly in the field by the surveyor when setting up a RTK Facet in Fixed Base mode.

Math done on the fly in the field is one of the biggest sources of blunders. Modern equipment and software do their best to minimize math that surveyors need to calculate in the field. Adding this feature to the RTK firmware will eliminate a potential source of blunders.

Most data collectors (SW Maps, SurvPC, etc.) allow the user to optionally enter the HI (height of instrument, instrument height, pole height, etc.) and optionally the antenna type and/or offset for various modes of operation (rover, base, etc. as applicable.) Some data collector have a database of known antenna models and offsets, and allow the user to save their own antenna model and offset. The data collectors then perform the math to convert from the reported GNSS coordinates of the antenna phase center to the coordinates of the tip of the survey pole.

When raw data is submitted for processing to OPUS, the submittal form requests the HI and the antenna type. When post-processing completes, OPUS returns the coordinates of the pole tip (i.e. the mark the pole is resting on.)

So the exception to the above usual and expected behavior in the industry is the RTK Express.

[gdt]

This makes sense to me. Perhaps the same config should be used on rovers so that coordinates are also pole tip, and that might involve parsing/regenerating NMEA. Or maybe people think that's a data collector job, but IMHO it would be nice to have ground coordinates while hiking. I have a 1"x4" in a backpack as a mount where the ARP is 2.1m above the surface I'm standing on, which seems like "HI" even if a surveyor would cringe, and then I tend to use (L1+L2)/2 phase center offsets.

I am a little unclear on APC/ARP offset in that typically (always?) the L1 and L2 offsets are different. With the F9P there is no antenna model being used, so one is left to do something cruder, perhaps average of L1 and L2, perhaps some value that minimizes errors compared to doing it right over the expected set of elevation angles. But I agree that this works out to a single offset from ARP to "usual computation of position by F9P".

[tonycanike]

gdt - Interesting idea about the rover outputting elevations corrected with HI and ARP/APC offsets. Maybe geoid correction too.

I suggest it's a related but separate feature request from calculating elevations for fixed rtk base input. I have some information drafted up and thoughts to add, but don't want to drift the conversation here under this feature request too much.

gdt if you open a separate issue or start a forum conversation I'd be happy to contribute there.

[gdt]

@tonycanike Fair point that it's separate; see #270

[nseidle]

Ok so user enters:

1. The ECEF or geodetic HAE of the survey mark
2. the height of the instrument (HI)
3. the antenna reference point offset

Then, before we start fixed base mode, we modify the ECEF Z with the -1 * (HI + ARP)? Can do. I have some other pressing features but we should be able to add this soon.

[tonycanike]

Awesome thanks! Great news. One comment though - can't just change Z by the HI and offset, the math to figure out how to change ECEF XYZ is not simple. Don't know the vector of a plumb bob over the mark in XYZ coordinates, it depends on the geoid, etc.

I'd say ECEF XYZ users are not given the option to enter HI and offset. (Use case A below).

The utility of the geodetic Lat, Long, and HAE coordinates is it's easy to add the HAE of the mark, the HI, and the antenna offset to get the HAE of the antenna phase center.

It's either:

Use Case A. User enters ECEF XYZ

This is the use case for a permanent base station, such as where someone has their antenna firmly attached to a structure and it doesn't move for a long period of time. That is, they

1. mount the antenna securely,
2. collect static data,
3. get an OPUS, NR-Canada, etc., solution (ECEF XYZ)
4. enter XYZ, with the antenna having never moved, so there's no need to enter HI and antenna offset.
5. transmit RTCM to a rover

OR

Use Case B. User enters geodetic Lat, Lon, and HAE of the survey mark, optionally HI, and optionally the ARP-APC offset. Assume zero if they don't enter the optional values.

This is the use case where a surveyor is setting (or reusing) one or more survey marks to use as control points. They do something like the below:

1. Choose or set a mark securely.
2. Setup their receiver over the mark with a tripod or pole.
3. Measure HI that day
4. Gather static data
5. Pack up the gear and go back to the office.
6. Get an OPUS, etc., solution for HAE of the mark, entering the HI and antenna type)
7. Go back out into the field days, weeks, or months later.
8. Setup their base on a tripod or pole over the mark. Could be a different tripod or different pole.
9. Measure HI for this day, it's probably different from the first HI.
10. Enter Lat, Lon, and HAE of the survey mark; HI , and antenna offset into the Wifi config.
11. Start transmitting RTCM to a rover.

It's common for surveyors to use sturdy tripods (e.g. a total station tripod) for their base GNSS receivers so they don't get moved by the wind when they are out and about with their rovers. Every time you setup one of these tripods you get a different HI.

[nseidle]

Right! Thanks for the reminder.

I agree with your two use cases and the ability to avoid ECEF and just adjust the HAE.

[gdt]

Also, I don't think you need to care about plumb line vs the HAE unit vector, over reasonable HI/ARP (2m, 5m would be pretty huge).

[ormingtrude]

Awesome thanks! Great news. One comment though - can't just change Z by the HI and offset, the math to figure out how to change ECEF XYZ is not simple. Don't know the vector of a plumb bob over the mark in XYZ coordinates, it depends on the geoid, etc.

I'd say ECEF XYZ users are not given the option to enter HI and offset. (Use case A below).

The utility of the geodetic Lat, Long, and HAE coordinates is it's easy to add the HAE of the mark, the HI, and the antenna offset to get the HAE of the antenna phase center.

It's either:

Use Case A. User enters ECEF XYZ

This is the use case for a permanent base station, such as where someone has their antenna firmly attached to a structure and it doesn't move for a long period of time. That is, they

1. mount the antenna securely,
2. collect static data,
3. get an OPUS, NR-Canada, etc., solution (ECEF XYZ)
4. enter XYZ, with the antenna having never moved, so there's no need to enter HI and antenna offset.
5. transmit RTCM to a rover

OR

Use Case B. User enters geodetic Lat, Lon, and HAE of the survey mark, optionally HI, and optionally the ARP-APC offset. Assume zero if they don't enter the optional values.

This is the use case where a surveyor is setting (or reusing) one or more survey marks to use as control points. They do something like the below:

1. Choose or set a mark securely.
2. Setup their receiver over the mark with a tripod or pole.
3. Measure HI that day
4. Gather static data
5. Pack up the gear and go back to the office.
6. Get an OPUS, etc., solution for HAE of the mark, entering the HI and antenna type)
7. Go back out into the field days, weeks, or months later.
8. Setup their base on a tripod or pole over the mark. Could be a different tripod or different pole.
9. Measure HI for this day, it's probably different from the first HI.
10. Enter Lat, Lon, and HAE of the survey mark; HI , and antenna offset into the Wifi config.
11. Start transmitting RTCM to a rover.

It's common for surveyors to use sturdy tripods (e.g. a total station tripod) for their base GNSS receivers so they don't get moved by the wind when they are out and about with their rovers. Every time you setup one of these tripods you get a different HI.

@tonycanike Sorry if I seem to be jumping in on another thread here but I noticed you mentioned Canada. I’ve been trying to figure out if this will work for me in Canada around 30miles from the Detroit border

[nseidle]

This is in the next RC:

//Add height of instrument (HI) to fixed altitude
//https://www.e-education.psu.edu/geog862/node/1853
//For example, if HAE is at 100.0m, + 2m stick + 73mm ARP = 102.073m
float totalFixedAltitude = settings.fixedAltitude + (settings.antennaHeight / 1000.0) + (settings.antennaReferencePoint / 1000.0);

Above is the math. User inputs a known monument location. Antenna height and ARP are input and added to HAE for a totalFixedAltitude in meters. When a user starts the fixed base, with geodetic coordinates, totalFixedAltitude is passed to ZED-F9P. All RTCM produced is done with a corrected altitude.

[nseidle]

TODO is to get this into the WiFi AP. Now in WiFi AP.

[amlago]

Good news. I reiterate my request to pass the coordinates obtained with survey in to the fixed base. The geodesic coordinates would be passed and with the modifications that they propose, the height of the cane could be changed according to the need of the day. Ultimately, the surveyor can switch to known coordinates if necessary. A complementary idea, which I think has already been suggested, would be to save in a list the last base positions, by date and time, and choose from the list the one that is needed. For example the last 5 positions or the necessary quantity according to the user. It would be a drop-down list and could be useful, easy to access and would avoid errors in the field when entering numbers with many figures. We keep going.

[amlago]

In the way that the data is presented, we would go from the height of the known monument to the height of the antenna. I assume that HI and antenna phase center offset accept negative values if we want to do the inverse operation and obtain elevation values of a monument placed by me to serve as a fixed point. Is it so?

[amlago]

I see that we are adding the height of the rod and the phase center difference to the ellipsoidal height, given by the Facet. The normal thing is the other way around, you must subtract from the ellipsoidal h the height of the cane and the difference in the phase center to obtain the height h of the mark or monument that we place. In general, in field tasks, we obtain the height of the mark with this subtraction. It may be a different interpretation of what is being entered as a fixed base. I interpret that the coordinates entered are those of the phase center and from there I obtain the coordinates of the marks. LL are the same and the height is obtained by subtracting the height of the rod and the difference in the phase center from the ellipsoidal height. That's the usual when working with approximate coordinates in fixed base mode. Which is the most usual in topographical tasks in general, to obtain certain areas and distances in a relative way, regardless of the absolute location in the world.

[amlago]

If the above is not understood or is not possible, please enable the entry of negative values for rod height and phase center difference. It's not what I like, but ultimately it solves my way of working. Thank you

[amlago]

322 and #302 are part of the topic being discussed here.

We will keep in touch.

[gdt]

I think there are two different things people want to do:

1) enter a position of a mark manually, based on someone else having established a position, and enter HI and APC-ARP so that in base mode the coordinates transmitted will be for the antenna. 2) in survey-in, enter HI and APC-ARP so that one can calculate a base position that is the mark, not the antenna, to be used later via method 1, possibly with a different rod height.

Probably we just need to be clear about mark coordinates vs APC coordinates.

[tonycanike]

Well said @gdt. And definitely agree with the point that the UI needs to be clear regarding what the numbers and entry fields are.

[amlago]

You summed it up very well. To be able to do the two things that are proposed, we have 2 options. 1)Leaving the current setting allow you to enter negative values for rod height and phase difference. 2) Add a box to mark indicating if the coordinates are from the antenna or from the mark, and program the addition or subtraction of pole heights and phase center difference as appropriate.

I think option 2) I like better.

As I always say sorry for the translations.

[amlago]

If we have absolute fixed coordinates, they are entered and nothing will be put in rod height and phase center if it corresponds.

[tonycanike]

If we have absolute fixed coordinates, they are entered and nothing will be put in rod height and phase center if it corresponds.

I think this would work fine @amlago.

---

[tonycanike]

@nseidle I don't understand the "tool tip" (i) for the Antenna Height and Antenna Reference Point in the Wifi base configuration screen for Fixed Geodetic Coordinates.

The tool tip says "....Amount is subtracted from HAE before starting fixed base"

But in comment above in this issue discussion thread, a while back you said it's added, not subtracted.

It should be added, as you stated a while back:

Above is the math. User inputs a known monument location. Antenna height and ARP are input and added to HAE for a totalFixedAltitude in meters. When a user starts the fixed base, with geodetic coordinates, totalFixedAltitude is passed to ZED-F9P. All RTCM produced is done with a corrected altitude.

That is,

HAE of the monument + antenna height + ARPAPC offset --> should get loaded into the ZED.

[amlago]

I relate it to what I suggested in #327. If we save the mark coordinates or enter mark coordinates, we must add the height of the pole and the difference from the center of the base, in order to obtain the height of the antenna.

[amlago]

@tonycanike : I would ask you to tell me what you think about the idea of #327 Thank you

[nseidle]

But in comment above in this issue discussion thread, a while back you said it's added, not subtracted.

Ah! Sorry, good catch. I've corrected the tool tip.

[nseidle]

If we save the mark coordinates or enter mark coordinates, we must add the height of the pole and the difference from the center of the base, in order to obtain the height of the antenna.

Right! Good point @amlago.

[amlago]

Clarifications. If you want to save the coordinates of the mark (NOT OF THE ANTENNA) if we must subtract. What I suggested in #327.

mark height = antenna ellipsoidal height - pole height - phase center difference

I insist: this is to save mark coordinates.

[amlago]

The next day, I park at the mark and the Facet must do the inverse operation, that is, add what is entered as the height of the pole and the difference in the phase center.

"If we save the mark coordinates or enter mark coordinates, we must add the height of the pole and the difference from the center of the base, in order to obtain the height of the antenna."

[tonycanike]

This confusion is why I submitted #330. We have two different and inverse operations occurring in the same web page form.

[nseidle]

I believe the core of this issue has been implemented in v2.5. Please open a new issue if we need to continue sub-discussions or feature refinements.