yesterday I decided to make a more recent patch for kernel PPS
support. The patch is now against 2.0.26, but the previous version
also worked. The patch can be found in
/pub/wiu09524/PPS/design.tar.gz on pcphy4.physik.uni-regensburg.de.
I also updated the serial driver to make Ted sleep again (he was
worried a lot about calling do_gettimeoffset() from within the serial
interrupt routine). I still call do_gettimeoffset() from within
interrupt, but only if PPS detection is enabled on the corresponding
port, and the reason for the interrupt was a PPS pulse. I hope that
Ted is satisfied.
Now the do_gettimeoffset just has to be correct (I hope it is).
As several people wanted to play with that patch, I'll give a very
short summary (HOWTO):
You have to apply the patch (of course), then you have to reconfigure
the kernel using "experimental features". After the serial driver
there is a new option about "PPS support"; use that. (The current
patch can't make the serial driver as a module, because I didn't know
how to export an additional symbol scorrectly for module use. Help
anybody?) Rebuild the kernel, install it and reboot.
One really ugly sample program (enable_PPS.c) tries to turn on PPS
detection for stdin; that only works if you redirect your serial port
(enable_PPS </dev/cua1). The program periodically outputs some
essential data about the kernel clock state. Also, if you terminate
the program the PPS detection is turned off again (close seems to
restore the drivers state).
Ok, you are read now. You just need a PPS pulse. If you don't have a
frequency oscillator, you might use the second ugly program
(rtctest3.c) that uses the independent RTC to generate a PPS pulse on
one serial port (RTS pin as far as I remember). You just need a cable
to feed the RTS output to the CD input of your "PPS port" (connect
the ground too, please). The latter ugly program wants to have two
arguments, serial port names. The first will be used to create the
output pule, the second is almost unused, but needs to be given (thus
an ugly program).
If it works you should be getting serial interrupts (two per second,
but one is ignored) and the 0x100 bit in the clock status should be
set immediately. After a while (12 seconds) the PPS frequency should
change for the first time and the shift constant should increase.
Stability should go down below 10ppm at least.
For use with xntp you should leave the serial port with the PPS pulse
alone (with enable_PPS.c running). xntpd knows _nothing_ about HOW
the PPS signal arrives in the kernel; it just recognizes that it is
there and what effects it causes.
For the electric levels required: about +-2V with a duration of a few
microseconds should do (the serial interrupt is generated upon level
change, but the level has to be sustained until the interrupt routine
can read the current level; the level is not latched. Right, Ted?)
I don't know exactly what the exact stability of the PPS signal has
to be, but it's rumoured that it should be off less than 1ms per
second.
Up to now I could not test anything better than the RTC solution,
because at work where there is a PPS signal with 50microseconds
precision I have no Linux box close to the signal...
To my understanding the code works just fine. Opposite proofs
appreciated!
Ulrich Windl