Alt MSL - Reported value is wrong on some devices

[vkbellis]

GPSTest v3.9.11 is displaying rather odd looking Alt (MSL) values and it's unclear to me as to why, even as we consider different geoid models.

For example, my control station 17U has an orthometric Height of 45.004 (m) NAVD88 Geoid12B, and if transformed (using VDatum v4.0.1) to EGM2008(WGS84_G1674), its ortho H is 44.617 (m). It's also unclear to me what exactly, if anything, I'm supposed to do in regards to NMEA sentences.

GPSTest displays Alt (MSL): 66.8 m which is off by almost the exact value as the quantity (ellipsoid h which is 20.472 + the height of the instrument (phone) 1.18 m) - see attached OPUS solution for 17U control values.

App, Device and Android version: RE: GPSTest v3.9.1 (18088-google) on Samsung Galaxy A71, Platform 11, API Level 30

17U - OPUS Solution.pdf

[barbeau]

@vkbellis Thanks for looking into this!

It's also unclear to me what exactly, if anything, I'm supposed to do in regards to NMEA sentences.

I added the "(requires NMEA support)" text in the Help section because the Android Location object from the Location API doesn't directly provide MSL altitude - it only provides [WGS84 altitude](https://developer.android.com/reference/android/location/Location#getAltitude()).

For MSL altitude (and DOPs), I have to manually parse this from NMEA strings that are provided from a different Android API. This API is optional, so isn't necessarily supported by all devices. However, from the GPSTest Database it does seem like nearly all devices do support NMEA, so perhaps I could remove that caveat from the docs.

GPSTest displays Alt (MSL): 66.8 m which is off by almost the exact value as the quantity (ellipsoid h which is 20.472 + the height of the instrument (phone) 1.18 m) - see attached OPUS solution for 17U control values.

Hmmm, curious. Could you provide NMEA logs from your device? See instructions at https://github.com/barbeau/gpstest/blob/master/LOGGING.md#logging-data-to-files.

As mentioned above MSL altitude is parsed from these (in particular $GPGGA, $GNGNS, and $GNGGA sentences - see the source code here).

You can see my original notes from the MSL altitude implementation at https://github.com/barbeau/gpstest/issues/22#issuecomment-260234637, which includes some sample NMEA data there.

[gdt]

Bordering on pedantic, but the Android API does not provide "WGS84 Altitude" -- it provides WGS84 Height above Ellipsoid. The other height reference is "WGS84 Orthometric Height" often called AMSL, defined as what you get from HAE and applying EGM2008 (for the most recent WGS84). WGS84 ALtitude is therefore not really well defined, although I'd argue that it should mean WGS84 Orthometric Height.

I said this before, and it's too confusing for normals, but HAE should not be labeled Alt, because Altitude is universally viewed to be a gravity-referenced concept.

I have heard people say (yes, this is fuzzy) that some phones report WGS84 orthometric height in the HAE field, as a bug, perhaps by people who do not believe that the API says what it says, instead of what it should have said. So I wonder if the phone is doing this, but the alt/MST values seem off by more than they should be.

Plugging the horizontal coordinates into geographiclib's online calculator, I get EGM2008 of -25.3125. So there is a spurious 20m error. I will note that I have seen bad geoid models in GPS chips; even an F9P reports -33 around me when it should say -29 (Boston, 42, -71, ish). But 20m off seems hard to believe.

What I'd recommend is to capture the NMEA data and look at it, in particular what geoid offset it reports. In theory, NMEA altitude adjusted by the NMEA geoid offset should get you back to HAE as reported by the android API. Probably exactly, as most GPS chips if in NMEA mode just do it that way. A chip that is reporting in raw XYZ and therefore letting android calculate lat/lon/HAE is something else.

On a pixel XL I see Alt (= HAE) and Alt MSL (= WGS84 Orthometric Height) as being 33.0m different, which is the answer from the cheesy geoid model that seems to be in my phone and in the F9p and ublox M8.

[vkbellis]

RE: h Without studying the NMEA DTM sentence from the individual Android device in order to try and understand the basis of the ellipsoidal height (h), it's difficult to say which local datum, and datum offsets from a reference datum are in play. The chipset manufacturer, and possibly together with the OEM of the device decide, but then obfuscate their decision and conceal its basis. But at least there is the NMEA sentences to study. See this article I just finished: What's Up with Android's Heights.pdf

RE: H Looking at geoidal separation (N) given in the NMEA GGA and GNS sentences from the individual Android device, we can then compare its value from a trusted authority like ICGEM, NGS and UNAVCO with values for the given geographic position and a variety of popular geoid models; e.g., xGeoid20, Geoid18, EGM2008, EGM96, EGM84 etc.

But geoidal separation (N) alone does not account for the observed errant orthometric heights (H) frequently seen reported on Android devices. Take for example the case in Sean's Issue #22. His NMEA sentence reveals a plausible N value within 2 to 3 meters of known gravity models for his station (Issue 22a), yet the same sentence indicates the orthometric height (H) to be 68 meters above a known ground height.

The NMEA sentences given in Issue 22 don't include the DTM sentence, so we don't know if a local datum was used, nor do we know if there were any offsets from the reference datum. It might be reasonable to think the reference datum was WGS84 (G1762), but it's possible that it wasn't. Regardless, the reason for the 68-meter GNS ortho height error is unknown.

In the Issue22.kmz file, I've included links to the nearby vertical control marks Sean, just in case you're into to doing some ground truthing in the field :)

Issue22 for Google Earth.zip

[gdt]

It strikes me that DTM and looking into local datums is a red herring. Everything I've seen indicates that GNSS chips in Android phones operate in WGS84. I have not seen a geoid model other than WGS84's EGM96/EGM2008, implemented coarsely enough that one can't tell between them anyway. Even in the US, where there is a national datum NAD83 that isn't WGS84, I haven't seen any phone claim to output in it. Does anyone have any example of an Android phone that is operating in some other datum.

My own phone is certainly not accurate enough to separate NAD83/WGS84, or NAVD88/WGS84-orthometric-height, but beyond the accuracy issues and the low-accuracy geoid, things seem ok.

It seems this issue is more "my phone's GNSS chip outputs data that seems wrong" more than "GPSTest is doing something wrong". I suspect that if you log and look at NMEA from the phone and take GPSTest out of the equation, things will be easier to understand, and I speculate that you will find that the phone in question is just buggy.

[barbeau]

So here is a NMEA log and corresponding screenshot from a Samsung Galaxy S21+ that I grabbed yesterday. I haven't had a chance to dive into them yet:

$GPGSV,3,3,11,20,6,207,18,24,14,265,21,28,45,153,26,1*55,,,,
$GPGSV,2,1,5,6,64,346,21,14,26,151,19,24,14,265,15,3,1,34,,8*62
$GPGSV,2,2,5,9,6,100,,8*56,,,,,,,,,,,,
$GLGSV,2,1,8,66,12,39,21,82,36,21,22,73,33,309,26,80,49,239,22,1*72
$GLGSV,2,2,8,79,15,182,22,83,38,318,22,67,32,90,21,68,19,145,26,1*73
$GAGSV,2,1,8,2,19,161,25,3,15,136,18,5,14,85,22,13,15,260,20,7*74
$GAGSV,2,2,8,15,55,304,21,27,42,305,22,30,62,202,24,36,0,0,,7*7A
$GAGSV,2,1,8,2,19,161,17,3,15,136,18,5,14,85,21,15,55,304,23,1*72
$GAGSV,2,2,8,27,42,305,17,30,62,202,22,13,15,260,,36,0,0,,1*7E
$GNGSA,A,3,2,6,14,17,19,24,28,,,,,,0.9,0.5,0.7,1*39,,
$PSSGR,GSA,A,2,6,14,,,,,,,,,,,0.9,0.5,0.7,1,8*4C
$GNGSA,A,3,66,67,68,73,79,80,83,,,,,,0.9,0.5,0.7,2*3F,,
$GNGSA,A,3,2,5,13,15,27,30,,,,,,,0.9,0.5,0.7,3*3F,,
$PSSGR,GSA,A,2,305,315,330,,,,,,,,,,0.9,0.5,0.7,3,1*75
$GNVTG,,T,,M,0,N,0,K,A*3D,,,,,,,,,,,
$GNDTM,P90,,0.000021,S,0.000002,E,0.989,W84*57,,,,,,,,,,,,
$GNRMC,181842,A,2804.275596,N,8225.599397,W,0,,140621,3.1,W,A,V*7A,,,,,,,
$GNGNS,181842,2804.275596,N,8225.599397,W,AAANNN,20,0.5,9.2,-24,,,V*1F,,,,,,,
$GNGGA,181842,2804.275596,N,8225.599397,W,1,12,0.5,9.2,M,-24,M,,*41,,,,,,
$PSMSG,tech=0x9,sensor=0x3,accu=11.015795,h_rel=3,speed=0.000000,time=1623694722000,magcal=PASS,SV_used=25,l5=2,e5=3*00,,,,,,,,,,
$BDMSG,ENGI_MSG,RPUSH,00001*00,,,,,,,,,,,,,,,,,
$GPGSV,3,1,11,2,51,280,35,5,3,203,18,6,64,346,26,9,6,100,13,1*6F
$GPGSV,3,2,11,12,24,319,13,14,26,151,24,17,38,73,21,19,52,43,21,1*6A
$GPGSV,3,3,11,20,6,207,18,24,14,265,21,28,45,153,28,1*5B,,,,
$GPGSV,2,1,5,6,64,346,19,14,26,151,19,24,14,265,15,3,1,34,,8*69
$GPGSV,2,2,5,9,6,100,,8*56,,,,,,,,,,,,
$GLGSV,2,1,8,66,12,39,21,82,36,21,22,73,33,309,26,80,49,239,24,1*74
$GLGSV,2,2,8,79,15,182,22,83,38,318,22,67,32,90,21,68,19,145,26,1*73
$GAGSV,2,1,8,2,19,161,25,3,15,136,18,5,14,85,24,13,15,260,20,7*72
$GAGSV,2,2,8,15,55,304,21,27,42,305,24,30,62,202,26,36,0,0,,7*7E
$GAGSV,2,1,8,2,19,161,17,3,15,136,16,5,14,85,19,15,55,304,23,1*77
$GAGSV,2,2,8,27,42,305,17,30,62,202,22,13,15,260,,36,0,0,,1*7E
$GNGSA,A,3,2,6,14,17,19,28,,,,,,,0.9,0.6,0.7,1*3C,,
$PSSGR,GSA,A,2,6,,,,,,,,,,,,0.9,0.6,0.7,1,8*4A
$GNGSA,A,3,66,67,68,73,79,80,83,,,,,,0.9,0.6,0.7,2*3C,,
$GNGSA,A,3,2,5,13,15,27,30,,,,,,,0.9,0.6,0.7,3*3C,,
$PSSGR,GSA,A,2,305,315,330,,,,,,,,,,0.9,0.6,0.7,3,1*76
$GNVTG,,T,,M,0,N,0,K,A*3D,,,,,,,,,,,
$GNDTM,P90,,0.000021,S,0.000002,E,0.989,W84*57,,,,,,,,,,,,
$GNRMC,181843,A,2804.275596,N,8225.599399,W,0,,140621,3.1,W,A,V*75,,,,,,,
$GNGNS,181843,2804.275596,N,8225.599399,W,AAANNN,19,0.6,9.2,-24,,,V*19,,,,,,,
$GNGGA,181843,2804.275596,N,8225.599399,W,1,12,0.6,9.2,M,-24,M,,*4D,,,,,,
$PSMSG,tech=0x9,sensor=0x3,accu=10.991882,h_rel=3,speed=0.000000,time=1623694723000,magcal=PASS,SV_used=23,l5=1,e5=3*00,,,,,,,,,,
$BDMSG,ENGI_MSG,RPUSH,00001*00,,,,,,,,,,,,,,,,,
$GPGSV,3,1,11,2,51,280,34,5,3,203,18,6,64,346,27,9,6,100,13,1*6F
$GPGSV,3,2,11,12,24,319,13,14,26,151,21,17,38,73,21,19,52,43,21,1*6F
$GPGSV,3,3,11,20,6,207,18,24,14,265,21,28,45,153,27,1*54,,,,
$GPGSV,2,1,5,6,64,346,19,14,26,151,19,24,14,265,16,3,1,34,,8*6A
$GPGSV,2,2,5,9,6,100,,8*56,,,,,,,,,,,,
$GLGSV,2,1,8,66,12,39,19,82,36,21,22,73,33,309,26,80,49,239,24,1*7F
$GLGSV,2,2,8,79,15,182,23,83,38,318,20,67,32,90,21,68,19,145,26,1*70
$GAGSV,2,1,8,2,19,161,24,3,15,136,18,5,14,85,23,13,15,260,21,7*75
$GAGSV,2,2,8,15,55,304,21,27,42,305,22,30,62,202,25,36,0,0,,7*7B
$GAGSV,2,1,8,2,19,161,17,3,15,136,16,5,14,85,23,15,55,304,24,1*79
$GAGSV,2,2,8,27,42,305,17,30,62,202,24,13,15,260,,36,0,0,,1*78
$GNGSA,A,3,2,6,14,17,19,28,,,,,,,0.9,0.6,0.7,1*3C,,
$PSSGR,GSA,A,2,6,,,,,,,,,,,,0.9,0.6,0.7,1,8*4A
$GNGSA,A,3,66,67,68,73,79,80,83,,,,,,0.9,0.6,0.7,2*3C,,
$GNGSA,A,3,2,5,13,15,27,30,,,,,,,0.9,0.6,0.7,3*3C,,
$PSSGR,GSA,A,2,305,315,330,,,,,,,,,,0.9,0.6,0.7,3,1*76
$GNVTG,,T,,M,0,N,0,K,A*3D,,,,,,,,,,,
$GNDTM,P90,,0.000021,S,0.000002,E,0.989,W84*57,,,,,,,,,,,,
$GNRMC,181844,A,2804.275641,N,8225.599388,W,0,,140621,3.1,W,A,V*7B,,,,,,,
$GNGNS,181844,2804.275641,N,8225.599388,W,AAANNN,19,0.6,9.1,-24,,,V*14,,,,,,,
$GNGGA,181844,2804.275641,N,8225.599388,W,1,12,0.6,9.1,M,-24,M,,*40,,,,,,
$PSMSG,tech=0x9,sensor=0x3,accu=10.960116,h_rel=3,speed=0.000000,time=1623694724000,magcal=PASS,SV_used=22,l5=1,e5=3*00,,,,,,,,,,
$BDMSG,ENGI_MSG,RPUSH,00002*00,,,,,,,,,,,,,,,,,
$GPGSV,3,1,11,2,51,280,34,5,3,203,18,6,64,346,27,9,6,100,16,1*6A
$GPGSV,3,2,11,12,24,319,13,14,26,151,21,17,38,73,21,19,52,43,21,1*6F
$GPGSV,3,3,11,20,6,207,18,24,14,265,21,28,45,153,27,1*54,,,,
$GPGSV,2,1,5,6,64,346,21,14,26,151,19,24,14,265,16,3,1,34,,8*61
$GPGSV,2,2,5,9,6,100,,8*56,,,,,,,,,,,,
$GLGSV,2,1,8,66,12,39,19,82,36,21,22,73,33,309,24,80,49,239,24,1*7D
$GLGSV,2,2,8,79,15,182,23,83,38,318,20,67,32,90,21,68,19,145,25,1*73
$GAGSV,2,1,8,2,19,161,25,3,15,136,18,5,14,85,21,13,15,260,21,7*76
$GAGSV,2,2,8,15,55,304,21,27,42,305,24,30,62,202,25,36,0,0,,7*7D
$GAGSV,2,1,8,2,19,161,17,3,15,136,16,5,14,85,24,15,55,304,25,1*7F
$GAGSV,2,2,8,27,42,305,17,30,62,202,22,13,15,260,,36,0,0,,1*7E
$GNGSA,A,3,2,6,9,14,17,19,28,,,,,,0.9,0.6,0.7,1*35,,
$PSSGR,GSA,A,2,6,,,,,,,,,,,,0.9,0.6,0.7,1,8*4A
$GNGSA,A,3,66,67,68,73,79,80,83,,,,,,0.9,0.6,0.7,2*3C,,
$GNGSA,A,3,2,5,13,15,27,30,,,,,,,0.9,0.6,0.7,3*3C,,
$PSSGR,GSA,A,2,305,315,330,,,,,,,,,,0.9,0.6,0.7,3,1*76
$GNVTG,,T,,M,0,N,0,K,A*3D,,,,,,,,,,,
$GNDTM,P90,,0.000021,S,0.000002,E,0.989,W84*57,,,,,,,,,,,,
$GNRMC,181845,A,2804.275643,N,8225.599385,W,0,,140621,3.1,W,A,V*75,,,,,,,
$GNGNS,181845,2804.275643,N,8225.599385,W,AAANNN,20,0.6,9,-24,,,V*11,,,,,,,
$GNGGA,181845,2804.275643,N,8225.599385,W,1,12,0.6,9,M,-24,M,,*4F,,,,,,
$PSMSG,tech=0x9,sensor=0x3,accu=11.062766,h_rel=3,speed=0.000000,time=1623694725000,magcal=PASS,SV_used=23,l5=1,e5=3*00,,,,,,,,,,
$BDMSG,ENGI_MSG,RPUSH,00001*00,,,,,,,,,,,,,,,,,
$GPGSV,3,1,11,2,51,280,32,5,3,203,18,6,64,346,25,9,6,100,16,1*6E
$GPGSV,3,2,11,12,24,319,12,14,26,151,20,17,38,73,21,19,52,43,21,1*6F
$GPGSV,3,3,11,20,6,207,14,24,14,265,18,28,45,153,24,1*51,,,,
$GPGSV,2,1,5,6,64,346,21,14,26,151,19,24,14,265,16,3,1,34,,8*61
$GPGSV,2,2,5,9,6,100,,8*56,,,,,,,,,,,,
$GLGSV,2,1,8,66,12,39,19,82,36,21,22,73,33,309,24,80,49,239,24,1*7D
$GLGSV,2,2,8,79,15,182,23,83,38,318,20,67,32,90,21,68,19,145,24,1*72
$GAGSV,2,1,8,2,19,161,22,3,15,136,18,5,14,85,21,13,15,260,21,7*71
$GAGSV,2,2,8,15,55,304,21,27,42,305,24,30,62,202,24,36,0,0,,7*7C
$GAGSV,2,1,8,2,19,161,17,3,15,136,16,5,14,85,24,15,55,304,24,1*7E
$GAGSV,2,2,8,27,42,305,17,30,62,202,22,13,15,260,,36,0,0,,1*7E
$GNGSA,A,3,2,6,9,14,17,19,20,24,28,,,,0.8,0.5,0.6,1*32,,
$PSSGR,GSA,A,2,6,,,,,,,,,,,,0.8,0.5,0.6,1,8*49
$GNGSA,A,3,66,67,68,73,79,80,83,,,,,,0.8,0.5,0.6,2*3F,,
$GNGSA,A,3,2,5,13,15,27,30,,,,,,,0.8,0.5,0.6,3*3F,,
$PSSGR,GSA,A,2,305,315,330,,,,,,,,,,0.8,0.5,0.6,3,1*75
$GNVTG,,T,,M,0,N,0,K,A*3D,,,,,,,,,,,
$GNDTM,P90,,0.000021,S,0.000002,E,0.989,W84*57,,,,,,,,,,,,
$GNRMC,181846,A,2804.27565,N,8225.599374,W,0,,140621,3.1,W,A,V*7A,,,,,,,
$GNGNS,181846,2804.27565,N,8225.599374,W,AAANNN,22,0.5,9.1,-24,,,V*1E,,,,,,,
$GNGGA,181846,2804.27565,N,8225.599374,W,1,12,0.5,9.1,M,-24,M,,*42,,,,,,
$PSMSG,tech=0x9,sensor=0x3,accu=11.594639,h_rel=3,speed=0.000000,time=1623694726000,magcal=PASS,SV_used=25,l5=1,e5=3*00,,,,,,,,,,
$BDMSG,ENGI_MSG,RPUSH,00001*00,,,,,,,,,,,,,,,,,
$GPGSV,3,1,11,2,51,280,33,5,3,203,18,6,64,346,27,9,6,100,16,1*6D
$GPGSV,3,2,11,12,24,319,12,14,26,151,20,17,38,73,21,19,52,43,21,1*6F
$GPGSV,3,3,11,20,6,207,14,24,14,265,18,28,45,153,26,1*53,,,,
$GPGSV,2,1,5,6,64,346,21,14,26,151,19,24,14,265,16,3,1,34,,8*61
$GPGSV,2,2,5,9,6,100,,8*56,,,,,,,,,,,,
$GLGSV,2,1,8,66,12,39,19,82,36,21,16,73,33,309,24,80,49,239,21,1*7F
$GLGSV,2,2,8,79,15,182,23,83,38,318,20,67,32,90,21,68,19,145,24,1*72
$GAGSV,2,1,8,2,19,161,23,3,15,136,18,5,14,85,19,13,15,260,21,7*7B
$GAGSV,2,2,8,15,55,304,21,27,42,305,20,30,62,202,23,36,0,0,,7*7F
$GAGSV,2,1,8,2,19,161,17,3,15,136,16,5,14,85,20,15,55,304,24,1*7A
$GAGSV,2,2,8,27,42,305,17,30,62,202,22,13,15,260,,36,0,0,,1*7E
$GNGSA,A,3,2,6,9,14,17,19,20,24,28,,,,0.8,0.5,0.6,1*32,,
$PSSGR,GSA,A,2,6,,,,,,,,,,,,0.8,0.5,0.6,1,8*49
$GNGSA,A,3,66,67,68,73,79,80,82,83,,,,,0.8,0.5,0.6,2*35,,
$GNGSA,A,3,2,5,13,15,27,30,,,,,,,0.8,0.5,0.6,3*3F,,
$PSSGR,GSA,A,2,305,315,330,,,,,,,,,,0.8,0.5,0.6,3,1*75
$GNVTG,,T,,M,0,N,0,K,A*3D,,,,,,,,,,,
$GNDTM,P90,,0.000021,S,0.000002,E,0.989,W84*57,,,,,,,,,,,,
$GNRMC,181847,A,2804.275653,N,8225.599376,W,0,,140621,3.1,W,A,V*7A,,,,,,,
$GNGNS,181847,2804.275653,N,8225.599376,W,AAANNN,23,0.5,9.1,-24,,,V*1F,,,,,,,
$GNGGA,181847,2804.275653,N,8225.599376,W,1,12,0.5,9.1,M,-24,M,,*42,,,,,,
$PSMSG,tech=0x9,sensor=0x3,accu=11.471963,h_rel=3,speed=0.000000,time=1623694727000,magcal=PASS,SV_used=26,l5=1,e5=3*00,,,,,,,,,,
$BDMSG,ENGI_MSG,RPUSH,00002*00,,,,,,,,,,,,,,,,,
$GPGSV,3,1,11,2,51,280,34,5,3,203,17,6,64,346,26,9,6,100,16,1*64
$GPGSV,3,2,11,12,24,319,12,14,26,151,20,17,38,73,18,19,52,43,19,1*6E
$GPGSV,3,3,11,20,6,207,14,24,14,265,18,28,45,153,27,1*52,,,,
$GPGSV,2,1,5,6,64,346,20,14,26,151,15,24,14,265,16,3,1,34,,8*6C
$GPGSV,2,2,5,9,6,100,,8*56,,,,,,,,,,,,
$GLGSV,2,1,8,66,12,39,19,82,36,21,16,73,33,309,24,80,49,239,21,1*7F
$GLGSV,2,2,8,79,15,182,21,83,38,318,20,67,32,90,19,68,19,145,24,1*7B
$GAGSV,2,1,8,2,19,161,24,3,15,136,10,5,14,85,19,13,15,260,19,7*7F
$GAGSV,2,2,8,15,55,304,21,27,42,305,23,30,62,202,26,36,0,0,,7*79
$GAGSV,2,1,8,2,19,161,17,3,15,136,16,5,14,85,23,15,55,304,24,1*79
$GAGSV,2,2,8,27,42,305,14,30,62,202,23,13,15,260,,36,0,0,,1*7C
$GNGSA,A,3,2,6,9,14,17,19,20,24,28,,,,0.8,0.5,0.6,1*32,,
$PSSGR,GSA,A,2,6,,,,,,,,,,,,0.8,0.5,0.6,1,8*49
$GNGSA,A,3,66,67,68,73,79,80,82,83,,,,,0.8,0.5,0.6,2*35,,
$GNGSA,A,3,2,3,5,13,15,27,30,,,,,,0.8,0.5,0.6,3*3C,,
$PSSGR,GSA,A,2,305,315,330,,,,,,,,,,0.8,0.5,0.6,3,1*75
$GNVTG,,T,,M,0,N,0,K,A*3D,,,,,,,,,,,
$GNDTM,P90,,0.000021,S,0.000002,E,0.989,W84*57,,,,,,,,,,,,
$GNRMC,181848,A,2804.275656,N,8225.599375,W,0,,140621,3.1,W,A,V*73,,,,,,,
$GNGNS,181848,2804.275656,N,8225.599375,W,AAANNN,24,0.5,9.1,-24,,,V*11,,,,,,,
$GNGGA,181848,2804.275656,N,8225.599375,W,1,12,0.5,9.1,M,-24,M,,*4B,,,,,,
$PSMSG,tech=0x9,sensor=0x3,accu=11.457834,h_rel=3,speed=0.000000,time=1623694728000,magcal=PASS,SV_used=27,l5=1,e5=3*00,,,,,,,,,,
$BDMSG,ENGI_MSG,RPUSH,00001*00,,,,,,,,,,,,,,,,,
$GPGSV,3,1,11,2,51,280,33,5,3,203,17,6,64,346,26,9,6,100,16,1*63
$GPGSV,3,2,11,12,24,319,12,14,26,151,20,17,38,73,18,19,52,43,19,1*6E
$GPGSV,3,3,11,20,6,207,14,24,14,265,18,28,45,153,24,1*51,,,,
$GPGSV,2,1,5,6,64,346,20,14,26,151,15,24,14,265,16,3,1,34,,8*6C
$GPGSV,2,2,5,9,6,100,,8*56,,,,,,,,,,,,
$GLGSV,2,1,8,66,12,39,19,82,36,21,16,73,33,309,24,80,49,239,23,1*7D
$GLGSV,2,2,8,79,15,182,21,83,38,318,20,67,32,90,19,68,19,145,23,1*7C
$GAGSV,2,1,8,2,19,161,24,3,15,136,10,5,14,85,21,13,15,260,19,7*74
$GAGSV,2,2,8,15,55,304,21,27,42,305,23,30,62,202,25,36,0,0,,7*7A
$GAGSV,2,1,8,2,19,161,17,3,15,136,16,5,14,85,23,15,55,304,24,1*79
$GAGSV,2,2,8,27,42,305,14,30,62,202,23,13,15,260,,36,0,0,,1*7C
$GNGSA,A,3,2,6,9,14,17,19,20,24,28,,,,0.8,0.5,0.6,1*32,,
$PSSGR,GSA,A,2,6,,,,,,,,,,,,0.8,0.5,0.6,1,8*49
$GNGSA,A,3,66,67,68,73,79,80,82,83,,,,,0.8,0.5,0.6,2*35,,
$GNGSA,A,3,2,3,5,13,15,27,30,,,,,,0.8,0.5,0.6,3*3C,,
$PSSGR,GSA,A,2,305,315,330,,,,,,,,,,0.8,0.5,0.6,3,1*75
$GNVTG,,T,,M,0,N,0,K,A*3D,,,,,,,,,,,
$GNDTM,P90,,0.000021,S,0.000002,E,0.989,W84*57,,,,,,,,,,,,
$GNRMC,181849,A,2804.275656,N,8225.599374,W,0,,140621,3.1,W,A,V*73,,,,,,,
$GNGNS,181849,2804.275656,N,8225.599374,W,AAANNN,24,0.5,9.1,-24,,,V*11,,,,,,,
$GNGGA,181849,2804.275656,N,8225.599374,W,1,12,0.5,9.1,M,-24,M,,*4B,,,,,,
$PSMSG,tech=0x9,sensor=0x3,accu=11.248057,h_rel=3,speed=0.000000,time=1623694729000,magcal=PASS,SV_used=27,l5=1,e5=3*00,,,,,,,,,,
$BDMSG,ENGI_MSG,RPUSH,00000*00,,,,,,,,,,,,,,,,,
$GPGSV,3,1,11,2,51,280,33,5,3,203,17,6,64,346,25,9,6,100,16,1*60
$GPGSV,3,2,11,12,24,319,12,14,26,151,20,17,38,73,18,19,52,43,19,1*6E
$GPGSV,3,3,11,20,6,207,14,24,14,265,18,28,45,153,25,1*50,,,,
$GPGSV,1,1,4,6,64,346,20,14,26,151,15,24,14,265,16,3,1,34,,8*6E
$GLGSV,2,1,8,66,12,39,19,82,36,21,16,73,33,309,24,80,49,239,24,1*7A
$GLGSV,2,2,8,79,15,182,21,83,38,318,20,67,32,90,19,68,19,145,25,1*7A
$GAGSV,2,1,8,2,19,161,24,3,15,136,10,5,14,85,21,13,15,260,19,7*74
$GAGSV,2,2,8,15,55,304,16,27,42,305,22,30,62,202,23,36,0,0,,7*79
$GAGSV,2,1,7,3,15,136,16,5,14,85,20,15,55,304,24,27,42,305,14,1*7F
$GAGSV,2,2,7,30,62,202,21,13,15,260,,36,0,0,,1*41,,,,
$GNGSA,A,3,2,6,9,14,17,19,20,24,28,,,,0.8,0.5,0.7,1*33,,
$PSSGR,GSA,A,2,6,,,,,,,,,,,,0.8,0.5,0.7,1,8*48
$GNGSA,A,3,67,68,73,79,80,82,83,,,,,,0.8,0.5,0.7,2*34,,
$GNGSA,A,3,2,3,5,13,15,27,30,,,,,,0.8,0.5,0.7,3*3D,,
$PSSGR,GSA,A,2,305,315,330,,,,,,,,,,0.8,0.5,0.7,3,1*74
$GNVTG,,T,,M,0,N,0,K,A*3D,,,,,,,,,,,
$GNDTM,P90,,0.000021,S,0.000002,E,0.989,W84*57,,,,,,,,,,,,
$GNRMC,181850,A,2804.275656,N,8225.599374,W,0,,140621,3.1,W,A,V*7B,,,,,,,
$GNGNS,181850,2804.275656,N,8225.599374,W,AAANNN,23,0.5,9.1,-24,,,V*1E,,,,,,,
$GNGGA,181850,2804.275656,N,8225.599374,W,1,12,0.5,9.1,M,-24,M,,*43,,,,,,
$PSMSG,tech=0x9,sensor=0x3,accu=11.150235,h_rel=3,speed=0.000000,time=1623694730000,magcal=PASS,SV_used=26,l5=1,e5=3*00,,,,,,,,,,

[vkbellis]

@gdt Greg - The gross errors are not being created by GPSTest and nobody that I know thinks so. Most of the apps I've tested don't display orthometric heights (H), and most of them do display ellipsoid heights. All of the ellipsoid height (h) values are reasonably commensurate with the non-survey grade GNSS smartphone receiver and poor antenna.

See this article I just finished: What's Up with Android's Heights.pdf and note the local datum is P90 with its lat, long and alt offsets from WGS84.

[gdt]

If this is about the phone not GPSTest, that's fine, but perhaps would be good to edit the issue title to "Samsung A71 GNSS receiver has strange/wrong output". As it is, it looks like the report is about GPSTest doing something incorrect.

So your phone is doing two very strange things. One is that while you are in the US, it is using a datum that I haven't heard of and can't find in the EPSG dataset (PE90, it seems is what P90 refers to - I wonder if this is supposed to be PZ90?). Looking at the offsets in the GNDTM sentence, and doing math perhaps badly, it seems like sub-decimeter in lat/lon and sub-meter in vertical, which doesn't explain anything.

The second strange thing is that the geoid separation seems very wrong, more so than any GNSS receiver geoid model that have ever seen. Previously, I thought the 4m u-blox error was bad.

FWIW, on a Pixel XL, I see -33.0 in the geoid offset field, plausible HAE/ortho heights (given the 4m geoid model error), and no DTM sentence.

I wonder what would happen if you filed a bug with samsung or qualcomm....

[gdt]

It seems @vkbellis has already done this, more or less confirming that the HAE computed off-phone by raw observables matches the HAE inferred from the phone's NMEA ortho height and geoid offset. If true, that more or less implies that the phone's chipset is computing XYZ and then lat/lon/hae correclty, and then applying the bad geoid model. I am curious what you think of that theory.

[vkbellis]

As you've noted here Greg, the issue of odd geoid models is not limited to one particular OEM or one particular model. On an old Moto E4 Plus, MediaTek MT6737 chipset (GPS only) had its own bizarre geoidal separation (N) value that was not close to a known geoid model. In the S21+ NMEA stream just shared by Sean above, the geoidal separation (N) value of -24 m looks just as reasonable as the value in his circa November 2016 LG G5. This is why I think it would be good if folks start sharing NMEA snippets #523

P90 is the NMEA 3-character abbreviation for the PE-90 frame (loosely Parameters Earth 1990) related to GLONASS with an Anglicization of Parametry Zemli; i.e., PZ-90, currently at PE-90.11 (EPSG: 7679)

[vkbellis]

@barbeau Thank you for posting the snippet (above). There are some NMEA sentences with extraneous information after the checksum; i.e., 2-charater hexadecimal, for example, ` $GNDTM,P90,,0.000021,S,0.000002,E,0.989,W8457,,,,,,,,,,,, $GNGNS,181842,2804.275596,N,8225.599397,W,AAANNN,20,0.5,9.2,-24,,,V1F,,,,,,, $GNGGA,181842,2804.275596,N,8225.599397,W,1,12,0.5,9.2,M,-24,M,,41,,,,,, `

Any idea what this means?

[gdt]

Thanks for explaining P90/PE90. I didn't realize people used PE-90 as an Anglicization for PZ-90. But, I think that's (in modern realizations) now close to ITRF2008 or similar, and thus while it is truly strange to have output in that frame, I don't see that it should have much to do with what we're seeing. (I have long wondered how GNSS manufacturers dealt with the multiple frames involved in multiconstellation solutions). I wonder if GLONASS/PZ-90 has an associated geoid model, but I would think that PZ-90 has a W_0 that is very close to WGS84's and thus there would be only minor differences.

Your #523 is a great suggestion. I had no idea things were as messy as they are.

[barbeau]

There are some NMEA sentences with extraneous information after the checksum; i.e., * 2-charater hexadecimal

@vkbellis I believe the value after the * is the checksum? See https://github.com/barbeau/gpstest/issues/71#issuecomment-263169174.

Or are you asking why there are commas without values appearing after the checksum? If that's the case, 🤷.

[barbeau]

FYI, a Google Pixel 5 has the same P90 and W84 values in the GNDTM NMEA string.

[gdt]

I asked a friend to check Pixel 5 output, and the DTM string matches the example above exactly (same offsets, and same checksum). The Pixel 5 is reporting a geoid separation of -33m, which is the same wrong value that I've seen on a Pixel XL and on a u-blox F9P, vs -29m right answer ~Boston. A Pixel XL has no DTM strings.

So it seems

• Pixel XL has the "mild geoid bug"
• Pixel 5 has the "DTM bug" and the "mild geoid bug"
• Samsung S21 has the "DTM bug" seems to have the "mild geoid bug"
• Samsung A71 has the "DTM bug" and the "bad geoid bug"

It might be that all the phones with L1/L5 chips are QualComm 765. It would be interesting to know of a phone that had dual-frequency GNSS that doesn't have that chip, or if any phone with that chip doesn't exhibit the DTM bug.

So far, the Samsung A71 is the only phone reported with the "bad geoid bug". (Sad that "only 4m off for no apparent reason" is being binned into "not that bad".)

[vkbellis]

@gdt - PZ-90/ PE-90 is indeed an interesting discovery as being QCOM's assigned Local Datum as revealed through the DTM sentence. And I also agree, QCOM's choice of geoid model is a disparate issue. Whether or not the OEM modifies either is difficult to say without evidence from real data.

@barbeau - I was referring to any information appearing after the 2-charater hexadecimal checksum, not being limited to a comma delimiter. The question arose 1) because the NMEA 0183 standard states the end of the sentence is the asterisk followed by the 2-charater hexadecimal checksum, followed by carriage return line feed; 2) in GPSTest's aggregated log, I've noticed sundry appending characters between the checksum and the carriage return line feed, and is what made me to wonder if you knew why.

@gdt and @barbeau - Thank you both for looking at other phones and noting similar DTM sentences.

@gdt - Limiting discussion to smartphone GNSS receivers, and lacking sufficient data, we only know 1) that the ellipsoidal height (h) values are looking reasonable in the context of this type of device; 2) that the device's reported geoidal separation (N) values and the device's reported orthometric height (H) are both, sometimes quite significantly, off from well known and proven values.

Kind regards,

Kelly

[gdt]

I agree that your data shows that h is reasonable for the 765 chipset, and that N and H are both wrong. Surely the receiver is computing XYZ and then lat/lon/h. My impression about Android is that the interface from the GNSS chip to the OS is an NMEA stream which reports H and N, and the os then backs out N to get h. I have never seen any OS/combo (even with reading NMEA in the app) report h/N/H that aren't self-consistent, and as I read your comments I don't think you have either. So it seems likely that the basic issue is a bad geoid model leading to wrong N, and the bad H follows from that as a computation from h.

[gdt]

It's also an interesting question about the bad N over space. I have a data point that a Pixel 5 near Boston has the mildly-wrong N, and you have one that a Samsung has a very-wrong H in Maine. What would be really interesting is to know of other very-wrong H values.

[vkbellis]

@gdt - You're correct, gravity varies widely from place to place, nearly 200 meters across the planet:

Hipsometric Coversation.pdf

Here in the USA, the newest and purely gravimetric geoid model will soon be officially released. Experimental xGEOID20B is an early peak at this part of our National Spatial Reference System and what will be likely called GEOID2022. Below is a portion of it covering just the lower 48. In it, and in lieu of the traditional atlas shader, I've chosen the full Sherwin-Williams color chart to illustrate the gradients more clearly. The model's actual grid points are spaced at 1.66666666666666664E-002 degree.

As for the chipset-based geoid model being solely responsible for the height issues, more data and study is needed.

[gdt]

Android seems pretty firmly in the land of WGS84, so while NGS's new geoids and the new 2022 datums are very interesting, the defintion of right in Android is EGM2008 until NGA releases a new WGS84 referencing a new EGM. Perhaps xGeoid20B has the same W_0 so it intends to be aligned. But all of the issues we are seeing are 20 dB less subtle than that.

As I see it, we have significant evidence that there are bad chipset-produced geoid values, many data points of h/H/N where the three are self-consistent but N is off, and no evidence that there is anything else going out besides bad N values. So "chipsets have bad geoid models is the basic problem we are dealing with" is my working hypothesis until I see conflicting evidence.

I'm quite willing to change my views based on evidence. Earlier I thought "nobody would be crazy enough to have a US-designed chipset in phones sold for use in the US by a US company report positions in a Russian frame". Now I believe it happened. I still have no idea of why. Since you're a customer, please file a bug with the manufacturer and let us know how that goes.

[barbeau]

I agree with @gdt that filing a bug is the best next step here. Thanks to you both for your insight into this issue.

@vkbellis if you want to file a bug with Samsung, I can file one with Google for the Pixel 5. Google has been pretty responsive lately with location issues so I have more confidence in them responding than Samsung.

[vkbellis]

@gdt - Why do you say Earth Geopotential Model 2008 is the gravity model being used and why do you think this is defined by the OS?

Also, would you be willing to share a couple of minutes worth of a static setup under open sky NMEA log and 1) a screenshot of GPSTest's Status screen near the end of your setup and 2) a screenshot from GPSTest's Help, About screen? I need the setup's position, so if you have a privacy concern, do this in a public place. Thank you Greg for considering to help with this.

@barbeau - I need to concurrently open tickets with the three amigos; Google, Qualcomm, and Samsung, as soon as time allows as I still have some additional studying to do beforehand. Any ticket-opening help you can lend would be very much appreciated. Thank you Sean for your kind offer.

I really wish we had more case data from different GNSS chipset manufacturers and OEMs for many reasons. Like the reporting of misinformation concerning GNSS antenna information, we don't know how pervasive these discoveries apply across the spectrum of mobile devices

[gdt]

More or less, I think it's obvious that a (navigation-type) GPS receiver should natively operate in WGS84. WGS84 incorporates by reference a gravity model, currently EGM2008, as the definition of WGS84 orthometric height; I have confirmed this understanding indirectly with someone at NGA via a friend who does gravity models professionally. It's also more or less obvious that the chipsets in phones, similar to standalone receivers like a Garmin Etrex 30, or a u-blox F9P, ought to be reporting in WGS84 and WGS84 orthometric height, as datums that are global in scope. The F9P is documented to use EGM96 with a caution that it's low resolution.

The Android spec exists in the context of this universal practice for GPS receivers to use WGS84 orthometric height as their "height above mean sea level". The actual spec says, bizarrely, that altitude is WGS84 HAE: https://developer.android.com/reference/android/location/Location#getAltitude() and there is no OS support for orthometric height. But lots of apps read the NMEA (with an API that just says it returns NMEA), and an NMEA stream of positions, for normal people, in 2020, should be in WGS84 lat/lon/ortho-height. To do otherwise strikes me as very strange and I'm not aware of any practice of doing otherwise, at least any practice that wouldn't be regarded as confused.

(Note that I'm avoiding the issue of WGS84(G1762), ITRF2008, PZ90.11, and other frames all being more or less the same at the cm level, and ignoring old WGS84 as no longer relevant. Basically the world datums have all aligned to ITRF.)

I am unaware of any associated geoid models with ITRF2008 , PZ90.11, the Galileo frame or the Chinese frame, in the sense that datum documents specifically refer to them.

To turn it around: Can you provide any example of a navigation-type GNSS receiver computing autonomous positions (or even with SBAS) and outputting elevations in the normal/default configuration that are documented to be other than some flavor of the the WGS84-associated EGMs?

I agree that one can use GPS to measure positions in NAD83 lat/lon/h, and that one can use hybrid geoids to find heights in national datums like NAVD88 and that the 2022 US datums are fun to nerd out about. But in all my years of playing with GPS receivers since about 1992, I have never seen one intend to report heights in other than WGS84 orthometric height. I have done RTK with an F9P with nad83(2011) reference, backed out the F9P's low-accuracy EGM96 and then converted to NAVD88 to compare to an actual benchmark. But that's not what a phone is doing for normals.

[barbeau]

Issue opened with Google for the Pixel 5 here: https://issuetracker.google.com/issues/191674805

@gdt and @vkbellis Please review and feel free to comment if I got any of the details wrong :).

[gdt]

Thanks for filing. That ticket can't be read without a google account. I did read the linked ticket, and I don't follow if you are suggesting this be added to AOSP or to the proprietary google maps API. In talking about network lookups, you object to them on the basis of data usage, but a far more serious problem is privacy.

This is a difficult subject with respect to terminology, and I would advise that you stick with two terms:

• WGS84 Height Above Ellipsoid (what GPS natively calculates and what is in the Android API)
• WGS84 Orthometric Height (where delta to HAE is defined by EGM2008)
• Note that I left out "WGS84 Altitude" because there is no formal definition for it, and some think it means HAE and some think it must be WGS84 orthometric height, because obviously all altitudes are gravity-based and referenced to some equipotential (or an approximation, e.g. NAVD88). I therefore more or less think that no one should ever use the term WGS84 Altitude when one can use the right number of words. (I still think GUIs should have the label "HAE" and "AMSL" for HAE and the EGM2008-defined heights, because while AMSL is fuzzy, it gives the right impression.)

I don't like "MSL" because while there is a global mean sea level at any point, that's not accessible, and it varies. Orthometric height systems aren't actually referenced definitionally to MSL; they are referenced to values that were thought at the time of defining the system to be good approximations. So it's ok when saying something fuzzy to people that don't understand, but it blurs careful discussions.

It's obvious that a coarse approximation to EGM2008 is entirely feasible in a phone. There are implementations out there in other Android programs (see opentracks). What may be unclear to many is that the EGM approximations in GPS receivers are not nearly as good as one would expect.

[vkbellis]

@gdt - I agree, that in theory and at present, the EGM2008 model is implicit when when speaking in general about WGS84; however, my very limited dataset from tests on just the Samsung A71 is nowhere near conforming with any known geoid model.

You've mentioned it in a couple of your remarks, but I don't know what you mean when you say W_0 - please define this term for me. Thanks!

@barbeau - Thank you for doing this Sean. Great points made under the heading Alternate solutions. I'm so glad you're involved with this from the perspective of developer! One very minor comment after a very quick reading, N's value of -24 got its algebraic sign dropped in 2 places.

FYI, and FWIW, yesterday afternoon I posted this: https://issuetracker.google.com/issues/191375130

Kind regards,

Kelly

[gdt]

@vkbellis Yes, your A71 is strange. But I think almost all of the probability is on "your device is buggy" and very little is on "it is a somehow non-buggy implementation of some geoid model we don't know about, and if they only specified it, it would be ok". Because all geoid models intend to have some resemblance to average sea level, a model that is 20m different from EGM2008 is not plausible. Arguing about a meter or maybe two is about what I'd expect.

W_0 (subscript) is the geopotential of the reference surface. A geoid by definition is a surface of constant geopotential, and it's expressed by the distance from the surface of that constant potential to the ellipsoid of some datum. So with a datum and a specfied potential, everything else is just measurement and representation of approximations that intend to describe that reality. in WGS84, one of the defining constants of the datum is GM, the gravitational constant times the mass of the earth (the product is know to greater accuracy than either). See NGA.STND.0036_1.0.0_WGS84, the G1762 version, 2014-07-08. See page 3-3 for GM. Then, see page 3-10 for U_0. They use U_0, but NGS in NAPGD2020 uses W_0 for the same quantity. This is the geopotential at a height of 0m in a particular geoid model.

Note that all of this is about gravimetric geoid models that are entirely about gravity, such as EGM2008 or xGEOID20. In contrast, hybrid geoid models like GEOID18 are the difference between the NAVD88 0m surface and the ellipsoid. Because NAVD88 is defined by passive marks and history, the NAVD88 0m surface is not a surface of constant geopotential. Thus, GEOID18 has no W_0. And GEOID18 - xGEOID20 is the difference between NAVD88 0m and xGEOID20's W_0 surface, which is more or less a map of the error in NAVD88.

[gdt]

See also

• https://www.ngs.noaa.gov/PUBS_LIB/EGM96_GEOID_PAPER/egm96_geoid_paper.html
• https://en.wikipedia.org/wiki/Geopotential

[barbeau]

Some interesting info in the response from Google on the AOSP issue tracker on how Qualcomm has implemented the geoid model that generates the values we see in the NMEA data: https://issuetracker.google.com/issues/191674805#comment8

Based on our understanding of the 1st question "the several meters off on GS", This is because our SW uses 2D interpolation from the 10 degrees x 10 degrees table (due to the ROM constraint), and the majority of the error seems to be from the coarse granularity of the table.

So sounds like the model is at the 10 degree resolution, and the N (geoid height value) is then linearly interpolated between these values. So they are blaming lack of precision for the differences between -24 (value from chipset) and the values -26.9576, -27.3398, or -26.4920 (EGM2008, EGM96, or EGM84). Google says "no easy fix yet".

This being the case, though, it's curious that the interpolated value is exactly -24 - maybe they are rounding too?

Note that they've acknowledged the P90 error too in the same comment:

For issue#2 (wrong local datum of P90 being returned in NMEA), Qualcomm has provided a fix and we will merge it in Dec QPR.

So the way I read this is that WGS84 is being used internally and the output of the string P90 is the error, and the error in the N value is purely from lack of precision (?).

[gdt]

@barbeau Great that you got a response. I have seen -33.1 around me, and my impression is that rounding is to 0.1m (which given everything else is not crazy). I have long heard that the reduced-resolution model in receivers is EGM96; while EGM2008 is correct now, the delta between those two seems small compared to 10x10 grid error. FWIW, I have not really heard of anyone using EGM84, so I think that's now just of historical interest.

[vkbellis]

Any ideas as to what is meant by GS referenced in "the several meters off on GS" ?

We still don't know which gravity model that's being used by Qualcomm, but at least there is an indication/ admission that it is defined by the chip maker and not the OS. It also isn't clear the nature of the "ROM constraint"; is it the size of the gridded file?; is it a computational constraint?

What is Dec QPR? Whatever it is, I guess Pixel 5 users will be getting it eventually while the rest of us... who knows?

[barbeau]

Any ideas as to what is meant by GS referenced in "the several meters off on GS" ?

"Geographic system", maybe?

It also isn't clear the nature of the "ROM constraint"; is it the size of the gridded file?; is it a computational constraint?

Yes, I assume it's primarily the size of the file, which does have implications on time required to parse it - but size being the primary obstacle.

What is Dec QPR?

I assume the monthly security patch updates that go out for Android devices - so December release target.

but at least there is an indication/ admission that it is defined by the chip maker and not the OS.

What's interesting about this is that Google will need their own geoid solution within Tensor in the upcoming Pixel 6. It will be interesting to see what those devices look like. I haven't heard anything about whether this chip will have GNSS processing on-board or if they will integrate something like a BCM47765 in addition. IMHO from the announcement at the end of last year it could go either way: https://android-developers.googleblog.com/2020/12/improving-urban-gps-accuracy-for-your.html

That could have been a trial run for integration of a BCM47765, or it could have been Google using this as a learning process for integration with their own hardware.

[barbeau]

FYI, for anyone who wants to see a reliable first-class Android API to get the H and N values directly from the platform (vs parsing NMEA sentences or bundling your own geoid model), please star my feature request to Google here: https://issuetracker.google.com/issues/195660815

[barbeau]

@vkbellis In case you missed it, Google is asking for the NMEA data you used to produce the graphs in https://issuetracker.google.com/issues/191674805#comment16. Qualcomm wants to see it to do more tests on the other devices.

[vkbellis]

Hey Sean, thanks for the heads up. I've replied to Google, though quite frankly find their lack of focus and chronically delayed responses are not very promising. This unfortunately discourages participants from offering to help them.