Re: DTM sentence and Russian datums in US phones (yes, that's clickbait!)

[Greg Troxel]

"Gary E. Miller" <gem@rellim.com> writes:

> On Wed, 16 Jun 2021 21:29:25 -0400
> Greg Troxel <gdt@lexort.com> wrote:
>
>> Over at GPSTest (and Android program for telling you what your GNSS
>> chip is doing), people report that some phones have strange
>> elevations, and digging in there appear to be be two notable oddities:
>> 
>>   geoid models that are wrong to a degree even more surprising than
>>   u-blox's reporting of -33m when it should be -29m.
>
> Different geoid models differ from each other by up to 200m.  Before
> you ccan compare geoids you need to know which geoid.  WGS84 is not
> a geoid, it is a framework for geoids.  You also need to know the
> year of the WGS84 data set.  Like WGS84-1984, WGS84-2004, etc.

WGS84 is a datum, but in incorporates by reference a geoid model EGM2008
which defines "WGS84 orthometric height".  What I am saying is there
there is a right answer for EGM2008, and that receivers which should be
producing EGM2008 geoid offsets are getting that wrong in the -29m/-33m
sense, and some others way worse.

>> an example is:
>> 
>>   $GNDTM,P90,,0.000021,S,0.000002,E,0.989,W84*57,,,,,,,,,,,,
>> 
>> explained, sort of, at:
>> 
>>   
>> https://www.trimble.com/OEM_ReceiverHelp/V4.44/en/NMEA-0183messages_GPDTM.html
>
> And here: https://gpsd.io/NMEA.html#_dtm_datum_reference

Which also doesn't explain what it means when "local datum" field has
the code P90 but the datum field is W84.

I also haven't found anything saying if PZ-90 has an
associated-by-definition geoid model and notion of orthometric height
(vs HAE which it straightforwardly does).

> Usually WGS84, the NMEA default.  From the gpsd regression tests:
>
> test/daemon//saab-r4.log:$GPDTM,W84,C*52

So that has only 1 field, but there are many more in all the
descriptions.  I see that as "WGS84" in the "local datum" code, and the
rest are missing/null.  But that's the default expectation anyway.

>> Certainly, I'd expect that if one put a Garmin into NAD27,
>> you'd have the transform.
>
> gpsd does no transforms.  That gets ugly fast.

Sure, but if you put a Garmin in NAD27, it does transform.  I used to
use that to look up points on paper topo maps in the 90s.

>> But today, that seems unusual (unless
>> navigating in a country with a local datum that isn't more or less
>> ITRFF2008), using local maps.  Even in the US, which has a national
>> datum, people navigate with their phones in WGS84.
>
> Except USA maps are not WGS84!  They are NAD84 and altitude in MSL.

There is no "USA maps" and there is no MSL.  There are maps from the
USGS and the National Map, which are NAD83 with heights in NAVD88.
There are older USGS maps in NAD27 and heights in NGVD29.

But when people navigate with phones, they are using maps from
Openstreetmap, Google, or Apple.  OSM is defined to be in WGS84, and
Google's TMS tiles appear to be in WGS84 (and they might even document
that).  I find Google/Apple to be opaque about metadata.

And, in New England at least NAD83/WGS84 is only ~1m different in
horizontal and NAVD88 and WGS84/EGM2008 are similarly close.  It takes
RTK to perceive that difference, and it takes really accurate maps.

>> What's funny is that PZ90.11 is so close to ITRF2008 that unless you
>> are playing at the 10 cm level or better it can be treated ~= ITF2008
>> != WGS84(G1762).
>
> And what about the other WGS84 that are > 10 cm from WGS84(G1762).

It's only the older ones that are that far off (TRANSIT and G730), and
1) nobody can get data in them any more and 2) nobody has any data in
those frames that have anywhere near sub-meter accuracy.  You just can't
observe 10 cm errors with a navigation solution.  Once you go
differential, you're in the frame of the reference station.

>> I do not believe that the frame being odd and the bad geoid model are
>> logically related, but they may both be in the same chip out there.
>
> Since the geoids change rapidly, the geoid baked into any firmware
> will diverge from what other receivers have.

EGM96 and EGM2008 are different, but when I looked them up to compare to
what the receiver had, the differences among model updates were tiny
compared to the unexplained errors.  For Boston, we're talking 30cm
going all the  way back to EGM84:
  
https://geographiclib.sourceforge.io/cgi-bin/GeoidEval?input=42+-71&option=Submit

and NW, only 1m to EGM84 and much less from EGM96.

  
https://geographiclib.sourceforge.io/cgi-bin/GeoidEval?input=45+-110&option=Submit

yet I am seeing -33 in a recent receiver.  That's not explainable as
using the previous version of the model.

>> A related question is  if anywone knows if recievers that do
>> multiconstellation solutions transform among the system's  frames, or
>> just assume all of them are ~== ITF2008.
>
> The receivers that do multi-GNSS have to convert frames, more or less.
> The current WGS84 table is now over 40MB, so do not exepct any receiver
> to get it right.

I don't know what you mean about "WGS84 table and 40 MB".

They don't have to convert; they can assume equivalence.  And, it seems
like all 4 global GNSS system frames are equivalent to a cm or so, and
that therefore, applications other than geodetic surveying, it's
sensible to treat them as equivalent.

>>  My working hypothesis is
>> that one can't really detect any errors from assuming equivalence in a
>> navigation solution
>
> My experience, and what you saw with P90, says otherwise.

Can you explain the experiment to detect?  Navigation solutions *with no
differential* have errors that are vastly more than a cm, and almost
always multiple meters.  What do you compare to what, and how do you
then say that it's because two frames that have a non-null cm-level
transform skipped that cm-level transform?

What I think people are seeing with the P90 DTM sentence is:

  inexplicable buggy behavior in choice of or reprorting of datum, which
  has not been shown to cause a perceptible error

  at the same time, not necessarily related, bad geoid model outputs

>> and that once you do RTK you are in the reference
>> stations frame anyway.
>
> Once you post process it is out of the hands of gpsd or the receiver.

Some receivers do RTK onboard.

But it's not about post process, it's about a differential solution.  If
you use WAAS, you no longer get WGS84(G1762) coordinates, but instead
the WAAS frame.  Even the non-GPS satellites are corrected to the WAAS
frame.

>>  Therefore this multiconstellation frame
>> question is of academic interest only.   Any actal info?
>
> Academic, until your car drives off the road.  All you need to do to see
> the effect is to compare different receivers at the same location.  They
> never agree.

They never do but I don't think that has anything to do with assuming
frame equivalnce when merging multiple constellations.  I think it's all
about errors in the navigation solution.  Two GPS-only receivers will
give you different answers, and we all know a track of a receiver at a
fixed point has quite a lot of a spread.  In my experience, adding
constellations makes things better, not worse.

signature.asc
Description: PGP signature