[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with gpsd under BullsEye

From: Greg Troxel
Subject: Re: Problems with gpsd under BullsEye
Date: Sat, 01 Jan 2022 13:54:31 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (berkeley-unix)

Don Rolph <> writes:

> As noted earlier, the 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 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

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

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]