To: rsgb_lf_group@blacksheep.org
References: <15bd53dda31-14f8-1cb1c@webprd-m59.mail.aol.com>
 <590B9892.9010406@posteo.de> <1493995971.279577405@f347.i.mail.ru>
 <590CA917.70808@posteo.de> <590CEE68.4000507@posteo.de>
 <alpine.DEB.2.11.1705061013160.685@mailn.lipkowski.org>
From: Paul Nicholson <vlf0403@abelian.org>
Message-ID: <c3299517-dacf-aa3d-5a2b-2c9212e436c8@abelian.org>
Date: Sat, 6 May 2017 16:17:20 +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: <alpine.DEB.2.11.1705061013160.685@mailn.lipkowski.org>
Subject: Re: VLF: tonite on the 36km band...
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


 > f = 8270.100000 Hz
 > Start time: 05.May.2017   18:00:00 UTC
 > Symbol period: 40 s
 > Characters: 4
 > CRC bits: 6
 > Coding 16K21A
 > ... start time delayed to 19:15 UTC.

Copied with

  constant reference phase
  carrier phase: 73.9
  carrier Eb/N0: 10.2 dB
  carrier S/N: 23.83 dB in 31.2 uHz,
              -21.22 dB in 1Hz,
              -55.20 dB in 2.5kHz

Regarding CRCs, I think now I must recommend using a small
CRC on very long messages.   The overhead of a small CRC,
say 8 bits, is negligible on a long message.

Example, a couple of false decodes on Stefan's 100 char
message:

  "THIS K36,Y CT LONGEST EBNAUT MESSAGE ON VLF.
   881 KM ON THE 36 KM BAND.
   JOIN THE VLF ACTIVITIES! 73!"

and

  "THIS IS A NEW LONGEST EBNAUT MESSAGE ON VLF.
   881 KKW5+CTRK72KHQM BAND.
   JOIN THE VLF ACTIVITIES! 73!"

These seem to be typical, where the decode goes astray for
several characters, then comes back.  It seems to involve
runs of about 3 to 5 constraint lengths (eg 4 * 19 = 76 bits =
~13 chars).  Such a run contains 3 to 5 bits of redundancy in
the source encoding (0.3 bits per char) which the list decoder
makes use of.  Putting in a small CRC allows the list decoder
to discard these 'diversions'.   False decodes aren't much
of a problem because usually the real decode comes in with a
higher path metric and trumps the false ones but sometimes a
false decode wins.  A small CRC will kill these off.

For short messages, a very small or zero CRC remains best,
because of the significant inner code overhead.

This also means I have to revise my policy for calculating an
optimum list length.  Later I'll update the signal calculator
web page.

--
Paul Nicholson
--