> 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
--