[ntp:questions] Re: TAC-2 internal delay

David L. Mills mills at udel.edu
Wed Oct 22 17:22:07 UTC 2003


In FreeBSD you can use a TTL signal via the parallel port, which avoids
the slew delay and UART chip. Even so, the incidental interrupt jitter
on an ISA (!) test machine is about a microsecond. Typical results for
other machines are at
http://www.eecis.udel.edu/~mills/nanokernel/proof.html. Be advised the
figures show the actual VFO adjustment, not the jitter apparent at
interrupt time.


Tim Shoppa wrote:
> shoppa at trailing-edge.com (Tim Shoppa) wrote in message news:<bec993c8.0310200757.594ff855 at posting.google.com>...
> > test <test at iinet.net.au> wrote in message news:<ge92pv0ta14fj5u9o7djco6pp4ga5jl9tg at 4ax.com>...
> > > Looking at the TAC-2 schematic, the 1PPS signal from the GPS module
> > > gets to the DCD serial pin via one 74AC04 and one MAX232.  The
> > > datasheets I have for these chips give their propagation delays as 8ns
> > > for the 74AC04 and 1.3us for the transmit section of the MAX232.
> > >
> > > So, the question I have is about the relevance of the 8ns receiver
> > > delay.  Shouldn't it be closer to 1.3us, or am I just missing the
> > > point completely?
> >
> > The 1.3 us number for the MAX232 includes the effect of driving a
> > long capacitive line.  When driving a short line, the actual delays that
> > I've measured are much shorter.
> I went back and re-measured, and it's not all that much shorter without
> a capacitive load.  It seems that the MAX232 is internally slew-rate
> limited, not surprising considering that the RS-232 standard specifically
> limits the slew rate and traditionally this was done by just putting
> extra capacitance on driver outputs until the slew rate condition was
> met.  This seems to be a feature of the MAX232 that doesn't exist
> with older RS-232 drivers.
> Looking inside my gadget box, I see that I used a MC1488 driver, and with
> the slew-rate-limiting-capacitor removed I measure a propagation delay of
> about 60ns to "assert" and about 200ns to "de-assert" on DCD (I may have the
> polarities mixed up... only one matters for NTP!).  I should
> also note that my motherboards' (ECS K7S5A and Via Epia) DCD input will
> not reliably interrupt on pulses as short as 1 microsecond as put out by some
> GPS receivers... I used a one-shot to stretch it out real long.  In
> retrospect, with slew rate limiting it's likely that 1 microsecond is
> just too short to be reliable.
> I might try noodling around with MAX232 vs MC1488 for delivering PPS to
> a commodity motherboard's serial port and see if there's any
> measurable difference in jitter measured by the nanokernel.
> Tim.

More information about the questions mailing list