[time-nuts] Testing frequency using NTP

[Steve Rooke]

Scuse me for top posting.

Guess I'm going to do something a bit like plan 3 but mostly in
hardware. My plan for the PC is just to use it to gate the oxco output
into the pre-scalier divider chain for a specific time period. The
output of the pre-scalier will be a series of pulses which can be
counted (as in 1,2,3,... not frequency counted) by my Fluke 1912A
Multi Counter in Tot (Totalise) mode.

Say I divided the oxco to produce an exact PPS output from the divider
chain (not the easiest thing to do when starting from 10MHz). If I
count for exactly 10^7 seconds, as gated by the NTP disciplined Linux
system, I should see 10000000 on the counter. So this should give me
.1ppm accuracy, in theory, in the text book case. Now, if I change the
divider to give 10 PPS and sample for 10^7 seconds, the counter will
overflow, as it only has 7 digits, but I know the top digit will be a
1 and I'll be able to see the .01ppm accuracy, if you get my drift. I
could do this with various divider ratios, IE. 100 PPS, 1000 PPS, etc,
to get at more and more digits.

I'm not planning to use this oxco to sync the NTP on my PC, just using
NTP to check the frequency of my oxco so I can use it to calibrate my
counters, as a timebase and hence to allow me to lock amateur radio
transceivers to a precise frequency for QRP (very low power long
distance work). If your not spot on the frequency you can miss a
signal. If I know that I am bang on the frequency, I can use a very
narrow band filter to pull a signal from the noise floor but if my
frequency is even slightly off, the filter will just remove the signal
I am looking for.

Now don't shoot me as I'm not directly thinking of this project in a
true time-nuts way but your group has some interesting aspects for the
work I am doing.

73
Steve

2008/10/2 Hal Murray <hmurray at megapathdsl.net>:
>
>> 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.
>
>
>
>
> _______________________________________________
> 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.
>



-- 
Steve Rooke - ZL3TUV & G8KVD
Omnium finis imminet