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

[Greg Troxel]

Luke Hutchison <address@hidden> writes:

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

This is the right place.   And thank you for not mangling the log lines.

> The u-blox M8 device delivers location updates to gpsd clients roughly
> twice per second, 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). These messages are
> near-duplicates, except that the altitude seems to swing up and down.

I have seen this too (M8030).  Often the positions are the same, but at
times the same-second-labeled reports have different positions.

Probably your M8 is configured for 2 Hz updates.  You should be able to
use ubxtool to check that and/or configure it for a different rate.
If you  are able to configure 1 Hz and 10 Hz GPS only (does M8 do that,
or as fast as you can), and verify that the json reports adjust to
match, that would be useful.

BTW you can use gpspipe to read the json and not do anything with it.
There are a ton of options and I don't want to discourage you from
reading the man page, but "gpspipe -w > LOG" is useful.

It is interesting to see 3 reports in some seconds.  I wonder if this is
2.5 Hz?

Somehow, since the M8 is probably configured for 2 Hz updates, it
should have a time-of-fix which has subsecond resolution, and this
should be carried all the way through.   So there is almost certainly a
bug like that.

There may also be a bug with timing, where fixes that are computed
aren't promptly carried through.  This seems unlikely, but on the other
hand we are seeing unlikely behavior.

It's also possible that the M8 is at 1 Hz and is sending binary messages
and gpsd is doing an update after one and then a second update right
away after the other one.   So capturing the raw ubx protocol and
groveling over that may help, and/or putting debugging in the ubx
protocol processing.

Beyond that, it gets much harder to figure out.  My view is that the
carrying time bug should be fixed first, and then the rest debugged; it
would not surprise me if some other issue (if it is really there) jumped
out at poeple when finding that bug and reviewing the fix.

> Here are the lat, long and altitude fields extracted for easy plotting:
>
> 40.599341900 -111.887235800 1353.380
> 40.599341398 -111.887233819 1351.587
> 40.599341400 -111.887233800 1353.421
> 40.599340695 -111.887230748 1351.525
> 40.599340700 -111.887230700 1353.357
> 40.599340700 -111.887230700 1353.357
> 40.599340758 -111.887228685 1351.609
> 40.599340800 -111.887228600 1353.439
> 40.599341244 -111.887227302 1351.792
> 40.599341300 -111.887227300 1353.626
> 40.599341300 -111.887227300 1353.626
> 40.599343038 -111.887230044 1351.943
> 40.599343100 -111.887230100 1353.773
>
> 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. Meanwhile the altitude is oscillating up and down by a
> couple of meters every two or three updates.

Interesting.  I wonder how much of this is just analyzing the Kalman
filter behavior inside the M8.

> 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
>
> Anyone have any ideas about this?

This seems to be some ROS format after conversion?

Are people using NMEA or binary?