Question: GPS disciplined stratum 1 NTP service with PPS?

[Dan Cross]

A quick update on this...

On Thu, May 9, 2024 at 11:08 AM Dan Cross <crossd at gmail.com> wrote:
> I'm curious if anyone has set up a GPS-disciplined, stratum 1 time
> server using a PPS signal on Dragonfly? I have an old PCEngines apu1d
> that I plan to dedicate to this task, and I'd like to run Dragonfly on
> this machine. I see that Chrony is in the ports collection (though a
> slightly older version), and I'd like to use that as the NTP server
> software; my question is more about the PPS signal, and finding a
> source for that.
>
> On the hardware side, in many respect, the apu1d is almost an ideal
> system for this application: [snip] and (importantly) has two UARTs;
> one at RS-232 levels, and the second that runs at 3V3. [snip]

Actually, as it turns out, this thing has four UARTs; the first two
are always enabled, and the second two are muxed with GPIO pins, but
updating to the latest firmware gave me an option to toggle between
UARTs enabled versus GPIO enabled. Furthermore, the second two UARTs
are lined out to a GPIO header, including for the modem control
signals. I chose to disable all GPIO and connect the GPS receiver, and
its PPS signal, to UART "D" (sio3), and was able to do that with no
hardware modifications to the APU. Huzzah.

A caveat has to do with IRQs; in the default kernel configuration,
sio3 is assigned IRQ 9. However, near as I can tell, the super IO chip
in the APU initializes this to 3, and the kernel didn't seem to do any
PnP magic to reset it to ITS default (9). Initially I was getting
weird, fragmented output, silo overruns, etc, and it looked like
interrupts weren't working. Because they weren't. Changing the
`sio3.irq` configuration resource at boot and setting the IRQ to 3
fixed that and it seems to work swimmingly.

> The question is more about support for PPS. There is some support in
> the kernel already, and there's a `PPS_SYNC` option and `pps`
> pseudo-device that one can enable in custom kernel configs.

Of course, I was wrong here: `pps` is not a pseudo-device, but rather
a driver for an actual device related to the PC parallel port, which
does not exist on this machine. Red herring, I'm afraid; I saw the
name and got excited. However, I compiled a kernel with PPS_SYNC and
`gpsd` saw that the KPPS API was enabled and is attempting to use it.

> It also
> appears as though the serial driver will inject PPS "events" into the
> kernel's timing machinery when DCD is asserted (or de-asserted, for
> that matter). It's lacking the `gpiopps` driver that's in FreeBSD and
> NetBSD, but perhaps that's not needed, and piggybacking off of the
> modem control signals is "good enough".

A caveat here is that doing this at TTL levels is different than doing
it at RS-232 levels: the signal is active low, but the GPS's TIMESYNC
pulse drives that line high (in RS-232, "0" is positive voltage, "1"
is negative). Thus, this signal is inverted as far as the UART is
concerned. Apparently, the GPS receiver itself can be configured to
invert the polarity of the edges it generates, which would solve that
problem. An alternative would be to build a small circuit that pulls
that signal high and then shunts it to ground when the pulse fires.
Either way, it's easy to fix.

> So it seems like all of the pieces are there. My question is: has
> anyone else tried this? Is my analysis wrong? Are there any other
> caveats to consider? Thanks for any insight!

Progress has been promising, so far.

        - Dan C.