[ntp:questions] Atom PPS with parallel port

William Unruh unruh at invalid.ca
Sun Feb 23 20:04:24 UTC 2014

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.

> David

More information about the questions mailing list