Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #12917 > unrolled thread

Comparing phase of physically distant signals

Back to article view | Back to comp.arch.embedded

Contents

  Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 00:45 -0700
    Re: Comparing phase of physically distant signals Jan Panteltje <pNaonStpealmtje@yahoo.com> - 2013-08-03 07:51 +0000
    Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 09:58 +0100
      Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-03 13:21 +0300
        Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 12:16 +0100
        Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 11:56 -0700
          Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 20:17 +0100
            Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 13:41 -0700
              Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 22:46 +0100
                Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 14:57 -0700
                  Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 23:09 +0100
      Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-03 13:58 +0300
        Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 12:30 +0100
      Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-03 16:08 +0300
        Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 14:22 +0100
          Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-03 16:38 +0300
            Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 10:46 -0700
        Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 10:40 -0700
          Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 20:04 +0100
          Re: Comparing phase of physically distant signals Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-08-04 15:55 +0200
            Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-04 19:42 +0300
              Re: Comparing phase of physically distant signals Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-08-04 21:08 +0200
                Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-05 15:28 +0300
                  Re: Comparing phase of physically distant signals Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-08-05 22:17 +0200
                    Re: Comparing phase of physically distant signals Richard Damon <Richard@Damon-Family.org> - 2013-08-05 23:20 -0400
      Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 14:26 +0100
      Re: Comparing phase of physically distant signals George Neuner <gneuner2@comcast.net> - 2013-08-03 14:47 -0400
    Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 08:17 -0700
      Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 12:08 -0700
        Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 20:37 +0100
          Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 12:57 -0700
            Re: Comparing phase of physically distant signals Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-08-04 15:58 +0200
        Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 12:44 -0700
          Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 18:36 -0700
            Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-04 09:56 -0700
              Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-05 14:53 -0700
                Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-05 15:38 -0700
                  Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-07 01:25 -0700
                    Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-07 08:06 -0700
                      Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-07 09:21 -0700
    Re: Comparing phase of physically distant signals josephkk <joseph_barrett@sbcglobal.net> - 2013-08-03 15:40 +0000
      Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 10:05 -0700
        Re: Comparing phase of physically distant signals John S <Sophi.2@invalid.org> - 2013-08-03 12:13 -0500
          Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 10:26 -0700
            Re: Comparing phase of physically distant signals John S <Sophi.2@invalid.org> - 2013-08-03 12:51 -0500
              Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 11:54 -0700
                Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 20:27 +0100
                  Re: Comparing phase of physically distant signals George Neuner <gneuner2@comcast.net> - 2013-08-05 03:26 -0400
                    Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-05 10:34 +0100
                    Re: Comparing phase of physically distant signals Richard Damon <Richard@Damon-Family.org> - 2013-08-05 23:29 -0400
                      Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 08:53 +0100
            Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 12:49 -0700
          Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 12:34 -0700
        Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 12:18 -0700
          Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 12:52 -0700
            Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 13:21 -0700
              Re: Comparing phase of physically distant signals Jeff Liebermann <jeffl@cruzio.com> - 2013-08-03 13:31 -0700
                Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 14:46 -0700
                  Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 15:03 -0700
                  Re: Comparing phase of physically distant signals Jeff Liebermann <jeffl@cruzio.com> - 2013-08-03 17:25 -0700
              Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 14:50 -0700
      Re: Comparing phase of physically distant signals "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-08-04 11:06 +0100
        Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-04 12:19 -0700
    Re: Comparing phase of physically distant signals John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> - 2013-08-03 11:47 -0700
    Re: Comparing phase of physically distant signals Richard Damon <Richard@Damon-Family.org> - 2013-08-03 18:23 -0400
    Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-05 16:53 +0100
      Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-05 13:19 -0700
        Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 00:27 +0100
          Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-05 20:09 -0700
            Re: Comparing phase of physically distant signals Paul Rubin <no.email@nospam.invalid> - 2013-08-05 22:12 -0700
              Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 09:12 +0100
              Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 01:47 -0700
                Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 10:08 +0100
                  Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 02:25 -0700
                    Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 02:48 -0700
                    Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 10:49 +0100
                      Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 03:06 -0700
                        Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 11:57 +0100
                          Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 10:28 -0700
                            Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 21:52 +0100
                              Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-07 01:34 -0700
                                Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-07 09:46 +0100
                Re: Comparing phase of physically distant signals Les Cargill <lcargill99@comcast.com> - 2013-08-06 07:22 -0500
                  Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 10:42 -0700
                    Re: Comparing phase of physically distant signals Les Cargill <lcargill99@comcast.com> - 2013-08-06 23:04 -0500
                      Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 23:50 -0700
                        Re: Comparing phase of physically distant signals Les Cargill <lcargill99@comcast.com> - 2013-08-07 13:05 -0500
                          Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-07 18:22 -0700
                            Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-08 09:35 +0100
                Re: Comparing phase of physically distant signals Paul Rubin <no.email@nospam.invalid> - 2013-08-06 22:18 -0700
                  Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-07 03:09 -0700
                    Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-07 12:39 +0100
                    Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-07 13:18 +0100
            Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 09:23 +0100
              Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 02:02 -0700
            Re: Comparing phase of physically distant signals "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-08-06 09:49 +0100
              Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 02:17 -0700
    Re: Comparing phase of physically distant signals Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-08-16 21:07 +0100
      Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-16 14:50 -0700
        Re: Comparing phase of physically distant signals Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-08-18 19:55 +0100
          Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-19 11:43 -0700
            Re: Comparing phase of physically distant signals Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-08-20 21:43 +0100
              Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-20 14:49 -0700

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#12930

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.

?-)

[toc] | [prev] | [next] | [standalone]

#12931

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%2020_13.pdf

-- 
Regards, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#12932

On 8/3/2013 12:05 PM, Joerg wrote:
> 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%2020_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

[toc] | [prev] | [next] | [standalone]

#12933

John S wrote:
> On 8/3/2013 12:05 PM, Joerg wrote:
>> 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%2020_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.

-- 
Regards, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#12936

On 8/3/2013 12:26 PM, Joerg wrote:
> John S wrote:
>> On 8/3/2013 12:05 PM, Joerg wrote:
>>> 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%2020_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.

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

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

[toc] | [prev] | [next] | [standalone]

#12939

John S wrote:
> On 8/3/2013 12:26 PM, Joerg wrote:

[...]


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

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/

[toc] | [prev] | [next] | [standalone]

#12945

On 03/08/13 19:54, Joerg wrote:
> John S wrote:
>> On 8/3/2013 12:26 PM, Joerg wrote:
>
> [...]
>
>
>>> 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.
>>

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!


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

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.

[toc] | [prev] | [next] | [standalone]

#12974

On Sat, 03 Aug 2013 20:27:49 +0100, Tom Gardner
<spamjunk@blueyonder.co.uk> wrote:


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

This only works in a confined space [such as a lab cylinder].  In open
water the bubbles cause an upwelling current which pulls in water from
the sides, supporting the column and pushing low density water upward
thus supporting whatever is floating in it.  

Some years ago, a team attempted to test the bubble theory by sinking
a full size yacht in a harbor.  The more bubbles they produced, the
*higher* the yacht road on the upwelling current.  The best they were
able to achieve was to create a confused sea state that managed to
swamp the yacht when it was heavily overladen.

OTOH, one giant bubble is likely to cause a problem - effectively
opening a hole in the water into which a ship may drop.  A large ship
that buries its nose or breaks in the middle is unlikely to survive.
The question is whether bubbles of such enormity can actually form.  

More likely rogue waves and pop-up severe storms are responsible for
most sinkings in the triangle.  But methane releases might be the
reason for some aircraft losses.  It only takes about 2% methane to
choke an engine.  It's possible that a large release could achieve
sufficient concentration over a wide enough area that a plane flying
through it would stall and not be able to restart.  Methane also
confuses pressure altimeters, which show the plane climbing as the
methane concentration increases.  At night or in low visibility, it's
possible this might trick a pilot into diving right into the water.

YMMV,
George

[toc] | [prev] | [next] | [standalone]

#12978

On 05/08/13 08:26, George Neuner wrote:
 > On Sat, 03 Aug 2013 20:27:49 +0100, Tom Gardner
 > <spamjunk@blueyonder.co.uk> wrote:
 >
 >
 >> 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.
 >
 > This only works in a confined space [such as a lab cylinder].  In open
 > water the bubbles cause an upwelling current which pulls in water from
 > the sides, supporting the column and pushing low density water upward
 > thus supporting whatever is floating in it.
 >
 > Some years ago, a team attempted to test the bubble theory by sinking
 > a full size yacht in a harbor.  The more bubbles they produced, the
 > *higher* the yacht road on the upwelling current.  The best they were
 > able to achieve was to create a confused sea state that managed to
 > swamp the yacht when it was heavily overladen.

Interesting and relevant.

However, having talked to people that work on North Sea
gas rigs, one of the things they fear is a rupture of
the pipe underwater. Gas in air => no helicopter rescue
(as you point out below) and gas in water => their lifeboats
sink. Whether their fear is justified is outside my
field of knowledge, and I don't know how relevant the
Deep Water Horizon explosion would have been.


 > OTOH, one giant bubble is likely to cause a problem - effectively
 > opening a hole in the water into which a ship may drop.  A large ship
 > that buries its nose or breaks in the middle is unlikely to survive.
 > The question is whether bubbles of such enormity can actually form.

That is a good question. I suspect that it might be
possible under infrequent circumstances. AFAIK undersea
hydrates are "fragile" in that they do tend to flash into
gaseous methane. So, what could provoke a flash?

First question: are clathrates present there? Definitely,
and in large quantities. Even if they don't come from
decaying organic matter, there are obviously plenty
of sub-surface sources (well, for the next few
decades anyway!)

Clathrates will of course form where they are only
marginally stable, but then small disturbances will
quickly destroy them. The deep sea environment is
relatively stable and slowly changing so the
clathrates could build up and not be "recycled"
into methane until...

An earthquake would have sufficient power over a
widespread area to cause clathrates to flash.

A mudslip ditto, with the added effect that clathrates
flashing at the top of a slope could set off a small
mudslip which then triggers flashing down the slope
in a self-reinforcing avalanche. It is a moot point
whether the avalanche causes the flash, or vice versa!

The debris from underwater avalanches is visible
in several places in the "Bermuda triangle". 2+2=?


 > More likely rogue waves and pop-up severe storms are responsible for
 > most sinkings in the triangle.

Undoubtedly a major contender, but IIRC some mysteries
occurred in relatively good weather. No, I can't remember
details since I haven't looked at such things since
the 70s.


 > But methane releases might be the
 > reason for some aircraft losses.  It only takes about 2% methane to
 > choke an engine.  It's possible that a large release could achieve
 > sufficient concentration over a wide enough area that a plane flying
 > through it would stall and not be able to restart.  Methane also
 > confuses pressure altimeters, which show the plane climbing as the
 > methane concentration increases.  At night or in low visibility, it's
 > possible this might trick a pilot into diving right into the water.

Visual height estimation when flying at night
over water is notoriously error prone too.

[toc] | [prev] | [next] | [standalone]

#12988

On 8/5/13 3:26 AM, George Neuner wrote:
> On Sat, 03 Aug 2013 20:27:49 +0100, Tom Gardner
> <spamjunk@blueyonder.co.uk> wrote:
> 
> 
>> 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.
> 
> This only works in a confined space [such as a lab cylinder].  In open
> water the bubbles cause an upwelling current which pulls in water from
> the sides, supporting the column and pushing low density water upward
> thus supporting whatever is floating in it.  
> 
> Some years ago, a team attempted to test the bubble theory by sinking
> a full size yacht in a harbor.  The more bubbles they produced, the
> *higher* the yacht road on the upwelling current.  The best they were
> able to achieve was to create a confused sea state that managed to
> swamp the yacht when it was heavily overladen.
> 
> OTOH, one giant bubble is likely to cause a problem - effectively
> opening a hole in the water into which a ship may drop.  A large ship
> that buries its nose or breaks in the middle is unlikely to survive.
> The question is whether bubbles of such enormity can actually form.  
> 
> More likely rogue waves and pop-up severe storms are responsible for
> most sinkings in the triangle.  But methane releases might be the
> reason for some aircraft losses.  It only takes about 2% methane to
> choke an engine.  It's possible that a large release could achieve
> sufficient concentration over a wide enough area that a plane flying
> through it would stall and not be able to restart.  Methane also
> confuses pressure altimeters, which show the plane climbing as the
> methane concentration increases.  At night or in low visibility, it's
> possible this might trick a pilot into diving right into the water.
> 
> YMMV,
> George
> 

I've always wondered if by creating the bubble field of enormous size,
much greater than the size of the boat, and also of scale at least
similar to the depth of the water, then the bubbles farther away might
shield the center from the upwelling effect, and get the sinking effect.

[toc] | [prev] | [next] | [standalone]

#12990

On 06/08/13 04:29, Richard Damon wrote:
> On 8/5/13 3:26 AM, George Neuner wrote:
>> On Sat, 03 Aug 2013 20:27:49 +0100, Tom Gardner
>> <spamjunk@blueyonder.co.uk> wrote:
>>
>>
>>> 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.
>>
>> This only works in a confined space [such as a lab cylinder].  In open
>> water the bubbles cause an upwelling current which pulls in water from
>> the sides, supporting the column and pushing low density water upward
>> thus supporting whatever is floating in it.
>>
>> Some years ago, a team attempted to test the bubble theory by sinking
>> a full size yacht in a harbor.  The more bubbles they produced, the
>> *higher* the yacht road on the upwelling current.  The best they were
>> able to achieve was to create a confused sea state that managed to
>> swamp the yacht when it was heavily overladen.
>>
>> OTOH, one giant bubble is likely to cause a problem - effectively
>> opening a hole in the water into which a ship may drop.  A large ship
>> that buries its nose or breaks in the middle is unlikely to survive.
>> The question is whether bubbles of such enormity can actually form.
>>
>> More likely rogue waves and pop-up severe storms are responsible for
>> most sinkings in the triangle.  But methane releases might be the
>> reason for some aircraft losses.  It only takes about 2% methane to
>> choke an engine.  It's possible that a large release could achieve
>> sufficient concentration over a wide enough area that a plane flying
>> through it would stall and not be able to restart.  Methane also
>> confuses pressure altimeters, which show the plane climbing as the
>> methane concentration increases.  At night or in low visibility, it's
>> possible this might trick a pilot into diving right into the water.
>>
>> YMMV,
>> George
>>
>
> I've always wondered if by creating the bubble field of enormous size,
> much greater than the size of the boat, and also of scale at least
> similar to the depth of the water, then the bubbles farther away might
> shield the center from the upwelling effect, and get the sinking effect.

One could even imagine creating a ring of bubbles around
the boat, the centre and boat then sink as they rush outwards
into the bubbles, then the sea around the outside rushes back
in.

Conceivable? Yes. Would I put money on it? Of course not,
without some practical experimentation :)

[toc] | [prev] | [next] | [standalone]

#12949

Hi Joerg,

On 8/3/2013 10:26 AM, Joerg wrote:

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

[toc] | [prev] | [next] | [standalone]

#12946

Hi John,

On 8/3/2013 10:13 AM, John S wrote:

>> 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%2020_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.

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!

[toc] | [prev] | [next] | [standalone]

#12944

Hi Joerg (and Joseph)

On 8/3/2013 10:05 AM, Joerg wrote:
> josephkk wrote:
>> 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%2020_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

[toc] | [prev] | [next] | [standalone]

#12950

Don Y wrote:
> Hi Joerg (and Joseph)
> 
> On 8/3/2013 10:05 AM, Joerg wrote:
>> josephkk wrote:
>>> 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%2020_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.

-- 
Regards, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#12952

Hi Joerg,

On 8/3/2013 12:52 PM, Joerg wrote:
>>> 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%2020_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.

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

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

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

[toc] | [prev] | [next] | [standalone]

#12953

On Sat, 03 Aug 2013 13:21:54 -0700, Don Y <this@isnotme.com> wrote:

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

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.

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

[toc] | [prev] | [next] | [standalone]

#12956

Hi Jeff,

On 8/3/2013 1:31 PM, Jeff Liebermann wrote:
> On Sat, 03 Aug 2013 13:21:54 -0700, Don Y <this@isnotme.com> wrote:
>
>> 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.
>
> 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.

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

[toc] | [prev] | [next] | [standalone]

#12959

Don Y wrote:
> Hi Jeff,
> 
> On 8/3/2013 1:31 PM, Jeff Liebermann wrote:
>> On Sat, 03 Aug 2013 13:21:54 -0700, Don Y <this@isnotme.com> wrote:
>>
>>> 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.
>>
>> 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.
> 

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.

-- 
Regards, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#12962

On Sat, 03 Aug 2013 14:46:32 -0700, Don Y <this@isnotme.com> wrote:

>Hi Jeff,
>
>On 8/3/2013 1:31 PM, Jeff Liebermann wrote:
>> On Sat, 03 Aug 2013 13:21:54 -0700, Don Y <this@isnotme.com> wrote:
>>
>>> 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.
>>
>> 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.

Bad news.  Any measurement between two points is going to involve some
medium in between.  The trick is to not have the medium
characteristics change during the measurement.  That makes copper and
dielectric a rather bad choice, and shoveling bits through repeaters,
hubs and switches a good source of additional errors.  Going though
the air seems to offer the least drift, error, and jitter.

Please note that CAT5 or 6 is not much of an improvement over coax
cable.  The major source of drift is the elongation of the copper
conductors with temperature.  Whether that error is significant
depends on the lengths involved, which you haven't disclosed.

I like Joerg's idea.  Two reference pulses, sent by each end, measured
at some known central location.  You can also do it backwards.  Have
the known central location send a single reference pulse, and then
have the two end points store and return the pulses after a stable and
fixed delay.

Incidentally, that works nicely for playing radio location via
hyperbolic navigation (same as LORAN).  I used it to create a line of
position for a VHF/UHF mobile radio talking through a repeater.  I
used two identical scanner receivers to listen to the repeater input
and the repeater output.  The delay through the repeater is fairly
stable and easily measured.  Therefore, the mobile transmitter was
somewhere along a line of position defined by a constant time
difference between the repeater and my receivers.  Today, I would have
a computer calculate the hyperbolic line of position.  In 1979(?), I
used a road map, two push pins, a loop of string, and a pencil.  I
still can't decode what you're trying to accomplish, but this might
give you some ideas.

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

Yep.  If you figure out how to reflect the injected signal, you can
probably live without having to transmit back any timing information. 

What I'm not seeing are any distances involved or accuracy
requirements.  Also, what equipment or devices you have to work with.
I'm floundering with bad guesses as to your intentions.

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

[toc] | [prev] | [next] | [standalone]

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web