[Top][All Lists]

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

[gpsd-dev] RFC2783 vs TIOCMIWAIT, PPS on NetBSD

From: Greg Troxel
Subject: [gpsd-dev] RFC2783 vs TIOCMIWAIT, PPS on NetBSD
Date: Thu, 31 Oct 2013 19:39:00 -0400
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.4 (berkeley-unix)

I read RFC2783.  It provides an API to get a timestamp from a DCD
transition, including a way for the call to wait until a new one
arrives.  The timestamps are returned not via read/write on the file
descriptor, but via pps calls on the pps object created from the
descriptor.  This seems entirely sufficient for gpsd.

NetBSD has sys/timepps.h, with a comment that it correpsonds to a draft
of what became RFC2783.  I tried to enable pps in ntpd (via
as described at
) and pointed /dev/pps0 at /dev/dtyU0 (GR601-W).  However, it seems that
the USB com device doesn't have pps support, which isn't really
surprising since it's only recently been useful.

I configured pps for a real i386 serial port, and ran ktrace, and saw
the calls I'd expect given RFC2783 and what's in sys/timepps.h.

The ntp_adjtime() call in RFC1589 can be used with RFC2783, but I don't
see that being possible (or sane) if gpsd is handling the gps/pps and
ntpd is disciplining the clock.  But I think that's ok.

So my current belief is that RFC2783 should be entirely adeequate for
gpsd to read pps, and I don't understand why TIOCMIWAIT is really

This creates several TODO items:

  add pps support to NetBSD ucom(4), so the GR601-W will work

  enable gpsd to find sys/timepps.h on NetBSD (sys/types.h is needed
  first, at least)

  enable gpsd to do pps with RFC2783 and without TIOCMIWAIT

Attachment: pgpFp8ncGZyYp.pgp
Description: PGP signature

reply via email to

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