Message-ID: <573EF90F.1080201@posteo.de>
Date: Fri, 20 May 2016 13:46:23 +0200
From: DK7FC <selberdenken@posteo.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: rsgb_lf_group@blacksheep.org
References: <154c32c4dba-373a-24653@webprd-m58.mail.aol.com> <573CAF79.9040701@abelian.org> <573CBBF0.4030701@posteo.de> <573E5907.6020107@posteo.de> <573EA094.3040205@abelian.org>
In-Reply-To: <573EA094.3040205@abelian.org>
Subject: Re: VLF: EbNaut transmissions on lower frequencies?, pre-tests: 6.47kHz
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: O

Hi Paul, VLF,

OK, all right, thanks for the helpful report.

So the current transmission could have even better chances with shorter 
symbols (80 s) beeing transmitted in the time of ideal SNR.
We will see. At least there should be more coding gain now with 10 
characters.
For a long message of 20 characters i would need more ERP if the 
transmission should have to fit into this ideal time slot. Impossible 
with this small coil. So the symbol length must be longer. That means 
the average SNR drops below the necessary limit as we saw now. That 
means, if the phase is not a big problem, it must be even more longer :-)
My recent 20 char (which was 18 char actually) message was placed into a 
night-day-night time slot. So day-night-day would have been better. 
"Day" starts at 4 UTC and holds until 18 UTC these days maybe. So i 
could try that again. If that won't work i should try 200s symbols or 
the other coding you suggested.

73, Stefan

Am 20.05.2016 07:28, schrieb Paul Nicholson:
>
> Measurement of reconstructed carrier from the 31.5 hour message,
> In approximately 8 hour blocks (34.7uHz):
>
>  From       To         Signal    S/N      Phase  Noise
>  16th 21:00 17th 05:00 0.077 fT  11.0 dB  112.7  0.022  fT
>  17th 05:00 17th 13:00 0.063 fT  17.4 dB   75.2  0.0085 fT
>  17th 13:00 17th 21:00 0.041 fT   9.2 dB   83.5  0.0143 fT
>  17th 21:00 18th 04:30 0.05  fT   3.8 dB  125.0  0.032  fT
>
> Day/night phase shift up to 50 degrees which is about what was
> expected, although this is a long average so it could be varying
> more on shorter timescales to make the signal apparently weaker.
>
> The 18th from 00:00 onwards was noisy.
>
> Overall, would have needed to average about 14dB in this
> bandwidth (34.7 uHz) to have a reasonable chance (~50%)
> of decode.
>
> Daytime is doing better than nighttime. In 17.36 uHz we have
>
>  17th 04:00 to 20:00 0.057 fT  18.2 dB
>
>  (eg 11 chars, 72 seconds, Eb/N0 = +0.23 dB)
>
> Or, in 34.7 uHz
>
>  17th 05:00 to 13:00 0.063 fT  17.4 dB
>
>  (eg 9 chars, 40 seconds, Eb/N0 = +0.2 dB)
>
> Conclusion is that it's not the phase that's blocking these
> long messages, it's the poor nighttime S/N.
>
> -- 
> Paul Nicholson
> -- 
>