Connect with us

Comparing phase of physically distant signals

Discussion in 'Electronic Design' started by Don Y, Aug 3, 2013.

  1. Don Y

    Don Y Guest

    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
     
  2. Joerg

    Joerg Guest


    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.
     
  3. josephkk

    josephkk Guest

    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.

    ?-)
     
  4. Joerg

    Joerg Guest

    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
     
  5. John S

    John S Guest

    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
     
  6. Joerg

    Joerg Guest

    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.
     
  7. John S

    John S Guest

    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
     
  8. Don Y

    Don Y Guest

    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)
    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".
     
  9. Don Y

    Don Y Guest

    Hi Joerg (and Joseph)

    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
     
  10. Don Y

    Don Y Guest

    Hi John,

    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!
     
  11. Joerg

    Joerg Guest

    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?

    [...]
     
  12. Don Y

    Don Y Guest

    Hi Joerg,

    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!)
     
  13. Joerg

    Joerg Guest

    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.

    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.
     
  14. Don Y

    Don Y Guest

    Hi Joerg,

    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 << 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"]
    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??
     
  15. miso

    miso Guest

    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.
     
  16. Don Y

    Don Y Guest

    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.

    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.
     
  17. Joerg

    Joerg Guest

    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.
     
  18. Joerg

    Joerg Guest

    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.

    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.
     
  19. miso

    miso Guest

    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.
     
  20. Don Y

    Don Y Guest

    Hi Joerg,
    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.)
    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.
    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 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).
    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...]
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-