[time-nuts] distirbuted sync

[Chris Albertson]

On Wed, Jul 24, 2013 at 12:45 AM, Hal Murray <hmurray at megapathdsl.net> wrote:
>
> albertson.chris at gmail.com said:
.. It's too big and
> complicated and will be hard to debug if something goes wrong.  The real
> problem is that it will do the best it can rather than scream and shout when
> something unexpected happens.x can be used by the OS time keeping code
> the drift should be hard to measure.  If not, measure whatever the system
> will be using.  Most likely, it will be way off, as in 10s to 100s of PPM.
> (The 100s covers software bugs in the OS and design errors in the hardware.)
>

Hard to debug?   It runs of every router and (non MS Windows) computer
on Earth every day 24x7 How often do people have to "debug" it?  I'd
guess that 99.99% of the people who use it don't know it even exists.
(for example NTP runs on Android phones, along with NITZ for cell
signals)
 It is pretty easy to keep track of how well it is doing   You run
"ntpq" and have it output some numbers, then look at the numbers and
do what's needed.

But then, intersystem communications between two or more radar should
be EASY.   You can put some data bits on the  radar pulses.

Same for timing if the PRF (pulse repetition frequency) is well timed
then the radar is broadcasting a timing reference

The infamous "radar range equation" pretty much ensures that every
radar can "hear" all the pulses from the other radars.  The receivers
need to be very sensitive relative to the transmit power MUCH more so
then in a communications system.

There is also a good reason to modulate a radar pulse with
psudorandom-like bits, The receiver "knows" what was sent and looks
for it with an autocorellation function.  This allows good noise and
jamming resistance.  Good plan if you have multiple radars in the same
general area.  Sounds like a lot of processing but I think this gets
done inside a FPGA

-- 

Chris Albertson
Redondo Beach, California