Message-ID: <5659E2DF.7070908@abelian.org>
Date: Sat, 28 Nov 2015 17:22:39 +0000
From: Paul Nicholson <vlf0403@abelian.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: rsgb_lf_group@blacksheep.org
References: <CAA8k23T4-DLQX1Vh6HA9A_H6M0oThZHKr3RSJBMFXx7jC40fpw@mail.gmail.com> <8D2F813A9C577D7-1DC0-5B23A@webmail-vd012.sysops.aol.com>
In-Reply-To: <8D2F813A9C577D7-1DC0-5B23A@webmail-vd012.sysops.aol.com>
Subject: Re: LF: More EbNaut 137.777
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Status: RO

Markus wrote:
 > used a text editor to "notch" the QRM by
 > 2100    -0.9     1.2  (after notching QRM)

That's a lucky result at -0.9 dB for this, the weakest coding
on the menu.

VO1NA at Todmorden, 2015-11-27/28, 8K19A 2 seconds 5 chars

  start  Eb/N0    T offset
  20:30  3.8 dB    +1.0
  21:00  5.9 dB    +0.8
  21:30  4.5 dB    +0.7
  22:00  6.7 dB    +1.0
  22:30  7.1 dB    +0.8
  23:00  2.9 dB    +1.1
  23:30  5.6 dB    +0.9
  00:00  6.8 dB    +1.2
  00:30  no decode
  01:00  no decode
  01:30 10.6 dB    +1.2
  02:00  2.3 dB    +1.7
  02:30  4.8 dB    +1.8
  03:00  no decode
  03:30 -0.6 dB    +1.8 rank 5534
  04:00  5.8 dB    +1.8
  04:30 11.3 dB    +1.7
  05:00  6.8 dB    +1.7
  05:30  5.5 dB    +1.8
  06:00  no decode
  06:30  7.1 dB    +1.9
  07:00 11.7 dB    +1.8
  07:30  8.9 dB    +1.8
  08:00 no decode

The timing offsets merely indicate the offset which gave the
lowest BER and does not necessarily mean the tx clock had that
particular offset.

Hopefully the timing can be fixed.  Certainly it will be
if using ntpd and ebkey.  Then, our PCs can be devoted to
searching in depth rather than breadth and we can try some
weak signals, stronger codes, and longer duration messages.

With longer messages, the oscillator stability is paramount
and the clock can be a bit off.

Short messages can get away with a drifty oscillator but
need a good clock.

Install a GSPDO and both clock and oscillator are sorted.

Markus wrote:
 > reducing the character set would not really solve it

No, and there's always an irreducible error floor with
list decoding, although you can make that floor very low by
increasing the bits allocated to the outer error detection code.

In list decoding, the backward pass phase of the Viterbi decoder
outputs a list of say, 50,000 possible decodes in order of
decreasing likelihood.   All 50,000 are valid codewords of
the convolutional code but have increasing distance from
the received noisy word.  The only way to tell which is the
intended codeword is to have an outer layer which can vet each
list entry to see if it qualifies in some way.  The 16 bit
CRC plus 0.3 bits per character provides this validation but
it is unavoidable that there is a probability that a random
list entry will happen by chance to qualify against the CRC.

In EbNaut this becomes noticeable with short messages and
large list size.  Then, the rx operator has to provide a 3rd
layer of recognition.   In effect, the outer layer is also a
list decoder, and the operator is providing the validation
it needs.

Under those conditions it is not possible to transmit arbitrary
messages with reliability because the operator must have
something to recognise.  It affects the Eb/N0 calculation
because we are implicitly reducing the space of the message
words by restricting them to things like 'VO1NA' instead of
things like ';B/-W'.  Restricting the allowed combinations of
characters like this has the same effect as restricting the
character set itself: they are releasing info bits for use as
list selection bits.  Either way, the information content is
reduced below 5.3 * Nchars and the Eb/N0 claims of the program
are invalidated.

Amazingly the battery is still going on the LF rx.
--
Paul Nicholson
--