Message-ID: <002501c0c829$01279700$0700000a@parissn2>
From: "Stewart Nelson" <sn@scgroup.com>
To: rsgb_lf_group@blacksheep.org
References: <63.14878f3e.28088e1e@aol.com> <003e01c0c53a$29315d90$0700000a@parissn2> <005301c0c614$19889180$0301a8c0@steve> <007f01c0c683$5af3b3b0$0700000a@parissn2> <004d01c0c6bf$6afea3a0$0301a8c0@steve>
Subject: LF: Re: Re: [TECH] WOLF, FDK, AFK, etc.
Date: Wed, 18 Apr 2001 18:59:54 +0200
Organization: SC Group
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Sender: <majordom@post.thorcom.com>

Hi Steve and all,

> FDK is only similar to
> BPSK in terms of a possible way it can be generated.   Its spectrum over a
> 60 second epoch (the initial character duration for now) looks identical to
> a two tone SSB test signal (assuming linear) and bears no resemblance to
> BPSK.

That's only because of your choice of parameters.  Consider a BPSK system,
with an XOR gate modulator, which can send one of six messages 'A' through 'F'.
A trivial code might be A=000, B=001, C=010, D=011, E=100, F=101.
Assume that eight repetitions of the message are sent, at 24 bps, so the total
transmission takes 1 second.

For example, 'B' would be sent as 001001001001001001001001.  If hard decisions
are used, we can only 'correct' for three bit errors, and detect four.  If
we received e.g. 101001101101001101101001 (five bits in error) we would
incorrectly copy an 'F'.

Now let's add some error correction by using the following code:
A 000000000000111111111111
B 000000111111000000111111
C 000011110000111100001111
D 000111000111000111000111
E 001100110011001100110011
F 010101010101010101010101

In the new code, every message differs in 12 bits from every other, so copy
is always correct with five or fewer bit errors.  We can now detect
a six bit error, and incorrect copy results only when seven or more bits
are wrong.  Tracking is also improved, because the receiver can expect
that the first bit is always '0' and the last is always '1'.

But, as you have probably already figured out, this is FDK.  The code is:
A +/- 1 Hz
B +/- 2 Hz
C +/- 3 Hz
D +/- 4 Hz
E +/- 6 Hz
F +/- 12 Hz

The spectrum and the performance of both 'systems' are identical, because
it's just two ways of talking about the same thing!  Of course, PSK and FDK
can have parameters that make them look very different.  But, IMO, for a
given data rate and a given bandwidth, the settings that provide the most
robust transmission result in very similar spectra and performance because:

> > If [the set of symbols used for FDK is] large, e.g. a pair for each
> > letter of the alphabet, I don't see a
> > good way to track the signal when it is very weak.

In most well designed systems, if the signal is strong, there is a direct
relation between signal power and speed: you can accommodate a 3 dB reduction
in Tx power by taking twice as long to send your message.  But once the
time to convey one bit (in the Shannon sense) exceeds the limit imposed by
path and/or equipment stability, the best you can hope for is taking four
times longer for each 3 dB reduction.  Essentially, you must transition from
coherent to noncoherent integration.  QRSS and PUA43 are examples of systems
which can perform well in that region.  In theory, WOLF could also, but time
synchronization of the stations would be required.  Since the present WOLF
has neither a real-time mode, nor a command line parameter to specify a time
offset, it doesn't work.  But that could fairly easily be fixed.

Now, you must realize that if you are using soft decisions with a powerful
ECC and/or with many repetitions of the message, you can get good copy even
when many received symbols are in error.  And, if symbols are chosen from
a large set, good copy is possible when most, perhaps a great majority,
of the received symbols are wrong!  As I understand FDK, whenever the pair
of FFT bins with the highest energy is not those for the symbol actually
sent, the tracking signal for that period is just noise.  If this occurs
a high percentage of the time, signal recovery is impossible.  If you
adjust parameters to tolerate very much of this trouble, the stability
requirements quickly reach the point where AFK would work just as well,
so why not just use AFK?

I am short of time here, so the remaining issues will be answered in
another post.

73,

Stewart KK7KA