gpsd-users
[Top][All Lists]
Advanced

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

Re: Problems with gpsd under BullsEye


From: Don Rolph
Subject: Re: Problems with gpsd under BullsEye
Date: Wed, 5 Jan 2022 07:44:25 -0500

The Dire Wolf author kindly made the changes required to build Dire Wolf 1.7 under gpsd 3.23.2~dev.  I used the tar file because the version with the default git clone command had some odd behaviors.  There also appear to be some quirks in the install instructions. There are some minor issues encountered which need to be resolved before such an install would be production worthy, but I now have a Dire Wolf 1.7 with libgps.so.29 working against gpsd 3.23.2~dev.  I get the same failure.  On the first TPV message after a 3D fix when using the MT3333 gps,  the Dire Wolf application is seeing the gpsd message repeated hundreds of times.  This happens with all combinations of gpsd 3.22-4 or above and does not happen with gpsd 3.17.

So with the MT3333 gps:

Dire Wolf 1.7 against libgps.so.23, gpsd 3.17, Buster works
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~dev , BullsEye: fails: floods with packets and never quenches the flood
Dire Wolf 1.7 against libgps.so.28, gpsd 3.23.2~dev, BullsEye: fails: floods with packets  quenches after about 101 packets (some ambiguity on t his number:  there are several levels of quenching)
Dire Wolf 1.7 agains the 3.23.1 libgps.so.29, gpsd 3.23.1 from git clone: BullsEye:  software does not install in a consistent manner perhaps due to install documentation ambiguities
Dire Wolf 1.7 against libgps.so.29, gpsd 3.23.2~dev, BullsEye: fails: floods with packets  quenches after about 101 packets (some ambiguity on this number: there are several levels of quenching)

This continues to suggest that the issue is with the gpsd 3.23.2~dev rather than the libgps.so version.  There is a hint that there is a change in the gpsd 3.23.2~dev gpsd TPV message format which is causing Dire Wolf 1.7 code to work with gpsd 3.17 TPV messages but fail on the first 3D fix TPV message with gpsd 3.23.2~dev, but I need a thorough analysis of the logs on this point.

Some more points:

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.  The Stratux GPYes also sends SKY messages prior to gps fix, while the MT3333 generally only sends s SKY message after 3D fix.

I have a set of logs from this test as well and will analyze these logs later today.

On Sat, Jan 1, 2022 at 11:23 AM Don Rolph <don.rolph@gmail.com> wrote:
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


--

73,
AB1PH
Don Rolph

reply via email to

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