Comparing phase of physically distant signals

[Don Y]

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.

Thx,
--don

 

[Joerg]

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.

 

[josephkk]

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.

Thx,
--don

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.

?-)

 

[Joerg]

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.

Thx,
--don

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:

http://tycho.usno.navy.mil/ptti/1988/Vol 20_13.pdf

 

[John S]

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.

Thx,
--don

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:

http://tycho.usno.navy.mil/ptti/1988/Vol 20_13.pdf

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

 

[Joerg]

On Sat, 03 Aug 2013 00:45:41 -0700, 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.

Thx,
--don

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:

http://tycho.usno.navy.mil/ptti/1988/Vol 20_13.pdf

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

Under "Results" it says so.

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

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.

 

[John S]

josephkk wrote:
On Sat, 03 Aug 2013 00:45:41 -0700, 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.

Thx,
--don

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:

http://tycho.usno.navy.mil/ptti/1988/Vol 20_13.pdf

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

Under "Results" it says so.

My mistake. I will read the article again.

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

You are correct.

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.

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

Cheers

 

[Don Y]

Hi Joerg,

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)

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

 

[Don Y]

Hi Joerg (and Joseph)

[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.
How do I practically do this when the devices are *deployed* and
physically distant (vs. "electrically distant" as in my test case)?

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.

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)

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:

http://tycho.usno.navy.mil/ptti/1988/Vol 20_13.pdf

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

 

[Don Y]

Hi John,

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.

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!

 

[Joerg]

Hi Joerg,



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.

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?

[...]

 

[Don Y]

Hi Joerg,

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.

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

 

[Joerg]

Hi Joerg (and Joseph)

On Sat, 03 Aug 2013 00:45:41 -0700, Don Y wrote:

[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.
How do I practically do this when the devices are *deployed* and
physically distant (vs. "electrically distant" as in my test case)?
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.

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)

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:

http://tycho.usno.navy.mil/ptti/1988/Vol 20_13.pdf

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)

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

http://www.instructables.com/id/Distance-measurement-with-radio-waves/

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

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)

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

<scratching head>

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.

 

[Don Y]

Hi Joerg,

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

http://www.instructables.com/id/Distance-measurement-with-radio-waves/

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

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

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

<scratching head>

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 << 1us of
"now".

[I.e., I'm not trying to compare two X Hz oscillators and get them
"in sync". Rather, I am trying to compare two TIMEBASES and ensure
they are in sync -- they both agree that it is 12:00:00.000000
*now* -- by emitting a signal "often enough" that a measurement
device can provide adequate feedback to a human being regarding
any discrepancies in the devices' notion of "now"]

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.

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

 

[miso]

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.

http://www.satsignal.eu/mrtg/performance_ntp.php

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.

 

[Don Y]

Hi Jeff,

What type of network cable? If coax, the velocity factor varies with
temperature and humdity.
<http://eor.berkeley.edu/wp-content/uploads/2011/09/p011.cparashare.pdf>
See Section 3.3 and Fig 6.

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.

 

[Joerg]

Hi Joerg,

On 8/3/2013 12:52 PM, Joerg wrote:
[...]

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

<scratching head>

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 << 1us of
"now".

[I.e., I'm not trying to compare two X Hz oscillators and get them
"in sync". Rather, I am trying to compare two TIMEBASES and ensure
they are in sync -- they both agree that it is 12:00:00.000000
*now* -- by emitting a signal "often enough" that a measurement
device can provide adequate feedback to a human being regarding
any discrepancies in the devices' notion of "now"]

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.

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

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.

 

[Joerg]

Hi Jeff,



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.

As long as pulse and response for the media test (ToF) happens via the
same cable it makes no difference whether its characteristics change.
Provided you repeat that ToF test before every transmitted timer tick of
your measurement method.

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.

It normally is. Unless you are next to a busy airport, freeway or
high-speed rail. You also need to make sure the frequency/carrier you
are using is free of interference, regardles of whether you use cables
or wireless.

 

[miso]

Cisco has ieee 1588 gear, but you need both host cards and switch. There
are easily half a dozen companies making the chips, but the hardware
hasn't become mainstream yet.

For GPS timing, you need to ignore satellites at the horizon. Using a
GPS for timing is a bit different than using one for position. Some of
the GPS timing antennas are designed to ignore the horizon, but this
isn't universal.

You can also synchronize from cellular signals, especially LTE.

 

[Don Y]

Hi Joerg,

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

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.

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