Remco.org

Due to interference from the multiplexed nixies, I encountered difficulties receiving DCF77 at my location.
I connected the receiver ground, and thus the clock, to my central heating system.
The result is a flawless reception of the DCF signal. This movie says it all ;- )

A while ago I posted the idea to use the rising edge of DCF77-pulses as PPS-generator. At that time LinuxPPS was not in the kernel
and it was a ‘small project’ (read: challenge ; -) to apply the necessary kernel patches, and to get it running.

As of linux-2.6.34 LinuxPPS is within the kernel and it can be easily activated in (k)Ubuntu 9.10 and onwards with:

ldattach pps /dev/ttyS0 (when the PPS source is connected to ttyS0 (COM1)

The necessary modules (pps_core and pps_ldisc) are automagically loaded when issuing the ldattach command.

You can monitor the PPS stamps with:  watch -n1 cat /sys/class/pps/pps0/assert .

After this, start a freshly compiled ntpd (see LinuxPPS wiki on how to do this) and use the ATOM driver (driver 22).

To make a long story short, although DCF77 misses the 59th ‘second’, the kernel stays within +/- 1 ms lock on my system.

Actually, this is surprisingly good, considering the distance between me and the DCF77-transmitter.

Real time results are visible here.  Below you find three snapshots.

PS.  For whatever reason the PARSE driver (driver 8 ) of ntpd cannot decode the DCF77 time with the PCIe RS232 card on my system. With ‘native’ (i.e. on board)
serial interfaces I didn’t encounter problems but with the current setup I keep getting errors like:

22 Jan 14:30:00 ntpd[17670]: parse: convert_rawdcf: parity check FAILED for “###############RADMLS1248124P124812P1248121241248112481248P”
22 Jan 14:30:00 ntpd[17670]: PARSE receiver #0: FAILED TIMECODE: “###############RADMLS1248124P124812P1248121241248112481248″ (check receiver configuration / wiring)

Anyone … ?

This post tries to explain how to install Kubuntu (10.10) when you’ve one primary partition left.
Information on how to install and boot a system where /boot is not on a primary partition, is scarce.

Recently I bought a Dell Inspiron 580 with a single 1.5 TB disk, with Windows 7 installed. Although I run Linux, I wanted to leave the Windows 7 installation untouched (just in case of…).
So, a dual boot system was the way to go.

First, I removed the Dell Datasafe Local Backup option because it seems to overwrite your MBR.

My Inspiron came with the following partitioning scheme (as could be seen with the Kubuntu installation .iso, which had been copied to a USB-drive with usb-creator-kde):

/dev/sda1     149MB   (type ‘de’ <- a ‘Dell thing’)
/dev/sda2     11.15GB (type ’7′ <- NTFS) ‘ RECOVERY’ (<- presumably the W7-system backup/recovery)
/dev/sda3     1.3TB (type ’7′ <- NTFS) ‘OS’ (<- the Windows7 partition)

I downsized /dev/sda3 to 225GB (google on how to do this), resulting in an unallocated partition of ca. 1.1TB.

Subsequently I created a new primary partition by booting Kubuntu using the USB-drive. I chose the ‘Try Kubuntu’-option.
A new primary partition (/dev/sda4, type ’8e’, Linux LVM) was allocated to the remaining space using fdisk.

After this, the partition table looked like:

#> sudo fdisk -l
Disk /dev/sda: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0×38000000

Device Boot         Start         End      Blocks   Id  System
/dev/sda1               1          19      152586   de  Dell Utility
/dev/sda2   *          20        1488    11794432    7  HPFS/NTFS
/dev/sda3            1488       30808   235517228    7  HPFS/NTFS
/dev/sda4           30809      182401  1217670772+  8e  Linux LVM

We’re now in the process of using LVM. For a beginners guide, also on how to use fdisk, look here.

First install LVM on the USB-Kubuntu-system with:

sudo apt-get install lvm2

The freshly created LVM-partition (/dev/sda4) was assigned as a physical volume:

sudo pvcreate /dev/sda4

A volume group was created with:

sudo vgcreate lvmdisk /dev/sda4
(being lvmdisk the name of your lvm, you can name it whatever you want)

I created the following logical volumes (your mileage may vary ; -):

sudo lvcreate -n boot -L 100M lvmdisk
sudo lvcreate -n root -L 15G lvmdisk
sudo lvcreate -n home -L 500G lvmdisk (I decided not to use the full available space and allocated 500 GB to /home)
sudo lvcreate -n swap -L 16G lvmdisk (I have 8GB of memory, so swap is not really necessary, but just in case of….)

After this, my ‘lvmdisk’ looked like:

#> sudo lvscan
ACTIVE ‘/dev/lvmdisk/boot’ [100.00 MiB] inherit
ACTIVE ‘/dev/lvmdisk/root’ [15.00 GiB] inherit
ACTIVE ‘/dev/lvmdisk/home’ [500.00 GiB] inherit
ACTIVE ‘/dev/lvmdisk/swap’ [16.00 GiB] inherit

The logical volumes were formatted with the ext3 file system, except for the swap space:

sudo mkfs -j /dev/lvmdisk/boot -L boot
sudo mkfs -j /dev/lvmdisk/root -L root
sudo mkfs -j /dev/lvmdisk/home -L home
sudo mkswap /dev/lvmdisk/swap -L swap

At this point the logical volumes can be mounted and accessed as if they are ‘normal’ partitions.
E.g. sudo mount /dev/lvmdisk/root /mnt will mount the lvm-root volume to /mnt.

As a safety measure I backed up the MBR of my disk (/dev/sda) with:

sudo dd if=/dev/sda of=mbr.i580 bs=4096 count=1

To be utterly safe, I also copied mbr.i580 to another machine.
When ‘everything goes wrong’, the MBR can be restored with:

sudo dd if=mbr.i580 of=/dev/sda bs=4096 count=1

I now rebooted Kubuntu and chose the ‘Install Kubuntu’ option. When you reach the disk partitioning options, choose ‘Manual’.
A window appears where you can see which partitions are visible and accessible to the Kubuntu installer.
Besides the ‘physical’ volumes /dev/sda and /dev/sdf (in my case the Kubuntu-pendrive), the logical volumes are visible too.
When you right click e.g. /dev/lvmdisk/boot you can assign a mount point, in this case ‘/boot’. Do this for root (/) and home (/home) too.
The swap space is automagically recognized.

For the ‘Bootloader’ option, choose /dev/sda and proceed with the installation process (you’ll be warned that the data on the selected partitions will be deleted etc. , but persist! ; -)
After running through the whole (and fast!) Kubuntu installation procedure the machine asks for a reboot.

With my fingers crossed, the GRUB bootloader appeared with Kubuntu and Windows 7 options available. So far so good.
I chose (of course) Kubuntu and after a while I got an error. The root-partition could not be found. Oh.. oh..

Rebooting the machine with the Kubuntu-pendrive resulted in my observation that the new Kubuntu-system was not aware of LVM.
My pendrive was, because I installed LVM on it (see earlier in this post).

To install LVM on the fresh Kubuntu installation do (in the following order):

sudo mount /dev/lvmdisk/root /mnt
sudo mount /dev/lvmdisk/boot /mnt/boot

Now chroot into /mnt and install LVM:

sudo chroot /mnt
apt-get update
apt-get install lvm2

and .. reboot, choose Kubuntu and… ready!

Yesterday I published about the insertion of a leapsceond (in Dutch: schrikkelseconde).
About 45 minutes ago I added an update to this post (please scroll down) and discovered that -at that ‘time’- the Russian Institute of Metrology for Time and Space (IMVP/VNIIFTRI) lacked to insert the leapsecond in their public NTP servers.

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

Short version of this post: look/click at/on the pictures.

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.

Today the 34th leapsecond will be inserted in ‘our time’ by adding a 60th second in the last minute of this year.
This was announced by the International Earth Rotation and Reference System Service (IERS) in July this year.

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 9 nov 2008: Currently ntp2.remco.org runs with the configuration mentioned below. Polling time for the PPS peer is 32 seconds (minpoll 5, maxpoll 5). Stats can be viewed here.

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.

Recently I bought a Motorola Oncore UT+ GPS timing receiver on Ebay. I run Debian Linux and it seems that the refclock_oncore driver is not included in ntpd because the LinuxPPSAPI from Rodolfo Giometti is not an official part of the linux kernel (yet? ; -)

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 ; -)

Although DCF77 seems to be the ‘default’ time reference for the European continent, I want to have a backup because I run a stratum 0 NTP server.

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)

Yesterday I built a 10.000.000 divider with a small cascade of 74LS390′s to divide the rubidium 87 (Rb87) locked 10,000.000.00000(0) MHz from my Efratom FRS into 1 Pulse Per Second (PPS). I know that there is a another approach available. However, I managed to program a 16F648A PIC, but the contrapsion did not work. Perhaps the code needs a 16F84.
But… I am more into hardware anyway.

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 !