RTK Facet – systematic vertical offset vs national benchmarks (geoid / vertical datum question)

GPS/GNSS
1

Hello,

I am using a SparkFun RTK Facet (Facet Rover) with RTK corrections via NTRIP (network solution).

Horizontally the results are excellent, and the solution is stable and repeatable.
However, I am seeing a systematic vertical offset when comparing Facet measurements to official national geodetic benchmarks.

Observed behavior

  • Fix type: RTK Fixed

  • Vertical accuracy reported: ~1–2 cm

  • Repeated measurements at the same location are internally consistent.

  • When compared to official survey benchmarks, the Facet-reported altitude is consistently higher by ~1.8–3.2 meters.

  • The benchmarks are only hundreds of meters apart, so this is not a large-area distortion.

This does not look like random error, but a vertical datum / geoid difference.

What has already been ruled out

  • Antenna / rod height: Facet has an internal antenna and no user-defined rod height. No constant offset is observed.

  • Coordinate system / projection: XY alignment is correct; the issue is vertical only.

  • RTK quality: VDOP is low, corrections are fresh, and the solution is stable.

Context

This is in Israel, where official heights use a local national geoid model (ILUM).
Local geoid undulation values are ~19.2 m in the area.

Based on the offsets observed, it appears that the Facet may be outputting MSL height referenced to a global geoid model (e.g. EGM96 or EGM2008), rather than ellipsoidal height.

Questions

  1. What vertical reference does the RTK Facet output by default?

    • Ellipsoidal height (h)?

    • Orthometric / MSL height?

  2. If MSL: which geoid model is used internally (EGM96, EGM2008, other)?

  3. Is the geoid model fixed in firmware or configurable?

  4. Does the NMEA GGA output include the geoid separation value actually used to compute the reported altitude?

  5. Is this behavior a known design choice / limitation of the Facet, or is there a recommended workflow when working against local national vertical datums?

Any clarification from SparkFun or others with deep Facet / ZED-F9x experience would be greatly appreciated.

Thanks in advance.

2

Hello, I live in South America.
My Facet app provides me with ellipsoidal heights.
It’s possible to obtain heights from geoid models using different data collection programs.

For example, in SWmaps you can add different geoids.

But Facet will give you ellipsoidal heights.

Regards

1 Like
3

What program are you using? Is it possible that your program is using a geoid by default? Investigate the data collection program.

1 Like
4

The NMEA GGA message provides ellipsoidal height and it includes the geoid separation in a separate field. The F9P uses a decimated internal geoid model, but you can load custom ones for more accurate local geoid heights as @amlago mentioned. Orthometric Elevations wont match unless you compare in the same system.

Take a look at the GGA message and you will likely notice the difference in the geoid separations between the nmea output and the 19.2m you mentioned for your local geoid (your couple of meters reported difference).

The ODD thing is, the vertical offset should be constant in a small area.

higher by ~1.8–3.2 meters

That (range of offset) makes me think you might have problems.

1 Like
5

ILUM is a “private” geoid model…

&

Auguri di buone feste a tutti

1 Like
6

Hello,

Thank you for the clarification in the forum thread — it helped confirm that the behavior we are seeing is related to vertical datum / geoid handling rather than RTK accuracy or hardware issues.

I would like to add an important detail regarding our workflow and ask for guidance accordingly.

Context – software used

In production we are not using SW Maps, but rather:

  • ArcGIS Field Maps

  • ArcGIS QuickCapture

These applications do not expose ellipsoidal height (HAE) or the geoid separation value, and typically store only a single “Altitude / Z” value as provided by the GNSS receiver.

As a result, the vertical datum applied internally by the RTK Facet directly affects the stored data, without being visible to the user in the field.

1. Preventing this issue in future surveys

Given that the RTK Facet applies an internal/global geoid when outputting orthometric height:

  • What is the recommended best practice when using the Facet together with Field Maps / QuickCapture in countries that use a mandatory national vertical datum (e.g. Israel – ILUM)?

  • Is the recommended approach to:

    • Work with ellipsoidal height (HAE) if possible, and apply a local geoid externally?

    • Or accept the Facet’s orthometric output and apply a correction afterward?

In short: how can users avoid hidden vertical datum offsets when using these ArcGIS field applications?

2. Correcting existing data

For datasets already collected via Field Maps / QuickCapture using the Facet’s altitude output:

  • Is it acceptable to apply a constant vertical offset (assuming the internal geoid is stable over a small project area)?

  • Or would you recommend a spatial correction model if small variations are observed?

Any guidance on what is considered a technically sound correction approach would be appreciated.

3. Expected variation over short distances

Within distances of only a few hundred meters, we observe differences between official national benchmarks and Facet-derived heights ranging from ~1.8 m to ~3.5 m.

  • Is this level of variation expected when using a global/internal geoid combined with GNSS vertical sensitivity?

  • Or would you expect the offset to be nearly constant over such short distances?

4. Internal geoid confirmation

Finally, for clarity:

  • Can you confirm whether the geoid separation value reported in the NMEA GGA message is exactly the same model used internally by the Facet to compute the reported orthometric height?

This information is critical for reconstructing ellipsoidal height and applying a correct local geoid externally.

Thank you again for your assistance and for the detailed explanations so far.

Best regards,
Lior Hammer

7

The Facet reports the standard GGA Sentence :

image
image1199×719 20.5 KB

For Instance, I just cranked up a facet and the GGA over the Bluetooth serial link is :
$GNGGA, UTC, Lat, N, Long, W, 1 , 12, 0.70, 116.139, M, -28.3670,M,checksum

Starting a data collector app (such as SW Maps), it lists the Orthometric Height as 116.139 Meters and also the Ellipsoid height at 87.78 M , which is Field 9 + Field 11, or h = 116.139 + (-28.367) = 87.78M

{copy/paste] To calculate ellipsoidal height (h) from orthometric height (H) and geoid separation (N), you use the formula h = H + N, where ‘h’ is the height above the reference ellipsoid, ‘H’ is the height above the geoid (mean sea level), and ‘N’ is the geoid’s separation (undulation) from the ellipsoid

It’s been years since I used ESRI (ArcGIS). I can’t image that there isn’t a way to have it use the required Israel – ILUM geoid…but I’ve been wrong before :wink:

It’s not a hidden vertical datum offset, the facet follows the industry NMEA Standard.

Look at your stored data in ArcGIS. Try to find the metadata. It should contain the geoid separation for each point (from the GGA) which will get you to HAE, then apply your own gridded Geoid (ILUM) so the elevations match what you are comparing them to.

Let me know if that doesn’t make sense, and good luck :nerd_face:

1 Like
8

Thanks for the explanation so far.

We realized that for our previously collected data we do NOT have the raw ellipsoidal height, because those points were collected in ArcGIS Field Maps / QuickCapture and not in SW Maps.

To validate ourselves, we went back to the field with SW Maps + SparkFun RTK Facet, and there we do see the expected behavior:

  • SW Maps shows ellipsoidal height and orthometric (MSL) height

  • The implied geoid separation at our test location in Israel is ~17.3 m, consistent between repeated measurements

However, when we sample global geoid models at the exact same coordinate:

  • EGM96 ≈ 20.3 m

  • EGM2008 ≈ 19.4 m

So the ~17.3 m value clearly does not come from EGM96 or EGM2008.

The key question:
:backhand_index_pointing_right: What geoid model (or vertical reference) is the Facet actually using to produce the GGA orthometric height / geoid separation?

Is this:

  • a built-in geoid inside the receiver (and if so, which one)?

  • something coming from the RTK/NTRIP correction stream?

  • or a simplified / legacy global model?

Identifying this model is critical for us, because we need to reconstruct and correct heights for points already collected.

Any clarification on the exact geoid model or source of the GGA geoid separation, and where cam i get it, would help a lot.

thank you

9

u-Blox uses a very rough EGM96 grid, and interpolates. The NMEA GGA reflects the value used so you can back out the MSL adjustment. One can look at the two heights reported in UBX-NAV-PVT, and derive the MSL adjustment there to cross-check

10

Google says :

Yes, ArcGIS Field Maps and QuickCapture can record detailed GNSS metadata, including NMEA-like info (accuracy, satellites, fix type, time) for points, but you must first add specific GPS metadata fields to your feature layer in ArcGIS Pro/Online/Portal and configure your receiver for NMEA output; QuickCapture uses the NMEA 0183 standard to pull data like GGA sentences for high-accuracy devices, while Field Maps writes metadata to designated fields for better data quality assessment.

If your data collection App wasn’t setup properly, you will likely have to do that first, test, and recollect the RTK positions.