Re: Problems with gpsd under BullsEye

[Don Rolph]

As noted earlier, the libgps.so built from the most recent gitlab distribution is not compatible with Dire Wolf.

I am therefore using the libgps.so built from gpsd 3.22-4 as the last shared library which is compatible with Dire Wolf.

I am happy to understand what the next steps in debugging are.

I believe the data is reasonably solid in indicating that there is an issue in gpsd 3.23.2 ~dev (which is what is returned by gpsd -V).

And I can say that it appears to be related to the MT3333 returning messages every 2 seconds or so even when there is no fix.

So what are the suggested next steps needed for debugging this?

Thanks for your help!

On Sat, Jan 1, 2022 at 1:12 PM Greg Troxel <gdt@lexort.com> wrote:

Don Rolph <don.rolph@gmail.com> writes:

> Dire Wolf 1.7 against libgps.so.23, gpsd 3.23.2, BullsEye: fails: floods
> with packets and never quenches the floor
> Dire Wolf 1.7 against libgps.so.28, gpsd 3.23.2, BullsEye: fails: floods
> with packets but quenches after about 101 packets

A few points:

  gpsd 3.23.2 does not exist, but I think you mean "built from recent
  git master", which this minute has 242 commits after 3.23.1.

  libgps is built from gpsd, so using libgps.so.23, which was presumably
  built with some much older gpsd, is not the tested path.  Yes, it
  should at least mostly work, as in the situation where a machine with
  one gpsd version runs a program that gets data from a machine with a
  different version.  Therefore, if there's a bug in libgps, you should
  be testing with 3.23.1 or newer, as gpsd isn't going to pay attention
  to bugs in older releases.  However, I see your point that the
  behavior seems to follow gpsd version.

  I am surprised at libgps.so.28, because libgps_version_current is 29,
  in both release-3.23.1 and current master.  I have libgps.so.29 on my
  (NetBSD) system with 3.23.1 release installed from pkgsrc.  So I
  wonder if you have libgps.so from gpsd 3.22?

  You are talking about flooding, but can you show a trace of what is
  being emitted?  If it's 2 packets per second without a fix, saying
  there is no fix, that doesn't sound incredibly broken.  If it's 1000
  packets per second, and you can reproduce that with something that
  just connects to gpsd, and doesn't involve direwolf, that would reduce
  greatly the scope of the issue, which would greatly help in getting to
  a fix.

  Are you saying that gpsd is emitting so much data that direwolf is
  spending 100% CPU time reading and discarding the data?  Or do you
  perhaps mean "direwolf only expects 1 packet per second and if there
  are more they build up"?  I don't really mean to suggest that, as to
  put out a strawman for correction.  I've mostly read this thread, and
  I really don't precisely understand what's happening.   Perhaps a log
  of messages received with timestamps?

  Saying 3.17 works, 3.23.2~dev does not work, might be accurate, but
  unless you want to bisect the 5362 commits, it doesn't really lead to
  knowing what's wrong.  And it doesn't show where the bug is, as
  sometimes valid bahavior in software exposes a latent bug in some
  other software, so "update A, A-B system breaks" does not prove A is
  buggy.  (I'm not presuming anything about where the problem is.)

--

73,

AB1PH

Don Rolph