Re: Analysis of log files: Dire Wolf 1.7, libgps.so.29, gpsd 3.23.2~dev, MT3333 gps

[Don Rolph]

You stated:

>> This suggests that a change in the message format going from 3.17 to
>> 3.22-400 is triggering a problem in the Dire Wolf gpsd code which
>> worked as expected under gpsd 3.17.

>I can't see how the Dire Wolf code ever worked reliably

I have now hundreds of hours of service experience showing that Dire Wolf using gpsd 3.17 was very reliable.

I have been running this for months with multiple GPS options.  and observationally it is working stably.

On Wed, Jan 5, 2022 at 2:12 PM Gary E. Miller <gem@rellim.com> wrote:

Yo Don!

On Wed, 5 Jan 2022 12:11:15 -0500
Don Rolph <don.rolph@gmail.com> wrote:

> Ok I have done a preliminary review of the log files at the time of
> the message storm in Dire Wolf.  log files dire3.log, gpsd3.log. and
> nmea3.log attached for independent review.

Good!

> One observes before gps fix, time is incrementing by 2 at each entry.
> After gps fix, we have about 100 messages all with the same time
> stamp.

Yes, that is normal.  Very dependent on what receiver you have, and
how it is configured.

> After about 100 messages in the log we see:
[...]
> Transmit packet queue for channel 0 is too long.  Discarding packet.
> Perhaps the channel is so busy there is no opportunity to send.

I sure hope you are not trying to send a bunch of fixes per second
aver the air at 9600!  That is not possible!

> Looking at the gpsd messages in gpsd3.log at the time of fix:
>
> It appears that speed is not provided in the gpspipe -w file which
> shows up as speed="NaN" in the Dire Wolf logs.

OTOH, it looks like the reciever is not moving.  We can come back to that
after you fix your really big problem.

> There are also some PRN records which I have not perused.

Don't bother.

> Dire Wolf 1.7 with libgps.so.23, libgps.so.28, or libgps.so.29 all
> show basically the same behavior when reading gpsd during time of GPS
> fix with the MT3333 gps  unit.
>
> This works as expected with gpsd 3.17 but not in gpsd 3.23.2~dev (or
> gpsd 3.22-400).

I'll ignore that since only your 3.23.2~dev is actually our code.

> This suggests that a change in the message format going from 3.17 to
> 3.22-400 is triggering a problem in the Dire Wolf gpsd code which
> worked as expected under gpsd 3.17.

I can't see how the Dire Wolf code ever worked reliably.

> I will now start perusing the code, BUT I am quickly outrunning my
> area of expertise.

The problem is now obvious to me.  The Dire Wolf code has never been
correct.  I can help you fix the code mistakes, and add a gate so that
only one message per fix is sent.

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