[Top][All Lists]

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

[gpsd-users] Using gpio-based kernelpps with gpsd

From: Robert Calhoun
Subject: [gpsd-users] Using gpio-based kernelpps with gpsd
Date: Tue, 14 Jul 2015 02:45:53 +0000
User-agent: Microsoft-MacOutlook/

Gary, this is probably a question for you based on your post "RFC 2783"
to gpsd-dev:

Is there a way to tell gpsd directly what pps device to use in gpsd 3.15?

I see some code and comments in ppsthread.c that suggest this is possible,
but I can't figure out how to do it. From ppsthread.c:
     * Some Linuxes, like the RasbPi's, have PPS devices preexisting.
     * Other OS have no way to automatically determine the proper
     * Allow user to pass in an explicit PPS device path.
    if (strncmp(pps_thread->devicename, "/dev/pps", 8) == 0)
    (void)strncpy(path, pps_thread->devicename, sizeof(path));
    else {...

But best as I can tell from how gpsmon calls it, pps_thread->devicename
is always going to be a serial device like /dev/ttyS0, not a pps device, so
we're never going to get a match on the code above. I have added the
path of my serial device to the .path property of the pps driver based
on the RFC 2783 discussion but I don't think that gets read anywhere in the
current code. Am I missing something or should I start modifying


Rob Calhoun

More details if helpful:

I am trying to get gpsd + kernel pps working on a custom Cortex A8 TI SoC
board that has an uBlox NEO-6 chipset. I am cross-compiling gpsd using the
build system.

The uBlox' time pulse is wired into a gpio on the SoC. There is a gpio
(such as used with the Raspberry Pi) in newer kernels, but as we are using
where there is no such driver, I wrote my own. I might have goofed that
but it seems to be working fine. (Exception: I don't have a
directory with my kernel, only /sys/class/pps/pps0 and /dev/pps0.)

/sys/class/pps/pps0 $ cat assert
/sys/class/pps/pps0 $ cat assert

While the kernel PPS feature seems to be working,  gpsd can't find it
because it
seems to assume the time pulse signal is always on the serial tty.

I've tried gpsd 3.14 based on the openembedded recipe:

and also 3.15 because there are a lot of kernel pps related changes going
gpsd 3.14 -> 3.15. I think I have gpsd (3.15) configured appropriately.
gpsd --help:

The following driver types are compiled into this gpsd instance:
  * NMEA2000
  * JSON slave driver
# n: mode switch, b: speed switch, c: rate switch, *: non-NMEA packet type.
# Socket export enabled.
# Shared memory export enabled.
# DBUS export enabled
# Time service features enabled.
# PPS enabled.

...but when I run gpsmon, init_kernel_pps() in ppsthread only looks at
/dev/ttyS3 for KPPS, which doesn't have it, so it returns failure.

$ gpsmon -D9 /dev/ttyS3 /dev/pps0 -l /var/log/gpsd
gpsmon:INFO: startup at 2015-07-13T22:35:49.000Z (1436826949)
gpsmon:INFO: opening GPS data source type 2 at '/dev/ttyS3'
gpsmon:INFO: speed 57600, 8N1
gpsmon:SPIN: open(/dev/ttyS3) -> 4 in gpsd_serial_open()
gpsmon:PROG: no probe matched...
gpsmon:INFO: gpsd_activate(1): activated GPS (fd 4)
gpsmon:INFO: KPPS:/dev/ttyS3 cannot set PPS line discipline Invalid
gpsmon:WARN: KPPS:/dev/ttyS3 kernel PPS unavailable, PPS accuracy will
gpsmon:PROG: PPS:/dev/ttyS3 thread launched

I might be able to route the gpio inside the SoC so it looks like it is
with /dev/ttyS3, but that seems like a hack given that /dev/pps0 works
fine as-is.

(side note for a different email to gpsd-dev: 3.15 makes fewer sysroot
than 3.14 and requires a lot less patching to cross-compile--great!---but
python-related code is still looking at the host's sysroot; I just
disabled python
via the scons options to get it to compile.)

p.s. Just 9 hours until New Horizons reaches Pluto!

reply via email to

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