Re: how to analyze clock drift

[brbarkstrom@gmail.com]

On Tuesday, November 25, 2014 1:15:56 PM UTC-5, Dennis Lee Bieber wrote:
> On Tue, 25 Nov 2014 06:04:28 -0800 (PST), brbarkstrom 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

Thanks for the information and the cautions.  Hopefully,
these items may be helpful to the original poster of the
problem.

Bruce B.