[time-nuts] Can eloran Backup GPS?
aphid1 at comcast.net
Sat Sep 8 13:40:48 EDT 2018
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
The link below is an analysis of eloran in Great Britain. The
receiver/transmitter distance was 300 miles.
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.
On 9/8/2018 9:35 AM, Bob kb8tq wrote:
> 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
> 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.
>> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 164180 bytes
Desc: not available
More information about the time-nuts