Date: Sat, 28 Nov 2015 16:29:52 -0330 (NST)
From: jcraig@mun.ca
To: rsgb_lf_group@blacksheep.org
In-Reply-To: <5659E2DF.7070908@abelian.org>
Message-ID: <Pine.LNX.4.64.1511281627550.9953@plato.ucs.mun.ca>
References: <CAA8k23T4-DLQX1Vh6HA9A_H6M0oThZHKr3RSJBMFXx7jC40fpw@mail.gmail.com>
 <8D2F813A9C577D7-1DC0-5B23A@webmail-vd012.sysops.aol.com> <5659E2DF.7070908@abelian.org>
MIME-Version: 1.0
Subject: Re: LF: More EbNaut 137.777
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Status: O

Hi Paul,

Telegram for you, sir.

Sorry for the late notice.  start time 2000 8 characters. Hope you get it.
  sudo echo ' ** ** '  | sudo ebnaut -et -N8 -p8K19A | sudo ebkey -S2.0 -m 
rp,gpio=27 -T 20151128200000 -r 1800 -vv

Hope that was correct.

TNX & 73
Joe VO1NA


On Sat, 28 Nov 2015, Paul Nicholson wrote:

> 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
> --
>
>