Refclock GPSD_JSON, bad NMEA time
There is an undocumented GPSD_JSON (refclock #46 (closed)) mode that exposes the base data better than the documented mode.
The configuration is documented, sort of, in refclock_gpsdjson.c. Here is my config:
# gpsd JSON
server 127.127.46.0 minpoll 4 maxpoll 4
fudge 127.127.46.0 time1 0.142
server 127.127.46.128 minpoll 4 maxpoll 4
fudge 127.127.46.128 time1 0.001500
For comparison, I have the very same GPS using driver #28 (closed), configured this way:
# for gpsd
server 127.127.28.0 minpoll 4 maxpoll 4 noselect
fudge 127.127.28.0 time1 0.142 refid GPS
# for PPS and gpsd
server 127.127.28.1 minpoll 4 maxpoll 4
fudge 127.127.28.1 time1 0.001500 refid GPS1
Notice the identical fudges on both SHM and GPSD_JSON
ntpq -p should report (near) identical jitters and offsets, yet:
catbert:/usr/local/src/NTP/ntpsec# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
-clepsydra.hpl.h .GPS. 1 u 22 64 377 26.265 -0.691 9.610
-204.152.184.72 .GPS. 1 u 61 64 377 28.276 -1.959 10.440
nist.netservice .ACTS. 1 u 757 1024 0 59.583 0.894 0.000
-spidey.rellim.c .GPS1. 1 s 35 64 376 0.166 -0.495 0.078
SHM(0) .GPS. 0 l 3 16 377 0.000 10.279 2.409
+SHM(1) .GPS1. 0 l 2 16 377 0.000 0.794 0.437
*SHM(2) .SHM. 0 l 16 16 377 0.000 -0.461 0.046
xGPSD_JSON(0) .GPSD. 0 l 16 16 377 0.000 -131.43 2.225
+GPSD_JSON(128) .GPSD. 0 l 14 16 377 0.000 0.700 0.461
It looks like the 140 milliSec time1 fudge is being ignored.
Nothing new here, the bug has existed since the dawn of GPSD_JSON, ad was previously reported to the NTPD project.
So, in short, the bug is that GPSD_JSON driver is using semi-random NMEA time to base PPS on. When the error exceeds 500 milliSec that could cause the PPS to be associated with the wrong second.
[Edited to use new driver nomenclature]