Re: [gpsd-dev] Port to QNX: PPS without SHM?

[Norton Allen]

On 12/20/2015 3:46 AM, Hal Murray wrote:

address@hidden said:

That mostly worked: I was able to see the JSON data and watch the NMEA
interface, but ntpd was unable to synch.

ntpd should work when gpsd doesn't have PPS.  What did ntpq -p show?

Any thoughts on what would be necessary to get PPS_ENABLE to work  without
NTPSHM_ENABLE? 

Bypass gpsd and feed the PPS directly to ntpd.  (after you get the JSON path 
working)

Hal, I have tried several different configurations:

1: gpsd with only NMEA input, ntpd configured to reference gpsd_json and /dev/pps1

In this configuration, gpsd does not transmit any data packets to ntpd. I am speculating and almost certainly wrong, but it seems as though gpsd is not sending packets because it has no PPS data. gpsd is sending version information.

$ ./ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 GPSD_JSON(1)    .GPSD.           0 l    -   64    0    0.000    0.000   0.000
 PPS(1)          .PPS.            0 l    -   64    0    0.000    0.000   0.000

 For some reason, this was less successful than my previous test where gpsd thought it had a pps device, but was not in fact accessing it. In that case, gpsd transmitted lots of TPV and SKY packets. But the ntpq output was the same.

2: I made modifications to timehint.c to actually activate the pps thread. [I will be more than happy to share the details, but I am hoping to spare you that at the moment. I'm hoping your high-level view will help, but feel free to demand more info.] For the first run, in separate terminals:

./gpsd -N -D2 /dev/gps1 /dev/pps1
./ntpd -c /etc/ntp/ntp_gps.conf -d -q -g -x

ntp_gps.conf includes:

# by default act only as a basic NTP client
restrict -4 default nomodify nopeer noquery notrap
restrict -6 default nomodify nopeer noquery notrap
# allow NTP messages from the loopback address, useful for debugging
restrict 127.0.0.1
restrict ::1
server 127.127.46.1 mode 1
fudge 127.127.46.1 time1 0.0
server 127.127.22.1

In this configuration, gpsd is producing TPV and TOFF packets:

gpsd:CLIENT: => client(0): {"class":"TPV","device":"/dev/gps1","mode":3,
  "time":"2015-12-22T01:41:46.000Z","ept":0.005,"lat":34.136280000,
  "lon":118.126761667,"alt":257.600,"epx":2.723,"epy":2.957,
  "epv":9.085,"track":260.6100,"speed":0.000,"climb":0.000,"eps":5.91,
  "epc":18.17}\x0d\x0a
gpsd:CLIENT: => client(0): {"class":"TOFF","device":"/dev/gps1",
  real_sec":1450748507, "real_nsec":0,"clock_sec":1450748507,
  "clock_nsec":398477396}\x0d\x0a

I still fail to get ntpd to lock, ntpq output is the same as above.

3: I replaced 127.127.22.1 with 127.127.46.129. Same results, except ntpq now says:

$ ./ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 GPSD_JSON(1)    .GPSD.           0 l    -   64    0    0.000    0.000   0.000
 GPSD_JSON(129)  .GPSD.           0 l    -   64    0    0.000    0.000   0.000

[The documentation of this option in ntpd's refclock_gpsdjson.c is somewhat unclear, so I would not be surprised if I misinterpreted it.]

In all cases, I have verified with ./ntpd -dd that ntpd is in fact receiving the packets gpsd is sending and appears to be parsing them correctly.

Is there anything obvious I am missing in this setup?
Is there any more complete information I could provide that would help?
I will continue to investigate on the ntpd end.