[time-nuts] Re: Eloran long test from now to August or September.

[paul swed]

Poul
You just explained something to me on LORAN C. This occurred many years
ago. A fellow out of Italy asked if I could create a system to deal with an
additional delay number for an old Austron 2000 receiver. I had done
something with my 2000. Anyhow I coded up the processor and sent him the
code. But I fear I did not understand NELS. Just maybe the solution was not
correct. Who knows it was a lot of years ago.
No luck last night on the austron 2100F at least the 2100 did go to settle
overnight on Saturday.
Regards
Paul
WB8TSL


On Mon, Sep 18, 2023 at 2:50 AM Poul-Henning Kamp <phk at phk.freebsd.dk>
wrote:

> > Interesting observation:  The Austron 2100F stays locked even
> > with all my local noise sources turned on and the LORAN pulse being
> > obscured (on the scope) by noise pulses.
>
> That is by design.
>
> Back when LORAN-C was designed, the VLF spectrum was considerbly
> more crowded by non-random RFI than today.
>
> Although they didnt call it that at the time, the combination of
> the GRI, pulse-shape and polarity coding makes LORAN-C a spread-spectrum
> signal.
>
> With the exception of badly chosen XX00 GRI's there are literally
> no man-made noise sources which survive the de-spreading operation.
>
> The European "NELS" switch to four-digit prime-number GRI's were
> made to make it even more robust, unfortunately that also made
> European Loran-C robust against any users with existing receivers.
>
> The one minor flaw in the design of the Loran-C signal is that
> the master signal pulses are not balanced, so only the slave
> signal have the deep null at precisely 100kHz.
>
> See:
>
>         http://phk.freebsd.dk/loran-c/theoretical_spectrum/
>
>
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>