[Top][All Lists]

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

Re: [gpsd-dev] GPSd on FreeBSD

From: O'Connor, Daniel
Subject: Re: [gpsd-dev] GPSd on FreeBSD
Date: Tue, 10 Sep 2019 13:04:45 +0930

> On 10 Sep 2019, at 07:09, Greg Troxel <address@hidden> wrote:
> "Gary E. Miller" <address@hidden> writes:
>>> I get..
>> [...]
>>> gpsd:WARN: PPS:/dev/pps0 die: no TIOMCIWAIT, nor RFC2783 CANWAIT
>>> gpsd:PROG: PPS:/dev/pps0 gpsd_ppsmonitor exited.
>> Your system PPS is not correctly configured.  I'm not familiar enough
>> with BSD to say where...
> I am unsure what's different now between freebsd and netbsd, but my
> impression is that one does pps on serial by doing pps ioctls on a
> serial port, rather than a specific /dev entity just for pps edges
> derived from another /dev entity.

This is a bit different to a normal PC approach.

The GPS engine is connected to a normal UART (/dev/cuau2) but there is a 
special driver  (dmtpps -
 that uses an input capture timer on the Beaglebone SoC to capture the PPS 
edges. This lets you avoid the interrupt latency because the hardware captures 
a 24MHz counter and then raises an interrupt. The kernel driver reads out the 
timer value to work out when it happened.

>>> It seems it isn't actually opening /dev/pps0 (based on the -2 for FD)
>> No, re-read the message.  It just says it can not use TIOMCIWAIT.  It
>> should use KPPS instead, which is better, but that also failed.  I'm
>> not afmiliar enough with *BSD to know why, but it does work for others.
> AIUI, TIOMCIWAIT is an extension to the standards-defined PPS, and is
> present in Linux and OpenBSD, but not in NetBSD.

Yes that is a red herring here, it should use time_pps_* on the dmtpps device 
>>> The PPS API does work on this device:
>>> [gps 7:35] ~/gpsd
>>>> /usr/obj/arm-src/arm.armv7/tools/test/ppsapi/ppsapitest /dev/pps0
>> I'm unfamiliar with ppsapitest.  What does "ppscheck /dev/pps0" show?
> ppsapitest probably tests to the spec.  I'm assuming ppscheck is from
> gpsd, and would test to what gpsd uses - of course quite relevant here.

Unfortunately as per my other email it doesn't build because it requires 
TIOMCIWAIT which FreeBSD doesn't have.

>>> Examining the code shows a big chunk is Linux specific so I guess I
>>> will have to modify it but if someone has advice on what the "right
>>> way" to do is that would be great :)
>> When you compiled gpsd it auto-detects your system.  It will autodetect
>> many flavors of *BSD and work just fine.
> The PPS code assumes there is some ioctl to "wait until a pps edge", not
> found in RFC? that defined the original PPS interface, and there was no
> path to it working well without that - a fairly minor (probably 4 hours
> to code and debug) reorg is needed to make it work without,  without
> impairing performance on systems that have the ioctl.
> I was thinking about this years ago, and have never gotten around to it.

I am not 100% sure what you mean, but I see gpsd has calls to time_pps_* but it 
feeds them an FD of -2 which looks like a bug.
There are a number of '#ifdef __linux__' blocks which I haven't fully decoded 
yet though.

> The ntpd that's part of NetBSD base understands PPS and works with PPS
> devices (without gpsd).  I would expect that FreeBSD base system ntpd,
> or FreeBSD ports ntpd would also do that.

Yes, initially I got ntpd to parse the NMEA sentences and use the PPS edge 
captures, sorry if I wasn't clear enough about that on my initial email.

Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum

reply via email to

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