[LinuxPPS] Ultimate time server

[Javier Herrero]

El 28/12/2010 22:17, Cirilo Bernardo escribió:
>
> That sounds like a fun project, especially if you can change the
> programming of the FPGAs to make them do other neat tricks.  Keep in
> mind that the GPS PPS signal is not necessarily well disciplined
> either; for some cheap receivers the error is unspecified if the unit
> is not stationary, and for some even when they are locked they are
> only good to ~2us. I think you have close to the best performance that
> you can reasonably expect from a TCXO. 5.4 milliseconds per day
> (without further external time sources) is not necessarily bad.
>
It is quite fun :) The board is this: 
http://www.hvsistemas.eu/en/prod/H8606.html

The Motorola M12T, or the i-Lotus M12M I'm using, although not 
expensive, is a timing receiver. Its PPS pulse performance is better 
than 10ns (1 sigma, not using clock granularity message) and 2ns (1 
sigma, using clock granularity message) 
http://www.ilotus.com.sg/sites/all/themes/zeropoint/pdf/m12m/M12M%20Timing%20-%20TDS%20%28Ver%201.0.0%29.pdf

>   In the case of a Rb clock, once it is somehow referenced to an
> absolute time the drift per day is very small and the Rb clock can be
> used to tell if the GPS PPS is behaving (in which case you can use the
> information to improve your offset from absolute time). A good GPS
> data sheet will give you an estimate of the propagation time from
> antenna jack until the PPS signal reaches 90% of its peak (or 10% for
> an inverted signal) as well as the transition time of the PPS signal;
> assuming no multi-pathing for the GPS signal, the additional delay
> through the antenna lead and within the active antenna are easy to
> calculate. The remaining error will be in the atmospheric propagation
> time.
>
The drift of a free running Rb like the FRS-C during one day can easily 
be over 5 microseconds (there are better ones), so not so small for what 
we're talking about. Usually, you will have a lot better performance 
from a timing GPS that from a Rb that you adjust to UTC from time to 
time (normally, what you would do would be to discipline the Rb to GPS). 
If you have a Cs, this is a different thing: the Cs is a primary 
standard. Anyway, how would you reference the Rb to absolute time? 
(appart from using a GPS)

A friend of mine, that works for a calibration laboratory, has there a 
Cs standard, and it is constantly monitorized using a GPS receiver. They 
obtain the traceability for the Cs as a frequency standard by supplying 
the drift data from the GPS PPS signal and the Cs derived PPS signal 
(time difference between them) to the spanish national standard bureau 
for time (Real Observatorio Astronómico de San Fernando). So you can see 
that GPS is really good, and used to check how other standards are 
behaving, and not the other way.

I think that timing GPS receivers usually takes its internal delay into 
account, and you can add the delay for antenna and transmission line 
(easy to calculate for transmission line, not so easy for antenna 
amplifier...) Anyway, this error is a few nanoseconds, but can be 
trimmed. To avoid multipath, you can select only satellites with high 
elevation angle (and of course have also an unobstructed antenna in top 
of a mast). For timing purposes, reception of only one satellite is needed.

But also, you must fix and fed to the GPS your antenna position 
(longitude, latitude and height) with high accuracy: 1m height error can 
represent 3ns error. And also... trimming to the nanosecond, you must 
know if the delay in the transmission line is affected by temperature, 
and how much.

So to reach nanosecond precisions is not so easy - uncertainities in UTC 
time derived by national standard laboratories are in fact over 1ns.

Anyway, once you have a clock in an ntp server with an accuracy of say 
50ns, you know it is there... but it is not too much useful, unless 
you're using IEEE-1588 to synchronize other machines (not ntp...).

> Did you implement a dual counter + latched readout on the FPGA to
> avoid errors in reading the PPS timestamp counter? If you only have a
> single counter then you must use a buffer (register) as well and also
> ensure that you don't lose a clock pulse (count) while resetting the
> counter. Personally I'm lazy and will use 2 counters.
>
>
It is only a 64-bit counter, latched on reading for the clock, and a 
different latch for the PPS timestamp (the tricky part was to have it 
running at 400MHz). Readings from PPS to PPS the jitter is the one 
expected for the GPS signal. I did a previous try using the internal 
Blackfin cycle counter (time is usually derived from it) and 
timestamping the PPS using the NMI interrupt, but uClinux for Blackfin 
and NMI are not very compatible :) Perhaps some time will try again 
using Adeos/Xenomai real time extensions.

Anyway, I'm only playing with this in free time - usually I'm more 
interested on precise frequency than on precise timing (for most of my 
necessities, 10 usec to UTC is far more than enough, and this is quite 
easy to obtain :) ) And usually, I've not too much free time for playing 
with these things.

Regards,

Javier