[time-nuts] Time stamping with a PICPET

[Chris Albertson]

So basically what you are proposing is an NTP reference clock that queries
a known good external clock at semi-random intervals.  The query method is
to send a pulse then read the time from the external clock.

GPS is a "push" device.  It just sends data forever.  What you are wanting
is a "pull" device, one that will tell you the absolute time of a pulse.
It would not be hard to build.  Get a 32 bit counter that is driven by a
10MHz GPSDO.  then a pulse will latch the counter.   You'd need a very fast
logic family if you plan to count nanoseconds.

The query would not be once per second.  NTP would use its normal method to
determine the interval, usually it is much longer than one second.

I bet there must already be an NTP ref clock that is based on query.  that
could be a starting place.


the typical HP counter could work as the clock.  On one channel you feed it
a PPS from your GPS the pulse from the computer goes to the other channel.
  the HP buss sends back the time after the last full second.  This could
be pico seconds if you have the right counter.    So you could implement
this with no solder.




On Sat, Oct 26, 2013 at 4:21 PM, Tom Van Baak <tvb at leapsecond.com> wrote:

> > If the system were to try and create a PPS then it would have to be based
> > on the nanosecond clock  or a hardware count down register based on it.
>  I
> > just cannot see how a count down timer interrupt can have less jitter
> than
> > a DCD line interrupt.
>
> Right. The key is not to use count-down timers and interrupts at all. The
> key is no interrupts; nothing asynchronous. What you do is:
>
> 1) About once a second (it doesn't really matter), with hot cache and
> interrupts disabled, record the s/w time before and after you output a
> pulse. If your PC/SBC has a low-latency DTR or GPIO pin code path, you're
> golden.
>
> 2) Then use external h/w to timestamp that pulse at the sub-microsecond
> level.
>
> 3) And then you compare the s/w timestamp of when the pulse was thought to
> be generated against the h/timestamp of when the pulse was known to be
> actually received. This allows you to compare s/w "pretend" time against
> "actual" h/w time. This jitter-free delta is what NTP can use for its
> discipline algorithm, to smoothly bend s/w virtual time to match real h/w
> time.
>
> > A few people have  gotten around this by moving the computer's timing
> clock
> > off the CPU chip.  Then you can use hardware latches and such that have
> > very predictable timing.  I think this is the only way to improve the
> > current system.  You have t remember that there is a large and active
> > community of researchers who have been working on this for just over 30
> > years now in the latest development version that are talking about
> > nanosecond level time keeping.
>
> If the CPU/PC/SBC has h/w counter/capture latches, you're all set. Then
> there's no jitter and NTP should be as accurate as the ADEV(tau 1s) of the
> LO that clocks the CPU and the ADEV(tau) of the external (GPS) 1PPS source.
>
> But h/w counter/capture is something no legacy PC has had AFAIK. If the
> new breed of SBC have this capability, NTP should show a one or two orders
> of magnitude jump in precision on those platforms.
>
> /tvb
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>



-- 

Chris Albertson
Redondo Beach, California