Re: Duplicate or near-duplicate messages on u-blox M8

[Gary E. Miller]

Yo Luke!

On Wed, 26 Feb 2020 02:33:31 -0700
Luke Hutchison <address@hidden> wrote:

> I'm having an issue with the u-blox M8 GPS receiver with gpsd. I
> followed the advice in the gpsd FAQ and reported a bug through the
> web form, but figured I'd post the same info here since that form
> says submitters will probably not get a response.

What directed you to the web form?  I don't even know where that goes
anymore.  Send us the URL and I'll get that excised.  We have been using
gitlab issues for a while now:

https://gitlab.com/gpsd/gpsd/issues

Here is our current doc on support:

https://gpsd.io/SUPPORT.html

> The u-blox M8 device delivers location updates to gpsd clients roughly
> twice per second,

Which M8 device? There are many, they perform differently.  2Hz by
default would be odd.

> but each update comes in clusters of two or three
> update messages (i.e. twice a second, either two or three updates all
> show up in the GPS client -- xgps or cgps -- in quick succession).

Do not mistake what cgps shows for what the M8 is sending. gpsd listens
to the receiver, and sends updates when it can.  Note the dynamic
tension between reporting each incoming TPV tidbit ASAP, and waiting
until all TPV data for a cycle is in and only reporting once.

> These messages are near-duplicates, except that the altitude seems to
> swing up and down.

What version gpsd?  Altitude handling was funcky until very recently.

Be sure you are using at least 3.19.

> Here is an example of output captured from the cgps display:

Not useful.

> Here are the lat, long and altitude fields extracted for easy
> plotting:

Not useful.

> If you plot each of the three as a time series using a line plot, you
> will see that lat and long update "stepwise" -- the value will stay
> almost (but not exactly) the same between two or three updates, then
> will step up or down, then will go back to staying almost (but not
> exactly the same) for the next update.

Yeah, it can happen.  Without your raw data, no way to know what is
happening.

> Meanwhile the altitude is
> oscillating up and down by a couple of meters every two or three
> updates.

Which might be the bug fixed in 3.19.  Is the delta equal to your geoid
separation?

> I'm not the only one who ran into this sort of issue on the u-blox M8,
> although the proposed client patch does not address the underlying
> issue in gpsd:
> 
> https://github.com/swri-robotics/gps_umd/issues/14
> https://github.com/ros-drivers/gps_umd/issues/3

Uh, this is gpsd.  What is gps_umd?  Why do we care about gps_umd here
at gpsd?

> Anyone have any ideas about this?

Many, but you did not send the data we need:

What is your version of gpsd?  How did you install it?  From package,
from source?  What exact model of receiver?  How did you configure the
receiver?

> Here are two logs, one captured before gpsd had a chance to
> initialize the u-blox M8, and one captured after gpsd had run and
> initialized the device:
> 
> https://pastebin.com/ksneY0yz

How did you capture those two logs?  The prefered method is: 
    gpspipe -R -n 100 > raw.log

Hard to say without knowing how you captured the logs, but it looks
like plain NMEA 1Hz data.  Which is never what people expect...

Notice the fractional seconds is always zero:

$GNRMC,072856.00
              ^^

$GNGGA,072856.00,
              ^^

$GNRMC,072857.00
              ^^

So clearly 1Hz data.  Your JSON capture also shows clearly 1Hz data:

[...]
"time":"2020-02-26T07:40:41.000Z
[...]
"time":"2020-02-26T07:40:41.000Z
[...]
"time":"2020-02-26T07:40:42.000Z
[...]
"time":"2020-02-26T07:40:42.000Z

You are getting doubles because you are using NMEA (discouraged) and the
NMEA trickles in the TPV data.  So gpsd reports ASAP when it gets sufficient
data for a TPV, then again after it has an entire cycle of data.  That
cuts the baby in half for those that want TPV ASAP, and for those that want
the TPV data in one place.



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

pgpaXGrKxnNKm.pgp
Description: OpenPGP digital signature