As many of you know, I run an ‘open access’ stratum 1 NTP server (ntp.remco.org) for almost four years now.
In fact, ntp6.remco.org is one of the few open access IPv6 NTP servers worldwide. During this period ntpd was disciplined with a DCF77 radio module, keeping the time within a few milliseconds of CET/UTC.

One of the problems I encountered was that Linux lacked a for me understandable PPSAPI, and still has no easy nano kernel implementation. Recently Rodolfo Giometti started writing a PPS implementation for the Linux kernel. He wants it to be inserted into the 2.6 kernel officially. For now patching existing kernels and software is the only way to go. His wiki tempted me to ‘try this at home’. Richard PA7FA, donated a few CIROCOMM G100/300 GPS-receivers and found out that besides 4800 bps NMEA, also a PPS signal was present. I mailed CIROCOMM for the datasheet of this OEM module, but I still heard nothing from them. Therefore I don’t know the accuracy and/or usability of the PPS signal.
The GPS module is fed by the USB port (+5V) and the 4800 bps NMEA data is inverted with a transistor and fed to pin2 of the DB9 of ttyS0 while the PPS signal (active positive) is fed directly into pin1 of the -same- serial port. Thus, no ‘level’ converters are required as both pin1 (DCD) and 2 (RxD) are inputs. The modern 16550A-chipsets have no problems detecting TTL input levels. This picture shows the first VERY experimental setup.
Traffic on the serial port can be monitored with minicom -s and/or cat /dev/ttyS0:

remco@helium [/home/remco]> cat /dev/ttyS0
$GPRMC,083057.198,A,5314.6975,N,00510.7342,E,0.00,,140208,,,A*71
$GPVTG,,T,,M,0.00,N,0.0,K,A*13
$GPGGA,083058.198,5314.6975,N,00510.7342,E,1,08,1.0,48.2,M,,,,0000*39
$GPRMC,083058.198,A,5314.6975,N,00510.7342,E,0.00,,140208,,,A*7E
remco@helium [/home/remco]>

I encountered some difficulties getting the LinuxPPS contrapsion to work. I will submit these difficulties to the LinuxPPS mailinglist soon.
Anyway, after some hacking I received the desired ‘o’ from ntpd:

remco@helium [/home/remco]> ntpq -p remco.org
remote refid st t when poll reach delay offset jitter
=======================================================
+GPS_NMEA(0) .GPS. 1 l 22 16 377 0.000 0.060 0.336
oPPS(0) .PPS. 0 l 5 16 377 0.000 -0.177 0.550
remco@helium [/home/remco]>

Initially I did not understand from Rodolfo’s wiki that the patched NMEA driver also handles PPS requests. Therefore I configured ntpd for the ATOM driver (driver 22) too. Below are some significant ntp.conf lines:

#NMEA 4800 bps on ttyS0
server 127.127.20.0 minpoll 4 prefer
fudge 127.127.20.0 stratum 1 flag2 0 flag3 0 refid GPS

#ATOM __| |___ (rising edge, flag2 0)
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 flag2 0 flag3 1 stratum 0 refid PPS

I learned from Philip that the (patched) NMEA driver handles PPS too (flag3 1).
I will experiment with these several setups, i.e. NMEA + seperate PPS, NMEA + PPS and DCF with separate PPS, e.g.:

#NMEA 4800 bps on ttyS0 and use PPS (flag3 1)
server 127.127.20.0 minpoll 4
fudge 127.127.20.0 stratum 15 flag2 0 flag3 1 refid GPPS

#ATOM __| |___ (rising edge, flag2 0 )
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 flag2 0 flag3 1 stratum 0 refid PPS+

#SHMPPS (falling edge) shm_splc2 -d /dev/ttyS0 -s -l DCD -u 0 -c
server 127.127.28.0 minpoll 4 prefer
fudge 127.127.28.0 flag3 1 refid PPS-

#PARSE Conrad RAW DCF77 (mode 5) no PPS
server 127.127.8.1 mode 5 minpoll 4
fudge 127.127.8.1 time1 0.0 flag2 0 flag3 0 stratum 14 refid DCF

You can track my experiments at ntp.remco.org.