To: rsgb_lf_group@blacksheep.org
References: <alpine.DEB.2.11.1702260842210.642@mailn.lipkowski.org>
 <e527c978-0559-b8f6-23ce-57ebd9b13cc2@abelian.org>
 <58B34590.3030802@posteo.de> <58B34924.6060005@posteo.de>
From: Paul Nicholson <vlf0403@abelian.org>
Message-ID: <81b61b29-0b37-3e1c-1a42-f9153a1c7870@abelian.org>
Date: Sun, 26 Feb 2017 22:31:37 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <58B34924.6060005@posteo.de>
Subject: Re: VLF: 16K19A?
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: RO


Stefan wrote:

 > Why is there no mode called 16K19A?

No reason why not.  I can put one together by combining a
couple of good rate 1/8 K=21 polynomials.  I'll try to do
that this week.   They take a little while to test and
measure performance.  The excuse I needed to play with the
latest 128 core PCs with 1952 Gbyte RAM.

 > Switching from 8K21A to 16K21A has an advantage (using the
 > same transmission time), as far as i understand...

That's right.  There is a modest gain going from rate 1/8 to
rate 1/16 and there is no transmission time or memory cost.
Further reduction of code rate, eg going from 1/16 to say
1/32 adds only a negligible (hard to measure) extra gain.
There's a rapidly diminishing return on reducing code rate.
It is better to increase constraint length but that incurs
severe memory cost with Viterbi decoding and also has a
diminishing return.

For short messages (eg up to 3 characters) it is not necessary
to use Viterbi decoding and we could make use of much longer
constraint lengths.    That's something else to play with.

 > In my recent transmissions i'm playing with the CRC value
 > so that the optimum list length is in a range of 100000.

I've noticed your thoughtful choices of CRC length.  That really
is a good policy.

I have a lot of performance data tabulated but not yet posted
on the web pages (partly because I haven't entirely understood
it all yet).  I've been searching for ways to calculate
performance but with only a little progress.  I've got as far
as being able to suggest an optimum list length which is on
the signal calculator page.   Longer than optimum list length
increases the chance of correct decode but also increases the
chance of a stronger (higher likelihood) false decode and the
overall performance levels off to a constant (in other words,
no further coding gain is available through increasing list
length).  I think there's a theoretical max 3dB coding gain
through list decoding but I wouldn't like to try to back that
up with a proof.

One day when I think I understand all this, I'll write it
up properly.
--
Paul Nicholson
--