Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #13019
| From | Don Y <this@isnotme.com> |
|---|---|
| Newsgroups | comp.arch.embedded, comp.realtime |
| Subject | Re: Comparing phase of physically distant signals |
| Date | 2013-08-07 03:09 -0700 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <ktt6d4$srt$1@speranza.aioe.org> (permalink) |
| References | (3 earlier) <jxWLt.346$Yd5.283@fx30.am4> <ktppcd$3vf$1@speranza.aioe.org> <7xmwovo10s.fsf@ruckus.brouhaha.com> <ktqd7j$j3q$1@speranza.aioe.org> <7xbo5ayt76.fsf@ruckus.brouhaha.com> |
Cross-posted to 2 groups.
On 8/6/2013 10:18 PM, Paul Rubin wrote:
> Don Y <this@isnotme.com> writes:
>> BETTER THAN MICROSECOND LEVEL
>
> OK, 1 microsecond, finally an actual number.
Why do you care? Note I claimed "tens to hundreds of nanoseconds".
You *buy* the level of performance you want/need for the application
you are solving.
As to "finally" implying that this has been a closely held
"secret" that was only "reluctantly divulged", I remind you
that my initial post was at 10:40AM on 8/3. At 1:21PM on
that same day (i.e., 2.5 hrs later, 3 days *before* your
message) I had already claimed:
"My software can easily achieve synchronization between
nodes to a level better than 1us -- without doing anything
fancy."
At 1:41PM I further qualified this:
"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)."
Earlier, at 11:56AM, I had already declared "a city block".
Perhaps you haven't been paying close attention?
>> I have two physical, tangible devices... interconnected by an
>> ethernet (CAT5) cable that is >100 ft long (but of uncalibrated
>> length).
>
> Well how long is it really? Is it fair to say 50 meters? I.e. several
> of us have asked you to state once and for all the actual numbers from
> your real system, so we can use them instead of speaking in
> hypotheticals.
A CITY BLOCK. For my test, I chose a ~100ft cable. I could have
chosen a 200 ft cable. etc. The length of the cable does not matter!
That's the whole point of the algorithm! And, why I intentionally and
repeatedly claim it is "of uncalibrated length" (didn't you think
it unusual that I deliberately drew attention to this fact? Maybe
that's *significant*???)
If you want to pick nits, you could possibly ask if that city
block is planar or three-dimensional -- and, in this latter case,
what limits exist on the Z axis.
(Let's make it simple. Pretend there is 1/10 - 1/8 mile separating
nodes. I.e., they are deployed -- possibly *uniformly* -- over 1/100
to 1/64 sq mile of real estate)
>> difference in absolute time between the two pulses is O(<1us).
>
> I don't know what "absolute time" is supposed to mean but 1us is an
> actual number, so fine.
Each device obviously has its own concept of "local time". That's
the point of "synchronizing" them! I am drawing attention to the
fact that a single observer in a single location with both devices
physically observable from that position would note <1us of time
difference between two events synthesized on those different
devices *intended* (by those devices) to "coincide" in time.
>> If I lengthen the cable between the two devices and repeat the
>> experiment, the results do not change.
>
> Where are you doing the measurement? In the middle of the cable?
No. Two devices on a bench. Two outputs -- one from each -- connected
to the *same* 'scope. Some uncalibrated (there's that word, again!)
length of cable electrically connects those two devices. There is
no other way they can communicate other than by this cable.
Both devices are allowed to "stabilize" (i.e., the FLL and PLL to
settle into lock). Then, the time difference between two pulses
intended to be omitted coincidentally is measured. I.e., both
devices share a common concept of "current time" -- even though
they are not residing in the same "CPU" clocked by the same
oscillator, etc. They are both told to emit a pulse at
t=12345678 (units being irrelevant -- as long as they can be
correlated between the two devices).
Now, power everything off, replace the interconnect cable with
one that is longer/shorter and repeat the process. The time
difference between the pulses doesn't change. I.e., the
algorithm compensates for the length of the cable.
[There is some sleight of hand in this explanation but it is
essentially correct -- the delay *will* vary by 1/2 the underlying
timebase, maximum]
>> so the devices are *really* separated by that 100+ feet, I still
>> *know* the two pulses are being emitted at the "same" time
>> (within a microsecond of each other). But, I can't *show*
>> that (or verify it!)
>
> Why do you want to show or verify <1 us? What happens if it's somehow
> become 2 us?
Ah! Now you see the problem! *Why* would it suddenly become 2 us?
All we did was move the devices. The electrical connection between
them has not changed. The software hasn't changed. Why does moving
the devices such that the cable is now "stretched taut" (or, more
taut than it was previously) change the tightness/looseness of the
synchronization?
If the algorithm and implementation have been *qualified*/quantified
to provide 1us (or 200ns) of synchronization, why does the PHYSICAL
location of the devices matter? (i.e., it should not -- assuming
you haven't changed some environmental factor *beyond* the limits
of the specification).
So, if you (as a customer/user/technician) observe a deployed system
"misbehaving", what is the "troubleshooting procedure" that you bring
to bear on the problem?
If you're troubleshooting a generic board, chances are you first
check power and other key signals ON WHICH THE DESIGN INTIMATELY
RELIES! Is the CPU running? How do you know -- observer the
oscillator? Monitor address/data bus? Watch an "idiot light"
blink?
Time is important in most "real world" systems. You can verify
the device (returning to the system in question, here) has *a*
concept of time. But, is it consistent with the *system's*
concept of time? How do you verify that when the other node(s)
that you want to compare against (like you did "on the bench"
in the example above) are behind walls, on different floors
and hundreds of feet away in space? You need *really* long
arms to "probe" those signals!
>> *I* use it to synchronize (control the timing relationship between):
>> - audio emitted from different "speakers"
>> - audio from said speakers with video from a "display device"
>> - audio received from a microphone with video from a camera
>
> Audio propagates at about 1 foot per millisecond, and there will be
> variations of much more than 1us across 100 feet due to changes in air
> temperature, breezes, frequency of the audio, etc. So the 1us
> requirement in relation to audio doesn't sound like part of a practical
> problem.
But there have been claims that we *can't* synchronize "time"
at all! Just note "which comes before/after". In that context,
1ms is just as "impossible" as 1us!
[Note, also, that you are actually looking to "tune" devices to
a fraction of a foot as the voice coil of a tweeter is often
located at a different "depth" than that of a woofer/squawker]
>> - determining the location of a moving target within an arena
>> - partitioning of resources (in time) across the system
>
> I don't see where 1us comes into this either.
Put a radio in a room. Let it emit a signal of its own choosing
at a time of its own choosing. Tell me where it is *without*
a common sense of time. (there are actually ways to do this
but they typically *add* RF to the environment)
>> - control phased ultrasonic arrays (emit & detect)
>> - deploy audio in "stadium scale" venues
>> - geological probes (emit & detect)
>> - industrial (process) control systems
>
> Or in those.
How do you precisely control the phase of a 100KHz signal with a
e.g., 1ms timebase? Even a 20KHz (lower end of ultrasound)
signal has a total *period* of only 50us. I.e., 1us gives
you ~7 degrees of phase resolution.
Now, look at the echo/detect aspect. How do you determine the
return angle of an echo if you can't resolve the temporal
differences between the many transducers in the array?
(there are ways around this, as well)
>> Having a common, shared, synchronized notion of "time" across
>> physically separate devices is a powerful mechanism!
>
> But it doesn't make physical sense.
Why? Is "now" somehow different for you than it is for me
based solely on where we are located? If the sun goes supernova,
doesn't it happen at *a* point in time? Regardless of where
we are each located?
If the leading edge of an earthquake occurs at some fixed point in
time, isn't it a *single* event occurring in "Time"? Despite the
fact that two observers may "notice" this event at different
points in "Time". Don't we explicitly rely on a synchronized
sense of time to locate where the event occurred? E.g., if
it happened at time=27 and I claim I noticed the event at time=blue;
this would provide no useful information. And, if I said I noticed
it at time=26 that would be equally useless. (i.e., having the same
*units* of measurement *and* reference point in time)
>> For example, those silly folks at CERN use a (greatly) enhanced PTP
>> implementation ("White Rabbit") that delivers sub-NANOsecond...
>> synchronization over distances of KILOMETERS.
>
> That doesn't make sense either. The physical world is not a shared
> memory system where there's a single register with the current time,
> that can be read instantaneously from everywhere. If A and B are 1km
> apart, then saying they happened within 1 ns of each other is
> meaningless.
No. You're getting caught up in relativity theory.
If I put two devices 1 inch apart and separate them by
10,000km of interconnect cable (e.g., fibre) and shine
a light on both of them (each has a photodetector),
do you agree that "now" is the same point in "Time"
for both units?
Now, one of the units sends a message to the other
saying "Wow! Someone JUST turned on the light!".
That message arrives at the second unit ~30 ms later!
But, both units understand that this was a single point
in Time that has been made to appear skewed simply because
of the transmission delay in the cable.
If the second unit had a precise notion of "1ms", then
it could accurately and reliably predict the *instant*
the message from the first unit would arrive.
Similarly, if the second device could not *see* the light
but was designed (specified!) to make a noise 50ms after
the light was illuminated, it could wait for the message
from the first unit, delay 20 additional ms and successfully
make that noise exactly 50ms after the light was illuminated!
Now, if you move that second unit to a point in space
10,000 km distant from the first unit and repeat the
experiment, the results remain the same. A blind but
not deaf observer at that remote location, on hearing
the noise, would *know* that the light was turned
on exactly 50ms ago. 50 of *his* ms being the same
unit of measure as the ms *at* the light!
How has their physical separation changed the instants
at which each of these events actually occurred?
> The best you could say "globally" is that they were within
> 3 us of each other (= 1km at the speed of light). You could say that
> events at A and B were observed within 1 ns of each other at some
> specific location C (say midway between A and B). Maybe that matches
> your actual requirement. There's no location-independent simultaneity.
>
>> Again, to be specific: tell me how I can verify/measure the
>> time relationship between those two pulse outputs WHEN THEY ARE
>> ACTUALLY SEPARATED BY HUNDREDS OF FEET.
>
> People have suggested radios, GPS, cables, etc. Lasers or LED's seems
> like another possibility. I don't see what the problem is, as long as
> you concretely say what you what to measure, and it seems to me you've
> been vague. 1us at 50m doesn't sound like it needs high tech methods.
(sigh) Yet again: I want to measure the skew (phase difference if you
want to think in terms of periodic signals) between two times *intended*
to be coincident over a long distance to a high tolerance.
You might want to *try* it before dismissing it :> With a (metal?)
wall between you and it and very few dollars to spend. Everything is
always easy until it's *your* problem to solve with real constraints!
E.g., try synchronizing two "clocks" (located side by side so
it doesn't upset your relativistic sensibilities!) on devices
interconnected by 2km of fibre (i.e., 2us propagation delay) and
*no* intervening hardware (e.g., network switch) to better than 1us.
Heck, you can even use a "present day" PC with all its resources
available to you and all that cost that entails -- for free! :>
Once you're done, figure out how you can prove this fact when
I drag one of the PC's into another room down the hall...
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web