Re: PPS fix determination vs. cgps?

[Gary E. Miller]

Yo Steve!

On Wed, 20 Jan 2021 21:27:03 -0600
Steve Bourland <sbourland@swri.org> wrote:

> Yo Gary!  (please be patient, take a deep breath....I tried to....but
> had a frustrating day and expect it might show here)

As have many others...

> > What version gpsd?  
> 3.22....freshly downloaded and installed.

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

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

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


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

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

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

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

pgpMYJQTOb6nC.pgp
Description: OpenPGP digital signature