Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

LF: Re: RE: reception with multiple antennas

To: [email protected]
Subject: LF: Re: RE: reception with multiple antennas
From: "Stewart Nelson" <[email protected]>
Date: Wed, 25 May 2005 00:00:03 -0700
Delivery-date: Wed, 25 May 2005 08:02:16 +0100
Envelope-to: [email protected]
References: <000001c5605f$4a951110$e6a4c593@RD40002>
Reply-to: [email protected]
Sender: [email protected]
Hi Jim and all,

I guess for an initial feasibility study it would only be necessary
for a number of stations to simultaneously make recordings under
defined conditions, and then the data could be up-loaded and
post-processed at leisure.

Because the files will be quite large, I'll set up an FTP account
for the purpose, and email the login info to the participants.
As a start, we might record 8-bit, 11025 Hz sampling, 135.500 kHz USB,
SSB bandwidth, about half an hour, at a time when it's likely for
DX QRSS to be visible.  I'm open for suggestions to change any of
the above parameters.
I presume you would have to initially synchronise the recordings
to within a GRI period for the signals to be combined in this way
would this require some external timing signal, or is it possible
to obtain that info from the Loran signals?

You can obtain some timing information from LORAN.  The signals are
synchronized with UTC.  For example, consider the signal from
Lessay.  Conceptually, the first master pulse group on 6731 was
emitted on 01/01/1958 at 00:00:00, and its first slave pulse on 7499
14100 microseconds later.  But for the next pulse group pairs, the
difference was 14100 + 2 * 10 * (7499 - 6731).  Now, the LCM of 2*6731
and 2*7499 is 100951538, so the cycle repeats every 1009.5154 seconds.
In theory, if you know what time it is, within +/- 500 seconds, you
could tell the exact time just by looking at Lessay.  By including
signals from other chains, you could tell the date and time without
any prior information.  One could even write a program that would
analyze a .wav file and tell what frequency was tuned, what time the
recording was made, and of course where the receiver was located.

In practice, this is not only quite complex, but also very difficult,
because the time difference between 6731 and 7499 can be any multiple
of 20 microseconds.  To distinguish them reliably, we would need to
measure the difference within +/- 10 us, requiring each measurement
to be accurate to +/- 5 us.  A real LORAN receiver can do that easily,
but when we are limited to SSB bandwidth, getting distorted splatter
signals, and sampling audio every 91 us, it would be very difficult.
So, I'll require that the operator identify the start time of each
recording, with an accuracy of +/- 10 seconds.  Then, the program
need only distinguish time differences that are at least 880 us apart.

how would you compensate for variations in gain between different
receiving stations?

I'd calibrate by using the strength of the reference LORAN signal.
Unfortunately, this is subject to error from skywave interference.
A real LORAN Rx can eliminate skywave by looking at just the first
few cycles of the pulse, but that would be nearly impossible for us,
for the reasons cited above.  Of course, if the stations are quite
close together, the skywave signals should be similar.  If not, we
could fix the gain using daytime calibration data.  If that is also
unworkable, because the Rx gain is unstable, I don't have a good
answer.

how would you deal with variations of phase response within the
passbands of different stations?

That's a serious problem -- Joe Taylor gave up on coherent detection
for JT65, largely because of the horrible group delay characteristics
of the typical ham transceiver.  The S/N of the average LORAN line
in Markus' recording (10 mHz BW) is about 10 dB.  I believe that
gating the input with a window for the desired station will improve
that by at least 3 dB.  There are about 682 lines in 2400 Hz passband.
If we compute the phase of each of those lines, and apply a little
smoothing, we should have a quite accurate picture of the phase
response.

That's the good news.  The bad news is that there may be random
phase errors caused by inability to lock onto a specific cycle.
I'm still working on that.

73,

Stewart KK7KA


<Prev in Thread] Current Thread [Next in Thread>