> 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 -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
