gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Problem with PPS detection - using Centos 7 and gpsd dev-


From: Gary E. Miller
Subject: Re: [gpsd-dev] Problem with PPS detection - using Centos 7 and gpsd dev-3.19a
Date: Sat, 12 Jan 2019 13:58:27 -0800

Yo Mick!

On Sat, 12 Jan 2019 20:56:47 +0000 (UTC)
Mick Durkin <address@hidden> wrote:

> 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.

Any way for us to see that driver source?

> 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.

Good.

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

Odd that both DCD and DSR are both changning, but not a problem.

> 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:"

Yeah, this shows the Perle driver code is not supporting KPPS:

gpsd:INFO: KPPS:/dev/ttyPS0 kernel PPS timeout Connection timed out

That is a driver problem.  Worse, the driver is pretending to
support KPPS so gpsd is not falling back to the simple watching of
the DCD line.

Maybe you can try to compile gpsd without the KPPS support and see
if you get the basic PPS working.  Accuracy will suffer.


> 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)".

Sort of.  gpsd will fall back to TIOMCIWAIT if the serial port does
not support KPPS at runtime.  But since your driver is pretending to
support KPPS, the fallback is not happening.

> 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".

The KPPS path is defined in RFC RFC2783.  Ask your vendor about it.

> 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.

Try compiling gpsd without /usr/include/sys/timepps.h and see if 
palin PPS works.  That would confirm a driver problem.

> A pointer to what I need to look for in the serial driver would be a
> real bonus!

The KPPS stuff is in the kernel.  Look in the kernel source at:

Documentation/pps/pps.txt
drivers/pps/kapi.c

For RasPi (gpio) users, also look in:

drivers/pps/clients/pps-gpio.c


RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

Attachment: pgpzpBeMV7Gj5.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]