Date: Sat, 28 Nov 2015 17:35:31 -0330 (NST)
From: jcraig@mun.ca
To: rsgb_lf_group@blacksheep.org
In-Reply-To: <Pine.LNX.4.64.1511281654560.10019@plato.ucs.mun.ca>
Message-ID: <Pine.LNX.4.64.1511281733070.10091@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>
 <Pine.LNX.4.64.1511281654560.10019@plato.ucs.mun.ca>
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

Unfortunately, a 'connection abort timeout' has affected the 2100
transmission. Will try again 2130.

Joe
On Sat, 28 Nov 2015, jcraig@mun.ca wrote:

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