gpsd-dev
[Top][All Lists]
Advanced

[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 16:30:52 +0930


> On 10 Sep 2019, at 13:48, Gary E. Miller <address@hidden> wrote:
> On Tue, 10 Sep 2019 13:04:45 +0930
> "O'Connor, Daniel" <address@hidden> wrote:
> 
>>>>> 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 node.
> 
> If you understand the issue, then send a patch.

I understand what I want it to do, but I don't understand the internals of GPSd 
- I am trying to work it out but it's slow going.

>>>> 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.
> 
> Ah, yes, scons is not building due to no TIOMCIWAIT.  I thought that
> had been fixed...

Looking at the ppscheck code it seems it only works with the TIOMCIWAIT ioctl 
so running it isn't useful for checking kernel PPS captures.

>> 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 FD of -2 is after the first failure.  The first failure is the
> failure to open the device, which returned the error code of -2 in place
> of an FD.  It does look like gpsd should not have continued using the
> error return as an FD.  But the first failure was earlier than you are
> looking.

There is no log message associated with the failure to open the device 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.
> 
> Figure out what NTP is doing and let's see if we can get gpsd to do
> similar on your distro.

NTP attempts to open /dev/gpspp0 and since it succeeds it uses that to get PPS 
info, it then opens /dev/gps0 and parse the NMEA.

It would be good if I could pass gpsd my PPS source and it used it purely for 
PPS, however I don't know if that is possible (I think so though).

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