Received-SPF: none (google.com: owner-rsgb_lf_group@blacksheep.org does not designate permitted sender hosts) client-ip=195.171.43.25;
Message-ID: <5370FABB.8020500@abelian.org>
Date: Mon, 12 May 2014 16:45:47 +0000
From: Paul Nicholson <vlf0403@abelian.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: rsgb_lf_group@blacksheep.org
References: <536F1A51.3060806@abelian.org> <CC7E3716DF7F412F8BFB5B216628F5A7@White> <078901cf6d1b$4179a730$c46cf590$@comcast.net>
In-Reply-To: <078901cf6d1b$4179a730$c46cf590$@comcast.net>
Subject: Re: VLF: Coherent BPSK at 8270 from DF6NM
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org

The coding itself imposes no limit to the number of bits to
send, but the availability of a steady channel does.

The previous weekend Markus made a long carrier transmission
and after the terminator cleared, the phase was steady enough
throughout the morning - except for a dip between 9:00 and 9:30.
This split the morning into two natural windows for a test.

The available window limits the transmission time.  In this
case, there was room for only 5 characters (in winter we would
do much better).

In March 2012 Markus was able to send 10.4 bits per hour to
Todmorden using MFSK-37.   In Saturday's test we have raised
that to about 21 bits per hour.  The Shannon-Hartley capacity
limit for this bandwidth and signal power is about 27 bits
per hour.

The signal from Markus is perfect for these tests - very stable,
and also quite weak at this range - ideal for tests of coherent
modulation with strong FEC.

Spectrum of the carrier from Markus - averaged for one hour,

  http://abelian.org/vlf/tmp/df6nm_140510b.png

It is 12dB above noise in this 278 uHz bandwidth. In the
bandwidth of a 30 second code symbol the S/N is around -9dB.
At that level, about 30% of the 264 code symbols are demodulated
incorrectly - about 80 errors.   This rate 1/4 K=21 code will
always decode correctly any message with up to 47 errors, and
will decode approximately half of all messages with 83 errors.
List decoding extends those thresholds significantly, so we
obtain quite a reliable decode at this signal level.

Graphs at http://abelian.org/fec/results.html show the
measured performance gains as the code strength increases and
compare standard Viterbi with list decoding.

Our limiting factor is in fact, not the FEC code, but the
ability to discern a reference phase from the BPSK signal.
Below some level, it becomes necessary to search for the
correct phase, and if necessary, the drift pattern.  It was
necessary to use such a search to find the reference phase
for both test transmissions because the extracted reference
phase just wasn't good enough.

For example, here is a scattergram of the 264 BPSK symbols in
I/Q space,

  http://abelian.org/vlf/tmp/df6nm_140510c.png

There is no sign of any 'preferred axis' to the scatter of
symbols - the phase distribution looks pretty randomly spread.
For comparison here is the same plot for the same message with
simulated noise corresponding to Eb/N0 of various levels

   2dB   http://abelian.org/vlf/tmp/df6nm_140510d.png
  10dB   http://abelian.org/vlf/tmp/df6nm_140510e.png
  20dB   http://abelian.org/vlf/tmp/df6nm_140510f.png

Above about 1dB it is quite easy to extract a reference phase,
but for much weaker signals we have to search for it.

I am working on ways to improve the reference search and will
modify the code and the iterative decoder before the next test.

--
Paul Nicholson
--