Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

Re: VLF: A 300 char message?

To: [email protected]
Subject: Re: VLF: A 300 char message?
From: Paul Nicholson <[email protected]>
Date: Sun, 12 Nov 2017 16:45:51 +0000
Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=abelian.org ; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=HcMnj/Z41TatXo/nK4ITlcgsWZUE0Gyf4GlhyW7fTOw=; b=HZhNJfCI1c1l9p4hXdPe0f1OTr arOkLSETTOkDVjEfx25+vkSqw81TLzgKSbevXH29V09Zh0VRx3O8zGzW1M51QODVaKJX3JryddKQn m19F+9wi+7l9mUuP1qHIYa91ZRkZ0ug88wtuxQNONxSL6XYLxxsi4kz5WP5qKYjh/VIY=;
In-reply-to: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]>
Reply-to: [email protected]
Sender: [email protected]
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
Stefan wrote:

> 6E6 list size? The calculator page says 325804 is optimum.

Oh, it's complicated with longer messages.  It's that pesky
0.3 bits per character of redundancy.  It makes the optimum
list length depend on S/N. With the weakest signals, the optimum becomes much longer with a long message.
With shorter messages, a false decode tends to corrupt all
the characters (more or less regardless of S/N), and you get
a total redundancy of CRC size plus 0.3 bits per char, eg a 12
char message with 16 bit CRC would be 16 + 12 * 0.3 to give 19.6
bits.  A list size of 1E6 would be likely to give a random match
with the redundancy, even if there was no signal present at all.

With longer messages, say 25 chars and upwards, a false decode
is often a 'nearby' decode in the sense that only some of the
characters are corrupted, often in a run of 5 to 15 chars.
To get a false decode, the CRC bits have to match as usual,
but if only a few characters are incorrect, they are still
quite likely by chance to pass the character set test.

        So, a long message which 'almost' decodes will often give
false decodes with only, say, 5 errored characters for a total
of 17.5 bits of redundancy and then a 200K list would have a
good chance of a false decode.

If the 300 char message is way too weak to decode, say at
Eb/N0 -3dB,  all 300 * 0.3 + 16 bits come into play and I
would need an astronomically long list to have any chance of
a false decode, ~ 2^106 ~= 10^32.

The fact that your message didn't decode with a 1E6 list and
uniform phase search told me that it was going to be unlikely
to decode at all.  If it was strong enough to almost decode,
there would have been false decodes with partially correct
message and I could have played with the pointing and blanking
to tease out that extra 0.1 dB or so that can always be found
if you try hard enough.

I left it running full search with 6E6 mainly because I
wanted to keep the office warm while I was up on the moors
this morning.  It cured the chill from four hours in a freezing
wind training mountain rescue search dogs.

Anyway, 49Gbyte is nothing these days.  Firefox soaks up a
couple of Gbyte before it even opens a page.  Thunderbird right
now is holding onto 2.6Gbyte and Firefox 9.7Gbyte.  Totally
crazy - what do they do with it all?  At least EbNaut makes
a decent use of all that RAM.

The latest AMD chips give you 32 threads and motherboards 128Gbyte
of 4-channel RAM - and they're aimed at the domestic PC market!
In not many years, you'll need that just to open your browser.

--
Paul Nicholson
--

<Prev in Thread] Current Thread [Next in Thread>