[time-nuts] distirbuted sync

[Jim Lux]

On 7/23/13 11:03 PM, Chris Albertson wrote:
> You can prototype a system with off the shelf parts  get a few
> computers, old notebook computers, Raspburry "pI' or repurposed
> routers, what ever you have.   Connect a Trimble Thunderbolt GPS to
> each one. Each one runs NTP. Connect them all to a isolated network.
>   It could be wired, WiFi or whatever.

This is at work. No junker old laptops.. there isn't enough time in the 
world to try and figure out their idiosyncracies.


>
> Let's say you have three systems.  When all three can se the sky they
> have good timing.    Now cover lone, two or all three GPS antenna and
> you are stil doing OK for a while.  With all thre antennacovered you
> ar will still have the system time sync'd even it it drifes from real
> UTC by a few tens of milliseconds.  But if just one of the three can
> see the sky for a little while the time gets corected in all systems

I think that's overkill for this system. 1 millisecond relative timing 
is an easy bar to meet with almost any comm link; that's more of an 
integration challenge: what off the shelf widget comes with the ability 
to do the sync. The challenge is in the frequency control, without 
resorting to OCXOs or atomic standards.



>
> You can't use Eithernet in the real system but you can rig some other
> media.  Blue Toth works over a short distance but you have radar.   It
> seems like you should be able to use the radar for data
> communications.   Radars if they ca hear the echo at all would be
> senitive for very long range lateral communications.

It's not a pulsed radar. CW, at a milliwatt or ten. the "bandwidth" of 
the communications channel, if it can be called that, is on the order of 
10-50 Hz.

The way the system works is to look at the received signal reflected 
from the rubble and victim.  That signal has a very strong fixed 
component (the rubble isn't moving) and a very weak component 
(heartbeats cause a phase shift of around 10 degrees). With a 
sufficiently large dynamic range receiver one could just digitize, 
calculate the baseline, subtract it, and look for the changes.  However, 
this is impractical for a variety of reasons.

So we coherently subtract a sample of the transmitted signal from the 
received signal to reduce the overall dynamic range requirement. Then we 
digitize and process. It's sort of like an nulling interference 
canceller in the RF comm world, or a flavor of Wheatstone bridge.

If the transmitter and receiver are separated (say on opposite sides of 
a collapsed building, with no direct path), the problem becomes "how do 
I get that copy of the transmitted signal to subtract".  We also use the 
transmitted signal as a coherent LO for the demodulation.  (Called 
homodyne detection in the radar world, and widely used in familiar 
applications like radar speed guns)



>
> You say you don't want more radios on the devices so just use the
> radar signal for low data rate local communications.   Put TCP/IP
> stack on it

Hmm.. TCP/IP at 10 bits/second?  I think we can go simpler.  We already 
have to have some sort of data link to send the sampled data for 
processing, but it's in the 1-10kbps range. Whatever that winds up 
being, I think that 1 millisecond sync won't be a problem.  The 
challenge is the "frequency control" (or perhaps "frequency knowledge".

One additional challenge with the separated Tx and Rx is that we now 
have two phase noise sources, and we can't leverage the inherent 
cancellation with homodyne detection.