To my surprise, I discovered the following around 13.00 UTC (14.00 LT):

remco@helium [/home/remco]> ntpdate -q ntp3.imvp.ru
server 62.117.76.138, stratum 1, offset 1.004891, delay 0.08247
1 Jan 13:53:49 ntpdate[21218]: step time server 62.117.76.138 offset 1.004891 sec
remco@helium [/home/remco]> ntpdate -q ntp3.imvp.ru
server 62.117.76.138, stratum 1, offset 0.075734, delay 0.22472
1 Jan 14:07:02 ntpdate[22005]: adjust time server 62.117.76.138 offset 0.075734 sec
remco@helium [/home/remco]> ntpdate -q ntp1.imvp.ru
server 62.117.76.142, stratum 0, offset 0.000000, delay 0.00000
1 Jan 14:07:18 ntpdate[22025]: no server suitable for synchronization found
remco@helium [/home/remco]> ntpdate -q ntp3.imvp.ru
server 62.117.76.138, stratum 1, offset 0.004711, delay 0.08287
1 Jan 14:07:38 ntpdate[22028]: adjust time server 62.117.76.138 offset 0.004711 sec
remco@helium [/home/remco]> ntpdate -q ntp4.imvp.ru
server 62.117.76.140, stratum 1, offset 2.005414, delay 0.08316
1 Jan 14:07:42 ntpdate[22032]: step time server 62.117.76.140 offset 2.005414 sec
remco@helium [/home/remco]> ntpdate -q ntp2.imvp.ru
server 62.117.76.141, stratum 0, offset 0.000000, delay 0.00000
1 Jan 14:08:07 ntpdate[22034]: no server suitable for synchronization found
remco@helium [/home/remco]> ntpdate -q ntp1.imvp.ru
server 62.117.76.142, stratum 1, offset 0.004364, delay 0.08261
1 Jan 14:11:48 ntpdate[22302]: adjust time server 62.117.76.142 offset 0.004364 sec
remco@helium [/home/remco]> ntpdate -q ntp2.imvp.ru
server 62.117.76.141, stratum 1, offset 0.004940, delay 0.08292
1 Jan 14:11:53 ntpdate[22303]: adjust time server 62.117.76.141 offset 0.004940 sec

Either it was a (late) planned reboot, insertion of a leapsecond, or . . . . the IMVP is tracking this Blog?!!

However, one machine is forgotten . . .  or is it part of the Russian contribution to the ISS and located in space? ; -) :
remco@helium [/home/remco]> ntpdate -q ntp4.imvp.ru
server 62.117.76.140, stratum 1, offset 2.005239, delay 0.08321
1 Jan 14:26:14 ntpdate[23108]: step time server 62.117.76.140 offset 2.005239 sec

remco@helium [/home/remco]> ntpq -p ntp4.imvp.ru
remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
LOCAL(0)        .LCL.            1 l   52   64  377    0.000    0.000   0.000
+GENERIC(0)      .GPS.            0 l   31   64  377    0.000   -0.002   0.004
oPPS(0)          .PPS.            0 l   64   64  377    0.000    0.002   0.004
xntp1.imvp.ru    .IMVP.           1 u  834 1024  377    0.966  -1999.9   0.000

Long(er) version of this post: read below ; -)

Recently a friend of mine offered me rack space in his colocation facility. This facility is connected directly to AMSIX, the nr. 1  internet exchange in the World, located in Amsterdam.
He also donated a surplus server, provided that I prepared the server for precision timekeeping.

First I had ‘bad ideas’ of ‘beating’ Poul-Henning Kamp’s gps.dix.dk by using my FE-5680A Rb-standard, programmed for 14.31818 MHz, as reference for the system clock PLL, in combination with a GPS receiver.
Secondly, I thought that I could never beat the combination of PHK, a Soekris, and -presumably- his own ntp server software ntpns. So, I defined offering time stamps within +/- 1 us as my goal.
Thirdly, I thought of locking the 14.31818 MHz PLL reference to GPS, but what should I gain, relative to my goal?
Fourthly, I am more into hardware than into (recent) software, remember?

The donated server has an ASUS TUSI-M P1266 motherboard with 1024 MB memory.
I chose FreeBSD (rel-7.0) as OS because LinuxPPS does not support the time_pps_kcbind() option (yet), and compiled a new kernel with PPS_SYNC enabled. My experience is that FreeBSD PPS-implementation reacts more ’smoothly’ on temperature changes than LinuxPPS.

Here, at home, the ntp kernel PLL offset remained within +/- 5 us limits due to the central heating system switching on and off (it is winter now and people are skating ; -).
So, this was not enough, although I knew that my server shall be located in a temperature controlled area.
Before considering ‘the GPS-locked system clock option’, I was curious how the system clock would behave in a more stable temperature environment, i.e. its temperature sensitivity.

I decided to ‘thermostatise’ the 14.31818 MHz PLL reference crystal, and built a thermostat around a ‘good old’ uA723, a power transistor, and two diodes as temperature sensor. I mounted the power transistor, and diodes on folded copper foil, and soldered the copper foil directly on the 14.31818 MHz crystal near the ICS PLL chip to achieve optimal conduction.
The temperature converged to approx. 45 Celsius and remained stable within ca. 0.1 C.

The difference between ‘before’ and ‘after’ can be seen in the first picture of this post, acquired by the Utrecht University (I studied there, and obtained my PhD there), which is monitoring my server out of curiousity. The result of the thermostat is almost a flat line, and the kernel PLL offset stays within +/- 1 us with this setup!

Normal performance (left), and performance with ‘thermostatised’ system clock PLL reference crystal (right).

Want to look the inside of Time.remco.org?
Here is a picture of its ‘thermostat Mk1′, and this is a picture of its built-in Rockwell Jupiter GPS receiver.

Within the colocation area a special coaxial cable has been routed towards the roof of the building for the Time.remco.org GPS antenna. Therefore, for future expansions and/or experiments I created a DC blocked HF GPS out, to connect more GPS receivers to one antenna, and a 1 PPS output (synchronised to GPS), to offer PPS to other (timing) machines in the colocation area. Ntpd can run perfectly with PPS only, provided that you have a networked time reference.

Pictures of the installation of Time.remco.org will appear later (in a separate posting)!!

Note: the above mentioned server is disconnected, ready to be shipped to the colocation facility. You can use/monitor another ‘themostatised’ FreeBSD machine: ntp.remco.org, member of the NTP pool. Its behaviour is somewhat less, due to less optimal hardware, but its PLL offset remains within +/- 2 us limits.

Dr. Daniel Gambis, director of the Earth Orientation Centre, explains precisely why insertion of leapseconds is necessary.

Of course I wanted to see whether my NTP servers followed this procedure. In August I downloaded the official leapsecond file and added it to my ntp.conf. This means that when you do not have a time reference capable of announcing leapseconds, this file informs ntpd accordingly.

Today around 01.00 local time (00.00 UTC) ntpd informed itself about the insertion of a leapsecond:

ntp.remco.org (FreeBSD):
31 Dec 00:59:46 ntpd[778]: crypto: leap epoch 1.0 days
31 Dec 01:00:02 ntpd[778]: kernel time sync status change 2117
31 Dec 01:00:02 ntpd[778]: crypto: leap epoch 1.0 days

ntpdc -c kern for this machine yields:
remco@time [/home/remco]> ntpdc -c kern freebsd
pll offset:           -6.7e-08 s
pll frequency:        -50.244 ppm
maximum error:        0.000236 s
estimated error:      1e-06 s
status:               2117  pll ppsfreq ppstime ins ppssignal nano
pll time constant:    4
precision:            1e-09 s
frequency tolerance:  496 ppm
pps frequency:        -50.244 ppm
pps stability:        0.003 ppm
pps jitter:           1.026e-06 s
calibration interval: 256 s
calibration cycles:   2869
jitter exceeded:      1383
stability exceeded:   0
calibration errors:   3

ntp2.remco.org (LinuxPPS):
31 Dec 00:59:53 ntpd[22455]: crypto: leap epoch 1.0 days
31 Dec 01:00:09 ntpd[22455]: kernel time sync status change 2011
31 Dec 01:00:09 ntpd[22455]: crypto: leap epoch 1.0 days

where ntpdc -c kern outputs:
remco@time [/home/remco]> ntpdc -c kern ntp2
pll offset: 1.017e-06 s
pll frequency: 5.571 ppm
maximum error: 0.00775 s
estimated error: 7e-06 s
status: 2011 pll ins nano
pll time constant: 4
precision: 1e-09 s
frequency tolerance: 500 ppm

DCF77 transmits leapsecond information, as can be seen in the logfile after restarting ntpd on a machine which has no leapsecond file:

31 Dec 11:19:45 ntpd[20791]: PARSE receiver #0: interval for following error message class is at least 00:01:00
31 Dec 11:19:45 ntpd[20791]: PARSE receiver #0: no data from device within poll interval (check receiver / wiring)
31 Dec 11:20:03 ntpd[20791]: synchronized to GENERIC(0), stratum 1
31 Dec 11:20:03 ntpd[20791]: kernel time sync status change 0001
31 Dec 11:21:55 ntpd[20791]: kernel time sync status change 0011

So at least I now know that ‘I am in time’ with my leapseconds! :- )

Update Jan 1st 2009:

Yesterday friends and family asked me: “What are the effects of not heeding the leapsecond insertions, anyway, when it is so important, why don’t we hear about it in the news?” My answer was: “Wait until tomorrow, then you’ll hear and read enough”.  Some URLs:

• http://www.nu.nl/internet/1892375/zunes-getroffen-door-millenniumbug.html (Dutch)
• http://forums.zune.net/0/1/404037/ShowPost.aspx#404037
• http://blog.seattlepi.nwsource.com/microsoft/archives/158289.asp

But the most intriguing discovery I just made was that the Russian Institute of Metrology for Time and Space (IMVP/VNIIFTRI) did not insert the 34th leapsecond yesterday (!):

remco@lithium [/home/remco]> ntpdate -q ntp1.imvp.ru
server 62.117.76.142, stratum 1, offset 1.002066, delay 0.08249
1 Jan 13:49:14 ntpdate[27913]: step time server 62.117.76.142 offset 1.002066 sec

remco@lithium [/home/remco]> ntpdate -q ntp2.imvp.ru
server 62.117.76.141, stratum 1, offset 1.001125, delay 0.08253
1 Jan 13:29:45 ntpdate[27803]: step time server 62.117.76.141 offset 1.001125 sec

remco@lithium [/home/remco]> ntpdate -q ntp3.imvp.ru
server 62.117.76.138, stratum 1, offset 1.001030, delay 0.08250
1 Jan 13:29:50 ntpdate[27804]: step time server 62.117.76.138 offset 1.001030 sec

remco@lithium [/home/remco]> ntpdate -q ntp4.imvp.ru
server 62.117.76.140, stratum 1, offset 2.001320, delay 0.08302
1 Jan 13:30:04 ntpdate[27808]: step time server 62.117.76.140 offset 2.001320 sec <- 2s ??

I won’t draw any conclusions, but I fear the next satellite/space mission or rocket launch on Russian territory ; -)

UPDATE 8 aug 2008: As I already felt, the idea below is already implemented by Poul-Henning Kamp in his own implementation of a NTP-server, NTPns. I am trying to figure it out and will report the results here as soon as I got it running.

———–
This post tries to describe an experiment using DCF77 pulses as PPS source. Although seemingly trivial, I could not find any information on the web dealing with this issue, therefore I publish it here. Presumably the following ‘discovery’ is already implemented in ntpd and/or its refclock-drivers. I am more into hardware.

Anyway. . . . enough disclaimers!

Today a friend of mine returned one of my DCF77 radio modules because ‘it didn’t work anymore’. Before he returned the module, he took a picture of it. Well… the ferrite antenna rod was missing, presumably ‘lost’ during a relocation of the server the module was connected to.

The module was interfaced to RS232 in conjunction with radioclkd2. I use(d) the PARSE/GENERIC driver on ntp.remco.org and for this driver the RS232 connector needs to be rewired.
Below the RS232 wiring is explained for a DB9 connector:

radioclkd2: Vcc-pin4/DTR, GND-pin5/GND, DCF-pin1/DCD
parse/generic: Vcc-pin7/RTS, GND-pin5/GND, DCF-pin2/RxD

While rewiring I thought it would be a nice idea to compare Frank’s parse driver with Jon’s SHM driver and fed the DCF77 signal to both pin1 (DCD) and pin2 RxD, using a drop of solder. +Vcc was connected to pin7 (RTS).

Using (sudo)  radioclkd2 -s iwait ttyS0:-dcd -d -v yielded DCF pulses and in ntp.conf I entered:

#PARSE Conrad RAW DCF77 (time1 0.2374)
server 127.127.8.0 mode 5
fudge 127.127.8.0 time1 0.2374 stratum 0 refid DCFa

#SHM driver (for use with radioclkd2)
server 127.127.28.0
fudge 127.127.28.0 time1 0.0282 stratum 0 refid DCFb

Putting radioclkd2 into daemon mode (discarding the -d -v options), I restarted ntpd subsequently.  After a while ntpd synchronized to DCFb.  I monitored the behaviour of both ‘DCFa’ and ‘DCFb’, and found out that DCFb (i.e. radioclkd2) revealed less jitter.

Anyway, for whatever reason I thought about the ‘PPS’ option in conjunction with the parse driver (add 128 to mode number, i.e. server 127.127.8.0 mode 5 -> server 127.127.8.0 mode 133 in ntp.conf) would also be interesting.

Because I use LinuxPPS on ntp.remco.org with an Oncore UT+ timing receiver *and* now had a second PPS-source, i.e. the ‘DCF77-PPS’-signal connected to pin1 (DCD). I was curious how ntpd dealt with this ‘new PPS-peer’.

NB: Yes, yes, yes…. I know that DCF77 does not transmit data in the 59th second of a minute!

I gave it a try and activated a second PPS interface with: setserial /dev/ttyS1 hardpps or ppsldisc /dev/ttyS1 & (cf. LinuxPPS wiki, please read!):

remco@helium [/home/remco]> cat /sys/class/pps/pps1/{assert,clear}
1212786628.000324988#43281
1212786628.118746763#43281

The rising (assert) edge of the pulses are synchronized to UTC epochs by the PTB (Germany), and the pulse length (100 vs. 200 ms) is used to transmit information (see PTB site for an explanation of the DCF77 protocol).

The PPS-option for the GENERIC parse driver is activated by creating a /dev/refclockpps-* symlink to /dev/pps*, e.g.
(sudo) ln -s /dev/pps1 /dev/refclockpps-1.

In /etc/ntp.conf the following lines were inserted:

#ATOM driver22, rising edge, flag2 0
server 127.127.22.1 minpoll 4 maxpoll 4
fudge 127.127.22.1 flag2 0 flag3 1 stratum 0 refid PPSa

#PARSE driver8 Conrad RAW DCF77 (time1 0.2374)
server 127.127.8.1 mode 133 prefer
fudge 127.127.8.1 time1 0.2374 flag1 0 time2 0.0282 flag2 0 flag3 1 stratum 0 refid DCFa

I determined the time1 value empirically and took the time2 value from the empirically determined offset for radioclkd2. Perhaps some tweaking is necessary, but I consider it to be a good initial guess.

And… yes! After a while I obtained a sync for PPS(1), and observed lower jitters of PPS(1) than the ‘original’ DCF77-signal (DCFa) using a polling time of 16 seconds (minpoll 4). This means that one second in every 4th sample is missing, generating additional jitter. I did not experiment nor determined whether changing polling times to e.g. 16 or 64 seconds, i.e. [3*16+1*15]/64, is better or worse than 63/64. Although arithmetically identical, perhaps some software loop filters within ntpd have different time constants when using different polling times.

Because the jitter of the ‘DCF77-PPS’ is increased by the missing 59th second, perhaps it would be a suggestion that the PARSE driver8 in mode 133 inserts a time stamp in the 59th second of every minute, in the case that the DCF signal is fed to RxD and DCD simultaneously (might this be mode 20 for example? ; -). The omitting 59th time stamp may be derived from the 58th second or, for example, or the average from the last 5 seconds or so. LinuxPPS then ’sees’  a time stamp every second, and my feeling says that the precision of the PARSE driver in RAWDCF mode (e.g. mode 5+128)  can be increased.

Feedback is highly appreciated.

I interfaced the module with three inverters (74HC14) to my RS232 port. The TX-line was leveled with two resistors and an universal diode (DUS). In my opinion complex interfaces like the TAC2 are not necessary.
(click on image to enlarge and see the details) or click here to download the schematic of my interface interpretation.

To get my UT+ to do work for ntpd, I needed to compile ntpd from source. Normally this is not an issue, but I did not manage to include the oncore refclock in the code and continuously obtained the error:

refclock_newpeer: clock type 30 invalid

in my ntpd logfiles.

With the help of the author of the Oncore driver, Reg Clemens, the following cookbook recipe crystallized, assuming that you have a working LinuxPPS system and a patched kernel(source):

1. in /usr/include ln -s /usr/src/<linux-source>/Documentation/pps/timepps.h . <- ‘.’ !
2. in /usr/include/sys ln -s /usr/src/<linux-source>/Documentation/pps/timepps.h . <- ‘.’ !
3. verify that you also have the links to asm, asm-generic and linux, according to Rodolfo’s wiki
4. in /dev ln -s pps0 oncore.pps.0 (or whatever ppsX you will use)
5. in /dev ln -s ttyS0 oncore.serial.0 (or whatever interface you’ll use, ln -s ttyS2 oncore.serial.1 is also allowed e.g.)
6. download the ntpd source from www.ntp.org and untar it. I use the development version of ntp.
7. configure with at least the options: ./configure –enable-ONCORE –enable-SHM
8. verify from the output that there are ‘yesses’ after timepps.h and Motorola Oncore
9. make
10. add the following entry in ntp.conf: server 127.127.30.0 (when you used oncore.pps.0 and oncore.serial.0)
11. edit /etc/ntp.oncore.0:
    #
    # Oncore UT+ configuration file
    #
    # —– mandatory lines —————-
    MODE 1
    LON 5 11.4548 #insert your own longitude here
    LAT 52 14.2342 #insert your own lattitude here
    HT 11.0 M #insert your own GPS height here
    # —– optional lines ——————
    DELAY 20 NS #delay is approx 5 ns/m cable (I have 4m cable between my antenna and UT+
    CLEAR #negative edge is synced to UTC epochs (due to HC14 inverter, see above)
    SHMEM /var/log/ntpstats/oncore.0
    MASK 0
    TRAIM YES
12. kill all ntpd processes, go to the ntpd directory and start ntpd with root privs as ./ntpd
13. verify in your ntpd logfile that ntpd picks up the Oncore driver:
    54571 82587.208 127.127.30.0 ONCORE DRIVER — CONFIGURING
    54571 82587.208 127.127.30.0 state = ONCORE_NO_IDEA
    54571 82587.225 127.127.30.0 Input mode = 1
    54571 82587.225 127.127.30.0 Initializing timeing to Clear..
    54571 82587.226 127.127.30.0 SHMEM (size = 3584) is CONFIGURED and available as /var/log/ntpstats/oncore.0
    54571 82587.226 127.127.30.0 state = ONCORE_CHECK_I
    *snip* and somewhat later…..
    54571 82588.542 127.127.30.0 This looks like an Oncore UT with version 3.1 firmware.
    54571 82588.542 127.127.30.0 Channels = 8, TRAIM = ON
    54571 82588.542 127.127.30.0 state = ONCORE_CHECK_CHAN
    54571 82593.151 127.127.30.0 Input says chan = -1
    54571 82593.151 127.127.30.0 Model # says chan = 8
    54571 82593.151 127.127.30.0 Testing says chan = 8
    54571 82593.151 127.127.30.0 Using chan = 8
    54571 82593.151 127.127.30.0 state = ONCORE_HAVE_CHAN
    54571 82594.641 127.127.30.0 state = ONCORE_TEST_SENT
    54571 82603.241 127.127.30.0 GPS antenna: OK
    54571 82603.241 127.127.30.0 state = ONCORE_INIT
    54571 82604.701 127.127.30.0 Setting Posn from input data
    54571 82604.701 127.127.30.0 state = ONCORE_ALMANAC
    *snip* and somewhat later……
    54571 82606.941 127.127.30.0 Cable delay is set to 20 ns
    54571 82609.291 127.127.30.0 Have now loaded an ALMANAC
    54571 82609.291 127.127.30.0 state = ONCORE_RUN
    54571 82609.291 127.127.30.0 SSstate = ONCORE_SS_DONE
    54571 82610.401 127.127.30.0 ONCORE: Detected TRAIM, TRAIM = ON
    54571 82610.401 127.127.30.0 Input says TRAIM = -1
    54571 82610.401 127.127.30.0 Model # says TRAIM = 1
    54571 82610.401 127.127.30.0 Testing says TRAIM = 1
    54571 82610.401 127.127.30.0 Using TRAIM = 1
    54571 82610.421 127.127.30.0 PPS Offset is set to 0 ns
    54571 82610.431 127.127.30.0 Satellite mask angle is 0 degrees
14. Enjoy and impress your friends with your timing receiver, just like I impressed you ; -)

Back stage there was tasty food. We were facilitated by Smokey, Joe’s personal assistant, and we reckon Smokey will find a way to transport the tube into The States : -)

Fltr: Dick, PA2DW, Joe WB6ACU and Remco PG0A/PA3FYM.

Oh yes, I almost forgot. The concert was great, the sound sublime and good old times revived!

73, Joe & Smokey!

MSF (60 kHz England, UK) is a good candidate. Compared to DCF receivers, MSF receivers are difficult to obtain and expensive on the continent.

So, I modified a Conrad DCF77 module for the reception of MSF, using a 60 kHz watch crystal as filter.
I tuned the antenna/ferrite coil from 77.5 to 60 kHz.

Click on the picture to enlarge v0.1 of the modified radio module.

The coil is from an old transistor radio but later I retuned the original ferrite coil as supplied with the Conrad radio module.

Most radio clock IC’s want to see a resonated loaded impedance between 50 - 100 kΩ. I simply multiplied the capacitance of my DCF77 ferrite antenna with 1.67 ( [77.5/60]²), i.e. for my Conrad radioclock module I added 4n7 parallel to the original 6n8 capacitor.

Using ntpd with the SHM refclock enabled and radioclkd2 as ‘atomic radio clock parser’ the MSF signal from Anthorn is decoded here:

pulse start: at 1206318120.024987
data(60):5,1,1,1,1,1,1,1,1,11,11,11,11,1,1,1,1,1,1,1,1,2,1,1,1,1,1,1,2,2,2,1,1,2,1,1,1,1,2,1,1,1,1,1,1,1,2,1,1,1,2,1,1,2,2,3,2,3,2,1,
MSF : |0 |5 |10 |15 |20 |25 |30 |35 |40 |45 |50 |55
MSF-A: …………………A……AAA..A….A…….A…A..AAAAAA.
MSF-B: ………BBBB……………………………………B.B..
MSF time: 2008-03-24 (day 1) 00:22 GMT
clock: radio time 1206318120.000000, average pctime 1206318120.024964, error +-0.004383
pulse end: length 0.494541 - 0: 5
pulse start: at 1206318121.039543
pulse end: length 0.089901 - 1: 1
pulse start: at 1206318122.025892

Update 1: it seems that there is some (propagation?) interference in the night which causes ntpd to loose lock sometimes. Perhaps I need a better antenna as the ERP of MSF was decreased after the relocation (April 1st 2007) from Rugby (ca. 50 kW ERP) to Anthorn (ca. 15 kW ERP).

Update 2: Today (18 april 2008) I received a Meinberg analogous DCF77 antenna module from a collegue. I tuned it to 60 kHz. First impression is that it works significantly better than the original antenna.

(click on the image to enlarge)

I built the divider on a small piece of epoxy bread board and combined my frequency standard with an “is locked, PPS works, and ready to use”-indicator. Thus, when the standard is switched on, several minutes later the PPS led starts to flicker.

The divider is depicted on the right (click to enlarge).

The PPS is shaped by a one shot generator (LS123) and the PPS width is approx. 75 ms.

A PDF of the -straight forward- schematic diagram can be downloaded here.

An advantage is that the PPS error is reduced by several orders.

This is a picture of the divider built into my Rubidium standard.

So, my Rb standard will now produce a ‘rock solid’ 1PPS for ntp.remco.org !

It seems that the Jupiter PPS signal is locked onto the GPS signal and the datasheet mentions that the rising edge of the TMARK pulse (i.e. PPS) is synchronized with the UTC one second epochs to within ± 1 μs. Other information states that the TMARK output is 10 - 40 ns accurate.
I interfaced the Jupiter using a 74HC00 to invert the TxD (mandatory) and PPS (not mandatory ; -).

Click on the image right to enlarge.

I placed the Jupiter into ‘Zodiac Binary Protocol mode’ (pin 7 HIGH and pin 8 GND, 9600 bps mode) first, and when I connected the receiver I could not see a GPS fix at all. I suspected the small patch antenna from Bas and remembered that I had an ‘official’ GPS antenna somewhere. To minimise errors, I placed the Jupiter into 4800 bps NMEA mode (pin 7 GND and pin 8 HIGH), and connected the GPS antenna to the Jupiter. Within a few minutes I could read the UTC time from the NMEA output. A few minutes later the receiver had a fix.

The relevant lines in my ntp.conf are:

#NMEA 4800 bps on ttyS0 (falling edge PPS, flag2 1)
server 127.127.20.0 minpoll 4 prefer
fudge 127.127.20.0 stratum 0 flag2 1 flag3 1 refid GPPS

#ATOM (falling edge, flag2 1 )
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 flag2 1 flag3 1 stratum 0 refid PPS

After six hours:

remco@helium [/home/remco]> ntpq -p

remote            refid   st t when poll reach   delay   offset  jitter
=======================================================================
+GPS_NMEA(0)      .GPPS.   0 l   11   16  377    0.000    0.008   0.001

oPPS(0)           .PPS.    0 l   10   16  377    0.000    0.006   0.002

I could not run ntpd with the Jupiter in ‘Zodiac mode’ because I receive errors in clockstats:

54513 26640.110 127.127.31.0 unknown message id 1003
54513 26640.310 127.127.31.0 pulse: jupiter_parse_t: Unknown gweek
54513 26640.874 127.127.31.0 gpos: Navigation solution not valid
54513 26640.982 127.127.31.0 unknown message id 1002

However, driver31 is not patched for LinuxPPS yet. Unfortunately I am more into hardware and did not succeed patching refclock_jupiter.c without gcc errors ; -(

You can monitor ntp.remco.org (helium) if you like : -)

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.