Re: [gpsd-users] Unexpected behavior

[Gary E. Miller]

Yo Nick!

On Thu, 21 Sep 2017 19:09:36 -0700
"Nick Burkitt" <address@hidden> wrote:

> > Uh, what 10 second delays?  
> 
> The 10-second delays that follow the occurances of this warning:
> 
> gpsd:WARN: PPS TIOCMIWAIT returns unchanged state, ppsmonitor sleeps
> 10.

And yet, later down in your email you are getting PPS just fine.

What is your GPS?  How is it connected to your PC?

Kill your gpsd, then you should be able to see th PPS directly:

# ppscheck /dev/ttyS0
# Seconds  nanoSecs   Signals
1506133914 000093401
1506133915 000039993
1506133916 000066533

ppscheck is part of the gpsd package.

> gpsd:INFO: KPPS cycle: -13477257, duration:   99996 @
> 1504801908.218487449

That means you got a nice PPS.

> gpsd:WARN: PPS TIOCMIWAIT returns unchanged state, ppsmonitor sleeps
> 10

And that means you lost PPS.  I assume your GPS has a good sky view?  Not
indoors?

> > Who said anything about user-space?  gpsd makes a system call to
> > grab the  
> PPS off the serial port the GPS is on.
> 
> TIOCMIWAIT is an tty ioctl call to wait for a modem status register
> change, no?

Yes.

> That suggests that user code is looking for DCD
> transitions.

The only user code here is gpsd.  No toerh user code invovled.  As long
as your kernel KPPS is working, that is what is used.

> /etc/ntp.conf:

> /etc/ntp-conf.d/use-gpsd-shm:
> refclock shm unit 0 refid GPS
> refclock shm unit 1 prefer refid PPS

The line with 'refix GPS' either needs the proper fudge, or
'noselect'.  That will cause problems.

Otherwise, looks good.  I assume you (or Ubuntu) fixed your use-country-pool?

> Well spotted! Reconfiguring my NTPsec build with --refclock=shm
> helped a lot. Here's what ntpmon thinks now:
> 
>      remote           refid      st t when poll reach   delay   offset jitter
> SHM(0)          .GPS.            0 l   51   64   17      0ns -83.57ms 1.6557ms
> SHM(1)          .PPS.            0 l    -   64    0      0ns      0ns 0ns

So your ntpd is working properly.  It is talking to gpsd, but gpsd is not
sending it any PPS data.

> At least it sees the GPS, so that's progress, but PPS is still playing
> hard-to-get.

Looks like your gpsd is possibly getting a flakey PPS.

You can see the output of gpsd, the input to ntpd, this way:

# ntpshmmon
ntpshmmon version 1
#      Name Seen@                Clock                Real                 L 
Prec
sample NTP0 1506134422.016921574 1506134421.635930274 1506134420.703999996 0 -20
sample NTP1 1506134422.016960107 1506134422.000115062 1506134421.000000000 0 -30
sample NTP0 1506134422.645864387 1506134422.645553734 1506134421.703999996 0 -20
sample NTP1 1506134423.000876365 1506134423.000073731 1506134422.000000000 0 -30
^C

> I've satisfied myself that PPS interrupts (that is, 16550 UART modem
> status register interrupts) are occuring, at least when /dev/ttyS0 is
> open.

Yeah, sometimes you do get them, but they seem to come and go.

> It's not clear at this point if the problem is related to gpsd, ntpd,
> or KPPS.

I'm guessing bad PPS/KPPS into gpsd.

> BTW, I’m using the stock Ubuntu (trusty) package for gpsd. Are there
> special build configurations I need to add there, too?

Uh, we don't support Ubuntu.  You have to ask them what damage they did
to the upstream gpsd code.  All we can manage is the gpsd main git
repository.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

pgpLtDbCuTkfj.pgp
Description: OpenPGP digital signature