Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #12917 > unrolled thread

Comparing phase of physically distant signals

Back to article view | Back to comp.arch.embedded

Contents

  Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 00:45 -0700
    Re: Comparing phase of physically distant signals Jan Panteltje <pNaonStpealmtje@yahoo.com> - 2013-08-03 07:51 +0000
    Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 09:58 +0100
      Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-03 13:21 +0300
        Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 12:16 +0100
        Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 11:56 -0700
          Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 20:17 +0100
            Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 13:41 -0700
              Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 22:46 +0100
                Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 14:57 -0700
                  Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 23:09 +0100
      Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-03 13:58 +0300
        Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 12:30 +0100
      Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-03 16:08 +0300
        Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 14:22 +0100
          Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-03 16:38 +0300
            Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 10:46 -0700
        Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 10:40 -0700
          Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 20:04 +0100
          Re: Comparing phase of physically distant signals Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-08-04 15:55 +0200
            Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-04 19:42 +0300
              Re: Comparing phase of physically distant signals Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-08-04 21:08 +0200
                Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-05 15:28 +0300
                  Re: Comparing phase of physically distant signals Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-08-05 22:17 +0200
                    Re: Comparing phase of physically distant signals Richard Damon <Richard@Damon-Family.org> - 2013-08-05 23:20 -0400
      Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 14:26 +0100
      Re: Comparing phase of physically distant signals George Neuner <gneuner2@comcast.net> - 2013-08-03 14:47 -0400
    Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 08:17 -0700
      Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 12:08 -0700
        Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 20:37 +0100
          Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 12:57 -0700
            Re: Comparing phase of physically distant signals Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-08-04 15:58 +0200
        Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 12:44 -0700
          Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 18:36 -0700
            Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-04 09:56 -0700
              Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-05 14:53 -0700
                Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-05 15:38 -0700
                  Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-07 01:25 -0700
                    Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-07 08:06 -0700
                      Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-07 09:21 -0700
    Re: Comparing phase of physically distant signals josephkk <joseph_barrett@sbcglobal.net> - 2013-08-03 15:40 +0000
      Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 10:05 -0700
        Re: Comparing phase of physically distant signals John S <Sophi.2@invalid.org> - 2013-08-03 12:13 -0500
          Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 10:26 -0700
            Re: Comparing phase of physically distant signals John S <Sophi.2@invalid.org> - 2013-08-03 12:51 -0500
              Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 11:54 -0700
                Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 20:27 +0100
                  Re: Comparing phase of physically distant signals George Neuner <gneuner2@comcast.net> - 2013-08-05 03:26 -0400
                    Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-05 10:34 +0100
                    Re: Comparing phase of physically distant signals Richard Damon <Richard@Damon-Family.org> - 2013-08-05 23:29 -0400
                      Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 08:53 +0100
            Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 12:49 -0700
          Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 12:34 -0700
        Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 12:18 -0700
          Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 12:52 -0700
            Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 13:21 -0700
              Re: Comparing phase of physically distant signals Jeff Liebermann <jeffl@cruzio.com> - 2013-08-03 13:31 -0700
                Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 14:46 -0700
                  Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 15:03 -0700
                  Re: Comparing phase of physically distant signals Jeff Liebermann <jeffl@cruzio.com> - 2013-08-03 17:25 -0700
              Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 14:50 -0700
      Re: Comparing phase of physically distant signals "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-08-04 11:06 +0100
        Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-04 12:19 -0700
    Re: Comparing phase of physically distant signals John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> - 2013-08-03 11:47 -0700
    Re: Comparing phase of physically distant signals Richard Damon <Richard@Damon-Family.org> - 2013-08-03 18:23 -0400
    Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-05 16:53 +0100
      Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-05 13:19 -0700
        Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 00:27 +0100
          Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-05 20:09 -0700
            Re: Comparing phase of physically distant signals Paul Rubin <no.email@nospam.invalid> - 2013-08-05 22:12 -0700
              Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 09:12 +0100
              Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 01:47 -0700
                Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 10:08 +0100
                  Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 02:25 -0700
                    Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 02:48 -0700
                    Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 10:49 +0100
                      Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 03:06 -0700
                        Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 11:57 +0100
                          Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 10:28 -0700
                            Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 21:52 +0100
                              Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-07 01:34 -0700
                                Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-07 09:46 +0100
                Re: Comparing phase of physically distant signals Les Cargill <lcargill99@comcast.com> - 2013-08-06 07:22 -0500
                  Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 10:42 -0700
                    Re: Comparing phase of physically distant signals Les Cargill <lcargill99@comcast.com> - 2013-08-06 23:04 -0500
                      Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 23:50 -0700
                        Re: Comparing phase of physically distant signals Les Cargill <lcargill99@comcast.com> - 2013-08-07 13:05 -0500
                          Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-07 18:22 -0700
                            Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-08 09:35 +0100
                Re: Comparing phase of physically distant signals Paul Rubin <no.email@nospam.invalid> - 2013-08-06 22:18 -0700
                  Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-07 03:09 -0700
                    Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-07 12:39 +0100
                    Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-07 13:18 +0100
            Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 09:23 +0100
              Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 02:02 -0700
            Re: Comparing phase of physically distant signals "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-08-06 09:49 +0100
              Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 02:17 -0700
    Re: Comparing phase of physically distant signals Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-08-16 21:07 +0100
      Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-16 14:50 -0700
        Re: Comparing phase of physically distant signals Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-08-18 19:55 +0100
          Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-19 11:43 -0700
            Re: Comparing phase of physically distant signals Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-08-20 21:43 +0100
              Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-20 14:49 -0700

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#12917 — Comparing phase of physically distant signals

Hi,

[posted to S.E.D in the hope that a hardware analog might exist]

I synchronize the "clocks" on physically distributed processors
such that two or more different machines can have a very finely
defined sense of "synchronized time" between themselves.

During development, I would measure this time skew (among other
factors) by locating these devices side-by-side on a workbench
interconnected by "unquantified" cable.  Then, measuring the
time difference between to "pulse outputs" that I artificially
generate on each board.

So, I could introduce a disturbance to the system and watch to
see how quickly -- and accurately -- the "clocks" (think FLL and
PLL) come back into sync.

How do I practically do this when the devices are *deployed*
and physically distant (vs. "electrically distant" as in my
test case)?

Two ideas come to mind:
1) two equal length cables to connect the "pulse outputs"
from their respective originating devices to the test gear.
2) two *radios* to do the same thing -- after accounting
for different flight times

[Though I wonder how hard it is to qualify two different
radios to have the same delay, etc.  Far easier to trim
two long lengths of wire to the same length!]

Of course, I would like to minimize the recurring cost of
any solution as it is just present for system qualification
(and troubleshooting) and offers no run-time advantage to
the design.

Thx,
--don

[toc] | [next] | [standalone]

#12918

On a sunny day (Sat, 03 Aug 2013 00:45:41 -0700) it happened Don Y
<this@isnotme.com> wrote in <kticf7$hg3$1@speranza.aioe.org>:

>Hi,
>
>[posted to S.E.D in the hope that a hardware analog might exist]
>
>I synchronize the "clocks" on physically distributed processors
>such that two or more different machines can have a very finely
>defined sense of "synchronized time" between themselves.
>
>During development, I would measure this time skew (among other
>factors) by locating these devices side-by-side on a workbench
>interconnected by "unquantified" cable.  Then, measuring the
>time difference between to "pulse outputs" that I artificially
>generate on each board.
>
>So, I could introduce a disturbance to the system and watch to
>see how quickly -- and accurately -- the "clocks" (think FLL and
>PLL) come back into sync.
>
>How do I practically do this when the devices are *deployed*
>and physically distant (vs. "electrically distant" as in my
>test case)?
>
>Two ideas come to mind:
>1) two equal length cables to connect the "pulse outputs"
>from their respective originating devices to the test gear.
>2) two *radios* to do the same thing -- after accounting
>for different flight times
>
>[Though I wonder how hard it is to qualify two different
>radios to have the same delay, etc.  Far easier to trim
>two long lengths of wire to the same length!]
>
>Of course, I would like to minimize the recurring cost of
>any solution as it is just present for system qualification
>(and troubleshooting) and offers no run-time advantage to
>the design.

This sounds like a GPS case,
but really without knowing _numbers_ and other parameters
no way to tell.

[toc] | [prev] | [next] | [standalone]

#12919

On 03/08/13 08:45, Don Y wrote:
> Hi,
>
> [posted to S.E.D in the hope that a hardware analog might exist]
>
> I synchronize the "clocks" on physically distributed processors
> such that two or more different machines can have a very finely
> defined sense of "synchronized time" between themselves.
>
> During development, I would measure this time skew (among other
> factors) by locating these devices side-by-side on a workbench
> interconnected by "unquantified" cable.  Then, measuring the
> time difference between to "pulse outputs" that I artificially
> generate on each board.
>
> So, I could introduce a disturbance to the system and watch to
> see how quickly -- and accurately -- the "clocks" (think FLL and
> PLL) come back into sync.
>
> How do I practically do this when the devices are *deployed*
> and physically distant (vs. "electrically distant" as in my
> test case)?
>
> Two ideas come to mind:
> 1) two equal length cables to connect the "pulse outputs"
> from their respective originating devices to the test gear.
> 2) two *radios* to do the same thing -- after accounting
> for different flight times
>
> [Though I wonder how hard it is to qualify two different
> radios to have the same delay, etc.  Far easier to trim
> two long lengths of wire to the same length!]
>
> Of course, I would like to minimize the recurring cost of
> any solution as it is just present for system qualification
> (and troubleshooting) and offers no run-time advantage to
> the design.

This whole question smacks of one of those questions
that ought to be "unasked".

The concept of having "as single time everywhere" is
erroneous in general, but under limited circumstances
there are useful approximations. You do not give enough
information to indicate whether the approximations
would be valid and/or useful.

If the time-of-flight of messages between the two
ends is much less than the time resolution to which
synchronisation is required, then effectively a
"single time" /is/ possible. Otherwise, not.
As an extreme illustration of that, consider somebody
orbiting Proxima Centauri so that the one-way
time-of-flight is 4.2 years. Clearly it doesn't make
any sense to ask the other person what the date is!
Reduce the distances, and similar principles apply
with smaller time differences.

As a separate issue, non-line-of-sight radio channels
are continuously varying in length and thus in propagation
delay (and even LoS ones to a lesser extent). Ask
any ham, or consider how multipath is *required* for
cellular phone systems.

[toc] | [prev] | [next] | [standalone]

#12920

On Sat, 03 Aug 2013 09:58:31 +0100, Tom Gardner
<spamjunk@blueyonder.co.uk> wrote:

>On 03/08/13 08:45, Don Y wrote:
>> Hi,
>>
>> [posted to S.E.D in the hope that a hardware analog might exist]
>>
>> I synchronize the "clocks" on physically distributed processors
>> such that two or more different machines can have a very finely
>> defined sense of "synchronized time" between themselves.
>>
>> During development, I would measure this time skew (among other
>> factors) by locating these devices side-by-side on a workbench
>> interconnected by "unquantified" cable.  Then, measuring the
>> time difference between to "pulse outputs" that I artificially
>> generate on each board.
>>
>> So, I could introduce a disturbance to the system and watch to
>> see how quickly -- and accurately -- the "clocks" (think FLL and
>> PLL) come back into sync.
>>
>> How do I practically do this when the devices are *deployed*
>> and physically distant (vs. "electrically distant" as in my
>> test case)?
>>
>> Two ideas come to mind:
>> 1) two equal length cables to connect the "pulse outputs"
>> from their respective originating devices to the test gear.
>> 2) two *radios* to do the same thing -- after accounting
>> for different flight times
>>
>> [Though I wonder how hard it is to qualify two different
>> radios to have the same delay, etc.  Far easier to trim
>> two long lengths of wire to the same length!]
>>
>> Of course, I would like to minimize the recurring cost of
>> any solution as it is just present for system qualification
>> (and troubleshooting) and offers no run-time advantage to
>> the design.

Have you studied NTP and IEEE 1588-2008 ?


>This whole question smacks of one of those questions
>that ought to be "unasked".
>
>The concept of having "as single time everywhere" is
>erroneous in general, but under limited circumstances
>there are useful approximations. 

Agreed when thinking of the theory of relativity.

>You do not give enough
>information to indicate whether the approximations
>would be valid and/or useful.

For ground bound or slowly moving (v << c) this should not be a
problem as long as the locations of the stations or at least the
distance to a common source is known.

>
>If the time-of-flight of messages between the two
>ends is much less than the time resolution to which
>synchronisation is required, then effectively a
>"single time" /is/ possible. Otherwise, not.

In GPS time transfer, the distance from the satellite to the atomic
clock is known within a meter as well as the distance from the end
user to the satellite. It is certainly possible to synchronize clocks
within nanoseconds. I am not talking about consumer GPS devices with 1
PPS outputs :-).

>As an extreme illustration of that, consider somebody
>orbiting Proxima Centauri so that the one-way
>time-of-flight is 4.2 years. Clearly it doesn't make
>any sense to ask the other person what the date is!

VLBI with quasars have been used to measure continental drift in
millimeters/year, with known time between different continents. With
known distances VLBI could be used to synchronize clocks.

If there is a phase coherent transponder on a (hypothetical) planet
around Proxima Centauri, the distance to that transponder can be
measured with a fraction of a wavelength from the propagation delay
(2x4.2 years) and the velocity from the doppler. 

To make sure that both clocks are the same, 3x4.2 years might be
needed.

A somewhat quicker and more accurate situation would be that both
stations monitor the phase of  a particular quasar billions of light
years away. To solve the phase ambiguity, monitoring some nearby
pulsars  should help.

IMHO, it is quite relevant to ask the date and time on a planet
orbiting Alpha Centauri, of course the answer might not be too usable
after 8.4 years :-).

>Reduce the distances, and similar principles apply
>with smaller time differences.
>
>As a separate issue, non-line-of-sight radio channels
>are continuously varying in length and thus in propagation
>delay (and even LoS ones to a lesser extent). Ask
>any ham, or consider how multipath is *required* for
>cellular phone systems.

If the response is sent back at _exactly_ the same frequency, the
propagation delay is the same in both directions and hence satisfy the
NTP approximation in both directions. However, if a duplex system is
used, using different frequencies for the up- and downlink, the
multipath pattern might be quite different and the NTP equal
propagation delay assumption do not apply.

[toc] | [prev] | [next] | [standalone]

#12922

On 03/08/13 11:21, upsidedown@downunder.com wrote:
> On Sat, 03 Aug 2013 09:58:31 +0100, Tom Gardner
> <spamjunk@blueyonder.co.uk> wrote:
>
>> On 03/08/13 08:45, Don Y wrote:
>>> Hi,
>>>
>>> [posted to S.E.D in the hope that a hardware analog might exist]
>>>
>>> I synchronize the "clocks" on physically distributed processors
>>> such that two or more different machines can have a very finely
>>> defined sense of "synchronized time" between themselves.
>>>
>>> During development, I would measure this time skew (among other
>>> factors) by locating these devices side-by-side on a workbench
>>> interconnected by "unquantified" cable.  Then, measuring the
>>> time difference between to "pulse outputs" that I artificially
>>> generate on each board.
>>>
>>> So, I could introduce a disturbance to the system and watch to
>>> see how quickly -- and accurately -- the "clocks" (think FLL and
>>> PLL) come back into sync.
>>>
>>> How do I practically do this when the devices are *deployed*
>>> and physically distant (vs. "electrically distant" as in my
>>> test case)?
>>>
>>> Two ideas come to mind:
>>> 1) two equal length cables to connect the "pulse outputs"
>>> from their respective originating devices to the test gear.
>>> 2) two *radios* to do the same thing -- after accounting
>>> for different flight times
>>>
>>> [Though I wonder how hard it is to qualify two different
>>> radios to have the same delay, etc.  Far easier to trim
>>> two long lengths of wire to the same length!]
>>>
>>> Of course, I would like to minimize the recurring cost of
>>> any solution as it is just present for system qualification
>>> (and troubleshooting) and offers no run-time advantage to
>>> the design.
>
> Have you studied NTP and IEEE 1588-2008 ?
>
>
>> This whole question smacks of one of those questions
>> that ought to be "unasked".
>>
>> The concept of having "as single time everywhere" is
>> erroneous in general, but under limited circumstances
>> there are useful approximations.
>
> Agreed when thinking of the theory of relativity.
>
>> You do not give enough
>> information to indicate whether the approximations
>> would be valid and/or useful.
>
> For ground bound or slowly moving (v << c) this should not be a
> problem as long as the locations of the stations or at least the
> distance to a common source is known.

Velocity is irrelevant to the issue - although
velocity would introduce extra complications.


>> If the time-of-flight of messages between the two
>> ends is much less than the time resolution to which
>> synchronisation is required, then effectively a
>> "single time" /is/ possible. Otherwise, not.
>
> In GPS time transfer, the distance from the satellite to the atomic
> clock is known within a meter as well as the distance from the end
> user to the satellite. It is certainly possible to synchronize clocks
> within nanoseconds. I am not talking about consumer GPS devices with 1
> PPS outputs :-).

All true, but misses the point.


>> As an extreme illustration of that, consider somebody
>> orbiting Proxima Centauri so that the one-way
>> time-of-flight is 4.2 years. Clearly it doesn't make
>> any sense to ask the other person what the date is!
>
> VLBI with quasars have been used to measure continental drift in
> millimeters/year, with known time between different continents. With
> known distances VLBI could be used to synchronize clocks.

All true, but misses the point.


> If there is a phase coherent transponder on a (hypothetical) planet
> around Proxima Centauri, the distance to that transponder can be
> measured with a fraction of a wavelength from the propagation delay
> (2x4.2 years) and the velocity from the doppler.
>
> To make sure that both clocks are the same, 3x4.2 years might be
> needed.
>
> A somewhat quicker and more accurate situation would be that both
> stations monitor the phase of  a particular quasar billions of light
> years away. To solve the phase ambiguity, monitoring some nearby
> pulsars  should help.

Having identical frequencies is possible. Having the same
time isn't.

>
> IMHO, it is quite relevant to ask the date and time on a planet
> orbiting Alpha Centauri, of course the answer might not be too usable
> after 8.4 years :-).

That's almost the point! Take it one stage further and
ask in what way it would be meaningful/useful to have April
1st around Proxima Centauri and around Sol. Answer: each
is valid in isolation, but not in combination.


>> Reduce the distances, and similar principles apply
>> with smaller time differences.
>>
>> As a separate issue, non-line-of-sight radio channels
>> are continuously varying in length and thus in propagation
>> delay (and even LoS ones to a lesser extent). Ask
>> any ham, or consider how multipath is *required* for
>> cellular phone systems.
>
> If the response is sent back at _exactly_ the same frequency, the
> propagation delay is the same in both directions and hence satisfy the
> NTP approximation in both directions.

Completely false. The path *changes* over time,
so what is true now won't be true in the future.
Look up and understand the concept of "coherence
distance" and its dual "coherence time".


> However, if a duplex system is
> used, using different frequencies for the up- and downlink, the
> multipath pattern might be quite different and the NTP equal
> propagation delay assumption do not apply.

True, but there are more fundamental problems.

[toc] | [prev] | [next] | [standalone]

#12940

Hi,

On 8/3/2013 3:21 AM, upsidedown@downunder.com wrote:
> On Sat, 03 Aug 2013 09:58:31 +0100, Tom Gardner
> <spamjunk@blueyonder.co.uk> wrote:
>
>>> [posted to S.E.D in the hope that a hardware analog might exist]
>>>
>>> I synchronize the "clocks" on physically distributed processors
>>> such that two or more different machines can have a very finely
>>> defined sense of "synchronized time" between themselves.
>>>
>>> During development, I would measure this time skew (among other
>>> factors) by locating these devices side-by-side on a workbench
>>> interconnected by "unquantified" cable.  Then, measuring the
>>> time difference between to "pulse outputs" that I artificially
>>> generate on each board.
>>>
>>> So, I could introduce a disturbance to the system and watch to
>>> see how quickly -- and accurately -- the "clocks" (think FLL and
>>> PLL) come back into sync.
>>>
>>> How do I practically do this when the devices are *deployed*
>>> and physically distant (vs. "electrically distant" as in my
>>> test case)?
>>>
>>> Two ideas come to mind:
>>> 1) two equal length cables to connect the "pulse outputs"
>>> from their respective originating devices to the test gear.
>>> 2) two *radios* to do the same thing -- after accounting
>>> for different flight times
>>>
>>> [Though I wonder how hard it is to qualify two different
>>> radios to have the same delay, etc.  Far easier to trim
>>> two long lengths of wire to the same length!]
>>>
>>> Of course, I would like to minimize the recurring cost of
>>> any solution as it is just present for system qualification
>>> (and troubleshooting) and offers no run-time advantage to
>>> the design.
>
> Have you studied NTP and IEEE 1588-2008 ?

Yes.  The protocol I designed is a bastardized version of PTP
(1588)  [Because I don't have to coexist with COTS devices and
can thus exploit this fact to make the protocol "less expensive"
for a given level of resources]

>> This whole question smacks of one of those questions
>> that ought to be "unasked".
>>
>> The concept of having "as single time everywhere" is
>> erroneous in general, but under limited circumstances
>> there are useful approximations.
>
> Agreed when thinking of the theory of relativity.

I am willing to ignore relativistic effects on the scale
of a city block  :>

>> You do not give enough
>> information to indicate whether the approximations
>> would be valid and/or useful.
>
> For ground bound or slowly moving (v << c) this should not be a
> problem as long as the locations of the stations or at least the
> distance to a common source is known.

But you wouldn't know those distances -- unless you *measured*
them.  (By contrast, two equal lengths of wire can be previously
constructed)

>> If the time-of-flight of messages between the two
>> ends is much less than the time resolution to which
>> synchronisation is required, then effectively a
>> "single time" /is/ possible. Otherwise, not.

The ToF can differ as long as the difference is known
(or can be known and compensated)

>> Reduce the distances, and similar principles apply
>> with smaller time differences.
>>
>> As a separate issue, non-line-of-sight radio channels
>> are continuously varying in length and thus in propagation
>> delay (and even LoS ones to a lesser extent). Ask
>> any ham, or consider how multipath is *required* for
>> cellular phone systems.
>
> If the response is sent back at _exactly_ the same frequency, the
> propagation delay is the same in both directions and hence satisfy the
> NTP approximation in both directions. However, if a duplex system is
> used, using different frequencies for the up- and downlink, the
> multipath pattern might be quite different and the NTP equal
> propagation delay assumption do not apply.

No, I'm not looking at putting this *in* the (control) loop.

Rather, I have two (multiple) devices who are synchronized
(whatever that means).  They are physically separated by distances
that make comparing reference "synthesized events" (i.e., a pulse
on a particular conductor) on each device to each other via
some piece of test kit.

I.e., on a test bench, I can put any number of such devices
separated by long, uncalibrated lengths of wire (network cable)
and verify/quantify the degree of synchronization by locating
them within inches of each other (i.e., so I can use a pair
of probes connected to a single piece of test equipment).

How does someone do that when the devices are *deployed* and
all that interconnect cable represents *physical* distance?

[toc] | [prev] | [next] | [standalone]

#12943

On 03/08/13 19:56, Don Y wrote:
> Hi,
>
> On 8/3/2013 3:21 AM, upsidedown@downunder.com wrote:
>> On Sat, 03 Aug 2013 09:58:31 +0100, Tom Gardner
>> <spamjunk@blueyonder.co.uk> wrote:
>>
>>>> [posted to S.E.D in the hope that a hardware analog might exist]
>>>>
>>>> I synchronize the "clocks" on physically distributed processors
>>>> such that two or more different machines can have a very finely
>>>> defined sense of "synchronized time" between themselves.
>>>>
>>>> During development, I would measure this time skew (among other
>>>> factors) by locating these devices side-by-side on a workbench
>>>> interconnected by "unquantified" cable.  Then, measuring the
>>>> time difference between to "pulse outputs" that I artificially
>>>> generate on each board.
>>>>
>>>> So, I could introduce a disturbance to the system and watch to
>>>> see how quickly -- and accurately -- the "clocks" (think FLL and
>>>> PLL) come back into sync.
>>>>
>>>> How do I practically do this when the devices are *deployed*
>>>> and physically distant (vs. "electrically distant" as in my
>>>> test case)?
>>>>
>>>> Two ideas come to mind:
>>>> 1) two equal length cables to connect the "pulse outputs"
>>>> from their respective originating devices to the test gear.
>>>> 2) two *radios* to do the same thing -- after accounting
>>>> for different flight times
>>>>
>>>> [Though I wonder how hard it is to qualify two different
>>>> radios to have the same delay, etc.  Far easier to trim
>>>> two long lengths of wire to the same length!]
>>>>
>>>> Of course, I would like to minimize the recurring cost of
>>>> any solution as it is just present for system qualification
>>>> (and troubleshooting) and offers no run-time advantage to
>>>> the design.
>>
>> Have you studied NTP and IEEE 1588-2008 ?
>
> Yes.  The protocol I designed is a bastardized version of PTP
> (1588)  [Because I don't have to coexist with COTS devices and
> can thus exploit this fact to make the protocol "less expensive"
> for a given level of resources]
>
>>> This whole question smacks of one of those questions
>>> that ought to be "unasked".
>>>
>>> The concept of having "as single time everywhere" is
>>> erroneous in general, but under limited circumstances
>>> there are useful approximations.
>>
>> Agreed when thinking of the theory of relativity.
>
> I am willing to ignore relativistic effects on the scale
> of a city block  :>

You don't need to invoke relativity, merely a finite
time for a message to get from one point to another.
Yup, that can include avian carriers or, more reasonably
just within living memory, the speed of a ship taking 3
weeks to get from the UK to Australia!

See below.

>>> If the time-of-flight of messages between the two
>>> ends is much less than the time resolution to which
>>> synchronisation is required, then effectively a
>>> "single time" /is/ possible. Otherwise, not.
>
> The ToF can differ as long as the difference is known
> (or can be known and compensated)

Nope. As I posted in a different message...

Consider points A and B, with
  - an observer O somewhere between A and B
  - an observer OAmid halfway between A and O,
  - an observer OBmid halfway between B and O.

Now consider messages MA and MB from A and B respectively which
whistle past O at the same instant.
  - OAmid will have seen MA before MB
  - OBmid will have seen MA after MB
So, which message was emitted first?

The only answer is the Zen/Pirsig/Hofstadter answer "mu"!


>>> Reduce the distances, and similar principles apply
>>> with smaller time differences.

<snip>

> No, I'm not looking at putting this *in* the (control) loop.
>
> Rather, I have two (multiple) devices who are synchronized
> (whatever that means).

Ah, but that's the point: you have to define what that
means in your case!

<snip>

[toc] | [prev] | [next] | [standalone]

#12954

Hi Tom,

On 8/3/2013 12:17 PM, Tom Gardner wrote:
> On 03/08/13 19:56, Don Y wrote:

>>>> This whole question smacks of one of those questions
>>>> that ought to be "unasked".
>>>>
>>>> The concept of having "as single time everywhere" is
>>>> erroneous in general, but under limited circumstances
>>>> there are useful approximations.
>>>
>>> Agreed when thinking of the theory of relativity.
>>
>> I am willing to ignore relativistic effects on the scale
>> of a city block  :>
>
> You don't need to invoke relativity, merely a finite
> time for a message to get from one point to another.
> Yup, that can include avian carriers or, more reasonably
> just within living memory, the speed of a ship taking 3
> weeks to get from the UK to Australia!
>
> See below.

Exactly.  But I can compensate for these.  E.g., I can
turn my system on, let two nodes synchronize their timebases,
*cut* the interconnect cable and insert an additional 100 ft
and the timebases will resynchronize (after adjusting to
the disturbance I introduced by altering the propagation time
as a consequence of cable length) TO THE EXACT SAME DEGREE
OF SYNCHRONIZATION!  I.e., cable length ("electrical distance")
falls out of the equation.

>>>> If the time-of-flight of messages between the two
>>>> ends is much less than the time resolution to which
>>>> synchronisation is required, then effectively a
>>>> "single time" /is/ possible. Otherwise, not.
>>
>> The ToF can differ as long as the difference is known
>> (or can be known and compensated)
>
> Nope. As I posted in a different message...
>
> Consider points A and B, with
>   - an observer O somewhere between A and B
>   - an observer OAmid halfway between A and O,
>   - an observer OBmid halfway between B and O.
>
> Now consider messages MA and MB from A and B respectively which
> whistle past O at the same instant.
>   - OAmid will have seen MA before MB
>   - OBmid will have seen MA after MB
> So, which message was emitted first?

Whichever one *left* it's point of origin, first.  You
aren't concerned with when you *saw* the event.

Imagine each message is of the form:  "I was emitted at XX:XX:XX"
*and* A and B have a common, synchronized timebase.  Assuming
neither A nor B are liars, then you wait for both messages to
arrive at *any* point (coincident or otherwise) and then examine
their content to determine "which was emitted first".

> The only answer is the Zen/Pirsig/Hofstadter answer "mu"!
>
>>>> Reduce the distances, and similar principles apply
>>>> with smaller time differences.
>
> <snip>
>
>> No, I'm not looking at putting this *in* the (control) loop.
>>
>> Rather, I have two (multiple) devices who are synchronized
>> (whatever that means).
>
> Ah, but that's the point: you have to define what that
> means in your case!

That depends on the level of resources I want to apply to the
problem.  For "free" I can get O(200ns).  If I want to more
carefully specify my hardware, I can drop that to O(20ns).

What I want to be able to do is *verify* that when the devices
are no longer sitting side-by-side on a workbench (with gobs of
wire pooled under said bench) making it impractical to access
both (several) devices froma single piece of test equipment.

[toc] | [prev] | [next] | [standalone]

#12955

On 03/08/13 21:41, Don Y wrote:
> Hi Tom,
>
> On 8/3/2013 12:17 PM, Tom Gardner wrote:
>> On 03/08/13 19:56, Don Y wrote:
>
>>>>> This whole question smacks of one of those questions
>>>>> that ought to be "unasked".
>>>>>
>>>>> The concept of having "as single time everywhere" is
>>>>> erroneous in general, but under limited circumstances
>>>>> there are useful approximations.
>>>>
>>>> Agreed when thinking of the theory of relativity.
>>>
>>> I am willing to ignore relativistic effects on the scale
>>> of a city block  :>
>>
>> You don't need to invoke relativity, merely a finite
>> time for a message to get from one point to another.
>> Yup, that can include avian carriers or, more reasonably
>> just within living memory, the speed of a ship taking 3
>> weeks to get from the UK to Australia!
>>
>> See below.
>
> Exactly.  But I can compensate for these.  E.g., I can
> turn my system on, let two nodes synchronize their timebases,
> *cut* the interconnect cable and insert an additional 100 ft
> and the timebases will resynchronize (after adjusting to
> the disturbance I introduced by altering the propagation time
> as a consequence of cable length) TO THE EXACT SAME DEGREE
> OF SYNCHRONIZATION!  I.e., cable length ("electrical distance")
> falls out of the equation.
>
>>>>> If the time-of-flight of messages between the two
>>>>> ends is much less than the time resolution to which
>>>>> synchronisation is required, then effectively a
>>>>> "single time" /is/ possible. Otherwise, not.
>>>
>>> The ToF can differ as long as the difference is known
>>> (or can be known and compensated)
>>
>> Nope. As I posted in a different message...
>>
>> Consider points A and B, with
>>   - an observer O somewhere between A and B
>>   - an observer OAmid halfway between A and O,
>>   - an observer OBmid halfway between B and O.
>>
>> Now consider messages MA and MB from A and B respectively which
>> whistle past O at the same instant.
>>   - OAmid will have seen MA before MB
>>   - OBmid will have seen MA after MB
>> So, which message was emitted first?
>
> Whichever one *left* it's point of origin, first.  You
> aren't concerned with when you *saw* the event.

So causality isn't of interest. OK. But that also
considerably relaxes the degree to which the time
has to be "synchronised"!


>>> Rather, I have two (multiple) devices who are synchronized
>>> (whatever that means).
>>
>> Ah, but that's the point: you have to define what that
>> means in your case!
>
> That depends on the level of resources I want to apply to the
> problem.  For "free" I can get O(200ns).  If I want to more
> carefully specify my hardware, I can drop that to O(20ns).

Is that what you can achieve or what you need? I don't
really need to know since it isn't my system, of course.

[toc] | [prev] | [next] | [standalone]

#12958

Hi Tom,

On 8/3/2013 2:46 PM, Tom Gardner wrote:
>>>> I am willing to ignore relativistic effects on the scale
>>>> of a city block  :>
>>>
>>> You don't need to invoke relativity, merely a finite
>>> time for a message to get from one point to another.
>>> Yup, that can include avian carriers or, more reasonably
>>> just within living memory, the speed of a ship taking 3
>>> weeks to get from the UK to Australia!
>>>
>>> See below.
>>
>> Exactly.  But I can compensate for these.  E.g., I can
>> turn my system on, let two nodes synchronize their timebases,
>> *cut* the interconnect cable and insert an additional 100 ft
>> and the timebases will resynchronize (after adjusting to
>> the disturbance I introduced by altering the propagation time
>> as a consequence of cable length) TO THE EXACT SAME DEGREE
>> OF SYNCHRONIZATION!  I.e., cable length ("electrical distance")
>> falls out of the equation.
>>
>>>>>> If the time-of-flight of messages between the two
>>>>>> ends is much less than the time resolution to which
>>>>>> synchronisation is required, then effectively a
>>>>>> "single time" /is/ possible. Otherwise, not.
>>>>
>>>> The ToF can differ as long as the difference is known
>>>> (or can be known and compensated)
>>>
>>> Nope. As I posted in a different message...
>>>
>>> Consider points A and B, with
>>>   - an observer O somewhere between A and B
>>>   - an observer OAmid halfway between A and O,
>>>   - an observer OBmid halfway between B and O.
>>>
>>> Now consider messages MA and MB from A and B respectively which
>>> whistle past O at the same instant.
>>>   - OAmid will have seen MA before MB
>>>   - OBmid will have seen MA after MB
>>> So, which message was emitted first?
>>
>> Whichever one *left* it's point of origin, first.  You
>> aren't concerned with when you *saw* the event.
>
> So causality isn't of interest. OK. But that also
> considerably relaxes the degree to which the time
> has to be "synchronised"!

Time *finer* than the degree to which you can synchronize
"doesn't exist".  Just like time finer than the resolution
of a "timer" doesn't exist (it exists but you can't say
anything definitive about it -- other than, "this happened
between X and Y")

If a device reports an observation/action at time X and
some other device reports an observation/action (perhaps
of a different event) at time Y, I want to be able to claim
X preceded Y (or vice versa).

And, be able to cause an action to occur at a specific point
in time *relative* to some other action/observation.

(I know I can't do this with picosecond resolution!  But,
milliseconds are effectively useless for many things!)

>>>> Rather, I have two (multiple) devices who are synchronized
>>>> (whatever that means).
>>>
>>> Ah, but that's the point: you have to define what that
>>> means in your case!
>>
>> That depends on the level of resources I want to apply to the
>> problem.  For "free" I can get O(200ns).  If I want to more
>> carefully specify my hardware, I can drop that to O(20ns).
>
> Is that what you can achieve or what you need? I don't
> really need to know since it isn't my system, of course.

I can already get O(200) without adding extra hardwware for more
precise timestamping *at* the PHY (effectively).  But, that's
only because I have control of lots of other aspects of the
system -- who says what, when, etc.  In a more generic deployment
(e.g., COTS) this would be more like O(2us).

My goal is to see how fine I can get without dramatically
increasing recurring costs -- as this allows the "solution"
to be applied to a larger set of problems.

But, regardless, I need to be able to measure this OFF the
workbench (i.e., deployed) to verify functionality in situ.

E.g., an EE testing a PLL can look at the reference signal and
synthesized signal within *inches* of each other on a PCB.
I want that sort of capability but where the distances involved
are "fractions of a mile" (awful long 'scope leads!!  :> )

[toc] | [prev] | [next] | [standalone]

#12960

On 03/08/13 22:57, Don Y wrote:
> Hi Tom,
>
> On 8/3/2013 2:46 PM, Tom Gardner wrote:
>>>>> I am willing to ignore relativistic effects on the scale
>>>>> of a city block  :>
>>>>
>>>> You don't need to invoke relativity, merely a finite
>>>> time for a message to get from one point to another.
>>>> Yup, that can include avian carriers or, more reasonably
>>>> just within living memory, the speed of a ship taking 3
>>>> weeks to get from the UK to Australia!
>>>>
>>>> See below.
>>>
>>> Exactly.  But I can compensate for these.  E.g., I can
>>> turn my system on, let two nodes synchronize their timebases,
>>> *cut* the interconnect cable and insert an additional 100 ft
>>> and the timebases will resynchronize (after adjusting to
>>> the disturbance I introduced by altering the propagation time
>>> as a consequence of cable length) TO THE EXACT SAME DEGREE
>>> OF SYNCHRONIZATION!  I.e., cable length ("electrical distance")
>>> falls out of the equation.
>>>
>>>>>>> If the time-of-flight of messages between the two
>>>>>>> ends is much less than the time resolution to which
>>>>>>> synchronisation is required, then effectively a
>>>>>>> "single time" /is/ possible. Otherwise, not.
>>>>>
>>>>> The ToF can differ as long as the difference is known
>>>>> (or can be known and compensated)
>>>>
>>>> Nope. As I posted in a different message...
>>>>
>>>> Consider points A and B, with
>>>>   - an observer O somewhere between A and B
>>>>   - an observer OAmid halfway between A and O,
>>>>   - an observer OBmid halfway between B and O.
>>>>
>>>> Now consider messages MA and MB from A and B respectively which
>>>> whistle past O at the same instant.
>>>>   - OAmid will have seen MA before MB
>>>>   - OBmid will have seen MA after MB
>>>> So, which message was emitted first?
>>>
>>> Whichever one *left* it's point of origin, first.  You
>>> aren't concerned with when you *saw* the event.
>>
>> So causality isn't of interest. OK. But that also
>> considerably relaxes the degree to which the time
>> has to be "synchronised"!
>
> Time *finer* than the degree to which you can synchronize
> "doesn't exist".  Just like time finer than the resolution
> of a "timer" doesn't exist (it exists but you can't say
> anything definitive about it -- other than, "this happened
> between X and Y")
>
> If a device reports an observation/action at time X and
> some other device reports an observation/action (perhaps
> of a different event) at time Y, I want to be able to claim
> X preceded Y (or vice versa).

That's fine provided the two devices are at the same point.
If not, the concept of "before/after" is moot.


> And, be able to cause an action to occur at a specific point
> in time *relative* to some other action/observation.

That's just fine since all observations and actions
are occurring at one point.



> (I know I can't do this with picosecond resolution!  But,
> milliseconds are effectively useless for many things!)

Picoseconds matter inside ics :) E.g. there are ics which
allow you to change the delay of digital signals in
increments of, IIRC, 11ps, where 11ps is the internal
delay of one gate. See the OnSemi NB6L295 for one example.


>>>>> Rather, I have two (multiple) devices who are synchronized
>>>>> (whatever that means).
>>>>
>>>> Ah, but that's the point: you have to define what that
>>>> means in your case!
>>>
>>> That depends on the level of resources I want to apply to the
>>> problem.  For "free" I can get O(200ns).  If I want to more
>>> carefully specify my hardware, I can drop that to O(20ns).
>>
>> Is that what you can achieve or what you need? I don't
>> really need to know since it isn't my system, of course.
>
> I can already get O(200) without adding extra hardwware for more
> precise timestamping *at* the PHY (effectively).  But, that's
> only because I have control of lots of other aspects of the
> system -- who says what, when, etc.  In a more generic deployment
> (e.g., COTS) this would be more like O(2us).
>
> My goal is to see how fine I can get without dramatically
> increasing recurring costs -- as this allows the "solution"
> to be applied to a larger set of problems.
>
> But, regardless, I need to be able to measure this OFF the
> workbench (i.e., deployed) to verify functionality in situ.
>
> E.g., an EE testing a PLL can look at the reference signal and
> synthesized signal within *inches* of each other on a PCB.
> I want that sort of capability but where the distances involved
> are "fractions of a mile" (awful long 'scope leads!!  :> )

There's no conceptual problem with synchronising edges of
repetitive signals to much less than the time-of-flight, but
that's not synchronising the time.

[toc] | [prev] | [next] | [standalone]

#12921

On Sat, 03 Aug 2013 09:58:31 +0100, Tom Gardner
<spamjunk@blueyonder.co.uk> wrote:

>If the time-of-flight of messages between the two
>ends is much less than the time resolution to which
>synchronisation is required, then effectively a
>"single time" /is/ possible. Otherwise, not.
>As an extreme illustration of that, consider somebody
>orbiting Proxima Centauri so that the one-way
>time-of-flight is 4.2 years. Clearly it doesn't make
>any sense to ask the other person what the date is!

Dropping this to the situation for a colony on Mars, there are no
technical problems maintaining the "same time" concept on Earth as
well as on Mars, but if "Mars Universal Time" would track the UTC, the
length of the second or the number of seconds a day needs to be
varied.

[toc] | [prev] | [next] | [standalone]

#12923

On 03/08/13 11:58, upsidedown@downunder.com wrote:
> On Sat, 03 Aug 2013 09:58:31 +0100, Tom Gardner
> <spamjunk@blueyonder.co.uk> wrote:
>
>> If the time-of-flight of messages between the two
>> ends is much less than the time resolution to which
>> synchronisation is required, then effectively a
>> "single time" /is/ possible. Otherwise, not.
>> As an extreme illustration of that, consider somebody
>> orbiting Proxima Centauri so that the one-way
>> time-of-flight is 4.2 years. Clearly it doesn't make
>> any sense to ask the other person what the date is!
>
> Dropping this to the situation for a colony on Mars, there are no
> technical problems maintaining the "same time" concept on Earth as
> well as on Mars, but if "Mars Universal Time" would track the UTC, the
> length of the second or the number of seconds a day needs to be
> varied.

Extra complications that obscure the fundamental point.

[toc] | [prev] | [next] | [standalone]

#12924

On Sat, 03 Aug 2013 09:58:31 +0100, Tom Gardner
<spamjunk@blueyonder.co.uk> wrote:

>This whole question smacks of one of those questions
>that ought to be "unasked".
>
>The concept of having "as single time everywhere" is
>erroneous in general, but under limited circumstances
>there are useful approximations. You do not give enough
>information to indicate whether the approximations
>would be valid and/or useful.

While I have no idea, what Don Y had in mind (might be whatever :-),
but at least for any ground based system, having "the same time" is
not that alien concept.

in the North East North America, there was a severe power black out in
Aug 2003 as well as in Central Europe in Nov 2006, which were caused
by individual link failures, which propagated to larger and larger
parts of the continent.

In order to solve the root cause of these events, various
SequenceOfEvent (SoE) analysis were performed later on, i.e. post
mortem dumps. Each protection relay will record the event with a time
stamp from the local clock.

In order to be useful for SoE analysis, the event must be time stamped
from a reliable local clock, which must be traceable to same local
time standard, ultimately back to IAT.

Modern protection relays on an electric switchyard are synchronized
to some local GPS time receiver via NTP and the event messages are
stamped with time with 1 ms resolution.

Thus, for millisecond level SoE analysis, about 1 ms continent wide
synchronization is needed.

[toc] | [prev] | [next] | [standalone]

#12925

On 03/08/13 14:08, upsidedown@downunder.com wrote:
> On Sat, 03 Aug 2013 09:58:31 +0100, Tom Gardner
> <spamjunk@blueyonder.co.uk> wrote:
>
>> This whole question smacks of one of those questions
>> that ought to be "unasked".
>>
>> The concept of having "as single time everywhere" is
>> erroneous in general, but under limited circumstances
>> there are useful approximations. You do not give enough
>> information to indicate whether the approximations
>> would be valid and/or useful.
>
> While I have no idea, what Don Y had in mind (might be whatever :-),
> but at least for any ground based system, having "the same time" is
> not that alien concept.
>
> in the North East North America, there was a severe power black out in
> Aug 2003 as well as in Central Europe in Nov 2006, which were caused
> by individual link failures, which propagated to larger and larger
> parts of the continent.
>
> In order to solve the root cause of these events, various
> SequenceOfEvent (SoE) analysis were performed later on, i.e. post
> mortem dumps. Each protection relay will record the event with a time
> stamp from the local clock.
>
> In order to be useful for SoE analysis, the event must be time stamped
> from a reliable local clock, which must be traceable to same local
> time standard, ultimately back to IAT.
>
> Modern protection relays on an electric switchyard are synchronized
> to some local GPS time receiver via NTP and the event messages are
> stamped with time with 1 ms resolution.
>
> Thus, for millisecond level SoE analysis, about 1 ms continent wide
> synchronization is needed.

And below that resolution the concept of "common time" has
no useful meaning. It all depends on the distance; inside
an ic it is much smaller, but still there :)

[toc] | [prev] | [next] | [standalone]

#12927

On Sat, 03 Aug 2013 14:22:14 +0100, Tom Gardner
<spamjunk@blueyonder.co.uk> wrote:

>On 03/08/13 14:08, upsidedown@downunder.com wrote:
>> On Sat, 03 Aug 2013 09:58:31 +0100, Tom Gardner
>> <spamjunk@blueyonder.co.uk> wrote:
>>
>>> This whole question smacks of one of those questions
>>> that ought to be "unasked".
>>>
>>> The concept of having "as single time everywhere" is
>>> erroneous in general, but under limited circumstances
>>> there are useful approximations. You do not give enough
>>> information to indicate whether the approximations
>>> would be valid and/or useful.
>>
>> While I have no idea, what Don Y had in mind (might be whatever :-),
>> but at least for any ground based system, having "the same time" is
>> not that alien concept.
>>
>> in the North East North America, there was a severe power black out in
>> Aug 2003 as well as in Central Europe in Nov 2006, which were caused
>> by individual link failures, which propagated to larger and larger
>> parts of the continent.
>>
>> In order to solve the root cause of these events, various
>> SequenceOfEvent (SoE) analysis were performed later on, i.e. post
>> mortem dumps. Each protection relay will record the event with a time
>> stamp from the local clock.
>>
>> In order to be useful for SoE analysis, the event must be time stamped
>> from a reliable local clock, which must be traceable to same local
>> time standard, ultimately back to IAT.
>>
>> Modern protection relays on an electric switchyard are synchronized
>> to some local GPS time receiver via NTP and the event messages are
>> stamped with time with 1 ms resolution.
>>
>> Thus, for millisecond level SoE analysis, about 1 ms continent wide
>> synchronization is needed.
>
>And below that resolution the concept of "common time" has
>no useful meaning. It all depends on the distance; inside
>an ic it is much smaller, but still there :)

1 ms = 200 .. 300 km of open wire power line.
1 ms = 5 % of 20 ms cycle at 50 Hz.

[toc] | [prev] | [next] | [standalone]

#12935

On 8/3/2013 6:38 AM, upsidedown@downunder.com wrote:

>>> Thus, for millisecond level SoE analysis, about 1 ms continent wide
>>> synchronization is needed.
>>
>> And below that resolution the concept of "common time" has
>> no useful meaning. It all depends on the distance; inside
>> an ic it is much smaller, but still there :)
>
> 1 ms = 200 .. 300 km of open wire power line.
> 1 ms = 5 % of 20 ms cycle at 50 Hz.

Move down a few orders of magnitude  :>

But, were not talking about "continent level synchronization".
Just comparing a locally derived clock in one room with another
locally derived clock in another room on a different floor or
in a different "wing" of a large building (e.g., office complex).

[toc] | [prev] | [next] | [standalone]

#12934

Hi,

On 8/3/2013 6:08 AM, upsidedown@downunder.com wrote:
> On Sat, 03 Aug 2013 09:58:31 +0100, Tom Gardner
> <spamjunk@blueyonder.co.uk> wrote:
>
>> This whole question smacks of one of those questions
>> that ought to be "unasked".
>>
>> The concept of having "as single time everywhere" is
>> erroneous in general, but under limited circumstances
>> there are useful approximations. You do not give enough
>> information to indicate whether the approximations
>> would be valid and/or useful.
>
> While I have no idea, what Don Y had in mind (might be whatever :-),
> but at least for any ground based system, having "the same time" is
> not that alien concept.

Of course!  Hence NTP, PTP, "let's synchronize our watches, gentlemen",
etc.

> in the North East North America, there was a severe power black out in
> Aug 2003 as well as in Central Europe in Nov 2006, which were caused
> by individual link failures, which propagated to larger and larger
> parts of the continent.
>
> In order to solve the root cause of these events, various
> SequenceOfEvent (SoE) analysis were performed later on, i.e. post
> mortem dumps. Each protection relay will record the event with a time
> stamp from the local clock.
>
> In order to be useful for SoE analysis, the event must be time stamped
> from a reliable local clock, which must be traceable to same local
> time standard, ultimately back to IAT.

Exactly.  If two different "entities" do or observer "things",
then you need some way of deciding which event is the chicken
an which the egg.

> Modern protection relays on an electric switchyard are synchronized
> to some local GPS time receiver via NTP and the event messages are
> stamped with time with 1 ms resolution.
>
> Thus, for millisecond level SoE analysis, about 1 ms continent wide
> synchronization is needed.

Yes.  I.e., any sense of time *finer* than this is ambiguous.
Saying something happened at t=4.035ms and something else happened
at t=4.036ms doesn't allow you to declare the ACTUAL ordering of
these events.

OTOH, if one occurs at t=4ms and the other occurs at t=6ms
you can confidently claim which followed the other.

But, there are (obviously) costs to getting more and more
precision.  And, being able to *measure* that when the two
signals that you are comparing are physically distant
(too far for scope leads to simultaneously monitor).

[toc] | [prev] | [next] | [standalone]

#12941

On 03/08/13 18:40, Don Y wrote:
> Hi,
>
> On 8/3/2013 6:08 AM, upsidedown@downunder.com wrote:
>> On Sat, 03 Aug 2013 09:58:31 +0100, Tom Gardner
>> <spamjunk@blueyonder.co.uk> wrote:
>>
>>> This whole question smacks of one of those questions
>>> that ought to be "unasked".
>>>
>>> The concept of having "as single time everywhere" is
>>> erroneous in general, but under limited circumstances
>>> there are useful approximations. You do not give enough
>>> information to indicate whether the approximations
>>> would be valid and/or useful.
>>
>> While I have no idea, what Don Y had in mind (might be whatever :-),
>> but at least for any ground based system, having "the same time" is
>> not that alien concept.
>
> Of course!  Hence NTP, PTP, "let's synchronize our watches, gentlemen",
> etc.
>
>> in the North East North America, there was a severe power black out in
>> Aug 2003 as well as in Central Europe in Nov 2006, which were caused
>> by individual link failures, which propagated to larger and larger
>> parts of the continent.
>>
>> In order to solve the root cause of these events, various
>> SequenceOfEvent (SoE) analysis were performed later on, i.e. post
>> mortem dumps. Each protection relay will record the event with a time
>> stamp from the local clock.
>>
>> In order to be useful for SoE analysis, the event must be time stamped
>> from a reliable local clock, which must be traceable to same local
>> time standard, ultimately back to IAT.
>
> Exactly.  If two different "entities" do or observer "things",
> then you need some way of deciding which event is the chicken
> an which the egg.
>
>> Modern protection relays on an electric switchyard are synchronized
>> to some local GPS time receiver via NTP and the event messages are
>> stamped with time with 1 ms resolution.
>>
>> Thus, for millisecond level SoE analysis, about 1 ms continent wide
>> synchronization is needed.
>
> Yes.  I.e., any sense of time *finer* than this is ambiguous.
> Saying something happened at t=4.035ms and something else happened
> at t=4.036ms doesn't allow you to declare the ACTUAL ordering of
> these events.
>
> OTOH, if one occurs at t=4ms and the other occurs at t=6ms
> you can confidently claim which followed the other.

But if the shortest latency between the two points is 1s then
the whole concept of "which happened first" is a moot
point - to the point at which is shouldn't even be considered.

Consider points A and B, with
  - an observer O somewhere between A and B
  - an observer OAmid halfway between A and O,
  - an observer OBmid halfway between B and O.

Now consider messages MA and MB from A and B respectively which
whistle past O at the same instant.
  - OAmid will have seen MA before MB
  - OBmid will have seen MA after MB
So, which message was emitted first?

The only answer is the Zen/Pirsig/Hofstadter answer "mu"!

[toc] | [prev] | [next] | [standalone]

#12966

On 03.08.2013 19:40, Don Y wrote:

> Yes.  I.e., any sense of time *finer* than this is ambiguous.
> Saying something happened at t=4.035ms and something else happened
> at t=4.036ms doesn't allow you to declare the ACTUAL ordering of
> these events.

It's way worse than that.  Not only don't you manage to "declare" that 
ordering ... that orderings simply may not _exist_ in the first place. 
In other words, you may be chasing a unicorn there.

In the full theoretical extreme, there is no such thing as 
"synchronicity" across _any_ special distance other than zero.  Einstein 
killed that notion pretty well.

Practically, there is no such thing as "synchronous" to a tolerance of 
delta_t within a set-up of (signal path length) diameter d if d/delat_t 
is lager than your signal propagation speed is

You've been strictly avoiding to give actual numbers, but you've 
mentioned "city block" and "dozens of nanoseconds".  Even that puts you 
almost certainly beyond the limits of possibility.  c can be memorized 
easily as one foot per nanosecond, cable-bound signalling tends to be 
2/3 of that, i.e. 20 cm/ns.  So unless your "city block" is much smaller 
than I think it would be, you're looking at a window of impossible 
synchronicity of around 500 nanoseconds.  So no, there's no way you'll 
get to 100 ns or less.

[toc] | [prev] | [next] | [standalone]

Page 1 of 6  [1] 2 3 4 5 6  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web