Message-ID: <5BAB3082.1090702@posteo.de>
Date: Wed, 26 Sep 2018 09:08:50 +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: <7aad9ea4-dfbc-dfd4-3494-4643cdeb10d9@bigpond.com> <5B9C0ECF.6060402@posteo.de> <5B9FB6C7.8080607@posteo.de> <5BA3EEC3.1010509@posteo.de> <5BA3F126.2050803@posteo.de>
In-Reply-To: <5BA3F126.2050803@posteo.de>
Subject: Re: VLF: EbNaut 3 character attempt to VK7
Content-Type: multipart/alternative;
 boundary="------------060007040107030003020903"
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org

This is a multi-part message in MIME format.
--------------060007040107030003020903
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Here is an update on the ongoing experiment between Edgar and me, trying 
to pass a 3 character EbNaut message over to VK7 on 17.4701 kHz.

Since the 21st September i'm transmitting the same message with 
identical parameters, one starts at 16:30 UTC, the other one at 19:30 UTC.
After some days it showed that the first time slot does not develop 
positively (2 days = +3 dB, 4 days = +6 dB....). The second message was 
more promising. *After 3 days stacked it got up to 9.71 dB SNR*. Best 
result so far:
rank 2673527 ber 4.5833e-01 Eb/N0 -5.3 M -6.947182617e+02 ph 77 
150,180,150,180
But this is not really a valid decode because you only get it when 
knowing the message before and searching explicitely for it.
Yesterday i got the 4th file, today the 5th.
Adding the 4th and 5th file to the stack unfortunately lowers the SNR again.

What now?
There is something to try:
These days the sunset happens about 2 minutes per day earlier. I want to 
try if it helps to start the transmission 2 minutes earlier per day. Of 
course this must be considered / compensated when building the stack.
So now i'm continuing to transmit the same messages but the start times 
will be:
*26th: 16:28 and 19:28 UTC
27th: 16:26 and 19:26 UTC
28th: 16:24 and 19:24 UTC*

and so on...

We have not been to far away from a valid decode, so let's hope this 
will help.

Comments or ideas?

73, Stefan


Am 20.09.2018 21:12, schrieb DK7FC:
> Correction: Same parameters as used for the first message, i.e. both 
> messages use
>
> *f = 17470.1000 Hz
> Start time: 20.SEP.2018  19:30:00 UTC & 16:30:00 UTC (daily)
> Symbol period: 10 s
> Characters: 3
> CRC bits: 19
> Coding 16K21A
> Antenna current: 1.2 A*
>
> 73, Stefan
>
>
> Am 20.09.2018 21:02, schrieb DK7FC:
>> VLF,
>>
>> In addition to the message below, which has been transmitted 3 times 
>> already, i will start to transmit the same message into a later time 
>> slot, also using different parameters:
>>
>> *f = 17470.1000 Hz
>> Start time: 20.SEP.2018  19:30:00 UTC (daily)
>> Symbol period: 10 s
>> Characters: 3
>> CRC bits: 16
>> Coding 16K21A
>> Duration: 02:24 [hh:mm]
>> Antenna current: 1.2 A
>>
>> *73, Stefan
>>
>> Am 17.09.2018 16:14, schrieb DK7FC:
>>> Edgar, VLF,
>>>
>>> After evaluating the latest 4 days of carrier transmissions it shows 
>>> that the path from DL to VK7 is quite unstable, i.e. the phase is 
>>> very dynamic.  When applying different frequency offsets, it seems 
>>> that the best start time for a message attempt is 16:30 UTC these 
>>> days. The SNR then peaks when applying a -40 uHz offset, attached. 
>>> Something between 2...3 hours seems to be best. Currently 2 hours 
>>> seem to give better results but 3 hours would be less dynamic.
>>> Based on this data i'm trying:
>>>
>>> *f = 17470.1000 Hz
>>> Start time: 17.SEP.2018  16:30:00 UTC (daily)
>>> Symbol period: 10 s
>>> Characters: 3
>>> CRC bits: 19
>>> Coding 16K21A
>>> Duration: 02:32 [hh:mm]
>>> Antenna current: 1.2 A*
>>>
>>> 73, Stefan

--------------060007040107030003020903
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Here is an update on the ongoing experiment between Edgar and me,
trying to pass a 3 character EbNaut message over to VK7 on 17.4701 kHz.<br>
<br>
Since the 21st September i'm transmitting the same message with
identical parameters, one starts at 16:30 UTC, the other one at 19:30
UTC.<br>
After some days it showed that the first time slot does not develop
positively (2 days = +3 dB, 4 days = +6 dB....). The second message was
more promising. <b>After 3 days stacked it got up to 9.71 dB SNR</b>.
Best result so far:<br>
rank 2673527 ber 4.5833e-01 Eb/N0 -5.3 M -6.947182617e+02 ph 77
150,180,150,180<br>
But this is not really a valid decode because you only get it when
knowing the message before and searching explicitely for it.<br>
Yesterday i got the 4th file, today the 5th.<br>
Adding the 4th and 5th file to the stack unfortunately lowers the SNR
again.<br>
<br>
What now? <br>
There is something to try:<br>
These days the sunset happens about 2 minutes per day earlier. I want
to try if it helps to start the transmission 2 minutes earlier per day.
Of course this must be considered / compensated when building the stack.<br>
So now i'm continuing to transmit the same messages but the start times
will be:<br>
<b>26th: 16:28 and 19:28 UTC<br>
27th: 16:26 and 19:26 UTC<br>
28th: 16:24 and 19:24 UTC</b><br>
<br>
and so on...<br>
<br>
We have not been to far away from a valid decode, so let's hope this
will help.<br>
<br>
Comments or ideas?<br>
<br>
73, Stefan<br>
<br>
<br>
Am 20.09.2018 21:12, schrieb DK7FC:
<blockquote cite="mid:5BA3F126.2050803@posteo.de" type="cite">
  <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
Correction: Same parameters as used for the first message, i.e. both
messages use <br>
  <br>
  <b>f = 17470.1000 Hz<br>
Start time: 20.SEP.2018  19:30:00 UTC &amp; 16:30:00 UTC (daily)<br>
Symbol period: 10 s<br>
Characters: 3<br>
CRC bits:<big> 19</big><br>
Coding 16K21A<br>
Antenna current: 1.2 A</b><br>
  <br>
73, Stefan<br>
  <br>
  <br>
Am 20.09.2018 21:02, schrieb DK7FC:
  <blockquote cite="mid:5BA3EEC3.1010509@posteo.de" type="cite">
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
VLF, <br>
    <br>
In addition to the message below, which has been transmitted 3 times
already, i will start to transmit the same message into a later time
slot, also using different parameters:<br>
    <br>
    <b>f = 17470.1000 Hz<br>
Start time: 20.SEP.2018  19:30:00 UTC (daily)<br>
Symbol period: 10 s<br>
Characters: 3<br>
CRC bits: 16<br>
Coding 16K21A<br>
Duration: 02:24 [hh:mm] <br>
Antenna current: 1.2 A<br>
    <br>
    </b>73, Stefan<br>
    <br>
Am 17.09.2018 16:14, schrieb DK7FC:
    <blockquote cite="mid:5B9FB6C7.8080607@posteo.de" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
Edgar, VLF, <br>
      <br>
After evaluating the latest 4 days of carrier transmissions it shows
that the path from DL to VK7 is quite unstable, i.e. the phase is very
dynamic.  When applying different frequency offsets, it seems that the
best start time for a message attempt is 16:30 UTC these days. The SNR
then peaks when applying a -40 uHz offset, attached. Something between
2...3 hours seems to be best. Currently 2 hours seem to give better
results but 3 hours would be less dynamic.<br>
Based on this data i'm trying:<br>
      <br>
      <b>f = 17470.1000 Hz<br>
Start time: 17.SEP.2018  16:30:00 UTC (daily)<br>
Symbol period: 10 s<br>
Characters: 3<br>
CRC bits: 19<br>
Coding 16K21A<br>
Duration: 02:32 [hh:mm] <br>
Antenna current: 1.2 A</b><br>
      <br>
73, Stefan<br>
    </blockquote>
  </blockquote>
</blockquote>
</body>
</html>

--------------060007040107030003020903--