[time-nuts] Testing frequency using NTP

[Hal Murray]

> 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. 

How accurately do you need to know the frequency?  (How much is "slightly"?)

Is your crystal stable enough?  Will it drift off frequency over 
time/temperature while you are listening?



> 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 don't think you need the divider/prescaler.

The basic idea is that your counter only has N digits.  If you count for T 
seconds, you can get any N digits out of the actual count.  If it doesn't 
overflow, there isn't much into in 0s on the top.

If you use a prescaler, that moves the digits you read to the left so you 
just have to wait longer to fill up the counter.  (Binary vs decimal 
prescalers move things by fractional digits.  Let's ignore that mess.  You 
can't get any digits to the right of the decimal point.)

There is a slight advantage to throwing away low digits rather than high ones 
because there is some noise on when you turn things on/off and that goes into 
the low digits.  I expect that's sub microsecond.  1 microsecond of noise 
would be 1 digit at 10 MHz.  So the bottom digit is trash and you only have 6 
useful ones.  Getting another digit isn't worth messing with a prescaler.

If you want to measure your OCXO within 1E8, you need 8 good digits.  You 
have a 7 digit counter counting at 10 MHz.  That will overflow at 1 count per 
second.  The bottom digit is trash leaving 6.  You need 2 fake digits from 
overflow so you have to count for 100 seconds.

I'd probably count for 100.5 seconds so I didn't have to worry about whether 
the overflow was 99 or 100.  You aren't going to get the 1/2 accurate (or the 
0 if you count for 100.0), so you will have to divide the count by the actual 
time (roughly 100.5) rather than 100.

You can also measure at 1 second and 10 seconds to verify that the speed is 
close enough so that you will get the right number of overflows.  If it's way 
off, say 1E6. that still won't show up in 100 overflows.

If I was doing something like this, I'd probably set it up to loop, counting 
for 100 or 1000 seconds, and plot the data.  If they are consistent you 
probably have the right answer.

I'd also grab the OCXO with my fingers to change temperature and/or run some 
CPU intensive job on the PC to see what happens when its temperature changes.

You will probably have to plot it for a week or so to see if it is drifting 
over time.





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