Message-ID: <01C22819.F66D8020.g4jnt@thersgb.net>
From: "Andy talbot" <g4jnt@thersgb.net>
To: rsgb_lf_group@blacksheep.org
Subject: RE: LF: Amtor FEC on LF
Date: Wed, 10 Jul 2002 13:58:39 +0100
Importance: high
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Sender: <majordom@post.thorcom.com>

OK then, so we need a waveform that is immune to high level broadband spikes. 
 Narrow filtering will remove the spike energy, but in turn will spread it out 
over the period of the filter response so won't help greatly with arbitrarily 
low bandwidth signalling.  So some data repetition or convolution is called for 
to get the basic link operational before we start adding error correction by 
repeats.  ARQ can only make a mediocre link good; not a poor or non-existant 
one into a mediocre link.

What hapenned to WOLF ?   That had very heavy convolution and repetition and 
would solve the problem very effectively by coding.

It ought to be easy to take out the noise pulses in DSP.   If these really are 
sharp spikes, then an algorithm similar to that used for cleaning up old vinyl 
recordings (frequently set as a university third year project a couple of 
decades ago) would clip the spikes before any narrow band filtering and 
demodulation spread them out.   Examine at the signal in the time domain (the 
raw samples from the A/D), and look for a sharp rise in energy,  ie. a peak in 
sucessive samples.  When a peak above a certain threshold is detected, either 
clip it, or replace by an interpolated version of adjacent ones.  It will now 
help to be receiving and digitising in as wide a bandwidth as possible, so the 
spike affects relatively less sample periods.

Andy  G4JNT


-----Original Message-----
From:	James Moritz [SMTP:j.r.moritz@herts.ac.uk]
Sent:	2002/07/10 12:29
To:	rsgb_lf_group@blacksheep.org
Subject:	RE: LF: Amtor FEC on LF

Dear Andy, LF Group,

At 08:52 10/07/2002 +0100, you wrote:
>137k, on the other hand is characterised by a much more constant noise
>background and does not behave like HF divided by ten -  if fading is
>present,
>it covers a much longer period of tens of minutes or hours

This is true under quiet winter-time conditions, but these are in the
minority - the rest of the time, a large proportion of the total noise
power is in the form of QRN spikes. If you look at an RX IF output on a
scope under noisy band conditions, you see a fairly low background level
with much larger spikes - the noisier the conditions, the greater the rate
of spikes occuring. The spikes are 10s of dB larger than the background
level, and usually overload the receiver for the duration of the spike - if
you manually reduce the IF gain, the background noise gets smaller, but the
peak amplitude of the spikes on the scope stays much the same. When you use
PSK31under weak signal conditions, the effect is that each time there is a
spike, a character is corrupted, which matters little if there is only 1
spike every few seconds, but when the noise is clattering away like it is
at the moment, the signal will probably be unreadable even if it is well
above the background noise level. So while PSK31 is good under quiet LF
conditions (and "PSK08" better still), I don't think it is the optimum mode
for typically noisy LF conditions.

Some sort of error correction would seem to be a good idea, since the data
bits between the noise spikes will be uncorrupted, so a fairly large
proportion of the data will be received OK - I have not tried the QPSK
variant of PSK31 due to lack of suitable TX hardware, But I recall VE2IQ's
"Coherent", which does include error correction, worked well under noisy LF
conditions. This is actually very flexible software - the only real
drawback of this is that it requires a computer running DOS, and some
external hardware. Oh, and as with other PSK modes it requires TX envelope
shaping - but there is the "variable phase" modulation technique which
could help there.

Since the spikes are of short duration, another approach might be to use a
hardware or software noise blanker in conjunction with a low baud rate so
that each bit was much longer than the noise impulse. This would require an
RX IF bandwidth much larger than the bandwidth of the signal for the
blanker to work effectively, but still narrow enough to eliminate adjacent
channel QRM like DCF39 which would cause dynamic range problems - but with
8 or 10 bauds this should not be a problem.

Cheers, Jim Moritz
73 de M0BMU