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

[Gary E. Miller]

Yo Luke!

On Wed, 26 Feb 2020 14:12:38 -0700
Luke Hutchison <address@hidden> wrote:

> I found the link at
> https://gpsd.gitlab.io/gpsd/faq.html#bug-reporting :

I'll remove that soon.

> > 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.
> >  
> 
> I'm using the Here2 GNSS GPS module with a Silicon Labs CP210x UART
> Bridge:
> https://www.getfpv.com/here2-gnss-gps-module.html

That is info on the board, we need the GPS model.  You can find it
this way with gpsd running:
       ubxtool -p MON-VER

Then send us the MON-VER section.  It will look sorta like this:

UBX-MON-VER:
  swVersion ROM CORE 3.01 (107888)
  hwVersion 00080000
  extension FWVER=SPG 3.01
  extension PROTVER=18.00
  extension GPS;GLO;GAL;BDS
  extension SBAS;IMES;QZSS


        
> > 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. 
> 
> Some of the updates seem to be issued when no additional location
> information is received (e.g. for a message only enumerating satellite
> locations -- SKY?).

Yup.  Such are the problems with NMEA.  That is why u-blox binary
mode is preferred.

> The slight drift in location during these
> non-location updates is probably due to Kalman filtering or something.

Nope.  gpsd does no filtering.

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

I'll ask again for you geoid separation.

> > 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?
> >  
> 
> I'm using 3.19 (specifically Fedora's binary gpsd-3.19-2.fc31.x86_64
> package).

3.20 is the latest release.  No idea here how Fedora may have miunged it.

> I didn't configure the receiver, I just plug it in and gpsd detects
> it and starts. (Or maybe gpsd starts when a client tries to connect
> to it, I'm unsure of the mechanism.)

How are you starting pgsd?  With systemd?  Or?  Are you using the "-n"
option.  These affect gpsd operation.

> I am using only defaults.

Are you sure?  Did you reset the device?  Many receivers get changed
from the defaults before shipping.

> I don't know how to check delta or geoid separation, please advise.

It would be in the raw.log I asked for.

> > How did you capture those two logs?  The prefered method is:
> >     gpspipe -R -n 100 > raw.log
> >  
> 
> I captured the previous logs with `gpscat`. But I am attaching logs
> captured with: gpspipe -R -n 100 > raw.log
> (hopefully the list can handle attachments)

That looks very different than you sent last time.  You previously
sent NMEA as the output of your receiver, and you just sent u-blox
binary.  NMEA != binary.  So either you did not collect what you
thought you collected, or you changed something.

This is why we need to know how you collect data that you send here.

This shows us what is in your raw.log:
    ubxtool -f raw.log -v 2

This is a NAV-PVT from the ubxtool decode of your raw.log:

UBX-NAV-PVT:
  iTOW 334524000 time 2020/2/26 20:55: 6 valid x37
  tAcc 18 nano -442616 fixType 3 flags x3 flags2 xa
  numSV 16 lon -1118872687 lat 405993252 height 1344541
  hMSL 1363357 hAcc 4096 vAcc 6679
  velN 22 velE -70 velD 45 gSpeed 74 headMot 28876577
  sAcc 373 headAcc 17273978 pDOP 138 reserved1 0 19192 35
  headVeh 9034 magDec 0 magAcc 0
    valid (validDate ValidTime fullyResolved) fixType (3D)
    flags (gnssFixOK diffSoln) flags2 ()
    psmState (n/a)
    carrSoln (None)
        
Notice "height" (height above the ellipsoid) is 1344.541 meters,
and hMSL (height Mean Sea Level) is 1363.357 meters.  So your
geoid separation (height - hMSL) is -18.816.

My guess is your "altitude" (undefined) is bouncing between those two
numbers.



> > Uh, this is gpsd.  What is gps_umd?  Why do we care about gps_umd
> > here at gpsd?
> >  
> 
> gps_umd is a gpsd client that converts gpsd updates into ROS NavSatFix
> messages:
> http://docs.ros.org/melodic/api/sensor_msgs/html/msg/NavSatFix.html

Dunno what that means...

Looking at the code here:

https://github.com/ros-drivers/gps_umd/blob/master/gpsd_client/src/client.cpp

They do not really support gpsd 3.19.

> I know the gpsd team is not concerned with specific clients such as
> gps_umd -- I was only pointing out that downstream consumers of gpsd
> messages are running into the same issue with the same receiver
> device.

Dunno about other clients, but that one does not really support 3.19.

> And one of the suggestions was to not update position on GSV,
> but rather GLL message. I didn't know if that was relevant. But the
> issue is upstream, because I see the clusters of 2 or 3
> nearly-identical updates (with oscillating altitude) happening even
> with the xgps client.

Since you are not really using NMEA, the you are off in the wilderness.
You are using u-blox binary which has not GSV or GLL.

> Here are the first few messages displayed by cgps,

Once again, useless.  You are not using cgps as your client and the
way cgps interacts with gpsd is not how your client is interacting with
gpsd.

> which seem to
> indicate that gpsd has automatically switched the receiver to binary
> mode ("nmea":false)

Nope.  nmea:false says that cgps told gpsd not to send any NMEA or
psuedo-NMEA.

> 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.
> >  
> 
> Please let me know if this is still your conclusion after looking at
> the attached raw log. Thanks.

Yes, and no.  You said you were using NMEA from the u-blox, but your
are really using u-blox binary.  Otherwise, the ASAP/eventualy
issue is always there.

What I know now, that I did not see before, is that your client does
not support gpsd 3.19.

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

pgpuaXc0tT3VM.pgp
Description: OpenPGP digital signature