Re: [gpsd-dev] GPSd on FreeBSD

[O'Connor, Daniel]

> On 13 Sep 2019, at 05:13, Gary E. Miller <address@hidden> wrote:
> 
>>> I'm not about to extend the kludge, I want to kill it off.  Just put
>>> "/dev/pps0" on your gpsd command line.  
>> 
>> I tried that first, it doesn't work:
> 
> Works for me.  I do it on more than half a dozen RasPi's in my test rack.
> Plus a bunch of other test servers.
> 
> Not sure why it does not work for you.  *BSD do their own thing.

They follow RFC2783 though..


>>> If I run gpsd like so..
>>> sudo ./gpsd -D5 -NnG /dev/gps0 /dev/pps0
>>> I get..
>>> gpsd:PROG: selecting PPS driver...
>>> gpsd:PROG: PPS:/dev/pps0 chrony socket /var/run/chrony.pps0.sock
>>> doesn't exist
>> gpsd:INFO: KPPS:/dev/pps0 RFC2783 path:/dev/pps0, fd is -2
> 
> Yes, as previsously discussed.  Someone needs to look into why that
> fails for you.  I don't have you distro, so can only guess.
> 
> Note the code in ppsthread.c new line 337 that notes *BSD do things
> differently than other distros.  It does appear to break the use
> of /dev/pps0 on *BSD.  It also seems to miss a lot of the special
> cases the linux code handles.  Someone that knows your *BSD will have
> to fix that branch.

The code seems to unnecessarily special case Linux and call non-portable Linux 
specific features (eg sysfs and TIOCMIWAIT).

> What error is -2 on your distro?

As far as I am aware no sys call would ever return -2. Errors are always -1 or 
NULL depending.

I think the -2 is more likely to be PLACEHOLDING_FD or DEVICE_ERROR from gpsd.h.

> The "#ifdef __linux__" on line 238 of ppsthread.c, very near the -2 error,
> shows the *BSD path is very different.  Not knowing *BSD I can't say
> what needs to get fixed.

I'll have to debug things.

>> If I put both /dev/cuau2 and /dev/dmtpps0 on the command line I see
>> it get timeouts for cuau2 but work for dmtpps:
> 
> Is it possible the link /dev/gps0 to /dev/cuau2 is confusing things?
> 
> Since it works further, I would stop using the gps0 link and use 
> cuau2.

Possibly, I will do more testing.

>> KPPS:/dev/dmtpps assert  1568261257.999806732, sequence: 266942,
>> clear   0.000000000, sequence: 0 - using: assert
> 
> That is a good timestamp.
> 
>> gpsd:PROG: PPS:/dev/dmtpps Assert ignored missing last_fixtime
> 
> That says your NMEA has not reported valid time yet.  What happens if you
> wait 30 mins?  (For leap seconds in the almanac).

But dmtpps will never have a NMEA sentence on it.
It is *only* for PPS captures.
The NMEA traffic is *only* on cuau2, it will never get PPS captures (it will 
accept time_pps_fetch calls but they will always timeout)

>> However after a little while it seems to give up on dmtpps (I guess
>> because it's not producing any actual GPS messages):
> 
> No, this is why it does not use the KPPS:
> 
>> gpsd:PROG: PPS:/dev/dmtpps Assert ignored missing last_fixtime

What does that actually mean though?

> This is something else, not sure what:
> 
>> gpsd:PROG:
>> KPPS:/dev/dmtpps descriptor cleaned up gpsd:PROG: PPS:/dev/dmtpps
>> gpsd_ppsmonitor exited.
> 
> 
>> So I guess that is why the kludge for the Pi Hat is there - to allow
>> you to fuse the two devices into one.
> 
> Sorry, apples and oranges.  The RasPi works just fine w/o the MAGIC_HAT
> kludge.  It is just a "convenience" that confused people.

I think that without the kludge it won't get PPS edges captured, it will only 
do timing based on NMEA sentences.
(based on the 
https://learn.adafruit.com/adafruit-ultimate-gps-hat-for-raspberry-pi/pinouts)

It looks like this is connected to a normal GPIO pin that generates an 
interrupt and presumably the kernel then timestamps the edge (based on 
http://www.unixwiz.net/techtips/raspberry-pi3-gps-time.html and 
https://github.com/torvalds/linux/blob/master/drivers/pps/clients/pps-gpio.c). 
This is pretty similar to what I am trying to do with the BBB in that there are 
2 separate devices connected to the same time source, one for NMEA sentences 
and one for PPS captures, hence I think I need the "Pi hat kludge" but fix it 
to work for FreeBSD.

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