[Top][All Lists]

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

Re: [gpsd-dev] GPSd on FreeBSD

From: Gary E. Miller
Subject: Re: [gpsd-dev] GPSd on FreeBSD
Date: Mon, 9 Sep 2019 19:43:55 -0700

Yo Daniel!

On Tue, 10 Sep 2019 11:56:17 +0930
"O'Connor, Daniel" <address@hidden> wrote:

> > On 10 Sep 2019, at 03:47, Gary E. Miller <address@hidden> wrote:  
> >> These end up as cuau2 (symlinked to /dev/gps0) and /dev/dmtpps
> >> (symlinked to /dev/pps0) respectively so my ntp.conf looks like:
> >> server mode 0x12 minpoll 4 maxpoll 4 fudge
> >> time1 0 time2 0 flag1 1 stratum 0 refid GPS <snip>  
> > 
> > Uh, don't do that!  You are trying to set time on the NMEA stream,
> > which will be jumpy on the oder of hundreds of ms.
> > 
> > You need to set the time on the PPS.  Check out the time-server
> > howto.  
> 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.

> [ 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?

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

> >> If I run gpsd like so..
> >> sudo ./gpsd -D5 -NnG /dev/gps0 /dev/pps0  
> > 
> > Well, other than that sudo is bad, that is very common.  Running  
> I plan on tightening up the permissions once I get it working
> correctly.

Any and all use of sudo is bad.  Delete it from your system.

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

> > 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).

> Although even if it had opened it it would have failed because dmtpps
> is not a tty, however the PPS_* ioctls used to implement time_pps_*
> will work.

Yes, we already know that *BSD do not support TIOMCIWAIT.

> My question is really: Why is the file descriptor set to -2?

It is not.  That is a failure code.  Which is expected since *BSD never

> The code
> mentions something about reserving a slot which implies it is
> expecting some other code to open it (perhaps). but I haven't fully
> traced it out yet.

Does not matter as *BSD does not support TIOMCIWAIT.

> >> 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?  
> 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.

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

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.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgp8Raxh6lYi5.pgp
Description: OpenPGP digital signature

reply via email to

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