Message-ID: <5655CBB5.8060902@abelian.org>
Date: Wed, 25 Nov 2015 14:54:45 +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: <Pine.LNX.4.64.1511241851390.27494@plato.ucs.mun.ca> <8D2F523EC346B57-948-18286@webmail-vm007.sysops.aol.com> <Pine.LNX.4.64.1511241947060.27721@plato.ucs.mun.ca>
In-Reply-To: <Pine.LNX.4.64.1511241947060.27721@plato.ucs.mun.ca>
Subject: Re: LF: EbNaut and The Cat / Take 3
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: O

Thanks to all for the interesting tests.  But we are battling
with clocks and oscillators rather than propagation and noise.

At least with EbNaut nobody can complain that the operator is
just installing the software and pressing 'start'.  It does
seem like that with some modes: the computers are doing all the
communicating and the operators are merely spectators.  Clearly
not the case here!

I cheated and used Markus' time offsets to polish my decodes:

  time   Eb/N0    Phase
  21:00    9.6    30 30 30 30
  21:30   13.3    0 0 0 0       (offset 1.8 seconds)
  22:00   12.0    0 0 30 30
  22:30   10.8    150 150 180 180

Quite a good signal in fact. 10dB too strong for a good test
but without the strong signal it would have been harder to
identify the clock offsets.  We don't seem to have a problem
with phase with these short messages.

I've updated the decoder, now version 0.3d

  http://abelian.org/ebnaut

It counts missing (padded) symbols as errors when calculating
BER and that will reduce Eb/N0.  That's not really the correct
thing to do: an erasure isn't quite like an error, the decoder
only has to work out the missing bits, not oppose errors from
the demodulator.   The consequence will be that instead of
Eb/N0 being incorrectly high, it will now be incorrectly low.

Eg I just tried decoding less than half the 21:30 message and
it gave

  found rank 0: TANGLES  ps [  1  180  180  180  180]
  re-encode 322/608 ber 5.30e-01  Es/N0=-20.0 Eb/N0=-8.4

Any BER over 50% is bogus and the Eb/N0 is totally meaningless.
Nevertheless the decoder is having to fix up 322 bits here.

Maybe a better thing to do is just sum over the un-padded
symbols, but that's still not quite right.   I tried that but
it throws up some other problems.

Probably not a big deal either way.  It's unusual to have so
much of the message missing.

I did once decode a VLF message with about a third of it
missing because I was unaware that the transmission was coming
and the rx and PCs were down for maintenance.

Just for fun I tried to see how little of the 21:30 message
was actually needed for a decode.  It worked with 108 seconds
of signal and 1108 seconds missing.

  found rank 206730: TANGLES ps [  1  180  180  180  180]
  re-encode 559/608 ber 9.19e-01

Of the 608 transmitted symbols, 554 were missing, 5 errored,
and 49 correctly demodulated.   Those 49 good bits were enough
to fix the errors and erasures.

This shows that an erased bit is much less distracting to
the decoder than an errored bit.  The list decoding becomes
very slow under these conditions due to a degenerate backward
pass tree.

--
Paul Nicholson
--