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]