Re: NMEA but no PPS in ntp, Ubuntu 18.04.5

[Steve Bourland]

> Date: Mon, 30 Nov 2020 22:31:28 -0800
> From: "Gary E. Miller" <gem@rellim.com>
> Subject: Re: NMEA but no PPS in ntp, Ubuntu 18.04.5
>
> On Mon, 30 Nov 2020 16:06:22 -0600
> Steve Bourland <sbourland@swri.org> wrote:
>
> >    So I am (again) struggling with getting NTPd and GPSd talking
> > super well with each other.
>
> Should be easy.

Agreed, which is why my head is getting sore from banging it against the 
desk :)

> 3.21 is good.
>
> > # ./gpsd -D 3 -N -b -n /dev/ttyS0
> [...]
> > 1605636037.000715367 real: 1605636037.000000000: no fix
>
> Yes, get a fix first.  You can use cgps to know when ou have a fix.

So from cgps on the server today:

┌───────────────────────────────────────────┐┌──────────────────Seen 12/Used 5┐
│ Time:        2020-12-01T17:37:56.000Z (0) ││     PRN  Elev   Azim   SNR Use │
│ Latitude:         NN.44352833 N           ││GP    10  57.0   80.0  27.0   Y │
│ Longitude:        NN.60732000 W           ││GP    20  29.0  115.0  24.0   Y │
│ Alt (HAE, MSL):   1281.168,   1367.782 ft ││GP    25  18.0  102.0  21.0   Y │
│ Speed:             0.00 mph               ││GP    27   5.0  230.0  40.0   Y │
│ Track (true, var):   150.1,   4.6     deg ││GP    31  51.0  191.0  33.0   Y │
│ Climb:             0.00 ft/min            ││GP     1  15.0  320.0   0.0   N │
│ Status:         3D DGPS FIX (8 secs)      ││GP     3  17.0  311.0   0.0   N │
│ Long Err  (XDOP, EPX):  1.00, +/- 14.9 ft ││GP     8   5.0  276.0   0.0   N │
│ Lat Err   (YDOP, EPY):  2.43, +/- 29.9 ft ││GP    11  12.0  308.0   0.0   N │
│ Alt Err   (VDOP, EPV):  0.90, +/- 67.9 ft ││GP    12   8.0   70.0   0.0   N │
│ 2D Err    (HDOP, CEP):  2.60, +/-  162 ft ││GP    14  58.0  299.0   0.0   N │
│ 3D Err    (PDOP, SEP):  2.70, +/-  174 ft ││GP    18  22.0  314.0   0.0   N │
│ Time Err  (TDOP):       1.59              ││                                │
│ Geo Err   (GDOP):       3.53              ││                                │
│ ECEF X, VX:              n/a    n/a       ││                                │
│ ECEF Y, VY:              n/a    n/a       ││                                │
│ ECEF Z, VZ:              n/a    n/a       ││                                │
│ Speed Err (EPS):       +/- 40.7 mph       ││                                │
│ Track Err (EPD):        n/a               ││                                │
│ Time offset:            1.304810981 sec   ││                                │
│ Grid Square:            EL09qk76          ││                                │
└───────────────────────────────────────────┘└────────────────────────────────┘

(Sorry, I did some whitespace editing in hopes that comes through well on 
the other end)
So that looks to me like I have a fix or am I reading it incorrectly?
I am sure you can figure out the Lat and Long, but figured I would mask 
those.

% 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   0.0000   0.0001
*10.3.3.5        .PPS.           1 u  866 1024  377   0.2003   0.1040   0.0738


# 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
source 0 - assert 1606844581.999868231, sequence: 87292 - clear 
1606844581.099837210, sequence: 87291
source 0 - assert 1606844581.999868231, sequence: 87292 - clear 
1606844582.099867758, sequence: 87292
source 0 - assert 1606844582.999858694, sequence: 87293 - clear 
1606844582.099867758, sequence: 87292

So is this a case where gpsd is feeding the kernel pps but not ntp's 
shared memory?  The shared memory looks "correct" to me as best I can 
tell:

ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x4e545030 0          root       600        96         2
0x4e545031 1          root       600        96         2
0x4e545032 2          root       666        96         1
0x4e545033 3          root       666        96         1
0x4e545034 4          root       666        96         1
0x4e545035 5          root       666        96         1
0x4e545036 6          root       666        96         1
0x4e545037 7          root       666        96         1
0x47505344 8          root       666        24512      1

Although with the perms at 600 for segments 1 and 2, could that be the 
issue?  I would think if that were the case the NMEA would have the same 
problem?
                                        Thanks,
                                          Steve