Date: Sat, 28 Nov 2015 16:56:04 -0330 (NST)
From: jcraig@mun.ca
To: rsgb_lf_group@blacksheep.org
In-Reply-To: <CAA8k23T+RUPt4+XOV7T+X=pLNcse_zgdwSYhiHB42zD4DXNGwQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1511281654560.10019@plato.ucs.mun.ca>
References: <CAA8k23T4-DLQX1Vh6HA9A_H6M0oThZHKr3RSJBMFXx7jC40fpw@mail.gmail.com>
 <8D2F813A9C577D7-1DC0-5B23A@webmail-vd012.sysops.aol.com> <5659E2DF.7070908@abelian.org>
 <Pine.LNX.4.64.1511281627550.9953@plato.ucs.mun.ca>
 <CAA8k23T+RUPt4+XOV7T+X=pLNcse_zgdwSYhiHB42zD4DXNGwQ@mail.gmail.com>
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

That's correct Andy assuming  I've got things under control.

Joe

On Sat, 28 Nov 2015, Andy Talbot wrote:

> Would I be right in thinking 137777Hz, 30 minute repeat, 2s symbols is
> running again?
>
> Inow appear to have an operational "Record Every to auto filename" option
>
> Andy  G4JNT
>
> On 28 November 2015 at 19:59, <jcraig@mun.ca> wrote:
>
>> 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
>>> --
>>>
>>>
>>>
>>
>