Achim,
On 21/08/2018 2:43 PM, Achim Gratz via devel wrote:
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.
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?
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?
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)
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.
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.
I'll worry about why that is later.
Thanks,
Michael
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
