[Fwd: LF: Amtor FEC on LF]

[Andre Kesteloot]

Andy talbot wrote:

> 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