[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