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 cl
Achim,
On 21/08/2018 5:54 PM, MLewis via devel wrote:
On 21/08/2018 2:43 PM, Achim Gratz via devel wrote:
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
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
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
Achim
On 20/08/2018 4:04 PM, Achim Gratz via devel wrote:
MLewis via devel writes:
Agreed. Except possible benefit with alignment, as described above.
You don't need any alignment either way (for NTP that is), just
reasonably equal-spaced pulses to correlate system w/ GPS time. It's
not even
