Re: how to analyze clock drift

[Dennis Lee Bieber <wlfraed@ix.netcom.com>]

On Tue, 25 Nov 2014 06:04:28 -0800 (PST), brbarkstrom@gmail.com declaimed
the following:

>
>The third reference in my previous post mentions software NIST provides
>that give time signals from NIST in several formates.  One format is the
>Network Time Protocol (RFC-1395), where "The NIST servers listen for a NTP request on port 123, and respond by sending a udp/ip data packet in the NTP
>format. The data packet includes a 64-bit timestamp containing the time in 
>UTC seconds since January 1, 1900 with a resolution of 200 ps."  I think 
>that should probably be sufficient for the 3 ns accuracy desired in determining
>clock drift.
>
	Note that part of the NTP protocol (or receiving computer
implementations) also incorporates lots of stuff to determine correction
factors for the receiving computer and the latencies in the network.

	As a result, it is not as precise as you may want it to be.

http://en.wikipedia.org/wiki/Network_Time_Protocol
"""
NTP is intended to synchronize all participating computers to within a few
milliseconds of Coordinated Universal Time 
"""
and
"""
NTP can usually maintain time to within tens of milliseconds over the
public Internet, and can achieve better than one millisecond accuracy in
local area networks under ideal conditions.
"""

	Note that: milliseconds

NTP is used to synchronize wall-clock time between computers by bouncing
packets between them, but does not provide a fixed/stable clock signal
itself.


	
>I suspect that it might also be possible to get time from a gps-equipped
>smartphone.  Since the GPS satellites maintain atomic time and are carefully
>cross-checking with ground stations, they are probably a potential source
>of data for this problem.
>
	Yes, but ...

	The time at the receiver is adjusted by fitting the delays from the
satellites... One reason you need four satellites for a decent fix... you
have to fit a local time along with distances from the satellites to
determine location. They are a source for standard time these days...
Consumer GPS and phones likely have a simple quartz clock for normal
time-keeping that gets updated when ever a GPS fix is performed.

	For a computer lab, a standard time base is something like this
http://www.arbiter.com/catalog/product/model-1084a-b-c-gps-satellite-precision-time-clock-%2840ns%29.php
but again it is only meant to synchronize the wall clock time of disparate
computers [the equivalent of setting your watch while listening to a time
announcement on a radio]. You have to move up to
http://www.arbiter.com/catalog/product/model-1083b.php to get standardized
frequency outputs which can be used for clock differencing.

>More exotic solutions might be uncovered from a bit of further research.
>For example, the astronomers doing Very Long Baseline Interferometry need
>to do remote time synchronization of high accuracy.  I don't know the
>methods they use, but maybe they have something that could be turned into
>a useful tool.
>
	Probably boxes like the above 1083b or 1084a -- depending upon whether
they need a civil time-stamp or a reference frequency (you'd need the
latter to calibrate a receiver, for example -- and wouldn't be using NTP
with its latencies; rather you'd be using a distribution amplifier and lots
of carefully measured coax so that the signal gets delivered to all end
points at the same time).

>Finally, after thinking about your response a bit, I think the average time
>delay between a WWWV station in the US and a receiver in the EU would be 
>fairly constant -- except for variations due to changes in the index of
>refraction and reflected signals bounced off the ionosphere.  The constant
>part of the delay becomes an offset in a linear regression data reduction.  
>Of course, this is minor quibble with your comment.
>
	If you are in the EU, you shouldn't be using WWVB (WWV is an AM
voice/tick signal [though there is a BCD subcarrier]; WWVB is a digital
signal for automated setting of clocks). The UK has MSF on the same 60kHz
as WWVB, and Japan has JJY. {I suspect those are the stations my watch
handles as all three are on the same frequency and just need to decode the
strongest signal -- the Citizen Skyhawk will identify which US/EU/JP was
used on the last synchronization}.

http://en.wikipedia.org/wiki/Time_from_NPL
http://en.wikipedia.org/wiki/WWVB


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/