Comparing phase of physically distant signals

[...]

I've heard more of those and lived some easier ones. At university one of my unspoken tasks was to salvage capsizing final projects. When people took on a huge hardware project and got stuck. For some reason a large number were hobby-sailors, even though my alma mater is hundreds of miles from any coast.

Once when on a semi-submersible oil rig we had a major strom go through. Middle of the North Sea, all land was far away. We had to go under deck, fast. Then ... *KAPOCK* ... "What was that?" ... "Probably one of the anchors but we've got another seven" ... "So what if another breaks?" ... "If it's at the same corner we'd be in a bad situation". Another "fun situation" was a gas alert. Those can end in a fire ball.

--
Regards, Joerg 

http://www.analogconsultants.com/

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

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

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

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

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

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

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

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

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

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

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

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

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)

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.

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

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

See below.

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

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

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

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

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

In my case, this is a form of PTP (much finer grained resolution... think sub-microsecond -- folks tout ns levels but that's not my goal)

Yes, we used to report TD's to 0.1us resolution -- though I am not sure if actual resolution was that or twice that. E.g., we'd use a 10MHz TCXO as our local timebase. And, since you were measuring the differences in arrival times between events, as long as your local timebase was stable (over the course of, say,

10GRI) and "accurate" *that* defined your positional accuracy (subject to the local geometry of your particular LORAN chain; i.e., no better than ~50 ft and considerably worse in areas of high GDoP)

I can easily get synchronization to < 1us. How much better depends on the resources I bring to bear on this. I would like to come up with a practical scheme for verifying and troubleshooting synchronization problems on *deployed* hardware (vs. "on the bench" where I can put things in convenient places)

--don

Long ago I worked for Decca Navigator which owned and operated a similar navigation system which was designed for the D-day landings. It created hyperbolic lines which were marked on charts. It was considered bad practice to sail exactly along a line since there had been several cases of ships colliding head-on since they had been sailing in opposite direction along the same line without keeping a lookout!

Gas is nasty even when it doesn't ignite. It turns "green water" into "white water" which has a much lower density. So you become too dense to float :(

IMHO that's a possible explanation for some bermuda-triangle-type phenomena: methane clathrates "flash" into methane and trigger nearby clathrates into flashing, thus causing sudden unpredictable bubbles of white water over relatively large areas.

TD's ("LORAN coordinates") are expressed in tenths of microseconds. Anything worse starts to get impractical (100ns is NO BETTER than ~50 ft -- and can easily be much worse as the geometry of the coordinate "basis" varies depending on where you are located wrt the master and secondaries you are currently using).

You track the LORAN signal (a "pulse" modulated 100KHz?) by watching the position of the 3rd (?) zero crossing of the carrier (you also monitor this on the first of the pulses in the CODED pulse train) so you can avoid/minimize multipath effects. Most receivers also allow you to move to *another* zero crossing (i.e., +1 or -1) if the 3rd is in the noise, etc. (though this affects the absolute time differences cuz you are now operating on the next 100KHz cycle)

[Sorry, it's been more than 35 years since I've worked with LORAN so many details are fuzzy]

There are variations in the propagation delay "over land" and "over water" so the theoretical math needs to be tweeked a bit if you want to map a TD pair to (lat,lon) -- but there are also variations in the shape of the Earth (oblateness) that have to be accommodated.

Regardless, in a given region of the ocean (where most commonly used) things are relatively repeatable, day to day. E.g., you could set a lobster pot, record the TD's, return to those TD's some time later and be able to see it from the vessel (there's more variation in where a buoy would appear on the surface due to tides/currents and the fact that a tethered buoy isn't "directly above" whatever it is tethered to!)

Given that it predated (commercial) GPS by decades, it was amazingly useful!

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.

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

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.

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?

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

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

[...]

--
Regards, Joerg 

http://www.analogconsultants.com/

I designed a LORAN-C "autopilot" in the early 80's. The device took TD's from a LORAN receiver. Converted them to (L,l). Then, took a destination -- specified in (L,l) coordinates -- and figured out how to steer the vessel *to* that destination (by driving a servo tied to the rudder).

Until that time, a maritime autopilot simply tried to maintain a desired heading, never cognizant of the effects of drift.

[Actually, there's some sleight of hand, here -- we manufactured the receiver/plotter so some of this crunching was done upstream of my little device -- barely a PIC nowadays!]

On our maiden voyage, we created a course from the south shore of Cape Cod (IIRC, somewhere near Falmouth? I.e., almost due south of Beantown but on the *south* side of the Cape) around the Cape (Provincetown) and into "boston".

Since there are no LANDmarks in the ocean, we used the published coordinates of certain buoys to delimit each leg of the trip. I recall approaching the buoy off the coast of Provincetown (recall, no one is "at the helm" and we're traveling pretty much as fast as the vessel can make in those seas) and watching to see if we would *hit* it (physically)!

[This would have been a fluke due to the variability in it's actual position over land -- see my other comments re: buoys -- as well as the tolerances in LORAN, my course corrections, etc.]

The same level of performance had us seriously considering letting the boat steer itself into port! (thankfully, we didn't let arrogance cloud our decision, there -- nor the beer!)

On short distances and with cheap hardware even hobbyists seem to get below 20ft:

I think you can push this a lot more. That should put you well below

100nsec.

But in your other post you said you don't want the radios in the BOM.

Either way, geting down to the 100nsec ballpark or less should not be a problem if the units are in the same building. The RF link ToF can be measured and calculated out.

--
Regards, Joerg 

http://www.analogconsultants.com/

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]

Sorry, I was recounting my experiences with LORAN -- on a planetwide scale with 80's vintage hardware. :>

Correct. We're conflating two different discussions: my time sync MEASUREMENT requirements and LORAN's capabilities.

I.e., to be more verbose:

My software can easily achieve synchronization between nodes to a level better than 1us -- without doing anything fancy. Recall you don't just have two radios talking to each other or two wired devices -- there are also bits in the middle that contribute to the uncertainty (e.g., network switch, length of interconnect cable, "software", etc.)

I have modified that software to toggle an output pin at specific "times" (i.e., I'm not just locking frequency and phase of a timebase but also it's notion of "absolute" time). More colloquially, each device can toggle this output pin at *it's* notion of "12 noon". I want to be able to *measure* (from the outside) how far off any two devices might be. I.e., if device #1 generates its pulse

*now*, then device #2 must generate it's pulse within Either way, geting down to the 100nsec ballpark or less should not be a

Actually, that gives me a *different* idea!

What if I sat at the "reference point" and injected a signal onto the network cable. A "ping" of sorts. Prior to (or coincident with!) this, I use a TDR to determine the (temporal!) length of the cable.

Now, at each node/device, I measure the time difference between the arrival of this ping (from which I can determine when it *departed* the point of origination) and the "pulse output".

Do that for each node and normalize the results?

This assumes a ping can transit from the reference to each of these points over a single piece of "cable". And, that the propagation speed will be the same from one cable to another??

What type of network cable? If coax, the velocity factor varies with temperature and humdity. See Section 3.3 and Fig 6.

Note: I had the displeasure of dealing with that effect in a VHF direction finder (AN/SRD-21) design. It had twin RG-58c/u cables between the receiver and the antenna that had to be phase matched. When one cable ended up on the sun, and the other in the shade, accuracy suffered badly.

--
Jeff Liebermann     jeffl@cruzio.com 
150 Felker St #D    http://www.LearnByDestroying.com 
Santa Cruz CA 95060 http://802.11junk.com 
Skype: JeffLiebermann     AE6KS    831-336-2558

Exactly. But I can compensate for these. E.g., I can turn my system on, let two nodes synchronize their timebases,

*cut* the interconnect cable and insert an additional 100 ft and the timebases will resynchronize (after adjusting to the disturbance I introduced by altering the propagation time as a consequence of cable length) TO THE EXACT SAME DEGREE OF SYNCHRONIZATION! I.e., cable length ("electrical distance") falls out of the equation.

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

Imagine each message is of the form: "I was emitted at XX:XX:XX"

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

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

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

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

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

In my case, CAT5/6. But, ideally, I would prefer a methodology that could be applied to other communications media without relying on some characteristic of *a* medium.

E.g., my ping could be applied to a wireless medium just as well as wired -- if we assume propagation is at a constant rate (over a reasonably short measurement interval) between devices.

That can be done via RF or cable. With RF you can send out a pulse train modulated onto a carrier whenever unit A says it is high noon. Then send a similar pulse train when unit B thinks it's high noon, but this one has to be on another carrier frequency so they can occur simultaneously.

The simplest form of comparing the transmission times would be zero-crossers for the demodulated signal. Complex FFT and correlation are other methods. All you need to know is the phase difference but you want to know it quite precisely.

I have recently done something similar but using the sound card of a PC. It was possible to reliably detect phase shifts in the milli-degree range. You have to make sure that the bandwidth after procesing is low, to knock the noise down far enough. No big deal, because you can let each unit transmit long enough.

I don't see why that would not work. Provided that any hardware between pinger and "pingee" is not flopping around to much in terms of phase noise.

--
Regards, Joerg 

http://www.analogconsultants.com/