[ntp:hackers] u-blox LKM Timemark driver

[Achim Gratz]

MLewis via devel writes:
> I once saw numbers and a timing diagram on the time range that the M8T
> takes to capture its timemark (haven't found them again).

My guess is that you've been looking at something other than an M8T.

> I'm speculating that the lag to timemark could be variable, and that
> it could be variable depending on what else the module is working on
> at that time. I don't know how regulated its tasks are, except that it
> has to PPS at TOS, and follow that with messages, so there's known
> load at that point.

There's no official documentation that I'm aware of, but from the bits
and pieces scattered about the uBlox forum I guess you'd be wrong.  I'm
almost certain that the timemark feature is implemented using a hardware
timer, specifically using the same free-running counter that produces
the local clock and then four capture registers triggered by the rising
and falling edges of the two possible inputs.  These then get read out
at the epoch and transferred to GPS time the same way the PPS correction
gets calculated.  There's a counter that tells you how many edges have
been seen as well (that will enable you to use much higher frequency
signals provided the frequency stays stable over one second and just
measure the last edge for the fractional timing), but since only the
last event gets latched, you only get one timemark per epoch.

> So by being able to align my Timemark Cycle
> (EXTINT0 rise, EXTINT0 fall, EXTINT1 rise, EXTINT1 fall) to the GPS
> TOS, that may expose different levels of jitter based on when in a
> second the timemark takes place. There may be a difference in response
> between detecting a rise vs. a fall. Where's the threshold in each
> direction... Plus the rise vs. fall time may be different on the Pi
> GPIO ports.

If you're going to drive long lines you'd need a proper buffer and for
short ones I don't expect much of a difference if the GPIO is properly
configured.

> We may get less jitter using the offsets from the two
> rises. Or the two falls. Or only the second fall. Until we have data,
> we won't know. Will it matter? Not likely, but what if it does. And
> it's cheap to know. Code for that is already done; add a lead for the
> PPS pin.

You'd get the same effect much cheaper is you simply set the period
slightly longer than one second.


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

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra