Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Newsgroups | comp.arch.embedded, sci.electronics.design, comp.realtime |
| Subject | Re: Comparing phase of physically distant signals |
| Date | 2013-08-07 08:06 -0700 |
| Organization | Consultant |
| Message-ID | <b6f644FjnhjU1@mid.individual.net> (permalink) |
| References | (4 earlier) <ktkb69$eja$1@speranza.aioe.org> <b67fdjFu2ksU1@mid.individual.net> <ktp6t8$sec$1@speranza.aioe.org> <b6anrmFl8rvU1@mid.individual.net> <ktt09u$db3$1@speranza.aioe.org> |
Cross-posted to 3 groups.
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/
Back to comp.realtime | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 00:45 -0700
Re: Comparing phase of physically distant signals Jan Panteltje <pNaonStpealmtje@yahoo.com> - 2013-08-03 07:51 +0000
Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 09:58 +0100
Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-03 13:21 +0300
Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 12:16 +0100
Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 11:56 -0700
Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 20:17 +0100
Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 13:41 -0700
Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 22:46 +0100
Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 14:57 -0700
Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 23:09 +0100
Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-03 13:58 +0300
Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 12:30 +0100
Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-03 16:08 +0300
Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 14:22 +0100
Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-03 16:38 +0300
Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 10:46 -0700
Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 10:40 -0700
Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 20:04 +0100
Re: Comparing phase of physically distant signals Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-08-04 15:55 +0200
Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-04 19:42 +0300
Re: Comparing phase of physically distant signals Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-08-04 21:08 +0200
Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-05 15:28 +0300
Re: Comparing phase of physically distant signals Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-08-05 22:17 +0200
Re: Comparing phase of physically distant signals Richard Damon <Richard@Damon-Family.org> - 2013-08-05 23:20 -0400
Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 14:26 +0100
Re: Comparing phase of physically distant signals George Neuner <gneuner2@comcast.net> - 2013-08-03 14:47 -0400
Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 08:17 -0700
Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 12:08 -0700
Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 20:37 +0100
Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 12:57 -0700
Re: Comparing phase of physically distant signals Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-08-04 15:58 +0200
Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 12:44 -0700
Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 18:36 -0700
Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-04 09:56 -0700
Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-05 14:53 -0700
Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-05 15:38 -0700
Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-07 01:25 -0700
Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-07 08:06 -0700
Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-07 09:21 -0700
Re: Comparing phase of physically distant signals josephkk <joseph_barrett@sbcglobal.net> - 2013-08-03 15:40 +0000
Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 10:05 -0700
Re: Comparing phase of physically distant signals John S <Sophi.2@invalid.org> - 2013-08-03 12:13 -0500
Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 10:26 -0700
Re: Comparing phase of physically distant signals John S <Sophi.2@invalid.org> - 2013-08-03 12:51 -0500
Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 11:54 -0700
Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 20:27 +0100
Re: Comparing phase of physically distant signals George Neuner <gneuner2@comcast.net> - 2013-08-05 03:26 -0400
Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-05 10:34 +0100
Re: Comparing phase of physically distant signals Richard Damon <Richard@Damon-Family.org> - 2013-08-05 23:29 -0400
Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 08:53 +0100
Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 12:49 -0700
Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 12:34 -0700
Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 12:18 -0700
Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 12:52 -0700
Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 13:21 -0700
Re: Comparing phase of physically distant signals Jeff Liebermann <jeffl@cruzio.com> - 2013-08-03 13:31 -0700
Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 14:46 -0700
Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 15:03 -0700
Re: Comparing phase of physically distant signals Jeff Liebermann <jeffl@cruzio.com> - 2013-08-03 17:25 -0700
Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 14:50 -0700
Re: Comparing phase of physically distant signals "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-08-04 11:06 +0100
Re: Comparing phase of physically distant signals 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 Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-08-16 21:07 +0100
csiph-web