Re: Problems with gpsd under BullsEye

[Don Rolph]

You stated:

"Dire Wolf is going to have to deal with that sooner or later, and I

suspect there is no actual problem other than a different API version
number to build against and try once and decide it's ok and therefore
decide to allow building"

Since I don't own the Dire Wolf code, I must defer to the author.  It looks like, however, that it is not a version issue per se, but differences in the calling sequences.  This will be a harder issue to fix than just checking for versions.

I will defer to the author on this point however.

You stated:

"If you can reproduce, with all code from 3.23.2~dev

  start gpsd with a MTK3333 (without systemd, which adds in complexity)

  connect to gpsd with a client

  observe a crazy high rate of messages:

The issue is apparently one of capturing messages after a fix is achieved.  I am unsure what command line clients there are to monitor the output of gpsd.  I can of course monitor the output of the MT3333, but I have already been monitoring this and it basically is the messages every two seconds.

Thoughts on a command line client to capture output of gpsd into say a log?

Thanks in advance!

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

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

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

Dire Wolf is going to have to deal with that sooner or later, and I
suspect there is no actual problem other than a different API version
number to build against and try once and decide it's ok and therefore
decide to allow building.  (Generally I do not hear of gpsd clients
failing to build or work when the API version number changes.)  However,
I haven't tried to build direwolf in a while as the build system wasn't
portable enough to work reasonably in my environment, and I got
distracted.  But I see there has been a release with cmake and I should
try again.

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

Which means you are testing with some code from 3.22 (gpsd does not
release 3.22-4; that's some Debian revision code) and some from
3.23.2~dev.  You're of course welcome to figure things out and test that
way if that's what you want to do, but you're off the rails of "gpsd
project only pays attention to the most recent release".

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

As I see it the path is to look at what data is actually being emitted
by gpsd, via adding debugging flags, or logging things on the direwolf
side, or perhaps writing a tiny test program that just asks for data.

If you can reproduce, with all code from 3.23.2~dev

  start gpsd with a MTK3333 (without systemd, which adds in complexity)

  connect to gpsd with a client

  observe a crazy high rate of messages

then I suspect this will be pretty easy to track down.

As of now, I don't understand

  what rate of messages does gpsd emit?

  what is in those messages?

So it should be easy to add logging call in direwolf to just record
timestamp, contents for each gpsd message, and that will be hugely
illuminating.

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

It appears, yes, but until we find the bug, it's just probability.  The
path to a fix is finding a specific problem in the source code, which
involves looking at data flowing across interfaces in the system, and
data/states at intermediate points within gpsd.

--

73,

AB1PH

Don Rolph