[time-nuts] Testing frequency using NTP

Hal Murray hmurray at megapathdsl.net
Thu Oct 2 03:39:13 EDT 2008


> I'd planned on a simple interface to the PC via using the parallel,
> suitably strapped, as a basic output port. Now, I could use it as an
> input but I'd probably have to poll the port which would be somewhat
> inefficient but an option I guess. Think I could just record the
> staring time of the sampling and then the ending time plus the number
> of cycles. 

Most *nix kernels have options available to grab the system time on 
interrupts from changes on the modem control lines.  This is what ntpd uses 
to take advantage of local reference clocks with a PPS line.

With NetBSD and FreeBSD it's included in the mainline sources.  You may have 
to recompile your kernel after turning on some option.  With Linux, it's a 
not in the official kernel sources.  There are normally patches available, 
but I've lost track of where to get them and/or which versions of the kernel 
are supported.

Some systems may have options to use a printer port rather than a modem 
control signal.


If I wanted to use ntp to measure frequency....

Start by running ntpd to stabilize the local clock.  With care and luck, that 
will get your local clock to somewhere between 0.1 ms to 10 ms.  Let's call 
it 1 ms since that makes the handwaving simpler.  You can do much better with 
a PPS signal from a local GPS unit. (under $100)

You can track temperature changes in the drift file.  The temperature changes 
depending upon what your PC is doing.  Without a local PPS, network traffic 
can screw things up.

Plan 1 would be to use the PPS stuff above.  Run a big divider to get down to 
roughly 1 PPS.  Wire that up to a serial port input.  Run another program to 
record the time stamps from the modem interrupts.  Collect a lot of data, 
then analyze it.

The PPS samples should be accurate to within a few microseconds.  You may 
have to run some filtering to discard the late samples.  I'd do something 
like graph the offset from the current second which should be a constant and 
then eyeball it to see what should get filtered out.


Plan 2 would be to use your clock to drive a PIC/AVR/whatever and use that to 
implement a big counter.  (details TBD)  A monitor program running on the PC 
would flap a modem control signal (outgoing, not incoming like the PPS) to 
poke the micro.  When it gets poked, the micro saves the value of the counter 
and sends it to the PC over an RS232 link.  The monitor program would log the 
time it did the poke and the value of the counter it received.

If you don't like programming micros, plan 3 would be to implement plan 2 in 
raw hardware.  It's just a big counter, a big shift register, and a bit of 
logic to load the shift register when poked.  (An FPGA would be fine but you 
can do it in DIPs.)  The RS232 start/stop bits are just constants loaded into 
the shift register.

So, if your system clock is within 1 ms and you run for 1000 seconds, the 
answer should be within 1 PPM.  (give or take a factor of 2 and some mumble 
about how you are going to verify that your system clock is really that good).



I don't quite know what your external counter can do.  Totalizer mode sounds 
like maybe it can latch a copy of the current count when you poke it and 
still keep counting until you poke it again.  If so, a monitoring program 
could grab the time, poke, read the counter, and log the values.  (No PPS 
kernel stuff needed.)  I think that's as good as you can get.  It's plan 2 
above implemented in an expensive box.  I'm assuming it will keep counting 
when it overflows or clear the counter on each poke.  You need to read it 
often enough where often enough depends upon how many bits the counter has.  
(The counter can overflow many times as long as you can tell N overflows from 
N+1.)

That won't work as well if your counter doesn't keep counting after each 
poke, Say you can start/stop it, but it doesn't have a shadow register that 
gets latched when you poke it and you can't read it while it's running.  You 
could, read the time, start it, wait a while, stop it, read the time, then 
read the counter.  That should give you good results.  The idea is ntp will 
keep your system clock ticking at the right rate.  ntp calls the correction 
"drift".  You don't care how far off your clock is as long as the rate is 
good.

One trick is that you want to read the time both before and after each poke.  
Subtracting the two can be used to detect the scheduler doing something nasty 
or an interrupt at an unlucky time or ...



If you have something like a TBolt, you can feed its 10 MHz output into the 
external clock of a counter and then tell the counter to count for a long 
time.  That gets NTP out of the critical parts of the loop.

My HP 4334B gives numbers like this:
  54741 22324.410 F +1.0000000004E+07 F  +9.999999999E+06
  54741 22624.490 F +1.0000000004E+07 F  +9.999999999E+06
  54741 22924.570 F +1.0000000004E+07 F +1.0000000000E+07

That's clocked from a HP Z3801A.  The 1.0...04E+07 column is a LPRO Rubidium 
brick.  The 999s column is a TBolt, collected over 60 seconds.  The LPRO 
column is rock solid.  The TBolt column is mostly 999s with an ocasional 
1.0...0 and a very occasional 1.000...001  Boring.

If you are measuring an OXCO rather than a GPSDO, counting for 60 seconds is 
long enough to watch it wander around.  I did that for a while, but I can't 
find the log files.

I'll set it up again if anybody is curious.


Another thing you could do with a TBolt is turn things inside out.  Feed the 
TBolt into your setup rather than the OXCO.  Now all the clock wander is in 
the measuring system so you can get an idea of how well this idea works.


-- 
These are my opinions, not necessarily my employer's.  I hate spam.






More information about the time-nuts mailing list