William Unruh wrote:
On 2015-01-20, Rob <[email protected]> wrote:
It turns out that the device has a mode where you can SEND a pulse at
a moment you decide and then the device RETURNS the timestamp of that
pulse you sent in a serial message.
Presumably you can take a nanosecond timestamp and change the output line
as closest together as possible, then read the returned timestamp and
compare the two.
That is equivalent in precision to receiving a PPS pulse, maybe even better.
(because you don't have interrupt latency issues, the only issue is how
close the pulse moment can be to the reading of the system time)
OK, that would certainly be a different situation. You could presumably
read the clock and toggle the pin to sub microsecond precision. You
would presumeably want a daemon to read the clock and toggle the pin,
perhaps with interrupts turned off for the microsecond required so that they
could not get between
the two. Not sure how long a pulse it requires.
No need for that!
The easy fix is to simply read the local time twice, before and after
toggling the bit:
If those two readings are too far apart (i.e. more than a few us) then
something happened, like a time slice running out or an interrupt
handler taking over the current core, in which case you simply discard
the current reading.
You could also mark it with the timestamp distance so that it would be
weighted less than a good sample.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
