Re: NOISE NOISE NOISE - clocks and other irrelevance

[jim bell <jimbell@pacifier.com>]

At 12:40 AM 1/27/96 -0500, Dave Emery wrote:
>
>> 
>> A peripheral I've long wanted to see, commonly available:  ACCURATE  time, 
>> broadcast to the millisecond/microsecond/nanosecond, available from sources 
>> as varied as TV VIR's, FM subcarriers, and other sources, available as an 
>> easy input (via a peripheral card) to a computer.
>
>	The only technology that I'd trust to be useful much below
>10-100 ms is GPS.   The others are unlikely to be controlled well enough
>at the source to be trusted. 

What about Loran?  WWV(B)?  Receptor-type signals?

Now, I agree that CURRENTLY few people "depend" on those other (non-GPS, 
non-Loran, non-WWVB) systems, but to some extent that's a "chicken and egg 
problem"  

> Current TV broadcasting, for example,
>usually involves multiple passes though digital frame stores and time
>base correctors  - most homes get the signal via cable which itself
>involves significant uncontrolled delays  (juat the thermal changes
>in propagation delay  in a long CATV cable and amplifier chain due to weather
>changes run into the many microseconds).

Perhaps, but I'm assuming broadcast tv.  Single source.  Limited variability 
in path length.  I admit there  are limitations; my argument is that the 
signals SHOULD contain accurately-defined points, even if it is only one per 
frame.


>	And humans beings being as imperfect as they are, it is hard to
>beleive that making sure that the time being broadcast is really kept accurate
>is going to be a priority when most people use it for purposes that require
>plus or minus a few seconds timing.

I think that if there WERE some reliably-available timecode system, plus a 
cheap single-chip system to drive it, it WOULD be kept reliable enough 
because of demand.


>> I have a 12-year-old Heathkit "Most Accurate Clock" that I assembled myself, 
>> and had the foresight to install it with its computer  interface option. 
>> (receives 5, 10, or 15 MHz signals broadcast from Boulder, Colorado, 
>> containing "exact" time.) 
>> 
>> While I've never taken the time to connect it to my PC, it provides 
>> (through an RS232 jack) correct time with a rated accuracy of about 5 
>> milliseconds, as I vaguely recall. (Even has a dipswitch setup on the bottom 
>> to tell it how many 500 mile increments you are away from WWVB... corrects 
>> for delay to a first order of magnitude.)
>> 
>	WWVB is the 60 khz broadcast (which is more accurate due to more
>stable propagation) 

Not much of a difference, given the context.  For example, I'm probably 1000
miles away from Boulder; it is highly unlikely that the path length
differences for the HF bands could exceed about 100 miles, or about 0.5
millisecond.  Given the context, it's accurate enough for anti-spoofing work
in networks.


. the  HF ones are WWV.  Commercial time receivers
>are available that work off the 60 khz time code (very narrow bandwidth
>ASK), but the 60 khz is most used as a standard frequency for long
>term tracking of error in local standards.

Any more?  I don't think so.  GPS has probably pretty much taken over as the
"gold standard" for clock synchronization, I suspect.  Path length is known,
by definition, and the resolution must (as a consequence of the distance
accuracy requirements) be in the low-nanosecond level.



>> (BTW, if anybody knows how to easily connect it to the pc, or has the 
>> appropriate software, please tell me  The task isn't difficult from a 
>> hardware standpoint; it's just RS-232 serial ASCII timecode at about 9600
>> bps which 
>> either continuously retransmits or on request.  The problem is the software:
>
>	If you run unix

Nope.

> there are some quite sophisticated programs that
>can use this specific clock (connected to a serial port) that allow sync
>to the full accuracy possible at good times of day (around 1 ms).   The
>programs also allow time distribution to other computers on a network -
>thus their name  - ntp - which stands for network time protocol (and the
>network time program that implements it). This protocol and the various unix
>programs that implement it are quite widely used on commercial LANs and
>the Internet to sychronize time amoung unix workstations, servers, and
>bridges and routers.  Current implementations are capable of tracking
>clock oscillator error on a system and adjusting the time periodically
>to compensate for the frequency error of the clock and even to predict
>(polynomial approximation) the change in frequency error with time.
>
>	The man behind much of this (at least the early research) is
>Dave Mills who used to be at louie.udel.edu which hosted a ftp
>site for the programs.   An archie search will reveal where they
>are kept now, and there is a newsgroup (comp.protocols.time.ntp) for this
>which no doubt has a substantial faq file about this. 

Thanks for the reference.

	

>> (Then again, there are those "Receptor" watches which have (at least)
similar 
>> accuracy, which as I understand it work on FM subcarrier principles.)
>
>	Yes they use the RDS broadcast on the 57 khz subcarrier for this.
>Of course there is no certainty the station has the clock set accurately.

Chicken and egg, again.  I assume that any radio station can afford $300 for
a GPS receiver that can put out time accurate to 1 microsecond.  If enough
people start USING such broadcasts, they will be considered NECESSARY and
will be maintained.  The Receptor watch is an excellent interest-developing
product to assist in this problem; the only problem might be that errors of
greater than the 5 msec spec'd are not necessarily immediately apparent to
the common watch-on-wrist user.

>
>	TV stations could be made to maintain a local clock sync'd to
>GPS and use that to do the final level of clocking out before feeding
>the transmitter and could thus ensure that some reference point in some
>frame happened at an exact time, but given that a user who can see a TV
>signal can probably see GPS signals and can do the same timekeeping himself
>for a couple hundred bucks it hardly seems worth it any more.  I do
>expect that time codes with modest accuracy (few tens of ms at best)
>will become common as part of the Starsite (or whatever they call it
>now) program guide distribution on PBS, simply because this has defined
>a format that can conveniantly contain time messages multiplexed with
>other data and the box displays the time.  DSS and VC-II both also have
>this capability, but of course the uncertainty of the satellite delay
>limits accuracy and neither has provisions for providing time to other
>devices.




>	This is possible, but I bet the variations in phase in the local
>distribution system due to power factor, choice of phase to use, propagation
>time through transmission lines and substations and so forth would
>mean that phase as observed at two distant sites was rather random
>and maybe even subject to shifts over time as load conditions varied.

I'm hoping some HV engineer will make a comment as to this factor.

>