MIME-Version: 1.0
In-Reply-To: <565B8A7B.8000608@abelian.org>
References: <8D2F8A79EEF4432-1FFC-66476@webmail-vd018.sysops.aol.com>
	<CAA8k23Rrxfi8PRg4hy7XPh0X2wA39oqsy91=YR-MepHqCzAV7w@mail.gmail.com>
	<Pine.LNX.4.64.1511291012230.11928@plato.ucs.mun.ca>
	<565B3DE9.7040401@abelian.org>
	<Pine.LNX.4.64.1511291551330.12557@plato.ucs.mun.ca>
	<565B6B1F.4070606@abelian.org>
	<565B70FC.1090505@abelian.org>
	<Pine.LNX.4.64.1511291905460.13093@plato.ucs.mun.ca>
	<565B8A7B.8000608@abelian.org>
Date: Mon, 30 Nov 2015 08:37:33 +0000
Message-ID: <CAA8k23QYD65tDXHNvmo6uk6tQ65SdcYG-SafeXQtKizTL-xMVQ@mail.gmail.com>
From: Andy Talbot <andy.g4jnt@gmail.com>
To: rsgb_lf_group@blacksheep.org
Subject: Re: LF: More EbNaut 137.777
Content-Type: text/plain; charset=UTF-8
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Status: O

I left it running overnight, and have tried a few capture files
selected at random.   Some produce a garbage message, with symbol
errors typically 200 or so out of 512 but this one at 0200 gave a
correct decode immediately with just slightly fewer symbol errors at
187   All the contents of the .txt file shown below
 (unless the one chance in  50 ^ 5 = 315 million threw the correct
callsign up at random :-)

One thing that puzzles me:
The EbNaut documentation states there is an outer checksum for message
validity.    Why does this allow the garbage decodes to get through -
surely that must be failing the checksum.    Or are they the few out
of millions of possible garbage decodes that pass the checksum
criteria?


Andy  G4JNT


ebnaut-rx V0.3b
input file C:\CohLFRx\151130_0159.WAV
sample rate 31.250000 per second
rx frequency 0.000
file start time 2015-11-30 01:59:59.000
polynomial 8K19A
number of chars 5
block size 46
symbol period 2.000
number of symbols 512
list length 6000
start offset 1.000
freq offset 0.000000
cores 1
initial reference phase 7.0
---------------------------------------------
found VO1NA
list rank 5354
reference phase  180  180  180  180
carrier RMS 3.401e+002 noise RMS 5.160e+001
carrier S/N 16.38 dB in 976.6 uHz
carrier Es/N0 -10.71 dB
carrier Eb/N0 1.83 dB
info bit period 35.93 seconds
symbol error rate 187/512 = 36.523 %
Es/N0 from symbol errors -12.2 dB
Eb/N0 from symbol errors 0.1 dB
Shannon capacity 211.5 bits/hour
Shannon efficiency 47.4 %
symbols file C:\CohLFRx\151130_0159-symbols.csv
elapsed 15 seconds
---------------------------------------------
found VO1NA
list rank 29
reference phase -150 -150 -150 -150
carrier RMS 3.401e+002 noise RMS 5.160e+001
carrier S/N 16.38 dB in 976.6 uHz
carrier Es/N0 -10.71 dB
carrier Eb/N0 1.83 dB
info bit period 35.93 seconds
symbol error rate 175/512 = 34.180 %
Es/N0 from symbol errors -10.8 dB
Eb/N0 from symbol errors 1.5 dB
Shannon capacity 211.5 bits/hour
Shannon efficiency 47.4 %
symbols file C:\CohLFRx\151130_0159-symbols.csv
elapsed 29 seconds

On 29 November 2015 at 23:30, Paul Nicholson <vlf0403@abelian.org> wrote:
>
> VO1NA 2015-11-29 8K19A 2S 5C
>
>  20:00  6.2 dB
>  20:30  7.0 dB
>  21:00  3.2 dB
>  21:30  1.4 dB
>  22:00  5.4 dB
>  22:30  no decode
>  23:00  8.7 dB
>
> Edgar wrote:
>
>> I had been looking at vtmatch.
>
> vtmatch monitors a stream and does a continuous
> cross correlation against the template: in other
> words a matched filter.
>
> It would be the one to use if you knew what the
> message was but not the start times.
>
> Generate a template file for vtmatch with
>
>  echo 'TNX PAUL' |
>    ebnaut -e -r100 -S2 -p8K19A -N8 |
>    awk '{print $1}' > ref.dat
>
> Here, I've dropped to sample rate 100.
>
> I should then be able to do something like
>
>  vtread -T2015-11-28_20:00,+8h /raw | # Get 8 hours of signal
>     vtfilter -h bp,f=2777,w=2 |
>     vtmult -f 2777 |     # Mix 137777 to baseband
>     vtresample -r 100 |  # Baseband I/Q at 100 samples/sec
>     vtmatch -t ref.dat > match.vt
>
> Then
>
>   vtplot match.vt
>
> should show a good spike whenever the message appears in that 8
> hour stream.  The spike should be surrounded by auto-correlation
> 'sidebands' which ought to be quite low compared to the peak.
> For some reason it's not quite working, getting the sidebands
> but no central spike, even on a simulated signal.  Maybe I'm
> too tired or there's a bug in vtmatch.  I'll look at it again
> tomorrow.
>
> --
> Paul Nicholson
> --
>