Re: Comparing phase of physically distant signals

From	Don Y <this@isnotme.com>
Newsgroups	comp.arch.embedded, sci.electronics.design, comp.realtime
Subject	Re: Comparing phase of physically distant signals
Date	2013-08-07 01:25 -0700
Organization	Aioe.org NNTP Server
Message-ID	<ktt09u$db3$1@speranza.aioe.org> (permalink)
References	(3 earlier) <b654s9Ff331U1@mid.individual.net> <ktkb69$eja$1@speranza.aioe.org> <b67fdjFu2ksU1@mid.individual.net> <ktp6t8$sec$1@speranza.aioe.org> <b6anrmFl8rvU1@mid.individual.net>

Cross-posted to 3 groups.

Show all headers | View raw

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!

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