Re: [gpsd-dev] GPSd on FreeBSD

[O'Connor, Daniel]

> On 10 Sep 2019, at 12:13, Gary E. Miller <address@hidden> wrote:
>> 
>> My reading of the NTP NMEA refclock code suggests that it will
>> attempt to use /dev/gpspps0 to go with /dev/gps0 since flag1 is 1.
> 
> Uh, that is NTP, this is gpsd.  Different projects.

Yes I know, I wanted to demonstrate (to myself mostly) that the GPS engine & 
PPS capture are working properly before adding GPSd into the mix.

>> [ Note that I forgot to mention in my original email that I have a
>> symlink from /dev/gpspp0 to the device capture device /dev/dmtpps ]
> 
> None are device names that I recognize.  Why did you do that?

That's what ntpd wants.

>>>> And it all looks good:  
>>> 
>>> Not really.  Your NTP is not using the SHM(0).  Which is a good
>>> thing. It should be using your SHM(1), your PPS.  
>> 
>> I think NTP must be using PPS otherwise the jitter would be much
>> higher.
> 
> Your ntpmon showed that you were NOT using the local time from gpsd!

Yes, as above.

>>>> in the foreground, with debug on high, degrades your timing
>>> quality.  
>> 
>> Sure, it was done to produce logging to demonstrate the issue, and
>> given it should be using the kernel for PPS edge capture I think it
>> wouldn't have an effect.
> 
> Well, the logging demonstrated it was NOT using KPPS.  Nor TIOMCIWAIT
> PPS.  So no PPS at all.

You seem to be missing the point that it is trying to do time_pps_create on a 
file descriptor set to -2 which is not a valid 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.  
>> 
>> Any ioctl on a negative file descriptor will fail.
> 
> You misunderstand the failure.  Always look at the First Failure (FF).

The "first failure" I can see in GPSd output is:
gpsd:INFO: KPPS:/dev/pps0 time_pps_create(-2) failed: Bad file descriptor

The "Bad file descriptor" is because it is trying to do an ioctl on -2.

>> I don't have ppscheck and I am not sure what it does. ppsapitest just
>> opens the given device and captures edges and logs the result.
> 
> ppscheck check comes with gpsd.  We are talking about gpsd, so you must
> have it.  If not, your gpsd install is bad.

ppscheck doesn't build:
cc -o ppscheck.o -c -pthread -Wall -Wcast-align -Wextra -Wimplicit-fallthrough 
-Wmissing-declarations -Wmissing-prototypes -Wno-missing-field-initializers 
-Wno-uninitialized -Wpointer-arith -Wreturn-type -Wstrict-prototypes -Wvla -g3 
-O0 -pthread -I/usr/local/include/dbus-1.0 -I/usr/local/lib/dbus-1.0/include 
ppscheck.c
ppscheck.c:113:16: error: use of undeclared identifier 'TIOCMIWAIT'
        if (ioctl(fd, TIOCMIWAIT, TIOCM_CD|TIOCM_DSR|TIOCM_RI|TIOCM_CTS) != 0) {

>>>> 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.
>> 
>> For just parsing serial data it works fine, PPS not so much :)
> 
> Looks to me like it worked fine.  It told us that you have no
> TIOMCIWAIT, but you have KPPS.  See below.
> 
>>> Can you provide your compile logs?
>> 
>> http://www.dons.net.au/~darius/gpsd-build.log
> 
> Checking for C header file sys/timepps.h... yes
> Checking if sys/ioctl.h supplies TIOCMIWAIT... no
> 
> As expected, you have KPPS, but not TIOCMIWAIT.  But when you ran
> gpsd the KPPS failed.

It failed to do either TIOCMIWAIT or time_pps_create because FreeBSD doesn't 
support the former and it called the later on an FD of -2.

My question remains: Why is it setting that FD to -2 then trying to do 
operations on it?

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