Dustin Marquess <dmarqu...@gmail.com> writes:
> On Nov 15, 2023 at 8:42 PM -0600, jo...@sdf.org, wrote:
>> Hello -- Does NetBSD support PPS output from a USB GPS? I'm
>> using NetBSD 10 RC1.
>>
>> I have a USB GT-U7 GPS module attached, and I have gpsd running on
>> /dev/ttyU0 and receiving GPS data. This looks good.
>>
>> After configuring ntpd, when I run ntpshmmon, I'm seeing NTP0, but no
>> NTP2. If I understand correctly, NTP2 is PPS. This seems to be confirmed
>> with ntpq -p, where I don't see a PPS peer.
>>
>> I unfortunately couldn't find anything when searching on this topic.
>>
>> My goal is to replace an aging RPi3 with a Rock64 running NetBSD as an NTP
>> stratum 1 server.
>
> I believe you have to use gpioctl(8) to mark the pin as the PPS pin.
>
> There's some helper scripts on https://anduin.eldar.org/stratum-1/ that you
> might be able to use.
>
> -Dustin
No, there is no support for the /dev/ttyXX based IOCTLs that glue a PPS
signal to a TTY port [1]. If there is an output on your GPS device for
a pure GPIO style PPS signal, something that is either 5v or 3.3v in
nature and pulses once per second at a digital logic level, you can feed
that into a GPIO pin and use gpiopps(4) to utilize the pulse-per-second
that way [2]. I have been doing that with GPS modules for years with
NetBSD and run 2 GPS Stratum 1 NTP servers and 1 WWVB Stratum 1 NTP
server.
As for stability and accuracy... using just the USB data alone will
yield very poor results, as has been mentioned. That can, however, be
used for a quick test with the NEMA driver that ntpd has, just don't be
impressed by it. By adding the digital PPS signal into the mix that
will deal with the USB problems and you will get a good result once the
device and ntpd stabilizes. My modules present their NEMA output as
digital tty (uart) signals that I hook to a FTDI chip and into a USB
port... so the effect is very simular to what you are probably doing. I
also use ntpd which can deal with both a /dev/ttyXX NEMA device and
/dev/gpioppsX PPS device at the same time. In this arrangement, you
won't be using shared memory and your output would look something like
this:
% ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*GPS_NMEA(0) .GPS. 0 l 6 8 377 0.000 3.097 3.958
oPPS(0) .PPS. 0 l 4 8 377 0.000 0.000 0.005
A snip of /etc/ntp.conf:
server 127.127.20.0 mode 65618 minpoll 3 maxpoll 3 prefer
fudge 127.127.20.0 time1 0.0 time2 0.072767 flag1 0 flag2 0 flag3 1 refid GPS
server 127.127.22.0 minpoll 3 maxpoll 3 prefer
fudge 127.127.22.0 flag3 1 refid PPS
You should start out your fudge of time2 at 0 and work with it until you
come up with the value that is correct for your particular module and
environmental conditions. Every module will have a different inherent
correction and stuff like room temperature and the like will effect
these modules and that will be noticed as drift and skew that will have
to be compensated for [3].
Good luck with your efforts....
[1] - if this were to be done, a "mux" device is probably a better
answer here... something like wsmux that takes a /dev/ttyXX and a
/dev/gpioppsN and presents one device. Nothing like that exists,
however.
[2] - from a very brief look at stuff called "GT-U7" on Amazon (which
may or may not be at all the same device you have) it appears that pin 3
of the module is the PPS signal. If your particular implementation
brings that out then that is what you would tap and feed into gpiopps.
To test that you are getting a pulse you can use gpioirq against the
GPIO pin or compile up the PPS tools that are all over the Internet and
use the ppstest utility to see the pulse-per-second output from
/dev/gpioppsN.
[3] - there are a ton of other factors that also can effect the PPS
signal, in particular, like activity on the small computer running all
of this (like the weekly and daily cron jobs). If you plot out the
skew, delay, etc.. and feed that into something that can visualize it
(like Elasticsearch) you will notice spikes at times. These are not a
big deal as long as they are only occasional.
--
Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
