[LinuxPPS] Ultimate time server

[Paul Lavender]

Thank you for all the replies - it will take some time to go through 
them and the associated links.

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 specifications for Rubidium sources say that they have an about 
50Mhz. oscillator tied to the Rubidium frequency (Ghz.) As the Ghz, 
frequency is a multiple of the Mhz. frequency I would expect the long 
term accuracy to be the same (but of course with short term drifting 
which all phase locked loops are prone to)
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!

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.

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.

Nice to see this list so active again.

On 28/12/10 22:01, Javier Herrero wrote:
> 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
>
>
> _______________________________________________
> LinuxPPS mailing list
> LinuxPPS at ml.enneenne.com
> http://ml.enneenne.com/cgi-bin/mailman/listinfo/linuxpps
> Wiki: http://wiki.enneenne.com/index.php/LinuxPPS_support
>