[ntp:questions] Atom PPS with parallel port
David Lord
snews at lordynet.org
Sun Feb 23 20:51:10 UTC 2014
William Unruh wrote:
> On 2014-02-23, David Lord <snews at lordynet.org> wrote:
>> Rob wrote:
>>> I would like to use the Atom driver (22) on a Linux system with a
>>> parallel port. It is not clear to me from the scattered info I have
>>> found on internet if this is going to work.
>>>
>>> Using a modern Linux kernel with the PPS module, is it possible to
>>> symlink /dev/pps0 to a parallel port device and then connect the PPS
>>> signal to the ACK input (pin 10)?
>>>
>>> If not, what else is required to get this working?
>>>
>>> Examples always refer to the use of a serial port DCD input, but for
>>> best accuracy (in the microsecond range) I think the parallel port
>>> is better.
>>> (no RS232 drivers/receivers, no funny UART that may delay interrupts)
>>>
>>> Any other suggestions for an accurate PPS input?
>> On NetBSD with stock ntpd, pre 2010, I did comparisons of
>> pps from Sure GPS with output from dcd at ttl level vs the
>> "serial" dcd but didn't really see any consistent difference.
>> From loop_summary the rms offsets from either would be 4-6 us
>> due to temperature changes (ambient and from system load)
>> with peaks of 30-100us otherwise rms offset would have been
>> significantly lower. Weekly log on Saturdays gives an
>> additional and larger peak.
>>
>> loopstats range(us) rms
>> 20140219 9+/-38.6 4.5
>> 20140220 7+/-37.9 4.5
>> 20140221 9+/-39.1 4.6
>> 20140222 20+/-49.2 6.2
>>
>> I just symlinked from lpt to pps but not certain if I needed
>> to set a flag in ntp.conf. I also used this to compare two pps
>> signals, serial vs parallel one marked noselect.
>
> The problem with trying to compare interrupts from two different sources
> on a single machine is that there will be something like a 10us
> difference always simply because the first interrupt processed has to
> read the clock to timestamp the interrupt before the interrupts are
> released and then the interrupt handling routine has to send the second
> interrupt to the relevant program for processing before the second can process.
>
> As I said when I did this I found about a 10us delay between the two
> interrupt processings.
I was testing some homebrew xtal oscillators that were divided
down to give around 1 Hz. They were sometimes at a stable offset
and varied within a range of 10 ms but other days the would have
gained or lost a second or more.
For comparing different PPS outputs at least one of my receivers
has a presettable offset that can then be fudged out by ntpd so
avoiding interrupts being too close together.
David
More information about the questions
mailing list