Re: NMEA but no PPS in ntp, Ubuntu 18.04.5

[Steve Bourland]

Yo Gary!
  Super happy to learn about new places to look for information :)

> ------------------------------
>
> Message: 2
> Date: Tue, 1 Dec 2020 10:07:29 -0800
> From: "Gary E. Miller" <gem@rellim.com>
> Subject: Re: NMEA but no PPS in ntp, Ubuntu 18.04.5
>
> Yes, 3D fix with DGPS.  So gpsd should be sending PPS.
>
> > % ntpq -pn
> >       remote           refid      st t when poll reach   delay
> > offset jitter
> > ===============================================================================
> > xSHM(0)     .NMEA.        0 l    -   16  377   0.0000 -173.812 23.2042
> >  SHM(1)     .PPS.         0 l    -   16    0   0.0000
>
> But no PPS.  You also do not have enough other chimers.  Hard to
> vote with only 2 voters.

I have 4 other voters but figured their info wasn't relevant, and knew I 
was already going to have a long message, just trying to keep it as short 
as possible.

> > # ppstest /dev/pps0
> > trying PPS source "/dev/pps0"
> > found PPS source "/dev/pps0"
> > ok, found 1 source(s), now start fetching data...
> > source 0 - assert 1606844580.999843801, sequence: 87291 - clear 
> > 1606844581.099837210, sequence: 87291
>
> That is good.  What is your gpsd command line?  See it this way:
>        # pstree -paul | fgrep gpsd

# pstree -paul | fgrep gpsd
  |-gpsd,25099,nobody -b -n /dev/ttyS0
  |   `-{gpsd},25100
  |                       |-grep,25730 -F --color=auto gpsd

> > So is this a case where gpsd is feeding the kernel pps but not ntp's 
> > shared memory?
>
> Uh, you have if backwards.  The kernel feeds PPS to gpsd.  Then gpsd
> uses a SHM to eed it to ntpd.

Is the lack of /dev/pps0 on the gpsd command line causing the issue?

> > The shared memory looks "correct" to me as best I can  tell:
>
> Yeah, but what is in the SHM?
>
> What does ntpshmmon show you?  Somthing like this:
>
> # ntpshmmon
> ntpshmmon: version 3.21.1~dev
> #      Name  Seen@                 Clock                 Real                 L 
> Prc
> sam NTP0 1606845882.050103448 1606845881.573978673 1606845867.999628191 0 -20
> sam NTP1 1606845882.050114664 1606845881.462974487 1606845881.462907608 0 -30
> sam NTP1 1606845882.463990992 1606845882.463088891 1606845882.463021608 0 -30

ntpshmmon
ntpshmmon: version 3.21

# Name Seen@ Clock Real L Prc

sample NTP0 1606854237.160599667 1606854236.723461751 1606854236.000000000 
0 -20
sample NTP2 1606854237.160618091 1605548548.531056191 1605548548.000000000 
0 -20
sample NTP0 1606854237.718897639 1606854237.718892305 1606854237.000000000 
0 -20
sample NTP0 1606854238.716614280 1606854238.715886937 1606854238.000000000 
0 -20
sample NTP0 1606854239.735856735 1606854239.735446446 1606854239.000000000 
0 -20
sample NTP0 1606854240.727061561 1606854240.726007851 1606854240.000000000 
0 -20

The NTP0 entries keep coming every second (with expected variation since I 
presume it's the NMEA).  I assume I should have NTP1 entries showing up 
for PPS, not sure what the NTP2 is, but checked and I seem to get one of 
those at the start of ntpshmmon (sometimes before the first NTP0).  Using 
this super cool new tool on a functioning system, I see NTP2, NTP3, and 
then NTP0, NTP1 every second.


> > Although with the perms at 600 for segments 1 and 2, could that be
> > the issue?
>
> You need to be running gpsd and ntpd as root, of course.

They both start as root but then drop privleges so gpsd runs as nobody, 
and ntpd runs as "ntp."  I believe this is expected behavior?

> > I would think if that were the case the NMEA would have
> > the same problem?
>
> Yes.

So hopefully I'm following along here, but it looks to me like gpsd isn't 
putting the PPS timing in the shared memory for ntpd, but we have 
confirmed the kernel is "happy" with the PPS source and is providing it to 
gpsd, through the /dev/pps0 device gpsd created:
crw------- 1 root root 247, 0 Nov 30 11:28 /dev/pps0
I'm guessing gpsd creates the device and grabs a file handle before giving 
up uid 0?  (Sorry, just trying to understand how things are supposed to 
work)

Restarted gpsd on the command line with -D 5 to see if there was useful 
information:

gpsd:IO: <= GPS: $GPGSA,A,3,01,16,26,,31,,,,,,,,2.4,2.2,1.0*35
gpsd:PROG: NMEA0183: xxGSA sets mode 3
gpsd:PROG: NMEA0183: xxGSA: mask 0x200000000c00
gpsd:PROG: NMEA0183: GPGSA is just after a cycle ender.
gpsd:IO: <= GPS: 
$GPGSV,3,1,12,01,13,232,42,16,53,160,28,26,63,085,18,27,01,160,45*75
gpsd:PROG: NMEA0183: xPGSV: part 1 of 3, last_gsv_talker '0' 
last_gsv_sigid 0
gpsd:PROG: NMEA0183: xPGSV: new part 1, last_gsv_talker '0', zeroing
gpsd:PROG: NMEA0183: xxGSV: Partial satellite data (1 of 3).
gpsd:PROG: NMEA0183: GPGSV is just after a cycle ender.
gpsd:PROG: KPPS:/dev/ttyS0 assert  1606856426.999959147, sequence: 566, 
clear   1606856426.099962515, sequence: 565 - using: assert
gpsd:PROG: KPPS:/dev/ttyS0 Assert cycle: 1000020, duration: 899996 @ 
1606856426.999959147
gpsd:PROG: PPS:/dev/ttyS0 Assert cycle: 1000020, duration: 899996 @ 
1606856426.999959147
gpsd:INFO: PPS:/dev/ttyS0 Assert hooks called clock:  1606856426.999959147 
real:  1606856427.000000000: no fix
gpsd:PROG: PPS:/dev/ttyS0 Assert no fix @  1606856426.999959147 offset 
0.000040853
gpsd:PROG: KPPS:/dev/ttyS0 assert  1606856426.999959147, sequence: 566, 
clear   1606856427.099931634, sequence: 566 - using: clear
gpsd:PROG: KPPS:/dev/ttyS0 Clear cycle: 999969, duration: 99972 @ 
1606856427.099931634
gpsd:PROG: PPS:/dev/ttyS0 Clear cycle: 999969, duration: 99972 @ 
1606856427.099931634
gpsd:PROG: PPS:/dev/ttyS0 Clear ignored 1Hz trailing edge

cgps is indicating we have a fix, and I believe the GPGSA also says it has 
a 3D fix, however, the PPS lines still indicates no fix?
                                Thanks,
                                  Steve