References: <570C161D.8040204@abelian.org>
To: rsgb_lf_group@blacksheep.org
From: Paul Nicholson <vlf0403@abelian.org>
Message-ID: <570EB258.3020707@abelian.org>
Date: Wed, 13 Apr 2016 20:55:52 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <570C161D.8040204@abelian.org>
Subject: Re: LF: EbNaut decoder upgrade
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Status: O


Another decoder upgrade: v0.4d

  http://abelian.org/ebnaut/win32/ebnaut-rx.exe
  http://abelian.org/ebnaut/win64/ebnaut-rx.exe

This one has improved memory allocation and list
length capability - up to 1 million with 31 chars
8K19A on 32-bit Windows.   On 64 bit you can use
up to 20 million if you have enough RAM.

I wrote:

 > For a CRC of size C bits you should use a list length of
 > 2 to the power of C-1 or thereabouts.

Actually this should take account of the redundant bits in
the source encoding, so the optimum list length is around

  2 to the power of (Nchars * 0.3 + CRC_bits - 1)

So far in testing, I'm finding that increasing the CRC size
always improves performance, although there's a diminishing
return and a 16 bit CRC is pretty good in general.

For example,  8K19A 3 chars at Eb/N0 = -1.0 dB has a 54.0%
success rate with a full phase search when using 8 bit CRC and
list size 500.   Switching to 16 bit CRC and reducing symbol
period to maintain the -1.0 dB Eb/N0 and same message duration,
has a 56.9% success rate with 50k list.  Going up to a 22 bit
CRC nudges 58% but you need a 4M list to achieve that.

Generally then, only a marginal improvement in performance
when using more than 16 bits and the cost is exponentially
increasing list length.

With the default 16 bit CRC it is often worth using a longer
list than the default 20k on longer messages.   For example
a 12 char message 8K19A at -1.0 dB has a 52.4% success rate
with 20k list and 55.7% with 400k list.

If you use a longer list than the formula above, it doesn't
do any harm, the decode performance doesn't deteriorate but
it takes longer and there's no further coding gain.

I had an intuitive suspicion that longer payloads could benefit
from smaller CRC (because of the redundant source bits).
Well, intuition turned out to be wrong.  Performance always
increases with wider CRC no matter how many chars are sent,
even though the symbols have to be shorter to fit more of
them within the same message duration.

Calculator page http://abelian.org/ebnaut/calc.php shows an
'optimum list length' but if you can't reach that length,
you'll only lose a percent or two by using half that size.

Bottom line: stay with CRC-16 but use longer lists if
appropriate and enough memory is available.

--
Paul Nicholson
--