[ntp:hackers] u-blox reference clock driver

Achim Gratz Stromeko at nexgo.de
Mon Aug 20 17:23:36 UTC 2018

Udo van den Heuvel via devel writes:
> I'd see a setup with a USB connection for the data part of the setup.
> PPS goes to LPT (ack pin).
> LPT strobe could be used to send pulse to the ublox(*1).


> At the ntpd level I could use the pps driver for pps reception, this
> should work with LPT port as well.

I'm not sure the LPT code is active by default in the PPS driver, but I
guess not since ages, so it likely needs cleanup.  But on rasPi we
really want the PPS echo via GPIO, so that's something to add to the
driver and device tree.

> Once the ublox driver is in ntpsec things change a bit:

I'm not sure this is the right way to go about that.  In principle it
should all end up in some souped-up version of the PPS API (PPS in
timestamp, PPS echo configuration, PPS echo timemark feedback).

Configuring the timemark for whatever way is used to get one should be
handled like "firmware" for any other driver.

> How to get the timemark kernel patch into Linux?
> Do we really need it? (can we work around it?)

You could do the whole time mark evaluation stuff in user space without
any problem, only the PPS echo _must_ be in the PPS driver.

> Udo
> *1: see https://lore.kernel.org/patchwork/patch/237682/ where the LPT
> pps generator is declared BROKEN; this driver (see
> https://lwn.net/Articles/373193/) could still be the basis to simply
> send a pulse when called as clear edge is not so important, we can
> loosen the no-interrupt time considerably?

There is actually no need to be extra precise on the clear edge of the
echo as long as you get a timestamp right before (and maybe after)
toggling the bit.  You only care about the relation of that timestamp to
the time mark from the GPS.

+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:

More information about the devel mailing list