[time-nuts] Can eloran Backup GPS?

Sat Sep 8 21:55:39 UTC 2018

Hi

Yup, and over something the size of a harbor, that works ok. It was done with the “old” 
Loran in a similar fashion and a couple of other ways as well.  Expanding any of  it to 
cover a country is a very different thing …..

I spent a lot of years trying to sell the designers of these systems on backup solutions. 
Not because I’m some kind of end of the world type. I figured selling them four boxes for
every tower was at least twice as good as selling them two boxes. I was far from the only
one making that pitch. None of us got a bite in 30 years of trying ….

Bob

> On Sep 8, 2018, at 5:16 PM, Bob Martin <aphid1 at comcast.net> wrote:
> 
> Bob,
> 
> That seems pretty conclusive to me but wait there's more..
> 
> By adding a letter to the name they are attempting to address the very issue you've raised.
> 
> https://rntfnd.org/wp-content/uploads/eDLoran-Reelektronica-Paper.pdf
> 
> I'm sure after a few more prefix letters are added to Loran it will work for everyone!
> 
> Time for a new house to flip or dead horse to flog,
> 
> Bob Martin
> 
> 
> 
> 
> 
> On 9/8/2018 2:44 PM, Bob kb8tq wrote:
>> 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.
>> _______________________________________________
>> 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.