u-blox LKM Timemark driver

[Achim Gratz]

MLewis via devel writes:
> That would mean the trigger lag should be close to the rise time of
> the port and the timemark should be extremely close to the time
> captured back in the kernel?

The GPIO on the rasPi is synchronized by the 19.2MHz clock (the SoC
would allow this to use a different clock, but my understanding is that
it is indeed run off the main crystal).  So you end up jittering by
~52ns, both in and out.

> A case for making the leads as short as possible, or just not stupidly long?
> I've got leads from the Pi to the com breakout board that are 140 mm,
> and the com cable to the GPS board is ~180 mm. Or does the resolution
> in the kernel mean these lengths aren't relevant?

1mm=3.3ps (or 1ft=1ns for you imperial types), slightly more if the
capacitive load is significant.  So you really don't care much about
that part of the delay as it is still swamped by jitter and it's
entirely systematic, so you can take it out by simply substracting if
you feel the need (timing recievers have a parameter for "cable
compensation" to shift the PPS pulse by some amount that corresponds to
cable dealy or whatever else you want).

> Interesting. I hadn't realized why they did that. And I'm sure I don't
> understand the significance of that, but it sounds intriguing.

It means that as long as the ADEV of your clock source on a 1s interval
is around or below 10^-9, you can measure the frequency of a pulse train
to almost 1ppb precision using the timestamping facility.  If it's a
worse clock (which is likely), then the error you make in that
measurement is entirely due to the clock you measure for all practical
purposes.


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

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds