Re: PPS fix determination vs. cgps? (fwd)

[Steve Bourland]

Yo Gary!
  First off, thank you very much for your patience and sage advice.

On Thu, 21 Jan 2021, gpsd-users-request@nongnu.org wrote:

> ------------------------------
>
> Message: 4
> Date: Wed, 20 Jan 2021 19:45:27 -0800
> From: "Gary E. Miller" <gem@rellim.com>
> Subject: Re: PPS fix determination vs. cgps?
> Message-ID: <20210120194527.6932162f@spidey.rellim.com>
>
> Yo Steve!
>
> On Wed, 20 Jan 2021 21:27:03 -0600
> Steve Bourland <sbourland@swri.org> wrote:
>
> Good.  Now what was the command you used to run gpsd?
>
> When in doubt, this tells me a lot about what you did:
>
> # pstree -paul | fgrep gpsd

-gpsd,3515,nobody -N -D 3 -n /dev/ttyS0

(when not wanting to see the output, it is simply ./gpsd -n /dev/ttyS0)

> > > What version ntpd? Does it really matter?  Right now I am asking about
> > deviasion between cgps/xgps and gpsd's PPS reporting.  But to answer your
> > question:
> > ntpd ntpsec-1.1.0+419 2018-03-14T12:03:57-0700
>
> It does not matter, yet, but gotta plug our sister project.

An excellent project indeed :)

> > > How long did you let it run?  It can often take 15 to 30 mins from
> > > startup for a Garmin to send good PPS. > Long enough for cgps and xgps to 
> report that they had a 3D fix.....so
> > I'd say long enough?
>
> No, maybe not long enough.  It can take up to 30 minutes to get the
> current leap second.  Without that some GPS will not output PPS.  In
> other cases the receiver reported time may be off up to 18 seconds.

So to help my understand...it had been running for over 30 minutes prior, and
now has run for over 24 hours with the same output.  I have an LED on the
adapter board that converts the Garmin cable to RS-232, driven by the PPS
line....and it is blinking away happily.  Also, I was under the impression the
PPS line:
gpsd:INFO: PPS:/dev/ttyS0 Assert hooks called clock:  1611241818.703900423 
real:
1611241819.000000000: no fix
Is triggered from the KPPS, when the kernel gets the PPS signal from the serial
port, am I on target with my thinking there?

> > > The best way is to capture a log of your session this way as root:
> > >
> > > # gpsd -nND 6 /dev/ttyS0 >& tmp.log
>
> I already asked for the one thing that solves most problems, that
> tmp.log.  Help me help you, send that.

Have started the collection, will attach to this message.

> > > Look in gpsd/ppsthread.c > OK.....so it really looks to me like you are 
> missing the key point of
> > my question...
>
> Or vice-versa.
> > WTF am I getting told by cgps and xgps that I have 3D fix....but the
> > debug log for PPS is telling me no fix?
>
> I pointed you to the exact place where that happens.  There are a
> few known cases where that can happen.  Usually timing related.
>
> BTW, care to share that debug log?
>
> > Pointing me to ppsthread.c in no way shows me why cgps and xgps both
> > think I have a 3D fix, no?
>
> Correct.  But, as you said, xgps and xgps are working as you expect, so
> no point looking at the working part.

My thinking was to see why they thought they had a good fix (what they were
keying off of) to see if PPS was looking for a different key...again, my lack 
of
understanding of the systems involved.

> >  Sorry Gary....I know you handle about
> > 20,000 questions per day.  I'm trying really hard to point you to the
> > point that is my confusion, why in the same code base...I'm being
> > told I have a 3D fix and no fix at the same time?
>
> Consider yourself in a time vortex.  NOTHING in gpsd happens at the
> same time.  And without your debug logs, I'm guessing.
>
> > This should really
> > bother you too in my mind as a fellow developer, which is why I am
> > poking at the bear.  I want an answer...I don't want to waste your
> > time, but I feel like you're missing the point?
>
> I encourage people to poke this bear, gently.  That is how things
> get fixed and improved.  Be patient, if I knew your problem, I'd
> have the answer already.  But what I need to find problems is
> logs, and data, not theories.
>
> > So here is the main issue in my mind:
> >    Both cgps and xgps show me "3D fix" (I can include logs if you
> > need it....or you can just trust me, they report that, version
> > 3.22....latest release...built expressly for troubleshooting this),
> > the debug log from gpsd shows the quoted PPS line with "no fix."  Am
> > I insane for thinking there is a disconnect somewhere?
>
> You are starting to undertand the complexity of gpsd.  The serial handling
> and the PPS handling are in different threads.  So things can go wrong
> in the communications between the threads.
>
> How to move forward?  Send me:
>
> # pstree -paul | fgrep gpsd
>
> The FULL and COMPLETE debug log.

Just to try and help keep your life a bit simpler, original command that
generated the above PPS log message:
-gpsd,3515,nobody -N -D 3 -n /dev/ttyS0

Log attached with hopefully enough seconds of runtime (file size limits) 
called with:
# gpsd -nND 6 /dev/ttyS0 >& tmp.log

(sorry, this is my third attempt to send this, used head to reduce the 
file size hopefully enough to get it to you, so file now gps.log)

Again, thank you very much for your patience and your help.
                                Steve

gps.log
Description: Text document