time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

eLoran is up and operating. Looking good

PS
paul swed
Mon, Feb 6, 2017 4:25 PM

Regards
Paul
WB8TSL

Regards Paul WB8TSL
RN
Ruslan Nabioullin
Tue, Feb 7, 2017 12:38 AM

So any ideas on how likely it will be that eLORAN becomes deployed with
at least partial US coverage within the next 5--10 years?  There exists
a solid company working on its R&D (UrsaNav), apparently increased
awareness in government, and UrsaNav entered into a partnership with
Spectracom for integrating its UN-152B (modern SDR-based eLORAN,
Loran-C, and Chayka frequency and time transfer receiver) for GNSS
fallback, which has been tested for commercial applications (e.g.,
NYSE), so apparently there is some commercial demand (I have been told
by an engineer at Google that they are aware of this for Spanner and
their other R&D projects requiring time metrology, but have not decided
yet).

-Ruslan

So any ideas on how likely it will be that eLORAN becomes deployed with at least partial US coverage within the next 5--10 years? There exists a solid company working on its R&D (UrsaNav), apparently increased awareness in government, and UrsaNav entered into a partnership with Spectracom for integrating its UN-152B (modern SDR-based eLORAN, Loran-C, and Chayka frequency and time transfer receiver) for GNSS fallback, which has been tested for commercial applications (e.g., NYSE), so apparently there is some commercial demand (I have been told by an engineer at Google that they are aware of this for Spanner and their other R&D projects requiring time metrology, but have not decided yet). -Ruslan
BC
Bob Camp
Tue, Feb 7, 2017 2:06 AM

Hi

On Feb 6, 2017, at 7:38 PM, Ruslan Nabioullin rnabioullin@gmail.com wrote:

So any ideas on how likely it will be that eLORAN becomes deployed with at least partial US coverage within the next 5--10 years?

No, this is not the world as I would like it to be. It is the world we live in now and are likely to live in for the foreseeable future.

If we are looking at it purely as a timing reference the outlook is not real good. Best guess about 1 in 1,000. I’m probably estimating
that on the generous side. If there is some other magic use for the thing (or a couple dozen other uses) that might change the
equation. Right now those other uses are not very obvious.

Why the lousy outlook:

  1. The way a system like this gets funded is for it to have  a lot of users. It might also get
    funded if some crazy black project needs it. That’s not happening with Loran. Loran died in
    the first place due to a lack of users.
  2. For a system like this to have a lot of users, you need to pass regulations requiring it’s use.
    That may seem odd, but that’s the way it works. Loran co-existed with GPS for a long time.
    GPS was less reliable back then than it is today.  Using Loran for timing was a very rare thing
    outside a handful of labs.
  3. To regulate it into major systems, it needs to have at least a country wide coverage and
    more likely a bit more than that. Without that there isn’t enough of a timing market to address.
    You need to retrofit it into every cell tower in the country (for instance).
  4. Loran getting into buildings from a single site (even fairly close) … not so much if they are
    full of switching power supplies, you have a problem. You need to have many Loran transmitters. Cell timing
    is moving out of the “edge” and into the central hubs. That means buildings full of switchers.
  5. Tying multiple time sources into a system costs big money. If you only have two clocks, how
    do you decide which one is wrong? Not an easy question to answer. That money has to come
    from somebody. Nobody wants to pay. The cell carriers have never been excited about
    investment that does not immediately result in more customers.
  6. There are multiple competing “for pay” backup timing systems. Adding another one to
    the mix is pretty hard to justify. Even more so if you can “steal” timing off of one and
    not pay for it. That would be the case with an eLoran that works with all our old gear.
  7. Like it or not, justified or not, cost effective (not), the world is hung up on space based
    systems. There is no excitement in 1950’s technology.
  8. Loran for exact timing has some major issues with propagation delay. If your goal
    is the same as the system specs ( < 100 ns) that’s going to be a really tough nut to
    crack. Do they need < 100 ns? It’s in the spec …

Will they keep studying it as long as they can get funding for the study? Of course they will.
How long will people keep pitching in for that funding … could be years. Five to ten year
studies that go nowhere are not at all uncommon.

Right now we have multiple broadcast time sources running 24/7 at various frequencies
with various coverage zones. As far as I know none of them are tied into major systems.
That’s just the way it is, and it’s nothing new. Even in military systems, multiple time sources
into a system is a very rare thing. In commercial systems …

Again, I’m not arguing that this is an ideal world.

Bob

There exists a solid company working on its R&D (UrsaNav), apparently increased awareness in government, and UrsaNav entered into a partnership with Spectracom for integrating its UN-152B (modern SDR-based eLORAN, Loran-C, and Chayka frequency and time transfer receiver) for GNSS fallback, which has been tested for commercial applications (e.g., NYSE), so apparently there is some commercial demand (I have been told by an engineer at Google that they are aware of this for Spanner and their other R&D projects requiring time metrology, but have not decided yet).

-Ruslan


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Hi > On Feb 6, 2017, at 7:38 PM, Ruslan Nabioullin <rnabioullin@gmail.com> wrote: > > So any ideas on how likely it will be that eLORAN becomes deployed with at least partial US coverage within the next 5--10 years? No, this is not the world as I would like it to be. It is the world we live in now and are likely to live in for the foreseeable future. If we are looking at it purely as a timing reference the outlook is not real good. Best guess about 1 in 1,000. I’m probably estimating that on the generous side. If there is some other magic use for the thing (or a couple dozen other uses) that might change the equation. Right now those other uses are not very obvious. Why the lousy outlook: 1) The way a system like this gets funded is for it to have a lot of users. It might also get funded if some crazy black project needs it. That’s not happening with Loran. Loran died in the first place due to a lack of users. 2) For a system like this to have a lot of users, you need to pass regulations requiring it’s use. That may seem odd, but that’s the way it works. Loran co-existed with GPS for a long time. GPS was *less* reliable back then than it is today. Using Loran for timing was a very rare thing outside a handful of labs. 3) To regulate it into major systems, it needs to have at least a country wide coverage and more likely a bit more than that. Without that there isn’t enough of a timing market to address. You need to retrofit it into every cell tower in the country (for instance). 4) Loran getting into buildings from a single site (even fairly close) … not so much if they are full of switching power supplies, you have a problem. You need to have *many* Loran transmitters. Cell timing is moving out of the “edge” and into the central hubs. That means buildings full of switchers. 5) Tying multiple time sources into a system costs big money. If you only have two clocks, how do you decide which one is wrong? Not an easy question to answer. That money has to come from somebody. Nobody wants to pay. The cell carriers have never been excited about investment that does not immediately result in more customers. 6) There are multiple competing “for pay” backup timing systems. Adding another one to the mix is pretty hard to justify. Even more so if you can “steal” timing off of one and not pay for it. That would be the case with an eLoran that works with all our old gear. 7) Like it or not, justified or not, cost effective (not), the world is hung up on space based systems. There is no excitement in 1950’s technology. 8) Loran for exact timing has some major issues with propagation delay. If your goal is the same as the system specs ( < 100 ns) that’s going to be a really tough nut to crack. Do they *need* < 100 ns? It’s in the spec … Will they keep studying it as long as they can get funding for the study? Of course they will. How long will people keep pitching in for that funding … could be years. Five to ten year studies that go nowhere are not at all uncommon. Right now we have multiple broadcast time sources running 24/7 at various frequencies with various coverage zones. As far as I know *none* of them are tied into major systems. That’s just the way it is, and it’s nothing new. Even in military systems, multiple time sources into a system is a very rare thing. In commercial systems … Again, I’m not arguing that this is an ideal world. Bob > There exists a solid company working on its R&D (UrsaNav), apparently increased awareness in government, and UrsaNav entered into a partnership with Spectracom for integrating its UN-152B (modern SDR-based eLORAN, Loran-C, and Chayka frequency and time transfer receiver) for GNSS fallback, which has been tested for commercial applications (e.g., NYSE), so apparently there is some commercial demand (I have been told by an engineer at Google that they are aware of this for Spanner and their other R&D projects requiring time metrology, but have not decided yet). > > -Ruslan > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.
RN
Ruslan Nabioullin
Tue, Feb 7, 2017 5:10 AM

On 02/06/2017 09:06 PM, Bob Camp wrote:

On Feb 6, 2017, at 7:38 PM, Ruslan Nabioullin
rnabioullin@gmail.com wrote:

So any ideas on how likely it will be that eLORAN becomes deployed
with at least partial US coverage within the next 5--10 years?

No, this is not the world as I would like it to be. It is the world
we live in now and are likely to live in for the foreseeable future.

Yes, from the perspective of myself and my fellow transhumanists, the
world is quite primitive in all aspects.  I yearn for the day when
singularity will take over and our primitive species is relegated to
wildlife status.  But I digress, as usual.

If we are looking at it purely as a timing reference the outlook is
not real good. Best guess about 1 in 1,000. I’m probably estimating
that on the generous side. If there is some other magic use for the
thing (or a couple dozen other uses) that might change the equation.
Right now those other uses are not very obvious.

Why the lousy outlook:

  1. The way a system like this gets funded is for it to have  a lot of
    users. It might also get funded if some crazy black project needs it.
    That’s not happening with Loran. Loran died in the first place due to
    a lack of users. 2) For a system like this to have a lot of users,
    you need to pass regulations requiring it’s use. That may seem odd,
    but that’s the way it works. Loran co-existed with GPS for a long
    time. GPS was less reliable back then than it is today.  Using
    Loran for timing was a very rare thing outside a handful of labs. 3)
    To regulate it into major systems, it needs to have at least a
    country wide coverage and more likely a bit more than that. Without
    that there isn’t enough of a timing market to address. You need to
    retrofit it into every cell tower in the country (for instance). 4)
    Loran getting into buildings from a single site (even fairly close) …
    not so much if they are full of switching power supplies, you have a
    problem. You need to have many Loran transmitters. Cell timing is
    moving out of the “edge” and into the central hubs. That means
    buildings full of switchers. 5) Tying multiple time sources into a
    system costs big money. If you only have two clocks, how do you
    decide which one is wrong? Not an easy question to answer. That money
    has to come from somebody. Nobody wants to pay. The cell carriers
    have never been excited about investment that does not immediately
    result in more customers. 6) There are multiple competing “for pay”
    backup timing systems. Adding another one to the mix is pretty hard
    to justify. Even more so if you can “steal” timing off of one and not
    pay for it. That would be the case with an eLoran that works with all
    our old gear. 7) Like it or not, justified or not, cost effective
    (not), the world is hung up on space based systems. There is no
    excitement in 1950’s technology. 8) Loran for exact timing has some
    major issues with propagation delay. If your goal is the same as the
    system specs ( < 100 ns) that’s going to be a really tough nut to
    crack. Do they need < 100 ns? It’s in the spec …

Makes sense---I was doubtful that it would be successful in non-niche
commercial areas, considering the different priorities and philosophy
(or lack thereof) in mind by the manufacturers and userbase.

Right now we have multiple broadcast time sources running 24/7 at
various frequencies with various coverage zones. As far as I know
none of them are tied into major systems. That’s just the way it
is, and it’s nothing new. Even in military systems, multiple time
sources into a system is a very rare thing. In commercial systems …

Yes, WWV/WWVH, WWVB, and CHU, within North America.  Very sad to hear
that---fusing standards and external sources of diverse characteristics
(MTBF, Allan deviation, propagation mode, sociopolitical considerations,
etc.) is the central approach of my project.

WWVB altered the signal format in '12, rendering phase locked-loop-based
receivers into metal paperweights (i.e., the remaining lab units used as
a fallback), and apparently there is no replacement nor retrofit, like a
Costas Loop (the only receiver I have found is a Meinberg USB unit,
which very well might not even work with the new format; I have in fact
submitted multiple quote requests, to no avail).  At the very least
millions of domestic and personal radio clocks use it (along with a
couple other analogs in some other parts of the world, like DCF77), not
that this approach is remotely optimal.

As for WWV/WWVH and CHU, it's quite a sad situation---I have only
counted 1--2 registered NTP servers that actually use at least one
channel, despite the fact that: 1. NTP has decoding modules built-in for
all these signals; 2. the equipment setup is typically simpler and
cheaper compared to dealing with mounting a GPS antenna on the roof and
interfacing with PPS, esp. if one uses a Chinese $6.50 incl. shipping HF
receiver off eBay; 3. it's a decent, and essentially only (not counting
CDMA---don't get me started on that!), external reference fallback to
GNSS.  I actually had this crazy idea of starting a Kickstarter campaign
to educate the masses about time transfer resiliency, and to launch a
contest that would supply good public NTP server operators with free HF
receivers.  These stations could very easily suffer the same fate as
LORAN-C under the Obama administration, unless a vocal userbase is built up.

-Ruslan

On 02/06/2017 09:06 PM, Bob Camp wrote: >> On Feb 6, 2017, at 7:38 PM, Ruslan Nabioullin >> <rnabioullin@gmail.com> wrote: >> >> So any ideas on how likely it will be that eLORAN becomes deployed >> with at least partial US coverage within the next 5--10 years? > > No, this is not the world as I would like it to be. It is the world > we live in now and are likely to live in for the foreseeable future. Yes, from the perspective of myself and my fellow transhumanists, the world is quite primitive in all aspects. I yearn for the day when singularity will take over and our primitive species is relegated to wildlife status. But I digress, as usual. > If we are looking at it purely as a timing reference the outlook is > not real good. Best guess about 1 in 1,000. I’m probably estimating > that on the generous side. If there is some other magic use for the > thing (or a couple dozen other uses) that might change the equation. > Right now those other uses are not very obvious. > > Why the lousy outlook: > > 1) The way a system like this gets funded is for it to have a lot of > users. It might also get funded if some crazy black project needs it. > That’s not happening with Loran. Loran died in the first place due to > a lack of users. 2) For a system like this to have a lot of users, > you need to pass regulations requiring it’s use. That may seem odd, > but that’s the way it works. Loran co-existed with GPS for a long > time. GPS was *less* reliable back then than it is today. Using > Loran for timing was a very rare thing outside a handful of labs. 3) > To regulate it into major systems, it needs to have at least a > country wide coverage and more likely a bit more than that. Without > that there isn’t enough of a timing market to address. You need to > retrofit it into every cell tower in the country (for instance). 4) > Loran getting into buildings from a single site (even fairly close) … > not so much if they are full of switching power supplies, you have a > problem. You need to have *many* Loran transmitters. Cell timing is > moving out of the “edge” and into the central hubs. That means > buildings full of switchers. 5) Tying multiple time sources into a > system costs big money. If you only have two clocks, how do you > decide which one is wrong? Not an easy question to answer. That money > has to come from somebody. Nobody wants to pay. The cell carriers > have never been excited about investment that does not immediately > result in more customers. 6) There are multiple competing “for pay” > backup timing systems. Adding another one to the mix is pretty hard > to justify. Even more so if you can “steal” timing off of one and not > pay for it. That would be the case with an eLoran that works with all > our old gear. 7) Like it or not, justified or not, cost effective > (not), the world is hung up on space based systems. There is no > excitement in 1950’s technology. 8) Loran for exact timing has some > major issues with propagation delay. If your goal is the same as the > system specs ( < 100 ns) that’s going to be a really tough nut to > crack. Do they *need* < 100 ns? It’s in the spec … Makes sense---I was doubtful that it would be successful in non-niche commercial areas, considering the different priorities and philosophy (or lack thereof) in mind by the manufacturers and userbase. > Right now we have multiple broadcast time sources running 24/7 at > various frequencies with various coverage zones. As far as I know > *none* of them are tied into major systems. That’s just the way it > is, and it’s nothing new. Even in military systems, multiple time > sources into a system is a very rare thing. In commercial systems … Yes, WWV/WWVH, WWVB, and CHU, within North America. Very sad to hear that---fusing standards and external sources of diverse characteristics (MTBF, Allan deviation, propagation mode, sociopolitical considerations, etc.) is the central approach of my project. WWVB altered the signal format in '12, rendering phase locked-loop-based receivers into metal paperweights (i.e., the remaining lab units used as a fallback), and apparently there is no replacement nor retrofit, like a Costas Loop (the only receiver I have found is a Meinberg USB unit, which very well might not even work with the new format; I have in fact submitted multiple quote requests, to no avail). At the very least millions of domestic and personal radio clocks use it (along with a couple other analogs in some other parts of the world, like DCF77), not that this approach is remotely optimal. As for WWV/WWVH and CHU, it's quite a sad situation---I have only counted 1--2 registered NTP servers that actually use at least one channel, despite the fact that: 1. NTP has decoding modules built-in for all these signals; 2. the equipment setup is typically simpler and cheaper compared to dealing with mounting a GPS antenna on the roof and interfacing with PPS, esp. if one uses a Chinese $6.50 incl. shipping HF receiver off eBay; 3. it's a decent, and essentially only (not counting CDMA---don't get me started on that!), external reference fallback to GNSS. I actually had this crazy idea of starting a Kickstarter campaign to educate the masses about time transfer resiliency, and to launch a contest that would supply good public NTP server operators with free HF receivers. These stations could very easily suffer the same fate as LORAN-C under the Obama administration, unless a vocal userbase is built up. -Ruslan
BC
Bob Camp
Wed, Feb 8, 2017 2:38 AM

Hi

A very practical contribution one could make would be to enhance the drivers
for the radio based systems. Propagation is a big deal with any of the radio
setups. Loran is no exception to that. Teaching the NTP drivers when not to
use the data and how to compare data is a do-able thing. It’s just that nobody
has ever bothered to do it. Coming up with some simple to use tools to estimate
the errors and config them in is likely the only practical way to do it.

Bob

On Feb 7, 2017, at 12:10 AM, Ruslan Nabioullin rnabioullin@gmail.com wrote:

On 02/06/2017 09:06 PM, Bob Camp wrote:

On Feb 6, 2017, at 7:38 PM, Ruslan Nabioullin

Hi A very practical contribution one *could* make would be to enhance the drivers for the radio based systems. Propagation is a big deal with any of the radio setups. Loran is no exception to that. Teaching the NTP drivers when not to use the data and how to compare data is a do-able thing. It’s just that nobody has ever bothered to do it. Coming up with some simple to use tools to estimate the errors and config them in is likely the only practical way to do it. Bob > On Feb 7, 2017, at 12:10 AM, Ruslan Nabioullin <rnabioullin@gmail.com> wrote: > > On 02/06/2017 09:06 PM, Bob Camp wrote: >>> On Feb 6, 2017, at 7:38 PM, Ruslan Nabioullin
GE
Gary E. Miller
Wed, Feb 8, 2017 4:17 AM

Yo Bob!

On Tue, 7 Feb 2017 21:38:52 -0500
Bob Camp kb8tq@n1k.org wrote:

Teaching
the NTP drivers when not to use the data and how to compare data is a
do-able thing.  It’s just that nobody has ever bothered to do it.

The NTPsec team would love to work with anyone that has a device
that could use an improved NTP driver.

Coming up with some simple to use tools to estimate the errors and
config them in is likely the only practical way to do it.

NTPsec has done a lot of recent work on tools.  We are open to any
suggestions or requests that people may make.

RGDS
GARY

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com  Tel:+1 541 382 8588

    Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
Yo Bob! On Tue, 7 Feb 2017 21:38:52 -0500 Bob Camp <kb8tq@n1k.org> wrote: > Teaching > the NTP drivers when not to use the data and how to compare data is a > do-able thing. It’s just that nobody has ever bothered to do it. The NTPsec team would love to work with anyone that has a device that could use an improved NTP driver. > Coming up with some simple to use tools to estimate the errors and > config them in is likely the only practical way to do it. NTPsec has done a lot of recent work on tools. We are open to any suggestions or requests that people may make. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin
BC
Bob Camp
Wed, Feb 8, 2017 11:55 AM

Hi

P

On Feb 7, 2017, at 11:17 PM, Gary E. Miller gem@rellim.com wrote:

Yo Bob!

On Tue, 7 Feb 2017 21:38:52 -0500
Bob Camp kb8tq@n1k.org wrote:

Teaching
the NTP drivers when not to use the data and how to compare data is a
do-able thing.  It’s just that nobody has ever bothered to do it.

The NTPsec team would love to work with anyone that has a device
that could use an improved NTP driver.

I have absolutely no doubt of that.The issue is not being able to do
the driver and get it accepted. The issue is that there is …errr …
work involved. :)

Bob

Coming up with some simple to use tools to estimate the errors and
config them in is likely the only practical way to do it.

NTPsec has done a lot of recent work on tools.  We are open to any
suggestions or requests that people may make.

RGDS
GARY

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com  Tel:+1 541 382 8588

    Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Hi P > On Feb 7, 2017, at 11:17 PM, Gary E. Miller <gem@rellim.com> wrote: > > Yo Bob! > > On Tue, 7 Feb 2017 21:38:52 -0500 > Bob Camp <kb8tq@n1k.org> wrote: > >> Teaching >> the NTP drivers when not to use the data and how to compare data is a >> do-able thing. It’s just that nobody has ever bothered to do it. > > The NTPsec team would love to work with anyone that has a device > that could use an improved NTP driver. I have absolutely no doubt of that.The issue is not being *able* to do the driver and get it accepted. The issue is that there is …errr … work involved. :) Bob > >> Coming up with some simple to use tools to estimate the errors and >> config them in is likely the only practical way to do it. > > NTPsec has done a lot of recent work on tools. We are open to any > suggestions or requests that people may make. > > RGDS > GARY > --------------------------------------------------------------------------- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > gem@rellim.com Tel:+1 541 382 8588 > > Veritas liberabit vos. -- Quid est veritas? > "If you can’t measure it, you can’t improve it." - Lord Kelvin > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.