[LinuxPPS] Ultimate time server

Cirilo Bernardo cirilo.bernardo at gmail.com
Wed Dec 29 09:52:48 CET 2010


On Wed, Dec 29, 2010 at 5:04 PM, Paul Lavender <paul at lavender-fam.net> wrote:

[snip]

> Some points - although specifications for some of the GPS units are
> maybe 1 microsecond I do remember seeing a post on this site showing
> jitter from a GPS18LVC of less than 100nS. I appreciate that jitter is
> not the same as time accuracy, but I have no access to a National
> Physical Laboratory.
>

The jitter will affect your ultimate precision as well as accuracy,
but generally the accuracy is much worse than the precision (large
offset from absolute time standard).

[snip]
> Curiously the specifications for the Rubidium source do talk about a
> frequency drift as the tube ages. Why? Surely a quantum jump in the
> excitation (which is where the Ghz. frequency comes from) is the same no
> matter how many times an atom has done it!
>

It is instability (short term error, a contributor to jitter) really
rather than drift (long term error); the instability is due to
increased noise as the tube ages. It is rubidium vapor which is used
and the radio frequency is locked to an absorption line of Rb. A
number of techniques can be employed and the specific technique chosen
will determine the jitter - so even 2 Rb clocks can have slightly
different characteristics.   As the tube ages you will typically have
an increasing metal deposit on the tube (and also less Rb vapor in the
tube) which in turn means poorer signal on the radio detector and
poorer control of the signal locking.

> What originally led me to this project was working in a not particularly
> demanding job away from home, giving me with too much time. My home
> server is using an Oncore at the moment which is continually locking up.
> A restart of NTP will get it going again, but it is a bit irritating to
> log in and find the stratum has gone to freerunning. So the plan was to
> lock a Rubium to the GPS, then to 'freerun' on the Rubium if necessary.
>

That arrangement I imagine is good enough to maintain a few hundred
microseconds drift over a few days. If the Oncore module is such a
problem, you can find a number of cheap GPS modules out there.  The
challenge is really in figuring out the voltage tolerances on the
serial port; "RS232/EIA232" doesn't seem to have any meaning these
days.  RS232 is a specification of the electrical signal levels (and
some cable and connector characteristics) and many serial
communications ports are claimed by manufacturers to be "RS232" when
they are not at all compliant with the standard. Anyway, typical
serial port voltages on modern computers are 0V+5V (not the 'typical'
-12+12 of the RS232 spec with minimum -3+3V) but these ports are often
compatible with genuine RS232 compliant devices. So step #1 is to find
out what the signal levels are on your serial port(s) and then select
an appropriate GPS.  On some of my embedded instruments with a 3.3V
serial signaling for example, I use a nice cheap GPS with integrated
active antenna from 'sparkfun.com'; there are quite a few models
available so you can look through to see if any are suitable. Note
that sparkfun offer USB-to-serial interfaces for many of their GPS
products, but as I have posted before you want to avoid USB if you
want good timekeeping; USB will basically guarantee a minimum jitter
of 1ms.

> As to the motherboard I am not afraid to get out my trusty soldering
> iron. I know less sophisticated processors have two pins - crystal in
> and crystal out. If the crystal is removed a clock can be fed into the
> crystal in pin. But I'll try to get other bits working first.
>

This is not so simple with surface mount devices, especially
'leadless' and 'ball grid' packages, and with increasing clock
frequency all kinds of issues come up. I suggest trying to avoid
modifications at the board level unless it is obviously easy. Other
people have had good results simply by attaching a home-made heater to
the appropriate circuitry on the board and maintaining a fairly
constant temperature which is guaranteed to be above the temperature
of the air inside the case.



More information about the LinuxPPS mailing list