Re: LF: More EbNaut 137.777

[Andy Talbot <andy.g4jnt@gmail.com>]

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