[time-nuts] Can eloran Backup GPS?

Sat Sep 8 20:44:11 UTC 2018

Hi

The differential approach to eLoran involves running two local receivers. You look at the time of arrival on one
and use it to “calibrate" the time of arrival on the other. Put another way - you look at the difference between the 
two arrival times. They can both “wander” over a 250 ns range, as long as they stay within 50 ns of each other 
they meet the “differential spec”. 

For disciplining a local reference, you really need an absolute number. The fact that both are wandering over a 
pretty big range *does* matter if you are looking at a stable local source (and trying to make it more stable).  What
would / does work is having a very accurate standard at one of the locations and using the difference measure
to “distribute” that source. That gets into bandwidth. 

Since the difference information is *very* local, there really isn’t a practical way to distribute it on the eLoran signal.
As you pile on more correction stations, your data bandwidth goes up. There are a very limited number of bits
available on the eLoran signal. 

Another way to look at it: If you have a standard sitting in your basement, and don’t have a buddy in town with a 
better standard. Does a difference measure to his house do you any good?

Bob

> On Sep 8, 2018, at 2:58 PM, Bob Martin <aphid1 at comcast.net> wrote:
> 
> Bob,
> 
> I believe that information is transmitted with the eloran signal. Way back when, I remember there was an added pulse called the LDC pulse. I had to modify that pulse with each transmission based on
> an input to the transmit timing unit from the computer.
> 
> I found the following on it:
> http://www-personal.umich.edu/~tmikulsk/loran/ref/eloran_ldc.pdf
> 
> Also, the article referenced previously on The Great Britain
> system mentions that the differential corrections are sent on the LDC pulse.
> 
> To be honest, I don't know if this addresses your "gotcha".
> 
> Best,
> 
> Bob Martin
> 
> On 9/8/2018 12:38 PM, Bob kb8tq wrote:
>> Hi
>> The gotcha is the differential corrections. That’s not the way these systems are set up to work. They
>> function with no external input other than the timing signal its self. Providing bandwidth to do correction
>> signaling just isn’t part of the overall system design.  If you wanted to use bandwidth, you would go
>> with 1588. Then you have a backup and no fiddling with anything else.
>> Indeed with an area wide 1588, you can do it all without even a GPS primary. Simply agree on a
>> “something” as the master source. The man with one watch *always* knows what time it is ….
>> The 250 ns "without correction" is the number that directly compares to the ~10 ns number for GPS.
>> Stretch out the distances to “USA” sort of stuff and it does not improve things at all.
>> Bob
>>> On Sep 8, 2018, at 1:40 PM, Bob Martin <aphid1 at comcast.net> wrote:
>>> 
>>> Bob,
>>> 
>>> I agree that eloran needs to be analyzed with regard to it's
>>> usefulness for each potential application. You are also 100% correct that timing requirements get tighter and tighter as technology advances.  In some ways the question isn't whether eloran can
>>> match GPS but rather would it suffice in a pinch were GPS to go down?
>>> 
>>> I think the 50ns accuracy is actually "as received" not "as transmitted".
>>> 
>>> The link below is an analysis of eloran in Great Britain. The receiver/transmitter distance was  300 miles.
>>> 
>>> http://www.ursanav.com/wp-content/uploads/On-the-Uses-of-High-Accuracy-eLoran-Time-Frequency-and-Phase-2015.pdf
>>> 
>>> I've attached a screen capture of one of the pages that compares
>>> eloran  with GPS in case anyone is interested. This is where it
>>> appears that the 50ns is received as opposed to at the transmitter.
>>> 
>>> 
>>> 
>>> Best,
>>> 
>>> Bob Martin
>>> 
>>> On 9/8/2018 9:35 AM, Bob kb8tq wrote:
>>>> Hi
>>>> I believe the 50 ns is the “as transmitted” signal from the tower. The “as received” signal after going
>>>> through all the various gyrations is not that good on a  ~1 second basis.
>>>> ====
>>>> One of the gotchas here is that we lump “systems” into one giant bag. That’s not a good way
>>>> to analyze things. One system may be quite happy with 10 ms timing another may be happy
>>>> with 10 us and yet another may die completely at 1 us and only run right at 100 ns. All of that
>>>> is on a 2 second basis for CDMA (they time every other second).
>>>> By far the biggest / baddest / most venerable system out the that uses GPS timing is the
>>>> cell tower system. They started out back in the 80’s with a 10us max timing / 1 us running
>>>> spec on CDMA. AFIK they were the first major system to adopt GPS time as their reference
>>>> (rather than UTC).
>>>> This worked out fine for a few decades while companies got a lot of towers built. People started
>>>> using those systems and they became congested. Others started streaming video over them
>>>> and they ran out of bandwidth. Upgrades followed. There have been a lot of them. Much of what
>>>> we TimeNuts buy on the surplus market comes to us as a result of older systems being scrapped
>>>> out.
>>>> The latest set of upgrades does / will / is getting them into the sub 1 us range at the end of holdover.
>>>> In normal operation they are spec’d at 100 ns worst case. To do that, you need a timing source in
>>>> the roughly 10 ns range. No you don’t see those GPSDO’s on the surplus market. You will see
>>>> them someday ….
>>>> Again, they went this way a decade ago. Rolling that all back …. not at all easy.
>>>> Are there other systems that have issues with sync? Of course there are. There also are a lot
>>>> of instances where miss-configuration ( or junk implementation) is a much bigger issue. Sorting
>>>> that all out requires a deep dive into the timing of each individual system / implementation.  No
>>>> two systems do things quite the same way. Unless you want to deal with the numbers and the
>>>> implementation details, simply moaning and groaning isn’t going anywhere.
>>>> Bob
>>>>> On Sep 8, 2018, at 3:23 AM, Hal Murray <hmurray at megapathdsl.net> wrote:
>>>>> 
>>>>> 
>>>>> kb8tq at n1k.org said:
>>>>>> You are not trying to run a cell system when checking your local oscillator
>>>>>> against LORAN.
>>>>> 
>>>>> The eLoran committee said 50 ns.  Is that good enough for cell towers?
>>>>> 
>>>>> Too bad it isn't up so we could collect some data.
>>>>> 
>>>>> 
>>>>> -- 
>>>>> These are my opinions.  I hate spam.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> time-nuts mailing list -- time-nuts at lists.febo.com
>>>>> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
>>>>> and follow the instructions there.
>>>> _______________________________________________
>>>> time-nuts mailing list -- time-nuts at lists.febo.com
>>>> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
>>>> and follow the instructions there.
>>> <Capture.JPG>_______________________________________________
>>> time-nuts mailing list -- time-nuts at lists.febo.com
>>> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
>>> and follow the instructions there.
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at lists.febo.com
>> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
>> and follow the instructions there.
> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.