>> 2 (or more) Loran-C stations gave you more accurate time. But if you
>> know where you are, and since the stations don't move, you can
>> manually adjust for signal propagation delay to some extent. This is
>> not unlike how one obtains time from WWV or WWVB.
>
> One of the big issues with LORAN C, I thought, was that those
> variations were measured in microseconds...
Right, the variations are huge compared to GPS. Microseconds (Loran),
even milliseconds (WWV*). So that's why when people talk about a "source
of UTC" the accuracy should be specified. Otherwise a even wristwatch or
sundial could be considered a source of UTC.
> But I guess those average out over time so if you have a stable local
> oscillator you can recover time fairly well.
Before Loran-C was canceled and before the WWVB format was "enhanced"
there were a number of disciplined time & frequency products that did
just that. Stuff from Austron, Spectracom, and SRS. Some of us time nuts
have this gear.
> Fun fact, LORAN has no leap seconds (since it is just a bunch of
> different rates). So to calculate time of coincidences with UTC you
> had to basically use TAI - 10s since the LORAN signal is paced with
> SI seconds. When I was working on the replacement timing system for
> the LORAN chains, this was a big deal since to start LORAN you needed
> to know both the UTC time and a recent / near future table of leap
> seconds... This leads to a lot of edge cases, especially when you
> needed to cope with the cold spare GPS reciever case. :(. It's also
> where all the love I feel for leap seconds left my body...
Yes, exactly. BTW, Loran TOC (for the 9940 chain) is available here:
http://leapsecond.com/java/gpsclock.htm
USNO used to publish Loran-C TOC tables for all the chains on their web
site. Last year most of their user-facing pages went away.
/tvb
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
