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 a problem if once in a while a pulse was missing, as long as
you know which one that was.
Regards,
Achim.
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).
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. 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. 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.
Stranger things have happened: I put my M8T in an insulated aluminum
bottle and got stronger signals. I put my Pi in an insulated tea box
after drafts from walking by it would change the response time of the
GPIO ports as displayed by PPS-Client.
Running aligned to system time TOS, as system time is brought in line,
then the TimeMark Cycle will be brought in line too. But it's cheap to
pick up the PPS and use that to initiate the Timemark Cycle and get
timemark data aligned to GPS TOS from the start. Or the variance may be
random, or appear to be random based on the limits of the resolution.
Michael
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
