Comparing phase of physically distant signals

On a sunny day (Sat, 03 Aug 2013 00:45:41 -0700) it happened Don Y wrote in :

This sounds like a GPS case, but really without knowing _numbers_ and other parameters no way to tell.

Installers will hate this.

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

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.

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.

Sounds like a use case for NTP (network time protocol) which already keeps millions of computers synchronized to a few milliseconds across the whole planet.

?-)

Don hasn't given us any specs yet but if this has to be in the sub-microsecond class then real terrestrial RF may be needed. Even old Loran could do that back in the 80's, over lots of miles:

According to the paper you referenced, it was not sub-microsecond.

Also, it discusses only the surface wave. Reflections may occur at other frequencies and upset the path length.

John S

Under "Results" it says so.

It does fall apart when you get over 100 miles or really bad terrain. But I doubt Don needs that much.

Loran is (or was) amazing. It literally saved the life of a guy at my university. He sailed his fathers large boat, alone, in the French Atlantic at the end of summer. Woe to whom who gets into a storm there. Long story short he got into a lull and then the mother of all storms rolled in. At night. He headed for a port but knew that it had a very narrow opening of just a couple hundred feet, with massive concrete and rock structures on either side. Structures that would have busted his boat into smittereens in that storm. He was not religious but turned to his navigation screen and prayed. The Loran coverage wasn't even that great. Many hours later his boat went right through the middle, he saw the two massive structures pass by on either side. He needed the bathroom, fast.

My mistake. I will read the article again.

You are correct.

Nice story. I longed to sail the sea, and in fact, I still do. But, at my age, I could not handle it.

Cheers

That will work, if you can get cables or fibers long enough. The propagation delays can be measured, but tempcos will matter if you're concerned about nanoseconds or less.

What are your numbers? Distance? Accuracy expectation?

There is a technique for absolute-time-syncing clocks that measures the round-trip cable (or fiber) delay in both directions and does the math to take it out. I don't recall what it's called.

Can't GPS deliver absolute time ticks? Wasn't that used in the recent bogus FTL neutrino experiment?

You can physically transport an atomic clock from site to site to align absolute times. You need relativity compensation to get really good.

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.

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.

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.

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

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,

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

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)

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!

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?

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.

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)!

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

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.

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

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.

You need to run NTP and a GPSDO (GPS disciplined oscillator). You can buy GPSDOs on ebay. Symetricom, Meinberg, etc. These days around $100 to $300 a box. Note the wireless companies have tossed thousands of these in the crusher. I got two from a cellular tech and have kicked myself for not wiping the guy out once I found out what they go for on ebay.

Check out ebay item 300943155756

I can tell from the text of the ad, this person knows what they are doing. Lady Heather is the free program you can use to monitor your GPSDO.

You will also have to tune up NTP. If you are using windows, you need to know that windows time is NOT NTP. Meinberg has a free windows NTP program.

The satsignal website has much useful software for NTP tuning. The deal is you need to find the right interval to update the PC clock. Update too often and it is jittery. Update to infrequently and the clock drifts.

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.