Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.realtime > #248 > unrolled thread
| Started by | Don Y <this@isnotme.com> |
|---|---|
| First post | 2013-08-03 00:45 -0700 |
| Last post | 2013-08-16 21:07 +0100 |
| Articles | 20 on this page of 96 — 16 participants |
Back to article view | Back to comp.realtime
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 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 Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-08-16 21:07 +0100
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | josephkk <joseph_barrett@sbcglobal.net> |
|---|---|
| Date | 2013-08-03 15:40 +0000 |
| Message-ID | <51fd247c$0$64328$c3e8da3$5e5e430d@news.astraweb.com> |
| In reply to | #248 |
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]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-08-03 10:05 -0700 |
| Message-ID | <b64rj8Fd0uiU1@mid.individual.net> |
| In reply to | #260 |
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]
| From | John S <Sophi.2@invalid.org> |
|---|---|
| Date | 2013-08-03 12:13 -0500 |
| Message-ID | <ktjdc5$snt$1@dont-email.me> |
| In reply to | #261 |
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]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-08-03 10:26 -0700 |
| Message-ID | <b64sppFdbocU1@mid.individual.net> |
| In reply to | #262 |
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]
| From | John S <Sophi.2@invalid.org> |
|---|---|
| Date | 2013-08-03 12:51 -0500 |
| Message-ID | <ktjfig$84b$1@dont-email.me> |
| In reply to | #263 |
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]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-08-03 11:54 -0700 |
| Message-ID | <b651vgFef4hU1@mid.individual.net> |
| In reply to | #266 |
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]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-08-03 20:27 +0100 |
| Message-ID | <UQcLt.49064$z47.11353@fx35.am4> |
| In reply to | #269 |
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]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2013-08-05 03:26 -0400 |
| Message-ID | <frhuv8l2qlrrvkhjrpc6ke5t6rdc918ra7@4ax.com> |
| In reply to | #275 |
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]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-08-05 10:34 +0100 |
| Message-ID | <QkKLt.2$Rp1.1@fx02.am4> |
| In reply to | #300 |
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]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2013-08-05 23:29 -0400 |
| Message-ID | <f4_Lt.2321$sr1.32@en-nntp-04.dc1.easynews.com> |
| In reply to | #300 |
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]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-08-06 08:53 +0100 |
| Message-ID | <0Y1Mt.1196$s85.187@fx08.am4> |
| In reply to | #312 |
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]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-08-03 12:49 -0700 |
| Message-ID | <ktjmt2$v3$1@speranza.aioe.org> |
| In reply to | #263 |
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]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-08-03 12:34 -0700 |
| Message-ID | <ktjlvj$u15$1@speranza.aioe.org> |
| In reply to | #262 |
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]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-08-03 12:18 -0700 |
| Message-ID | <ktjl2v$ruf$1@speranza.aioe.org> |
| In reply to | #261 |
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]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-08-03 12:52 -0700 |
| Message-ID | <b655bvFf69hU1@mid.individual.net> |
| In reply to | #274 |
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]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-08-03 13:21 -0700 |
| Message-ID | <ktjop2$5tg$1@speranza.aioe.org> |
| In reply to | #280 |
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]
| From | Jeff Liebermann <jeffl@cruzio.com> |
|---|---|
| Date | 2013-08-03 13:31 -0700 |
| Message-ID | <jtpqv89e3tsa18403o5tufakrj6heclnqp@4ax.com> |
| In reply to | #282 |
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]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-08-03 14:46 -0700 |
| Message-ID | <ktjtnn$i0c$1@speranza.aioe.org> |
| In reply to | #283 |
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]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-08-03 15:03 -0700 |
| Message-ID | <b65d11FgpgfU1@mid.individual.net> |
| In reply to | #286 |
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]
| From | Jeff Liebermann <jeffl@cruzio.com> |
|---|---|
| Date | 2013-08-03 17:25 -0700 |
| Message-ID | <jj6rv8tobj7sliv3jkj9umdd79br13oa7p@4ax.com> |
| In reply to | #286 |
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 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.realtime
csiph-web