[time-nuts] distirbuted sync

Wed Jul 24 06:03:11 UTC 2013

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.

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

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.

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

On Tue, Jul 23, 2013 at 8:19 PM, Jim Lux <jimlux at earthlink.net> wrote:
> On 7/23/13 9:15 AM, Chris Albertson wrote:
>>
>> I don't think those requirements are hard.  You can build a system
>> that works in three cases
>> 1) GPS is available full time
>> 2)  GPS is available intermittently.
>> 3) there is not GPS system, world war III has destroyed it.
>
>
> or you're in an urban canyon
> or you're underground
> or you're working in a GPS-denied environment (battlefield scenario)
>
>
>>
>> I think what you want is a system that is failure tolerant and can
>> make use of the best available source of timing and degrade
>> performance gracefully.  And you need this is be automatic with the
>> only control maybe being a status LED that shows free/yellow/red
>
>
> I'm not sure "failure tolerance" is actually the right approach: more like
> selecting the appropriate mode.
>
> There's probably no need to smoothly change between GPS available and not
> available, for instance, so one doesn't need some sort of optimal estimator
> that combines all available sources.  You can just "jump"
>
> There is a desire to leverage other assets that are available (there's
> already too many radios.. we don't need to add more).
>
>
>
>
>>
>> Each system has a GPS receiver that disciplines a crystal oscillator.
>> This oscillator is used for timing.  I think it's clear that this
>> handles cases #1 and #2.
>>
>> Then use you Blue Tooth or whatever other short distance
>> communications system you have to support an IP network.  TCP/IP over
>> zBlueTooth works well and is a standard now.  Using this you can
>> configure a NTP based network of "peers".  Each of the above systems,
>> when they are close enough will share timing with the other peers.
>
>
> Time is probably not the hard part. There's tons of ways to sync to 1
> millisecond, and for the ranges of interest, light/propagation time isn't an
> issue.  The challenge is finding something that gives me the 1 millisecond
> without having to add some sort of hardware.
>
> For instance, the system *is* a 3 GHz radar, and the challenge is to
> synchronize transmitters and receivers, but hey, the transmitter can
> transmit at a known time, the receiver can detect when it sees the
> transmitted signal. I could even modulate the transmitter.
>
>> The system runs on a "consensus time".  If one or more systems has
>> access to GPS those system will supply timing to  any other system in
>> range of the blue tooth.   If there is no GPS at all the systems will
>> form what they call an "orphan network" and will remain synced to each
>> other untill some outside source of time connects and puts them all
>> back on GPS time.   NTP is pretty good at handing the case where
>> timing sources come on and off line and where network connects connect
>> and then go away.  It is very failure tolerant.
>
>
> Or an NTP-like algorithm that handles the communications dynamics of the
> system. NTP is tuned/designed for "networks" in terms of adaptation rates
> and the filters.
>
>
>
>>
>> What you'd have is a kind os graceful degradation.  When GPS is
>> visible to all units they are all "dead-on" and running well above you
>> specs.  If GPS is hidden (perhaps in an urban canyon or you happen to
>> be inside a tunnel) the systems ail remain in spec for many hours or
>> even days depending on how much money you spent on the crystal  (or
>> Rubidium) oscillators
>
>
> Power & mass is more an issue than cost, although $1000 oscillators are
> probably out of the question. Imagine you have to carry one or more of these
> things for 12 hours across a disaster site along with your other gear.
> Power turns into mass, too.
>
>
>>
>> Finally if there is no GPS at all but several systems are within blue
>> tooth range that can sync to each other at the few millisecond level.
>> but because you did spend $$ on a god crystal will stay sync'd for
>> hours even when out of bluetooth range with no GPS.
>
>
> Most off the shelf BT interfaces don't have timing outputs, and I'm not
> exactly thrilled about implementing BT from scratch.  It's sort of like
> getting timing from Ethernet.  Sure, you *could* modify a standard ethernet
> transceiver to be driven from a 10 MHz, or to recover 10 MHz from the
> Ethernet signals, and you could modify it to tag when you get a sync detect.
> But it's a heck of a lot easier to buy someone's PTP enabled interface.
>
>
>>
>> The good thing is that you only need to integrate existing technology
>> to make this happen. The  software, hardware and all the parts are
>> available.   You'd not have to pay to advance the state of the art.
>>
>> You would have to balance things like crystal oscillator stability vs.
>> power.  Ovenized units suck up power.  TCOXs use less power but maybe
>> hours and not days of hold over time is enough.
>>
>> The LED's color depends on the estimated timing error, NTP is good at
>> computing that based on if GPS is connected and working, the network
>> status and so on.  So it might be green for microsecond level, yellow
>> for millisecond level error and red for "few seconds" level, flashing
>> for no-sync
>>
>
> In this system, the user doesn't care what the time uncertainty is. either
> it's good enough, or it's not.
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

-- 

Chris Albertson
Redondo Beach, California