Content-Transfer-Encoding: 8bit
Message-ID: <65AECDF1F89AD411900400508BFC869F9C0454@pdw-mail-1.dera.gov.uk>
From: "Talbot Andrew" <ACTALBOT@dera.gov.uk>
To: "LF Group \(E-mail\)" <rsgb_lf_group@blacksheep.org>
Subject: LF: Propagation monitoring and LORAN
Date: Tue, 24 Apr 2001 11:20:17 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Sender: <majordom@post.thorcom.com>

May recall a discussion about using Loran for propagation monitoringon
this reflector a couple of months ago which I then forwarded to G3PLX.
He seems to have started looking at this method of propagation
monitoring in some detail now.     See attached.
Andy  G4JNT
----------------------------------------------------------------

-----Original Message-----
From: Peter Martinez [mailto:Peter.Martinez@btinternet.com]
Sent: 2001-04-14 10:27
To: Talbot Andrew
Subject: Re: FW: Comports and Delphi


Andy:

Just thought I would give you an interim report on the LORAN project.
I have a working system now, after quite a bit of work and some
useful help from Stewart Nelson. At the moment the program runs on my
56001 card with the PC software under DOS but the next step is to
move it over to the soundcard and Windows.

The present system uses a conventional SSB receiver tuned 1.7 kHz off
100 kHz so that the LORAN signal appears at 1700Hz in the audio band.
Only the signal 1 kHz either side of 100kHz is processed, so the
resolution and the sensititivity are limited.  The program contains a
database of LORAN stations worldwide, and needs to know the user's
latitude and longitude within 1 degree and the date/time to an
accuracy of a few seconds. With this information, the program looks
for the nearest LORAN chain, which in my case is the Lessay chain,
and identifies the master station, locking it's own oscillator
frequency to that of the signal and synchronising it's clock to the
repetition rate. By using the signal from the second-most-local chain
(in my case the Sylt chain), the program can resolve any ambiguity in
the timing. Without this the program would need to know the precise
time to within +/- one repetition cycle of 67mS, which is not easy.
Using two chains, the system can lock even if the PC clock is several
tens of secs out. It would be possible to use some other external
time reference, such as MSF, DCF77, or WWV, to resolve the ambiguity
if only one LORAN chain was audible locally. I haven't done this yet.
The most interesting part of the research needed to write the
time-synchronisation code was the part where I had to calculate the
precise number of cycles of the 100kHz LORAN carrier frequency that
had occurred between midnight on 31st December 1957 and the time I
start the program! This has to take account of leap years and leap
seconds during this time, and is needed in order to set all the
repetition-cycle counters to the correct values, since they were all
notionally "zeroed" on this date and will never be in step again for
the foreseeable future.

Having locked in frequency and time to the local chain, there is no
further sensitivity to drift of the local oscillators, and the
program can then be used to look for the signals from any other known
LORAN chain right down into the noise. At the moment I have made it
coherently integrate up to about half an hour and retains the last 30
minutes of history thereafter. I haven't found this to be too long:
if the skywave signals were too unstable, I would have seen the
signal level rise to a peak soon after zeroing the integrator then
fall back down into the noise. There is no sign of this effect even
on the more distant signals. In any case, I would expect only local
skywave signals to exhibit large variations, with the more distant
ones being less disturbed in phase by sunrise/sunset effects. Because
the program knows it's own location and synchronises to absolute time
via the local LORAN signal, and all the other LORAN transmitters are
also synchronised in time, it should be possible to predict precisely
the arrival time of each signal. Each pulse seen on the screen should
be identifiable from the database. However, I have seen three chains
which are not well aligned to absolute time (West Russia, Saudi
Arabia North, and Saudi Arabia South). The time-offsets of these
chains, if they are stable, could be included in the database but at
the moment, looking at these signals means they are off to one side
of the display or the other by a few tens of mS. Incidently, a
by-product of locking to LORAN in this way is that the system
provides an accurate time-signal, limited only by the uncertainty in
the delay through the IF filter of the LORAN receiver.

I am seeing East Coast USA/Canada LORAN signals, notably Fox Harbor
(18dB SNR) and Cape Race in Newfoundland, with Comfort Cove, Caribou,
and Nantucket also occassionaly visible at night. In the other
direction, the Saudi Arabian chains and Russian signals up to 40E are
visible.

Porting the program to the soundcard would make it more readily
available to others, but I may not be able to do a good job of this
myself because my PC is not fast enough. It would help if another
programmer with Win 9X and a decent Pentium were to pick up this
project rather than me. Using a narrowband SSB receiver is not an
ideal way to monitor LORAN but there is the interesting possibility
of building a simple direct-conversion receiver, perhaps with
quadrature mixers. This, with a fast PC, would be capable of
demodulating the full +/- 10kHz LORAN spectrum. Contrary to
conventional weak-signal experience, the sensitivity will be rather
better with a wider bandwidth and the time resolution will also be
much improved, to the extent that separate pulses for surface waves
and skywaves should be visible on many signals. I propose to
experiment with this approach myself in order to verify that this
idea will work. I am not sure, for example, whether the lack of a DC
path through the soundcard will be a problem. I also propose to lock
the oscillator in the direct-conversion receiver back to a tone
output from the soundcard itself. This in turn makes it possible to
reference the software timing to the received 100kHz RF phase rather
than just to the received pulse envelope. This eliminates a further
source of drift/error and opens up interesting possibilities for
studying received signal phase and for truly coherent transmission
and reception of other signals using LORAN as a common reference for
time and frequency.

Pass this on to the LF group if you think they might be interested.

73
Peter


-- 
The Information contained in this E-Mail and any subsequent correspondence
is private and is intended solely for the intended recipient(s).
For those other than the recipient any disclosure, copying, distribution, 
or any action taken or omitted to be taken in reliance on such information is
prohibited and may be unlawful.