Seductive serendipity / Verleidende serendipiteit

February 23rd, 2008

Rb87 experiment with

1e7-divider-1.jpgYesterday 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 !

February 16th, 2008

Rockwell Jupiter and LinuxPPS

jupiter-rockwell.jpgIn my previous post I reported a succesfull try wih LinuxPPS in conjunction with ntpd’s NMEA, ATOM and SHMPPS drivers. However, as far as I could ascertain, the PPS signal from the CIROCOMM G100/300 (I still have not heard anything from them..) can not be locked to the GPS signal due to the relatively large offsets and jitters.
I borrowed a Rockwell Jupiter unit, which Bas PE1JPD bought on a HAM-radio flea market a few years ago, to use it with his PDA and TomTom Navigator.

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 minpoll 4 prefer
fudge stratum 0 flag2 1 flag3 1 refid GPPS

#ATOM (falling edge, flag2 1 )
server minpoll 4 maxpoll 4
fudge 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 unknown message id 1003
54513 26640.310 pulse: jupiter_parse_t: Unknown gweek
54513 26640.874 gpos: Navigation solution not valid
54513 26640.982 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 (helium) if you like : -)

February 14th, 2008


As many of you know, I run an ‘open access’ stratum 1 NTP server ( for almost four years now.
In fact, 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
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
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 minpoll 4 prefer
fudge stratum 1 flag2 0 flag3 0 refid GPS

#ATOM __| |___ (rising edge, flag2 0)
server minpoll 4 maxpoll 4
fudge 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 minpoll 4
fudge stratum 15 flag2 0 flag3 1 refid GPPS

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

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

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

You can track my experiments at