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

[Gary E. Miller]

Yo Greg!

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.

>   a DTM statement that says positions are in PZ-90, the grame used for
>   GLONASS.

OMG, let us not go near PX-90...

> At least DTM has been observed in both Samsung phones and a Google
> Pixel 5, and perhaps both have the Qualcomm 765 (5G, and
> dual-frequency GPS).

Kill it before it spreads.

> 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

> full thread at
> 
>   https://github.com/barbeau/gpstest/issues/503

I'm scared to go there.

> I wonder if anyone has seen a DTM sentence,

Yes.

> and if so what it
> contained.

Usually WGS84, the NMEA default.  From the gpsd regression tests:

test/daemon//saab-r4.log:$GPDTM,W84,C*52

> 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.

> 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.

> 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).

> 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.

> Has anybody seen this?

Yes, hard to unsee.

> 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.

>  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.

> 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.

>  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.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgpeTBLyLi9kn.pgp
Description: OpenPGP digital signature