[gpsd-dev] Problem with PPS detection - using Centos 7 and gpsd dev-3.19a

[Mick Durkin]

Hi,

I am preparing a time server which will use a computer that is presently 
lacking a serial port. I have a dual serial port card available for this 
computer (made by Perle, includes Linux driver source code) and I have 
temporarily installed this in a test machine.

When I connect my GPS to the test machine's internal serial port, gpsd works 
fine, detecting the serail data stream and DCD transitions, passing both NMEA 
and PPS time to NTP.

When I move the cable to the Perle serial card, the serail data stream is seen 
as before but the DCD transitions are not handled and no PPS is sent to NTP.

I ran "ppscheck" against both ports and both produce similar output (files 
attached ppscheck_good.log and ppscheck_bad.log).

I then ran gpsd with some debugging active like "gpsd -nND 5 /dev/ttyS0" and 
captured the output for both ports (files attached pps_good.log and 
pps_error.log). To shorten these logs I have only included the lines generated 
containing "KPPS:" or "PPS:"

In the good log early lines show "Kernel PPS timeout Interrupted system call" 
but after a few seconds it settles down to detecting the pulses and eventually 
these are recognised as valid and "accepted" as good timestamps.

In the errored log there are many less messages and after a few "Kernel PPS 
timeout Interrupted system call" it changes to "Kernel PPS Timeout Connection 
timeed out" and eventually the 10 second timer on "unchanged state" is 
triggered.

When I investigated the code further with some temporary extra logging I found 
that line 569 of ppscheck.c is the point at which the "time_pps_fetch" call is 
made which fails.

The code of ppscheck seems to work by using the TIOCMGET ioctl which sees the 
DCD transitions for either port, but the ppsthread code goes a different way 
and invokes "time_pps_fetch" in the block of code guarded by "#if 
defined(HAVE_SYS_TIMEPPS_H)".

It is clear that the Perle serial driver is passing DCD transitions to the 
kernel but is somehow not giving the information to handle "time_pps_fetch".

If my supposition is correct, then the fault is in the Perle driver and outside 
the scode of gpsd, but I would appreciate if if someone could have a look at my 
findings and confirm (or otherwise) my ideas. A pointer to what I need to look 
for in the serial driver would be a real bonus!

Regards

Mick

pps_good.log
Description: Binary data

ppscheck_good.log
Description: Binary data

ppscheck_bad.log
Description: Binary data

pps_error.log
Description: Binary data