Re: Problems with gpsd under BullsEye

[Don Rolph]

I looked back and realized my testing does not distinguish between the client libgps.so version and the gpsd version.

So:

Dire Wolf 1.7 against libgps.so.23, gpsd 3.17, BullsEye works

Dire Wolf 1.7 against libgps.so.28, gpsd 3.17, BullsEye works

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

This is suggestive that the issue is with the gpsd 3.23.2 rather than the libgps.so version.

Some more points:

This is observed with the MT3333 GPS which sends a message every 2 seconds whether or  not there is a gps fix.

This is not observed with the Stratux GPSYes based on the ublox-8 which is appears to be only sending occasional messages prior to achieving gps fix.

As soon as gps fix is achieved, the Dire Wolf application is complaining about having to drop messages because the queue is filled.

Best I can do so far, but the data seems to continue to point to the gpsd 3.23.2 (an 3.22-4) executable.

On Sat, Jan 1, 2022 at 7:36 AM Don Rolph <don.rolph@gmail.com> wrote:

So I expanded my testing.  I was able to install gpsd  3.17 and liibgps.so.28 on Bullseye.

New test set:

MT3333, Diure Wolf 1.7; gpsd 3.17, Buster:  works

MT3333, Dire Wolf 1.7, gpsd 3.17, BullsEye: works

MT3333, Dire Wolf 1.7, gpsd 3.22-4, BullsEye:  autobaud failure, flood of packets, inconsistent return of gps coordinates

MT3333, Dire Wolf 1.7, gpsd 3.23.2, Bullseye:  autobaud now works, flood of packets, need to confirm if gps coordinates are returned properly

So:

MT3333, Dire Wolf 1.7, gpsd 3.17 works on both Buster and BullsEye.

The deployment of gpsd 3.17 with libgps.so.23 probably is not usable in a production mode however.

The changes between 3.17 and 3.2X seem to have changed something critical.  I have some partial debugging data on the difference between the returned data from gpsd3.17 and 3.23.2 but I need to do more testing.

On Fri, Dec 31, 2021 at 4:47 PM Don Rolph <don.rolph@gmail.com> wrote:

Testing:

MT3333; Dire Wolf 1.7; gpsd 3.17; Buster: works

MT3333, Dire Wolf 1.7; gpsd 3.22; BullsEye:  we get the message flood

MT3333; Dire Wolf 1.7; gpsd 3.23.2; BullsEye:  message flood reduced but not eliminated

MT333; Dire Wolf 1.7; gpsd 3.17; BullsEye: we get message flood

So we have one working system using gpsd 3.17 and the Buster environment.

On Fri, Dec 31, 2021 at 3:42 PM Gary E. Miller <gem@rellim.com> wrote:

Yo Don!

On Fri, 31 Dec 2021 15:06:03 -0500
Don Rolph <don.rolph@gmail.com> wrote:

> It is most clearly a gpsd issue.  It does not occur if gpsd is not
> called by Dire Wolf.  If we call the gps device directly without
> gpsd, there is no issue.

Since you never showed it is a problem with any gpsd release, as
opposed to 3rd party hacked gpsd binaries, I'll have to await some
real data.

If you can reproduce any problem with gpsd built from our source, please
report it. report problems with bonaries to their source, ehich is not
here.

> Using gpsd 3.17 under Buster this does not occur.

Ancient history and Buster is not from here.

> I keep poking but it looks like it is an issue with gpsd executable

gpsd does not supply any executables.

> AND the version of gpsd libraries used by the client software.

Of course.

gpsd, like openssl, ffmpeg, boost, etc. is designed that the daamon, and
client, be built with the same exact toolchain.  When you have binary
structures changing there is no avoiding it.  Not doing so will cause
problems, and is not supported.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

--

73,

AB1PH

Don Rolph

--

73,

AB1PH

Don Rolph

--

73,

AB1PH

Don Rolph