gpsd-users
[Top][All Lists]
Advanced

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

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


From: Gary E. Miller
Subject: Re: Analysis of log files: Dire Wolf 1.7, libgps.so.29, gpsd 3.23.2~dev, MT3333 gps
Date: Wed, 5 Jan 2022 14:10:07 -0800

Yo Don!

loop++.  Loop count exceeded.  Aborting...

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

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




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

Attachment: pgpi3J_dyP1TB.pgp
Description: OpenPGP digital signature


reply via email to

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