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