[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 11:56:17 +0930

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


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

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

>> However I wanted to used GPSD to process the NMEA (mainly so I can
>> monitor satellite visibility and the like), can it handle the two
>> separate devices correctly?
> Of course.  Very common.
>> 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.

> 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 

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

Any ioctl on a negative file descriptor will fail.

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.

My question is really: Why is the file descriptor set to -2? 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.

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

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

> Can you provide your compile logs?

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]