Quoting Warner Losh <i...@bsdimp.com>:
On 02/23/2011 05:57, Richard B. Langley wrote:
For those who might not be aware. Loran-C in North America is dead.
It might be resurrected as eLoran or some other LF service in the
future:
http://www.ursanav.com/sites/default/themes/danland/images/buzz/pdfs/LF-Solutions-for-APNT-ION2011.pdf
Well, eLoran was implemented in the North American chain a couple of
years before they started to shut it off. Given that the stations
have been decommissioned and the towers blown up in at least some
places, I doubt it will ever resurrect.
The decision to terminate Loran-C in North America, leaving GPS
without an effective backup there, was extensively covered in GPS
World. eLoran was initiated but not completed. I had an article in my
column about GPS plus eLoran before Loran-C got the chop:
<http://www.gpsworld.com/transportation/road/innovation-gps-loran-c-6550>.
-- Richard
But the requirements of that system, and how they interacted with
other requirements when coupled with inflexible military bureaucracy
shows that there's a wide diversity of requirements for some problem
domains that you don't run into with a server in a computing center.
Warner
-- Richard
Quoting Ian Batten <i...@batten.eu.org>:
Nope. tried that when getting the spec approved. Approximate
times weren't allowed. UTC times were required. There was no
way to indicate approximate time in the user interfaces present
(how do you blink a 5071A anyway :). The other systems that
interfaced to ours had a fixed format, and required UTC and not
approximate UTC for a while and then a possible jump in time to
actual UTC.
Well, if the use-case is navigation (Loran, military) then UTC
sans leap seconds isn't much use to you anyway, so the "solution"
of dropping them would take your requirement with it, and you'd
seen something closer to UT1. And of course, requirements are
simply line items on an invoice, and if deriving immediate UTC
costs 10X rather than X, the customer has to make a decision on
whether they're prepared to pay for it. Just saying "my customer
demands X and therefore the rest of you need to enable X" isn't
realistic.
ian
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
----------------------------------------------------------------------------- | Richard B. Langley E-mail: l...@unb.ca
|
| Geodetic Research Laboratory Web:
http://www.unb.ca/GGE/ |
| Dept. of Geodesy and Geomatics Engineering Phone: +1 506
453-5142 |
| University of New Brunswick Fax: +1 506
453-4943 |
| Fredericton, N.B., Canada E3B 5A3
|
| Fredericton? Where's that? See:
http://www.fredericton.ca/ |
-----------------------------------------------------------------------------
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
-----------------------------------------------------------------------------
| Richard B. Langley E-mail: l...@unb.ca |
| Geodetic Research Laboratory Web: http://www.unb.ca/GGE/ |
| Dept. of Geodesy and Geomatics Engineering Phone: +1 506 453-5142 |
| University of New Brunswick Fax: +1 506 453-4943 |
| Fredericton, N.B., Canada E3B 5A3 |
| Fredericton? Where's that? See: http://www.fredericton.ca/ |
-----------------------------------------------------------------------------
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
