Return-Path: Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by klubnl.pl (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w8RKo7Kn021022 for ; Thu, 27 Sep 2018 22:50:08 +0200 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1g5d8y-0007mF-7u for rs_out_1@blacksheep.org; Thu, 27 Sep 2018 21:44:16 +0100 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1g5d8x-0007m6-4I for rsgb_lf_group@blacksheep.org; Thu, 27 Sep 2018 21:44:15 +0100 Received: from mout01.posteo.de ([185.67.36.65]) by relay1.thorcom.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91_59-0488984) (envelope-from ) id 1g5d8v-0001ft-8h for rsgb_lf_group@blacksheep.org; Thu, 27 Sep 2018 21:44:14 +0100 Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 518CF210FD for ; Thu, 27 Sep 2018 22:44:10 +0200 (CEST) X-DKIM-Result: Domain=posteo.de Result=Signature OK DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1538081050; bh=8cQb9uvupPcZabkijBJdhcovq7NHYkofw++ayCWAbkc=; h=Date:From:To:Subject:From; b=MTXSf76kfB/hXoxcVncp92MMAf9wVuce7NcUjWYUYU/bMxBZKFnIb0yDLqCVGQWDL 27CQ9O+BT4iHt7mz0RhKBcc+y4qG36w/GU70prTPt3QbG75w4T3Ji8KBeXL6sXQtkf 8YpYCbC3UmX/fGg4Ghg6A+5JGxQKEb7pTXlsdFdlM/Dwpvco/pG5h2y4lNrAgOgE9N UpxOHHpORoq0KDwjnGmh2YmCxtX9yhHutgH8z70lZPiqTtDbDn+4BvbU++zPUrcBlC ldCEadphFpbzfk+VlOTYXq/6MJHUGjgRNiVRDM6wB9SX/fWd1lGXHePcG7xK11X76n 9bbxJa5LfvqzQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 42Lmxj2jgsz6tmJ for ; Thu, 27 Sep 2018 22:44:09 +0200 (CEST) Message-ID: <5BAD4119.2040105@posteo.de> Date: Thu, 27 Sep 2018 22:44:09 +0200 From: DK7FC 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: <1661b94f4d2.marcocadeddu@tin.it> In-Reply-To: <1661b94f4d2.marcocadeddu@tin.it> X-Spam-Score: -2.3 (--) X-Spam-Report: Spam detection software, running on the system "relay1.thorcom.net", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Thanks Marco, Yes i will. And, surprisingly the stack is now developing quite well, very well! However, today i found my H bridge PA damaged, one half-bridge had a short circuit. I replaced the two FETs but there was still no output signal. A restart of the TX PC was required, then the system was available again. But unfortunately the second EbNaut message should have started already. I was 1 hour to late. So there is no message transmission today. I will continue tomorrow, as announced, starting * 28th: 16:24 and 19:24 UTC* [...] Content analysis details: (-2.3 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [185.67.36.65 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Scan-Signature: df2e2c1e83972f6e42eeb17d78e70347 Subject: Re: R: Re: VLF: EbNaut 3 character attempt to VK7 Content-Type: multipart/alternative; boundary="------------070705060807090702060508" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.63 X-SA-Exim-Scanned: Yes Sender: owner-rsgb_lf_group@blacksheep.org Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group X-SA-Exim-Rcpt-To: rs_out_1@blacksheep.org X-SA-Exim-Scanned: No; SAEximRunCond expanded to false This is a multi-part message in MIME format. --------------070705060807090702060508 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Thanks Marco, Yes i will. And, surprisingly the stack is now developing quite well, very well! However, today i found my H bridge PA damaged, one half-bridge had a short circuit. I replaced the two FETs but there was still no output signal. A restart of the TX PC was required, then the system was available again. But unfortunately the second EbNaut message should have started already. I was 1 hour to late. So there is no message transmission today. I will continue tomorrow, as announced, starting * 28th: 16:24 and 19:24 UTC* 73, Stefan Am 27.09.2018 17:10, schrieb marcocadeddu@tin.it: > just one :-) > keep on with your patience and dedication, you will get the resoult! :-) > 73, Marco IK1HSS > > > ----Messaggio originale---- > Da: selberdenken@posteo.de > Data: 26-set-2018 9.08 > A: > Ogg: Re: VLF: EbNaut 3 character attempt to VK7 > > 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 > > --------------070705060807090702060508 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Thanks Marco,

Yes i will. And, surprisingly the stack is now developing quite well, very well!

However, today i found my H bridge PA damaged, one half-bridge had a short circuit. I replaced the two FETs but there was still no output signal. A restart of the TX PC was required, then the system was available again. But unfortunately the second EbNaut message should have started already. I was 1 hour to late.
So there is no message transmission today.
I will continue tomorrow, as announced, starting
28th: 16:24 and 19:24 UTC

73, Stefan

Am 27.09.2018 17:10, schrieb marcocadeddu@tin.it:
just one :-)
keep on with your patience and dedication, you will get the resoult! :-)
73, Marco IK1HSS


----Messaggio originale----
Da: selberdenken@posteo.de
Data: 26-set-2018 9.08
A: <rsgb_lf_group@blacksheep.org>
Ogg: Re: VLF: EbNaut 3 character attempt to VK7

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


--------------070705060807090702060508--