Re: [gpsd-users] Driving to tunnel with UBlox M8 did not show deadreckoning (estimated) correctly with gpspipe -r

[Gary E. Miller]

Yo Irko!

On Thu, 3 Oct 2019 20:55:39 +0300
Irko Aario <address@hidden> wrote:

> Without the gpsd running, the raw NMEA sentences from the device
> (/dev/ttyACM0) show valid looking NMEA sentences. GNGGA shows the fix
> quality as 6 Estimated (dead reckoning) as it should in the tunnel
> with UBlox M8.

Good.  What model u-blox?

> But when starting up gpsd and running gpsd -r,

gpsd has no opnt "-r'.

> the gpsd switches to
> raw mode and the GGA sentences are now generated with pseudonmea()

Yup, as designed.

> -function and they have different data compared to raw NMEA
> sentences.

Yup, the data has to be reconstructed from the binary, and often
the u-blox binary and NMEA do not agree.  Or the sentence mix is
different, or...

> The GGA messages now start with $GPGGA.

I sure hope that does not matter to you.  Trying to correlate talker
ideas in NMEA is painful.  Ignore them if you can.

> The field for fix
> quality now shows 1 or 5, although 5 should not even be possible with
> UBlox when NMEA v 4.0 was used (as was the case)

Just reporting what the u-blox binary reported.  NMEA and u-blox status
do not line up well.

> Further investigation showed that when parsing binary messages in
> driver_ubx.c they will set the session->gpsdata.status to be one of
> the following from gps.h:
> 
> STATUS_NO_FIX 0, STATUS_FIX 1, STATUS_DGPS_FIX 2, STATUS_RTK_FIX 3,
> STATUS_RTK_FLT 4, STATUS_DR 5, STATUS_GNSSDR 6, STATUS_TIME 7,
> STATUS_SIM 8

Yup.  Which maps to what most GNSS receivers use for NMEA.  Some
oddballs report 9 for NMEA status of WAAS used:

https://docs.novatel.com/oem7/Content/Logs/GPGGA.htm#GPSQualityIndicators

> But when generating pseudonmea, the status is used to generate the
> fix quality value in **GGA message. But the values do not map
> correctly to fix quality values specified in NMEA
> (https://www.gpsinformation.org/dale/nmea.htm
> <https://www.gpsinformation.org/dale/nmea.htm>), which specifies the
> following values:
> 
> 0=invalid, 1=gps fix, 2=dgps fix, 3=pps fix, 4=Real Time Kinematic,
> 5=Float RTK, 6=estimated (dead reckoning), 7=manual input mode,
> 8=Simulation mode 

Usually 3 is named "surveyed position" or "fixed position" as that is
the best mode for PPS.  You correctly mapped that to quality indicator 7.

Yup, status codes are a mess.  And that is just the first one
you looked at.  All the vendors just make up stuff.

You'll probably find more similar issues in the NMEA, very few actually
use the psuedo NMEA, best to use the JSON.  NMEA is just too ill
defined.

> The attached patch demonstrates a fix for the problem, assuming that
> I___ve understood the problem or actually the inner workings of gpsd. 

The patch looks good.  I changed a few style things.  NMEA does not
distinguish STATUS_DR from STATUS_GNSSDR.  So I changed that a tad.

"static" mode, your PPS mode, is reported by some GNSS, that needs to
get looked at.

Applied to git head.  It changed no regressions, so you found some
corner cases that no one hit until now.  If you can submit a log that
shows the problem, then I can add it to the regressions.

Thanks for the patch!

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

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

pgp7l7b4iSD6e.pgp
Description: OpenPGP digital signature