distirbuted sync
Starting a new thread...
Brian wrote:
Have you considered WWVB? Works fine within structures.
Even though the carrier today is phase modulated one can probably glean
1 ms accuracy from it or the data transmitted.
-- disasters occur world wide, any time day or night, so depending on
WWVB won't work.
Magnus wrote:
The movie-business have similar problems, so a sync-ones and keep drift
low system emerged to make field recordings easier.
If it would be tolerable to have a "central" transmitter, putting a PN
code over a voice radio system would suffice to keep the drift fairly
well kept together for this form of system. If you choose to do it on
the audio channel, then you can use of the shelf radios, and replace
those or re-program those as needed. Also, they are dirt cheap nowdays.
-- yes, I'd thought about that, but that's another piece of gear (the
centralized transmitter). And if we added another radio into the
system, you get into the whole size, weight, power aspect. We already
have to have the GPS (for those places where GPS is available). We
already have a comm link of some sort (TBD.. long range Bluetooth
possibly) between the modules, so we could transmit a sync signal on
that. The question would then be whether that signal has modulation
and propagation characteristics that allow the frequency disciplining.
BT is 2.45 GHz, and subject to all the multipath and other ills we
encounter with the radar at 3 GHz.
This is a bit down the road a bit, so what might wind up being the
ticket for GPS denied is putting up GPS pseudolites at the site. that's
back to the "extra piece of gear" problem, but maybe we could make a
case that it isn't our piece of gear<grin>.
Or have our modules have the ability to transmit a GPS-like signal that
the GPS-18 would appropriately handle (oh yeah, I can see the
regulatory issues looming for that one!)
It is an interesting problem.. It's sort of weird, though, as I write
the requirements..
High frequency accuracy (1E-10, 1E-11) ideally.. or high stabiity over
1-100 seconds, with a way to get "knowledge".
But relatively low timing accuracy: 1-3 milliseconds over the same 100
second interval (1E-5)
Often you have a time requirement that is commensurate with the
frequency requirement.
Hi Jim,
On 23/07/13 16:55, Jim Lux wrote:
Starting a new thread...
Good idea!
Brian wrote:
Have you considered WWVB? Works fine within structures.
Even though the carrier today is phase modulated one can probably glean
1 ms accuracy from it or the data transmitted.
-- disasters occur world wide, any time day or night, so depending on
WWVB won't work.
Magnus wrote:
The movie-business have similar problems, so a sync-ones and keep drift
low system emerged to make field recordings easier.
If it would be tolerable to have a "central" transmitter, putting a PN
code over a voice radio system would suffice to keep the drift fairly
well kept together for this form of system. If you choose to do it on
the audio channel, then you can use of the shelf radios, and replace
those or re-program those as needed. Also, they are dirt cheap nowdays.
-- yes, I'd thought about that, but that's another piece of gear (the
centralized transmitter). And if we added another radio into the system,
you get into the whole size, weight, power aspect. We already have to
have the GPS (for those places where GPS is available). We already have
a comm link of some sort (TBD.. long range Bluetooth possibly) between
the modules, so we could transmit a sync signal on that. The question
would then be whether that signal has modulation and propagation
characteristics that allow the frequency disciplining. BT is 2.45 GHz,
and subject to all the multipath and other ills we encounter with the
radar at 3 GHz.
This is a bit down the road a bit, so what might wind up being the
ticket for GPS denied is putting up GPS pseudolites at the site. that's
back to the "extra piece of gear" problem, but maybe we could make a
case that it isn't our piece of gear<grin>.
Or have our modules have the ability to transmit a GPS-like signal that
the GPS-18 would appropriately handle (oh yeah, I can see the regulatory
issues looming for that one!)
It is an interesting problem.. It's sort of weird, though, as I write
the requirements..
High frequency accuracy (1E-10, 1E-11) ideally.. or high stabiity over
1-100 seconds, with a way to get "knowledge".
But relatively low timing accuracy: 1-3 milliseconds over the same 100
second interval (1E-5)
Often you have a time requirement that is commensurate with the
frequency requirement.
Consider my audio channel over radio-sets.
Consider a 1 kHz sine being modulated.
Consider that lock your 10 MHz to that 1 kHz.
Keeping within a few degrees on that 1 kHz should not be too hard,
unless you bump/turn the crystal too much.
A little intelligence to bridge the gaps when radio fading occurs is
naturally needed.
Let's assume you maintain within +/- 1.8 degrees, that's 1/100th of the
1 ms period. You have a maximum of 10 us drift in 1 s, which really is
measly 1E-5, but as it is locked, it moves *tau which means 100 us at 10
s and 1 ms at 100 s... for the peak error as you go into hold-over. It
will naturally be better as it maintains track.
Seems feasible to maintain the needed tracking requirement on the
back-of-envelope level of analysis.
Oh, if you have a number of these devices spread out, and coordinated
time between them is important, just assign one of the devices as
master. That way it disappears as "extra device".
Cheers,
Magnus
I don't think those requirements are hard. You can build a system
that works in three cases
- GPS is available full time
- GPS is available intermittently.
- there is not GPS system, world war III has destroyed it.
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
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.
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.
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
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.
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
On Tue, Jul 23, 2013 at 7:55 AM, Jim Lux jimlux@earthlink.net wrote:
It is an interesting problem.. It's sort of weird, though, as I write the
requirements..
High frequency accuracy (1E-10, 1E-11) ideally.. or high stabiity over 1-100
seconds, with a way to get "knowledge".
But relatively low timing accuracy: 1-3 milliseconds over the same 100
second interval (1E-5)
Often you have a time requirement that is commensurate with the frequency
requirement.
time-nuts mailing list -- time-nuts@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
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
- GPS is available full time
- GPS is available intermittently.
- 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.
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@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
- GPS is available full time
- GPS is available intermittently.
- 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@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
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.