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 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

#12968

On Sun, 04 Aug 2013 15:55:55 +0200, Hans-Bernhard Bröker
<HBBroeker@t-online.de> wrote:

>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.


What is the actual problem ?

If one event occurred at 12:34:56.004.035 UTC and an other at
12:34:56.004.036 UTC, there should not be a problem to determine the
sequence of event (SoE), provided that the local clocks are within one
microsecond.

If you have minutes or even weeks time to synchronize the absolute
time clocks in two devices, you should be able to get quite close
reliable time stamps.
 
Of course, when the system is started for the first times, within a
few seconds of startup, the time stamps can be wildly off scale.

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

#12972

On 04.08.2013 18:42, upsidedown@downunder.com wrote:
> On Sun, 04 Aug 2013 15:55:55 +0200, Hans-Bernhard Bröker
> <HBBroeker@t-online.de> wrote:

>> 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.

> What is the actual problem ?
>
> If one event occurred at 12:34:56.004.035 UTC and an other at
> 12:34:56.004.036 UTC, there should not be a problem to determine the
> sequence of event (SoE), provided that the local clocks are within one
> microsecond.

Even if they start out like that, they won't stay synchronized over any 
period of time.

You're putting yourself in the realm where fundamental physics denies 
the existence of what you're trying to achieve.  The fact that one 
device sits two storeys higher than the other could already disrupt your 
synchronisation in the long run.

You said elsewhere that for a problem this small you plan on ignoring 
the theory of relativity.  Well, here's the bad news: that won't help 
you, because that won't make RT ignore you.

It's a fallacy to believe that SRT only concerns very big or very fast 
objects.  As you drive your timing requirements down, and the size of 
things up, sooner or later you always hit relativistic boundaries. 
Silicon designers learned that about a decade ago, when they found out 
that they just couldn't push CPU core frequencies any higher because 
they couldn't maintain synchronicity of clock edges across a region as 
small as 1 cm^2.  You're trying to cross essentially the same boundary.

> If you have minutes or even weeks time to synchronize the absolute
> time clocks in two devices, you should be able to get quite close
> reliable time stamps.

Having a long time to achieve synchronization only makes the problem 
worse.  Think about it: now you're expecting those clocks to maintain a 
tolerance of one microsecond across several weeks.  Several weeks is at 
least a million seconds.  I.e. now you're requiring 1e-6 / 1e6 = 1e-12 
relative clock speed tolerance.  You would need atomic clocks or better 
for that, which I'm willing to bet your devices don't have, nor anywhere 
near it.

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

#12979

On Sun, 04 Aug 2013 21:08:25 +0200, Hans-Bernhard Bröker
<HBBroeker@t-online.de> wrote:

>On 04.08.2013 18:42, upsidedown@downunder.com wrote:
>> On Sun, 04 Aug 2013 15:55:55 +0200, Hans-Bernhard Bröker
>> <HBBroeker@t-online.de> wrote:
>
>>> 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.
>
>> What is the actual problem ?
>>
>> If one event occurred at 12:34:56.004.035 UTC and an other at
>> 12:34:56.004.036 UTC, there should not be a problem to determine the
>> sequence of event (SoE), provided that the local clocks are within one
>> microsecond.
>
>Even if they start out like that, they won't stay synchronized over any 
>period of time.

With GPS/GLONAS etc. as long as there are sufficient number of
satellites in view, your local clock will be updated quite frequently,
so in reality, the local clock short time stability is an issue, the
long term (aging etc.) is not much an issue, provided that satellite
navigation is available. With more and more countries running their
own navigation systems, there is a reduced risk that a single country
could disrupt the service by unilateral decision.

>You're putting yourself in the realm where fundamental physics denies 
>the existence of what you're trying to achieve.  The fact that one 
>device sits two storeys higher than the other could already disrupt your 
>synchronisation in the long run.

OK, so you want to put some relativistic issues into the picture.

A device in the upper floor will "orbit" the earth with about 10 m
longer path than the device on the lower floor, thus the device on the
upper floor has a 0.25  ppm higher velocity than the device on the
lower floor. Now that the whole building rotates about 1 ppm of the
speed of light, so it takes quite a long time, until some relativistic
effects will be observed between the floors.

The gravity at upper floor is slightly lower than on the lower floor,
so again, this will have some minor relativistic issues. 

But again, with only daily time updates, these errors should be easily
compensated.

>You said elsewhere that for a problem this small you plan on ignoring 
>the theory of relativity.  Well, here's the bad news: that won't help 
>you, because that won't make RT ignore you.
>
>It's a fallacy to believe that SRT only concerns very big or very fast 
>objects.  As you drive your timing requirements down, and the size of 
>things up, sooner or later you always hit relativistic boundaries. 
>Silicon designers learned that about a decade ago, when they found out 
>that they just couldn't push CPU core frequencies any higher because 
>they couldn't maintain synchronicity of clock edges across a region as 
>small as 1 cm^2.  You're trying to cross essentially the same boundary.

Big parallel synchronous systems are going to fail simply because of
propagation delays, long before relativistic issues are included.

>
>> If you have minutes or even weeks time to synchronize the absolute
>> time clocks in two devices, you should be able to get quite close
>> reliable time stamps.
>
>Having a long time to achieve synchronization only makes the problem 
>worse.  Think about it: now you're expecting those clocks to maintain a 
>tolerance of one microsecond across several weeks.  Several weeks is at 
>least a million seconds.  I.e. now you're requiring 1e-6 / 1e6 = 1e-12 
>relative clock speed tolerance.  You would need atomic clocks or better 
>for that, which I'm willing to bet your devices don't have, nor anywhere 
>near it.

There seems to be some misunderstanding here. I did not say that two
measurements should be taken a week apart. I was suggesting that
measurements should be as often as possible and the result should be
averaged over a week or two.

Think about a geodetic surveying terminal that might sit a week or two
in the same place will get the location of the receiver (actually
antenna phase center) to within a millimeter or two. I would assume
that the timing accuracy could also increase in a similar way.

My naivistic approach would be to get timing signals from the
satellites as often as possible (say every second), calculate the
difference from my local clock and use some Kalman filtering to get
rid of bad samples. Assuming random timing errors and my local clock
is synchronized with the reference, equal amount of "early" and "late"
samples should be available, i.e. the sum of differences should be
zero. When the sum of differences is not zero, you should adjust your
own local clock.

Multiple manufacturers claim timing errors  in the tens of nanoseconds
range even a few minutes after switch-on, so apparently they use
something better than my naivistic approach.

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

#12981

On 05.08.2013 14:28, upsidedown@downunder.com wrote:
> On Sun, 04 Aug 2013 21:08:25 +0200, Hans-Bernhard Bröker
> <HBBroeker@t-online.de> wrote:

>> Even if they start out like that, they won't stay synchronized over any
>> period of time.

> With GPS/GLONAS etc. as long as there are sufficient number of
> satellites in view, your local clock will be updated quite frequently,

And each of those updates to an individual station will _disrupt_ your 
carefully achieved synchronization.  So that's not actually helping --- 
it's making things worse by introducing yet another source of variation.

> Big parallel synchronous systems are going to fail simply because of
> propagation delays, long before relativistic issues are included.

And relativity is the law that tells you that those propagation delays 
will _never_ be smaller than distance / c.  It sets a rigid upper limit 
worth keeping in mind.

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

#12987

On 8/5/13 4:17 PM, Hans-Bernhard Bröker wrote:
> On 05.08.2013 14:28, upsidedown@downunder.com wrote:
>> On Sun, 04 Aug 2013 21:08:25 +0200, Hans-Bernhard Bröker
>> <HBBroeker@t-online.de> wrote:
> 
>>> Even if they start out like that, they won't stay synchronized over any
>>> period of time.
> 
>> With GPS/GLONAS etc. as long as there are sufficient number of
>> satellites in view, your local clock will be updated quite frequently,
> 
> And each of those updates to an individual station will _disrupt_ your
> carefully achieved synchronization.  So that's not actually helping ---
> it's making things worse by introducing yet another source of variation.
> 
>> Big parallel synchronous systems are going to fail simply because of
>> propagation delays, long before relativistic issues are included.
> 
> And relativity is the law that tells you that those propagation delays
> will _never_ be smaller than distance / c.  It sets a rigid upper limit
> worth keeping in mind.
> 
> 

Note, that if you are properly receiving and using GPS signals to set
your clock, you are correcting for the propagation delays (at least to
the level they are predictable). GPS units will typically know the
current time in the GPS time system to within a small number of
nano-seconds, as much larger errors in time would make the position they
compute very inaccurate.

The trick is getting this time out of the unit. GPS modules designed to
provide ultra accurate times will have a signal that transitions at the
precise roll over of the GPS time second (or a faction thereof), which
the external system can try to lock onto. (your cheap consumer GPS won't
even try to generate this).

The relativistic issue would be if the propagation time (of what ever is
being used to observe) between the two systems exceeds the accuracy that
you are trying to synchronize to, then different observers will conclude
differently if you maintained synchronization or not.

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

#12926

On 03/08/13 09:58, Tom Gardner 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.
>
> 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.

I ought to add that comparing the *phase* of repetitive
signals is entirely possible and useful to much less than
time-of-flight resolution and accuracy. But not the *time*.

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

#12938

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!

Unless you have some kind of quantum entangled "radio" which
[theoretically] would be instantaneous at any distance.  
[Yes, I have trouble with "spooky action at a distance" too.]

George

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

#12929

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.


Installers will hate this.


> 2) two *radios* to do the same thing -- after accounting
> for different flight times
>

Installers will love this. But why different flight times? Where is this
stuff going to be located? Down a borehole?


> [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!]
> 

Aside from using GPS, WWV or some other reliable transmitter you could
have a very stable oscillator on each module. Such as a TCXO. Then you
have a transceiver on each. You perform a loopback echo locally, via an
RF switch. That gives you the latency of each radio (should be pretty
much the same for each module). Now only the path adds in which should
normally be reciprocal.


> 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.
> 

If the distance is small you can use a cheap transceiver chip or module.
If using a chip and rolling your own hardware you must usually go
through the radio cert for "intentional radiator" at the EMC lab which
adds NRE.

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

#12942

Hi Joerg,

On 8/3/2013 8:17 AM, Joerg wrote:
> Don Y wrote:
>> 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.
>
> Installers will hate this.

Exactly.  Imagine point A and point B are on different floors
in different buildings, etc.  "Hey, Tony, head out to the truck
and fetch the REALLY REALLY REALLY LONG cable set..."

(Then, *deploying* those cables -- even if only for an hour or so)

>> 2) two *radios* to do the same thing -- after accounting
>> for different flight times
>
> Installers will love this. But why different flight times? Where is this
> stuff going to be located? Down a borehole?

If you are measuring at a third point (without knowing its
distance/ToF from each of the other two points -- cuz you
have no reference you can rely upon!), then you need to
know the difference "in time" from the "reference output"
on each device, *through* the respective radio, through the
"air" and into the "receiver" -- before it can be applied
to some bit of test kit.

>> [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!]
>
> Aside from using GPS, WWV or some other reliable transmitter you could
> have a very stable oscillator on each module. Such as a TCXO. Then you
> have a transceiver on each. You perform a loopback echo locally, via an
> RF switch. That gives you the latency of each radio (should be pretty
> much the same for each module). Now only the path adds in which should
> normally be reciprocal.

[I don't want this to be a recurring cost.  So, the radio is
a "bag" attached solely for testing/calibration/troubleshooting]

You still don't know what the difference in the propagation
(through air) from each transceiver.

I.e., if the distance to device 1 is A and the distance to device 2
is B, then there will be a difference between the signals arriving
that corresponds to the difference between A and B.  Even after you
compensate for any differences in the radios themselves.

[The same is true with a single radio at device 1 "received" at
device 2 -- how much time did the RF signal take to get to device
2 cuz it's arrival will occur after device 2's notion of the
device 1 event with which it is intended to correlate.]

That's the appeal between "two equal lengths of wire" -- the
delay through each can be made "identical".

>> 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.
>
> If the distance is small you can use a cheap transceiver chip or module.
> If using a chip and rolling your own hardware you must usually go
> through the radio cert for "intentional radiator" at the EMC lab which
> adds NRE.

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

#12947

On 03/08/13 20:08, Don Y wrote:
> Hi Joerg,
>
> On 8/3/2013 8:17 AM, Joerg wrote:
>> Aside from using GPS, WWV or some other reliable transmitter you could
>> have a very stable oscillator on each module. Such as a TCXO. Then you
>> have a transceiver on each. You perform a loopback echo locally, via an
>> RF switch. That gives you the latency of each radio (should be pretty
>> much the same for each module). Now only the path adds in which should
>> normally be reciprocal.
>
> [I don't want this to be a recurring cost.  So, the radio is
> a "bag" attached solely for testing/calibration/troubleshooting]
>
> You still don't know what the difference in the propagation
> (through air) from each transceiver.

The propagation delay will /vary/ over time due to changes in
the environment. Whether the variation is or is not significant
depends on your (unstated) specification, the distances, RF
frequency, temperature/pressure and multipath reflections.

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

#12951

Hi Tom,

On 8/3/2013 12:37 PM, Tom Gardner wrote:
>>> Aside from using GPS, WWV or some other reliable transmitter you could
>>> have a very stable oscillator on each module. Such as a TCXO. Then you
>>> have a transceiver on each. You perform a loopback echo locally, via an
>>> RF switch. That gives you the latency of each radio (should be pretty
>>> much the same for each module). Now only the path adds in which should
>>> normally be reciprocal.
>>
>> [I don't want this to be a recurring cost.  So, the radio is
>> a "bag" attached solely for testing/calibration/troubleshooting]
>>
>> You still don't know what the difference in the propagation
>> (through air) from each transceiver.
>
> The propagation delay will /vary/ over time due to changes in
> the environment. Whether the variation is or is not significant
> depends on your (unstated) specification, the distances, RF
> frequency, temperature/pressure and multipath reflections.

You don't care because the time is short -- you aren't leaving this
"deployed"... just using it to measure performance and sort out
if something is wrong (i.e., the system is claiming things are in
sync to a tolerance of 100ns yet it isn't *acting* as if that is
the case; is it, perhaps, NOT synchronized as finely as it thinks?)

To be clear:  distances are on the order of a city block
(but in three axis, not just two).  Events are synchronized to
something on the order of tens to hundreds of nanoseconds.
Reference events are, ideally, very low frequency (tens of
Hz or less).  The timespan over which the "measurement"
must be observed is on the order of hours of "a work day"
(i.e., you can recalibrate in the morning if you need more
time)

Cost to the deployed design should be as close to $0.00 as
possible (e.g., currently, it is an unused I/O pin on each
device).  Ideally, the test kit wouldn't be super expensive,
either.

[Keep in mind that I can do this easily "on a bench" and
that's how people will want to think of the problem -- the
cost associated with the distance shouldn't completely change the
nature of the solution]

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

#12967

On 03.08.2013 21:57, Don Y wrote:

> To be clear:  distances are on the order of a city block
> (but in three axis, not just two).  Events are synchronized to
> something on the order of tens to hundreds of nanoseconds.

No, they're not.  Because over that distance, they cannot be.  It's just 
flat-out impossible, because the thing you're trying to measure doesn't 
physically exist.

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

#12948

Don Y wrote:
> Hi Joerg,
> 
> On 8/3/2013 8:17 AM, Joerg wrote:
>> Don Y wrote:
>>> 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.
>>
>> Installers will hate this.
> 
> Exactly.  Imagine point A and point B are on different floors
> in different buildings, etc.  "Hey, Tony, head out to the truck
> and fetch the REALLY REALLY REALLY LONG cable set..."
> 
> (Then, *deploying* those cables -- even if only for an hour or so)
> 

No to mention the Motrin they will need for the back pain from
schlepping that cable drum up three flights of stairs.


>>> 2) two *radios* to do the same thing -- after accounting
>>> for different flight times
>>
>> Installers will love this. But why different flight times? Where is this
>> stuff going to be located? Down a borehole?
> 
> If you are measuring at a third point (without knowing its
> distance/ToF from each of the other two points -- cuz you
> have no reference you can rely upon!), then you need to
> know the difference "in time" from the "reference output"
> on each device, *through* the respective radio, through the
> "air" and into the "receiver" -- before it can be applied
> to some bit of test kit.
> 

If it absolutely has to be done from a separate console at a third point
you can have it measure the ToF automatically in both directions. Or
triangulate. AFAIU you don't need a reference, you can just pick on of
the units as reference.


>>> [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!]
>>
>> Aside from using GPS, WWV or some other reliable transmitter you could
>> have a very stable oscillator on each module. Such as a TCXO. Then you
>> have a transceiver on each. You perform a loopback echo locally, via an
>> RF switch. That gives you the latency of each radio (should be pretty
>> much the same for each module). Now only the path adds in which should
>> normally be reciprocal.
> 
> [I don't want this to be a recurring cost.  So, the radio is
> a "bag" attached solely for testing/calibration/troubleshooting]
> 

Then it's even easier because you can have calibrated radios of higher
quality. Why not ditch the third point and have the installer do it
while next to one unit?


> You still don't know what the difference in the propagation
> (through air) from each transceiver.
> 

With calibrated radios that's a piece of cake to find out. Pulse-echo.
Or let the whole link oscillate.


> I.e., if the distance to device 1 is A and the distance to device 2
> is B, then there will be a difference between the signals arriving
> that corresponds to the difference between A and B.  Even after you
> compensate for any differences in the radios themselves.
> 
> [The same is true with a single radio at device 1 "received" at
> device 2 -- how much time did the RF signal take to get to device
> 2 cuz it's arrival will occur after device 2's notion of the
> device 1 event with which it is intended to correlate.]
> 
> That's the appeal between "two equal lengths of wire" -- the
> delay through each can be made "identical".
> 

But radio can measure them. How much precision do you need?

[...]

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

#12963

Hi Joerg,

 >>>> Two ideas come to mind:
>>>> 1) two equal length cables to connect the "pulse outputs"
>>>> from their respective originating devices to the test gear.
>>>
>>> Installers will hate this.
>>
>> Exactly.  Imagine point A and point B are on different floors
>> in different buildings, etc.  "Hey, Tony, head out to the truck
>> and fetch the REALLY REALLY REALLY LONG cable set..."
>>
>> (Then, *deploying* those cables -- even if only for an hour or so)
>
> No to mention the Motrin they will need for the back pain from
> schlepping that cable drum up three flights of stairs.

Yes.  I know folks who do variations of this with *hundreds* of
pounds of cable!  (since the cable has to be ruggedized if
you want to be able to reuse it, etc.)

>>>> 2) two *radios* to do the same thing -- after accounting
>>>> for different flight times
>>>
>>> Installers will love this. But why different flight times? Where is this
>>> stuff going to be located? Down a borehole?
>>
>> If you are measuring at a third point (without knowing its
>> distance/ToF from each of the other two points -- cuz you
>> have no reference you can rely upon!), then you need to
>> know the difference "in time" from the "reference output"
>> on each device, *through* the respective radio, through the
>> "air" and into the "receiver" -- before it can be applied
>> to some bit of test kit.
>
> If it absolutely has to be done from a separate console at a third point
> you can have it measure the ToF automatically in both directions. Or
> triangulate. AFAIU you don't need a reference, you can just pick on of
> the units as reference.

In some cases, yes.  The third point ultimately gets tied into
everything, though, as it is *the* reference (GrandMaster in PTP
parlance).

But, if I can measure (test equipment, not *inside* the application)
the skew between two distant devices, I can always bring the third
device into the equation.

>>>> [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!]
>>>
>>> Aside from using GPS, WWV or some other reliable transmitter you could
>>> have a very stable oscillator on each module. Such as a TCXO. Then you
>>> have a transceiver on each. You perform a loopback echo locally, via an
>>> RF switch. That gives you the latency of each radio (should be pretty
>>> much the same for each module). Now only the path adds in which should
>>> normally be reciprocal.
>>
>> [I don't want this to be a recurring cost.  So, the radio is
>> a "bag" attached solely for testing/calibration/troubleshooting]
>
> Then it's even easier because you can have calibrated radios of higher
> quality. Why not ditch the third point and have the installer do it
> while next to one unit?

This doesn't happen during installation.  The system self-calibrates.
This is only an issue when you are troubleshooting something that
*isn't* working.

I.e., how do you verify that "time" is correct?  How do verify that
the local servo loop is tracking the current reference correctly?
E.g., is the local clock currently *locked*?  Is the loop filter
currently configured correctly to track once locked (vs. acquisition)?
What sort of jitter is the local loop experiencing?  Is the reference
seen as drifting?  etc.

E.g., if the loops are out of sync (phase and/or frequency), the
network speaker's output is out of sync with other network speakers
(or network video), etc.  Or, reproducing at incorrect pitch.

Internally, these manifest as buffer underruns or overruns (because
the local notion of time differs from the system's notion of time).
Is the problem *here*?  Or, *there*?

You (I) want to be able to nudge the system and see how individual
components react to those disturbances to give clues as to what's
working and what isn't.

>> You still don't know what the difference in the propagation
>> (through air) from each transceiver.
>
> With calibrated radios that's a piece of cake to find out. Pulse-echo.
> Or let the whole link oscillate.

With calibrate network interconnects, the problem wouldn't exist!  :>
I'm trying to reduce the complexity of the measurement (verification?)
system to *a* device -- preferably something non-esoteric (so folks
don't have to buy a special piece of gear to verify proper operation
and diagnose problems).

>> I.e., if the distance to device 1 is A and the distance to device 2
>> is B, then there will be a difference between the signals arriving
>> that corresponds to the difference between A and B.  Even after you
>> compensate for any differences in the radios themselves.
>>
>> [The same is true with a single radio at device 1 "received" at
>> device 2 -- how much time did the RF signal take to get to device
>> 2 cuz it's arrival will occur after device 2's notion of the
>> device 1 event with which it is intended to correlate.]
>>
>> That's the appeal between "two equal lengths of wire" -- the
>> delay through each can be made "identical".
>
> But radio can measure them. How much precision do you need?

As I said (elsewhere), I can currently verify performance at the
~100-200ns level "with a scope".  [I am trying to improve that
by an order of magnitude.]  But, that's with stuff sitting on
a bench, within arm's reach (physically if not electrically).

So, I need a (external) measurement system that gives me at least
that level of performance.  Without necessitating developing
yet another gizmo.

[E.g., the 'scope approach is great:  set timebase accordingly;
trigger off pulse from device 1; monitor pulse from device 2; count
graduations on the reticule!  This is something that any tech
should be able to relate to...]

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

#12970

Don Y wrote:
> Hi Joerg,
> 

[...]

>>> You still don't know what the difference in the propagation
>>> (through air) from each transceiver.
>>
>> With calibrated radios that's a piece of cake to find out. Pulse-echo.
>> Or let the whole link oscillate.
> 
> With calibrate network interconnects, the problem wouldn't exist!  :>
> I'm trying to reduce the complexity of the measurement (verification?)
> system to *a* device -- preferably something non-esoteric (so folks
> don't have to buy a special piece of gear to verify proper operation
> and diagnose problems).
> 

The interconnects would calibrate themselves during the test. It doesn't
matter whether it's a radio link or a wired link.


>>> I.e., if the distance to device 1 is A and the distance to device 2
>>> is B, then there will be a difference between the signals arriving
>>> that corresponds to the difference between A and B.  Even after you
>>> compensate for any differences in the radios themselves.
>>>
>>> [The same is true with a single radio at device 1 "received" at
>>> device 2 -- how much time did the RF signal take to get to device
>>> 2 cuz it's arrival will occur after device 2's notion of the
>>> device 1 event with which it is intended to correlate.]
>>>
>>> That's the appeal between "two equal lengths of wire" -- the
>>> delay through each can be made "identical".
>>
>> But radio can measure them. How much precision do you need?
> 
> As I said (elsewhere), I can currently verify performance at the
> ~100-200ns level "with a scope".  [I am trying to improve that
> by an order of magnitude.]  But, that's with stuff sitting on
> a bench, within arm's reach (physically if not electrically).
> 
> So, I need a (external) measurement system that gives me at least
> that level of performance.  Without necessitating developing
> yet another gizmo.
> 

I am afraid you will have to develop a gizmo. Because there ain't enough
of a market for what you are trying to do and I doubt there is
off-the-shelf stuff. Except for very expensive test equipment that can
probably be programmed to do this job (the stuff that costs as much as a
decent car).


> [E.g., the 'scope approach is great:  set timebase accordingly;
> trigger off pulse from device 1; monitor pulse from device 2; count
> graduations on the reticule!  This is something that any tech
> should be able to relate to...]
> 

But you need a link to each unit. And this is also easy if a scope
approach is acceptable:

a. Provide a full-duplex radio link to each unit, meaning two different
frequencies each. Can purchased. Send tone burst out, measure phase
difference when it comes back.

b. Do the same with unit B.

c. Listen for timer tick and measure delta.

d. Subtract difference found in steps a and b.

You might want to take a look at Daqarta. I found it to be very precise
in measurement precision when it comes to phase delays:

http://daqarta.com/dw_0o0p.htm

Not sure how far down in precision this app would go but it'll even give
you a histogram of timing errors:

http://daqarta.com/dw_psth.htm

The author is very responsive and knowledgeable when it comes to
specialty applications you want to pursue. Speaking from experience here.

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

#12983

Hi Joerg,

Tooth settled down, yet?

>>>> You still don't know what the difference in the propagation
>>>> (through air) from each transceiver.
>>>
>>> With calibrated radios that's a piece of cake to find out. Pulse-echo.
>>> Or let the whole link oscillate.
>>
>> With calibrate network interconnects, the problem wouldn't exist!  :>
>> I'm trying to reduce the complexity of the measurement (verification?)
>> system to *a* device -- preferably something non-esoteric (so folks
>> don't have to buy a special piece of gear to verify proper operation
>> and diagnose problems).
>
> The interconnects would calibrate themselves during the test. It doesn't
> matter whether it's a radio link or a wired link.

You'd have to locate a piece of kit at each end of each link.
I.e., three devices (assuming a common reference point) to
test two links.  (Or, hope nothing changes in the minutes
or fractional hours that it takes you to redeploy for the
"other" link)

[E.g., the timing protocol updates itself at ~1Hz just to deal
with things like drift in the local oscillator]

>>>> I.e., if the distance to device 1 is A and the distance to device 2
>>>> is B, then there will be a difference between the signals arriving
>>>> that corresponds to the difference between A and B.  Even after you
>>>> compensate for any differences in the radios themselves.
>>>>
>>>> [The same is true with a single radio at device 1 "received" at
>>>> device 2 -- how much time did the RF signal take to get to device
>>>> 2 cuz it's arrival will occur after device 2's notion of the
>>>> device 1 event with which it is intended to correlate.]
>>>>
>>>> That's the appeal between "two equal lengths of wire" -- the
>>>> delay through each can be made "identical".
>>>
>>> But radio can measure them. How much precision do you need?
>>
>> As I said (elsewhere), I can currently verify performance at the
>> ~100-200ns level "with a scope".  [I am trying to improve that
>> by an order of magnitude.]  But, that's with stuff sitting on
>> a bench, within arm's reach (physically if not electrically).
>>
>> So, I need a (external) measurement system that gives me at least
>> that level of performance.  Without necessitating developing
>> yet another gizmo.
>
> I am afraid you will have to develop a gizmo. Because there ain't enough
> of a market for what you are trying to do and I doubt there is
> off-the-shelf stuff.

That's what I've feared.  Once you start having to support "test kit"
your TCO goes up, fast!  ("authorized service personnel", etc.)

Part of the appeal of legacy devices (60's) was that a "tech"
could troubleshoot problems with common bits of test equipment.
E.g., the original ECU's could be troubleshot (?) with a VOM...
(no longer true though that market is large enough that OBD
tools are relatively inexpensive)

> Except for very expensive test equipment that can
> probably be programmed to do this job (the stuff that costs as much as a
> decent car).
>
>> [E.g., the 'scope approach is great:  set timebase accordingly;
>> trigger off pulse from device 1; monitor pulse from device 2; count
>> graduations on the reticule!  This is something that any tech
>> should be able to relate to...]
>
> But you need a link to each unit.

Yes.  And, relies on a *wired* link (or equivalent hooks in a wireless
implementation)

> And this is also easy if a scope
> approach is acceptable:
>
> a. Provide a full-duplex radio link to each unit, meaning two different
> frequencies each. Can purchased. Send tone burst out, measure phase
> difference when it comes back.
>
> b. Do the same with unit B.

This has to happen "nearly coincident" with "a)." to be able to
ignore short term variations in the signals.  E.g., if you
were troubleshooting an analog PLL, you wouldn't measure the
phase of the input signal against some "reference"; then, some
seconds later, measure the phase of the synthesized signal against
that same reference.  Rather, you would measure the synthesized
signal against the input signal "directly" so the measurements
appear to be concurrent.

> c. Listen for timer tick and measure delta.

Also coincident with a & b.  I.e., you want to deploy to pairs
of radios and this "tick measurement" device to take/watch
an instantaneous measurement free of jitter, and short term
uncertainty, etc.

I'm not claiming it can't be done.  Rather, I'm trying to show
the height at which it sets the bar for a "generic technician".

It may turn out that this becomes a specialized diagnostic
procedure.  I would just like to avoid that, where possible,
as it makes such a system "less ubiquitous" in practical
terms.

(Alternatively, *guarantee* that the system always knows when
things are not in sync and have *it* report this problem)

> d. Subtract difference found in steps a and b.
> You might want to take a look at Daqarta. I found it to be very precise
> in measurement precision when it comes to phase delays:
>
> http://daqarta.com/dw_0o0p.htm
>
> Not sure how far down in precision this app would go but it'll even give
> you a histogram of timing errors:
>
> http://daqarta.com/dw_psth.htm
>
> The author is very responsive and knowledgeable when it comes to
> specialty applications you want to pursue. Speaking from experience here.

At 256KHz sample rates, I think it is probably too slow to get the
sort of resolution I would need (I'll examine the site more carefully
to see if there is some "extended precision" scheme that could be
employed)

--don

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

#12984

Don Y wrote:
> Hi Joerg,
> 
> Tooth settled down, yet?
> 
>>>>> You still don't know what the difference in the propagation
>>>>> (through air) from each transceiver.
>>>>
>>>> With calibrated radios that's a piece of cake to find out. Pulse-echo.
>>>> Or let the whole link oscillate.
>>>
>>> With calibrate network interconnects, the problem wouldn't exist!  :>
>>> I'm trying to reduce the complexity of the measurement (verification?)
>>> system to *a* device -- preferably something non-esoteric (so folks
>>> don't have to buy a special piece of gear to verify proper operation
>>> and diagnose problems).
>>
>> The interconnects would calibrate themselves during the test. It doesn't
>> matter whether it's a radio link or a wired link.
> 
> You'd have to locate a piece of kit at each end of each link.
> I.e., three devices (assuming a common reference point) to
> test two links.  (Or, hope nothing changes in the minutes
> or fractional hours that it takes you to redeploy for the
> "other" link)
> 
> [E.g., the timing protocol updates itself at ~1Hz just to deal
> with things like drift in the local oscillator]
> 

Yes, either that or you have to make it part of the standard on-board
equipment (which I understand you don't want). There is no other way.
The locations have to broadcast their timer ticks and that requires
hardware.


>>>>> I.e., if the distance to device 1 is A and the distance to device 2
>>>>> is B, then there will be a difference between the signals arriving
>>>>> that corresponds to the difference between A and B.  Even after you
>>>>> compensate for any differences in the radios themselves.
>>>>>
>>>>> [The same is true with a single radio at device 1 "received" at
>>>>> device 2 -- how much time did the RF signal take to get to device
>>>>> 2 cuz it's arrival will occur after device 2's notion of the
>>>>> device 1 event with which it is intended to correlate.]
>>>>>
>>>>> That's the appeal between "two equal lengths of wire" -- the
>>>>> delay through each can be made "identical".
>>>>
>>>> But radio can measure them. How much precision do you need?
>>>
>>> As I said (elsewhere), I can currently verify performance at the
>>> ~100-200ns level "with a scope".  [I am trying to improve that
>>> by an order of magnitude.]  But, that's with stuff sitting on
>>> a bench, within arm's reach (physically if not electrically).
>>>
>>> So, I need a (external) measurement system that gives me at least
>>> that level of performance.  Without necessitating developing
>>> yet another gizmo.
>>
>> I am afraid you will have to develop a gizmo. Because there ain't enough
>> of a market for what you are trying to do and I doubt there is
>> off-the-shelf stuff.
> 
> That's what I've feared.  Once you start having to support "test kit"
> your TCO goes up, fast!  ("authorized service personnel", etc.)
> 
> Part of the appeal of legacy devices (60's) was that a "tech"
> could troubleshoot problems with common bits of test equipment.
> E.g., the original ECU's could be troubleshot (?) with a VOM...
> (no longer true though that market is large enough that OBD
> tools are relatively inexpensive)
> 

I find it's even better today. Back in the 60's, just the thought of
schlepping a Tektronix "portable" (as in "has a handle but take a Motrin
before lifting") could make you cringe. Then you had to find a wall
outlet, plug in, push the power button ... TUNGGGG ... thwock ... "Ahm,
Sir, sorry to bug you but where is the breaker panel?"

Nowadays they already have laptops for reporting purposes and all you
need to do is provide a little USB box and software. TI has a whole
series of ready-to-go radio modules, maybe one of those can be pressed
into service here. The good old days are ... today. Doing this
wirelessly was totally out of the question in the 60's. The wrath of FCC
alone was reason enough not to.


>> Except for very expensive test equipment that can
>> probably be programmed to do this job (the stuff that costs as much as a
>> decent car).
>>
>>> [E.g., the 'scope approach is great:  set timebase accordingly;
>>> trigger off pulse from device 1; monitor pulse from device 2; count
>>> graduations on the reticule!  This is something that any tech
>>> should be able to relate to...]
>>
>> But you need a link to each unit.
> 
> Yes.  And, relies on a *wired* link (or equivalent hooks in a wireless
> implementation)
> 

Wired works, as long as the infrastructure in the wiring won't get in
the way too much (Hubs? Switches? Routers?).


>> And this is also easy if a scope
>> approach is acceptable:
>>
>> a. Provide a full-duplex radio link to each unit, meaning two different
>> frequencies each. Can purchased. Send tone burst out, measure phase
>> difference when it comes back.
>>
>> b. Do the same with unit B.
> 
> This has to happen "nearly coincident" with "a)." to be able to
> ignore short term variations in the signals.  E.g., if you
> were troubleshooting an analog PLL, you wouldn't measure the
> phase of the input signal against some "reference"; then, some
> seconds later, measure the phase of the synthesized signal against
> that same reference.  Rather, you would measure the synthesized
> signal against the input signal "directly" so the measurements
> appear to be concurrent.
> 

Not really. How should an RF path change much in just a few minutes?
Unless someone moves a massive metal file cabinet near the antennas, but
you'd see that.


>> c. Listen for timer tick and measure delta.
> 
> Also coincident with a & b.  I.e., you want to deploy to pairs
> of radios and this "tick measurement" device to take/watch
> an instantaneous measurement free of jitter, and short term
> uncertainty, etc.
> 

Since it seems you are not after picoseconds I don't see where the
problem is. You can do that simultaneously, it's not problem, but it
isn't necessary.


> I'm not claiming it can't be done.  Rather, I'm trying to show
> the height at which it sets the bar for a "generic technician".
> 
> It may turn out that this becomes a specialized diagnostic
> procedure.  I would just like to avoid that, where possible,
> as it makes such a system "less ubiquitous" in practical
> terms.
> 

Take a look at SCADA softare. Something like this could be pieced
together and then all the tech would need to be told is "Hook all this
stuff to the units, plug this gray box into a USB port your laptop,
click that icon over here, wait until a big green DONE logo appears,
then retrieve all the stuff".


> (Alternatively, *guarantee* that the system always knows when
> things are not in sync and have *it* report this problem)
> 

That would be by far the best solution and if I were to make the
decision that's how it would be done.


>> d. Subtract difference found in steps a and b.
>> You might want to take a look at Daqarta. I found it to be very precise
>> in measurement precision when it comes to phase delays:
>>
>> http://daqarta.com/dw_0o0p.htm
>>
>> Not sure how far down in precision this app would go but it'll even give
>> you a histogram of timing errors:
>>
>> http://daqarta.com/dw_psth.htm
>>
>> The author is very responsive and knowledgeable when it comes to
>> specialty applications you want to pursue. Speaking from experience here.
> 
> At 256KHz sample rates, I think it is probably too slow to get the
> sort of resolution I would need (I'll examine the site more carefully
> to see if there is some "extended precision" scheme that could be
> employed)
> 

Mostly this only samples at 44.1kHz, 48kHz or 96kHz, depending on the
sound hardware you use. Unless I misunderstand your problem at hand,
that isn't an issue. AFAIU all you are after is a time difference
between two (or maybe some day more) events, not the exact occurrence of
an event in absolute time. So if each event triggers a sine wave at a
precise time you can measure the phase difference between two such sine
waves transmitted by two different units. Combining it with a complex
FFT of sufficient granularity you can calculate the phase difference
down to milli-degrees. 1/10th of a degree at 10kHz is less than 30nsec
and to measure that is a piece of cake.

You can get much more accurate than that. In fact, one of the big
projects I am involved in right now (totally different from yours) fully
banks on that and we have our first demo behind us. Since the system
aced it so well I tried to push it, measuring the phase shift in a
filter when a capacitor goes from 100000pF to 100001pF. It worked.

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

#13016

Hi Joerg,

On 8/5/2013 3:38 PM, Joerg wrote:
> Don Y wrote:

>>>>> With calibrated radios that's a piece of cake to find out. Pulse-echo.
>>>>> Or let the whole link oscillate.
>>>>
>>>> With calibrate network interconnects, the problem wouldn't exist!  :>
>>>> I'm trying to reduce the complexity of the measurement (verification?)
>>>> system to *a* device -- preferably something non-esoteric (so folks
>>>> don't have to buy a special piece of gear to verify proper operation
>>>> and diagnose problems).
>>>
>>> The interconnects would calibrate themselves during the test. It doesn't
>>> matter whether it's a radio link or a wired link.
>>
>> You'd have to locate a piece of kit at each end of each link.
>> I.e., three devices (assuming a common reference point) to
>> test two links.  (Or, hope nothing changes in the minutes
>> or fractional hours that it takes you to redeploy for the
>> "other" link)
>>
>> [E.g., the timing protocol updates itself at ~1Hz just to deal
>> with things like drift in the local oscillator]
>
> Yes, either that or you have to make it part of the standard on-board
> equipment (which I understand you don't want). There is no other way.
> The locations have to broadcast their timer ticks and that requires
> hardware.

I think that last sentence is the key.  The devices already have that
capability.  And, already do it -- in a cryptic way (i.e., if you
examined the control packets for the protocol, you could infer
this information just like the "resident hardware/software" does
in each node.

So, maybe that's the way to approach it!

I.e., the "pulse" output that I mentioned is a software manifestation.
It's not a test point in a dedicated hardware circuit.  I already
*implicitly* trust that it is generated at the right temporal
relationship to the "internal timepiece" for the device.

[This is also true of multi-kilobuck pieces of COTS 1588-enabled
network kit:  the "hardware" that generates these references is
implemented as a "finite state machine" (i.e., a piece of code
executing on a CPU!)]

So, just treat this subsystem the same way I would treat a medical
device, pharmaceutical device, gaming device, etc. -- *validate*
it, formally.  Then, rely on that "process" to attest to the
device's ability to deliver *whatever* backchannel signals I deem
important for testing!

At any time, a user can verify continued compliance (to the same
specifications used in the validation).  Just like testing for
characteristic impedance of a cable, continuity, line/load
regulation for a power supply, etc.

Then, instead of delivering a "pulse" to an "unused" output pin
on the board, I can just send that "event" down the same network
cable that I am using for messages!  (i.e., its a specialized
message, of sorts)

>>> Except for very expensive test equipment that can
>>> probably be programmed to do this job (the stuff that costs as much as a
>>> decent car).
>>>
>>>> [E.g., the 'scope approach is great:  set timebase accordingly;
>>>> trigger off pulse from device 1; monitor pulse from device 2; count
>>>> graduations on the reticule!  This is something that any tech
>>>> should be able to relate to...]
>>>
>>> But you need a link to each unit.
>>
>> Yes.  And, relies on a *wired* link (or equivalent hooks in a wireless
>> implementation)
>
> Wired works, as long as the infrastructure in the wiring won't get in
> the way too much (Hubs? Switches? Routers?).

These are almost always in "accessible" locations (the actual
*nodes* that are being tested may be far less accessible:  e.g.,
an RFID badge reader *protected* in a wall.

And, for high performance deployments they are "special" devices
that are part of the system itself.   E.g., the equivalent of
"transparent switches" and "boundary switches" -- to propagate the
timing information *across* the nondeterministic behavior of the
switch (hubs are friendlier in this sort of environment!).

>>> And this is also easy if a scope
>>> approach is acceptable:
>>>
>>> a. Provide a full-duplex radio link to each unit, meaning two different
>>> frequencies each. Can purchased. Send tone burst out, measure phase
>>> difference when it comes back.
>>>
>>> b. Do the same with unit B.
>>
>> This has to happen "nearly coincident" with "a)." to be able to
>> ignore short term variations in the signals.  E.g., if you
>> were troubleshooting an analog PLL, you wouldn't measure the
>> phase of the input signal against some "reference"; then, some
>> seconds later, measure the phase of the synthesized signal against
>> that same reference.  Rather, you would measure the synthesized
>> signal against the input signal "directly" so the measurements
>> appear to be concurrent.
>
> Not really. How should an RF path change much in just a few minutes?
> Unless someone moves a massive metal file cabinet near the antennas, but
> you'd see that.

Can you be sure that you can get from point A to point B in
"just a few minutes"?  (This was why I was saying you have to
deploy *all* the test kit simultaneously -- what if A is in
one building and B in another)

What if an elevator happens to move up/down/stops its shaft
(will you be aware of it?)

>>> c. Listen for timer tick and measure delta.
>>
>> Also coincident with a & b.  I.e., you want to deploy to pairs
>> of radios and this "tick measurement" device to take/watch
>> an instantaneous measurement free of jitter, and short term
>> uncertainty, etc.
>
> Since it seems you are not after picoseconds I don't see where the
> problem is. You can do that simultaneously, it's not problem, but it
> isn't necessary.
>
>> I'm not claiming it can't be done.  Rather, I'm trying to show
>> the height at which it sets the bar for a "generic technician".
>>
>> It may turn out that this becomes a specialized diagnostic
>> procedure.  I would just like to avoid that, where possible,
>> as it makes such a system "less ubiquitous" in practical
>> terms.
>
> Take a look at SCADA softare. Something like this could be pieced
> together and then all the tech would need to be told is "Hook all this
> stuff to the units, plug this gray box into a USB port your laptop,
> click that icon over here, wait until a big green DONE logo appears,
> then retrieve all the stuff".

I'd *prefer* an approach where the tech could just use the
kit he's already got on hand instead of having to specially
accommodate the needs of *this* system (does every vendor impose
its own set of test equipment requirements on the customer?
Does a vendor who *doesn't* add value to the customer?)

>> (Alternatively, *guarantee* that the system always knows when
>> things are not in sync and have *it* report this problem)
>
> That would be by far the best solution and if I were to make the
> decision that's how it would be done.

See above (validation).  I think that's the way to go.

I.e., how do you *know* that your DSO is actually showing you
what's happening on the probes into the UUT?  :>

[I've got a logic analyzer here that I can configure to
"trigger (unconditionally) after 100ms" -- and, come back
to it 2 weeks later and see it sitting there still saying
"ARMED" (yet NOT triggered!)]

Define, *specifically*, how this aspect of the device *must*
work AS AN INVARIANT.  Then, let people verify this performance
on the unit itself (if they suspect that it isn't performing
correctly)

>>> d. Subtract difference found in steps a and b.
>>> You might want to take a look at Daqarta. I found it to be very precise
>>> in measurement precision when it comes to phase delays:
>>>
>>> http://daqarta.com/dw_0o0p.htm
>>>
>>> Not sure how far down in precision this app would go but it'll even give
>>> you a histogram of timing errors:
>>>
>>> http://daqarta.com/dw_psth.htm
>>>
>>> The author is very responsive and knowledgeable when it comes to
>>> specialty applications you want to pursue. Speaking from experience here.
>>
>> At 256KHz sample rates, I think it is probably too slow to get the
>> sort of resolution I would need (I'll examine the site more carefully
>> to see if there is some "extended precision" scheme that could be
>> employed)
>
> Mostly this only samples at 44.1kHz, 48kHz or 96kHz, depending on the
> sound hardware you use. Unless I misunderstand your problem at hand,
> that isn't an issue. AFAIU all you are after is a time difference
> between two (or maybe some day more) events, not the exact occurrence of
> an event in absolute time. So if each event triggers a sine wave at a
> precise time you can measure the phase difference between two such sine
> waves transmitted by two different units. Combining it with a complex
> FFT of sufficient granularity you can calculate the phase difference
> down to milli-degrees. 1/10th of a degree at 10kHz is less than 30nsec
> and to measure that is a piece of cake.

The "pulses" are currently just that:  pulses (I am only interested in
the edge).  Currently, these are really *infrequent* (hertz) -- though
I could change that.

> You can get much more accurate than that. In fact, one of the big
> projects I am involved in right now (totally different from yours) fully
> banks on that and we have our first demo behind us. Since the system
> aced it so well I tried to push it, measuring the phase shift in a
> filter when a capacitor goes from 100000pF to 100001pF. It worked.

Yeah, I worked with a sensor array that was capable of detecting a few
microliters (i.e., a very small drop) of liquid (blood) in any of 60
test tubes for a few dollars (in very low quantities).  It had to
handle 60 such sensors simultaneously as you never knew where the blood
might "appear".

Interesting when you think of unconventional approaches to problems
that would otherwise appear "difficult" and suggest "expensive"
solutions!

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

#13028

Don Y wrote:
> Hi Joerg,
> 
> On 8/5/2013 3:38 PM, Joerg wrote:
>> Don Y wrote:
> 
>>>>>> With calibrated radios that's a piece of cake to find out.
>>>>>> Pulse-echo.
>>>>>> Or let the whole link oscillate.
>>>>>
>>>>> With calibrate network interconnects, the problem wouldn't exist!  :>
>>>>> I'm trying to reduce the complexity of the measurement (verification?)
>>>>> system to *a* device -- preferably something non-esoteric (so folks
>>>>> don't have to buy a special piece of gear to verify proper operation
>>>>> and diagnose problems).
>>>>
>>>> The interconnects would calibrate themselves during the test. It
>>>> doesn't
>>>> matter whether it's a radio link or a wired link.
>>>
>>> You'd have to locate a piece of kit at each end of each link.
>>> I.e., three devices (assuming a common reference point) to
>>> test two links.  (Or, hope nothing changes in the minutes
>>> or fractional hours that it takes you to redeploy for the
>>> "other" link)
>>>
>>> [E.g., the timing protocol updates itself at ~1Hz just to deal
>>> with things like drift in the local oscillator]
>>
>> Yes, either that or you have to make it part of the standard on-board
>> equipment (which I understand you don't want). There is no other way.
>> The locations have to broadcast their timer ticks and that requires
>> hardware.
> 
> I think that last sentence is the key.  The devices already have that
> capability.  And, already do it -- in a cryptic way (i.e., if you
> examined the control packets for the protocol, you could infer
> this information just like the "resident hardware/software" does
> in each node.
> 
> So, maybe that's the way to approach it!
> 
> I.e., the "pulse" output that I mentioned is a software manifestation.
> It's not a test point in a dedicated hardware circuit.  I already
> *implicitly* trust that it is generated at the right temporal
> relationship to the "internal timepiece" for the device.
> 

Then you may be home already, almost for free.


> [This is also true of multi-kilobuck pieces of COTS 1588-enabled
> network kit:  the "hardware" that generates these references is
> implemented as a "finite state machine" (i.e., a piece of code
> executing on a CPU!)]
> 
> So, just treat this subsystem the same way I would treat a medical
> device, pharmaceutical device, gaming device, etc. -- *validate*
> it, formally.  Then, rely on that "process" to attest to the
> device's ability to deliver *whatever* backchannel signals I deem
> important for testing!
> 
> At any time, a user can verify continued compliance (to the same
> specifications used in the validation).  Just like testing for
> characteristic impedance of a cable, continuity, line/load
> regulation for a power supply, etc.
> 
> Then, instead of delivering a "pulse" to an "unused" output pin
> on the board, I can just send that "event" down the same network
> cable that I am using for messages!  (i.e., its a specialized
> message, of sorts)
> 

A way to do something like this is signature analysis. You watch each
unit while it sends out a certain pattern that's always the same. The
pattern has to come in response to some other pattern that gets sent to
it, and the response time (turn-around time) must be very determined and
validated. Now you can correlate the heck out of it and get almost any
precision you want.


>>>> Except for very expensive test equipment that can
>>>> probably be programmed to do this job (the stuff that costs as much
>>>> as a
>>>> decent car).
>>>>
>>>>> [E.g., the 'scope approach is great:  set timebase accordingly;
>>>>> trigger off pulse from device 1; monitor pulse from device 2; count
>>>>> graduations on the reticule!  This is something that any tech
>>>>> should be able to relate to...]
>>>>
>>>> But you need a link to each unit.
>>>
>>> Yes.  And, relies on a *wired* link (or equivalent hooks in a wireless
>>> implementation)
>>
>> Wired works, as long as the infrastructure in the wiring won't get in
>> the way too much (Hubs? Switches? Routers?).
> 
> These are almost always in "accessible" locations (the actual
> *nodes* that are being tested may be far less accessible:  e.g.,
> an RFID badge reader *protected* in a wall.
> 

Yeah, but you don't want to have to temporarily re-shuffle a customers
wiring installation. It'll be labor-intense and also interrupt their
normal business.


> And, for high performance deployments they are "special" devices
> that are part of the system itself.   E.g., the equivalent of
> "transparent switches" and "boundary switches" -- to propagate the
> timing information *across* the nondeterministic behavior of the
> switch (hubs are friendlier in this sort of environment!).
> 
>>>> And this is also easy if a scope
>>>> approach is acceptable:
>>>>
>>>> a. Provide a full-duplex radio link to each unit, meaning two different
>>>> frequencies each. Can purchased. Send tone burst out, measure phase
>>>> difference when it comes back.
>>>>
>>>> b. Do the same with unit B.
>>>
>>> This has to happen "nearly coincident" with "a)." to be able to
>>> ignore short term variations in the signals.  E.g., if you
>>> were troubleshooting an analog PLL, you wouldn't measure the
>>> phase of the input signal against some "reference"; then, some
>>> seconds later, measure the phase of the synthesized signal against
>>> that same reference.  Rather, you would measure the synthesized
>>> signal against the input signal "directly" so the measurements
>>> appear to be concurrent.
>>
>> Not really. How should an RF path change much in just a few minutes?
>> Unless someone moves a massive metal file cabinet near the antennas, but
>> you'd see that.
> 
> Can you be sure that you can get from point A to point B in
> "just a few minutes"?  (This was why I was saying you have to
> deploy *all* the test kit simultaneously -- what if A is in
> one building and B in another)
> 
> What if an elevator happens to move up/down/stops its shaft
> (will you be aware of it?)
> 

Tricky but not impossible. That's why the test should run for a longer
time, to see if anything changes. You also have another tool, RSSI. If
the RSSI is markedly different from when the system was installed then
something in the path has changed.

[...]


>>> I'm not claiming it can't be done.  Rather, I'm trying to show
>>> the height at which it sets the bar for a "generic technician".
>>>
>>> It may turn out that this becomes a specialized diagnostic
>>> procedure.  I would just like to avoid that, where possible,
>>> as it makes such a system "less ubiquitous" in practical
>>> terms.
>>
>> Take a look at SCADA softare. Something like this could be pieced
>> together and then all the tech would need to be told is "Hook all this
>> stuff to the units, plug this gray box into a USB port your laptop,
>> click that icon over here, wait until a big green DONE logo appears,
>> then retrieve all the stuff".
> 
> I'd *prefer* an approach where the tech could just use the
> kit he's already got on hand instead of having to specially
> accommodate the needs of *this* system (does every vendor impose
> its own set of test equipment requirements on the customer?
> Does a vendor who *doesn't* add value to the customer?)
> 

If this doesn't add value to the customer, why do it in the first place?
If calibration is required then that is of value to the customer.


>>> (Alternatively, *guarantee* that the system always knows when
>>> things are not in sync and have *it* report this problem)
>>
>> That would be by far the best solution and if I were to make the
>> decision that's how it would be done.
> 
> See above (validation).  I think that's the way to go.
> 

Yup. Didn't know that it was leagally or technically possible in your case.

[...]


>>>> d. Subtract difference found in steps a and b.
>>>> You might want to take a look at Daqarta. I found it to be very precise
>>>> in measurement precision when it comes to phase delays:
>>>>
>>>> http://daqarta.com/dw_0o0p.htm
>>>>
>>>> Not sure how far down in precision this app would go but it'll even
>>>> give
>>>> you a histogram of timing errors:
>>>>
>>>> http://daqarta.com/dw_psth.htm
>>>>
>>>> The author is very responsive and knowledgeable when it comes to
>>>> specialty applications you want to pursue. Speaking from experience
>>>> here.
>>>
>>> At 256KHz sample rates, I think it is probably too slow to get the
>>> sort of resolution I would need (I'll examine the site more carefully
>>> to see if there is some "extended precision" scheme that could be
>>> employed)
>>
>> Mostly this only samples at 44.1kHz, 48kHz or 96kHz, depending on the
>> sound hardware you use. Unless I misunderstand your problem at hand,
>> that isn't an issue. AFAIU all you are after is a time difference
>> between two (or maybe some day more) events, not the exact occurrence of
>> an event in absolute time. So if each event triggers a sine wave at a
>> precise time you can measure the phase difference between two such sine
>> waves transmitted by two different units. Combining it with a complex
>> FFT of sufficient granularity you can calculate the phase difference
>> down to milli-degrees. 1/10th of a degree at 10kHz is less than 30nsec
>> and to measure that is a piece of cake.
> 
> The "pulses" are currently just that:  pulses (I am only interested in
> the edge).  Currently, these are really *infrequent* (hertz) -- though
> I could change that.
> 

The method above (sine wave trains) is usually better. Lower bandwidth,
more SNR, better accuracy, much cheaper hardware.


>> You can get much more accurate than that. In fact, one of the big
>> projects I am involved in right now (totally different from yours) fully
>> banks on that and we have our first demo behind us. Since the system
>> aced it so well I tried to push it, measuring the phase shift in a
>> filter when a capacitor goes from 100000pF to 100001pF. It worked.
> 
> Yeah, I worked with a sensor array that was capable of detecting a few
> microliters (i.e., a very small drop) of liquid (blood) in any of 60
> test tubes for a few dollars (in very low quantities).  It had to
> handle 60 such sensors simultaneously as you never knew where the blood
> might "appear".
> 
> Interesting when you think of unconventional approaches to problems
> that would otherwise appear "difficult" and suggest "expensive"
> solutions!


That's where engineering begin to be fun :-)

The best comment I ever got after finishing a prototype that then did
exactly what the client wanted, after one of their engineers looked into
the rather sparse collectioon of parts: "You mean, THAT's IT?"

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

#13032

Joerg wrote:
> Don Y wrote:
>> Hi Joerg,
>>
>> On 8/5/2013 3:38 PM, Joerg wrote:
>>> Don Y wrote:

[...]


>>>>> And this is also easy if a scope
>>>>> approach is acceptable:
>>>>>
>>>>> a. Provide a full-duplex radio link to each unit, meaning two different
>>>>> frequencies each. Can purchased. Send tone burst out, measure phase
>>>>> difference when it comes back.
>>>>>
>>>>> b. Do the same with unit B.
>>>> This has to happen "nearly coincident" with "a)." to be able to
>>>> ignore short term variations in the signals.  E.g., if you
>>>> were troubleshooting an analog PLL, you wouldn't measure the
>>>> phase of the input signal against some "reference"; then, some
>>>> seconds later, measure the phase of the synthesized signal against
>>>> that same reference.  Rather, you would measure the synthesized
>>>> signal against the input signal "directly" so the measurements
>>>> appear to be concurrent.
>>> Not really. How should an RF path change much in just a few minutes?
>>> Unless someone moves a massive metal file cabinet near the antennas, but
>>> you'd see that.
>> Can you be sure that you can get from point A to point B in
>> "just a few minutes"?  (This was why I was saying you have to
>> deploy *all* the test kit simultaneously -- what if A is in
>> one building and B in another)
>>
>> What if an elevator happens to move up/down/stops its shaft
>> (will you be aware of it?)
>>
> 
> Tricky but not impossible. That's why the test should run for a longer
> time, to see if anything changes. You also have another tool, RSSI. If
> the RSSI is markedly different from when the system was installed then
> something in the path has changed.
> 

It is actually easier than I thought this morning:

You can perform round-trip calibration and timing in rapid succession,
for both units. Unless the elevator has a rocket motor and goes at
Mach-2 it should be accurate enough.

Ok, if an F-16 roars through the path at full throttle you'd have a
problem :-)

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

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

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

csiph-web