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 v9OH2eNG019600 for ; Tue, 24 Oct 2017 19:02:43 +0200 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1e72Uq-0007z3-7I for rs_out_1@blacksheep.org; Tue, 24 Oct 2017 17:56:08 +0100 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1e72Up-0007yu-Ao for rsgb_lf_group@blacksheep.org; Tue, 24 Oct 2017 17:56:07 +0100 Received: from mout02.posteo.de ([185.67.36.66]) by relay1.thorcom.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1e72Um-00084f-L9 for rsgb_lf_group@blacksheep.org; Tue, 24 Oct 2017 17:56:06 +0100 Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 0D3C520A17 for ; Tue, 24 Oct 2017 18:56:00 +0200 (CEST) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 3yLztS08J5z10JG for ; Tue, 24 Oct 2017 18:55:59 +0200 (CEST) Message-ID: <59EF709F.7090704@posteo.de> Date: Tue, 24 Oct 2017 18:55:59 +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: <15f3640d1bf-c10-10621@webjas-vac109.srv.aolmail.net> <59E9451E.80901@posteo.de> <59E945D8.30101@posteo.de> <59E9FF29.5000206@posteo.de> <59EA03F4.2040700@posteo.de> In-Reply-To: <59EA03F4.2040700@posteo.de> X-Spam-Score: 0.0 (/) 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 the administrator of that system for details. Content preview: ...the message was running on the 20th, 22th and 23th. Today i made a mistake in the SpecLab settings which unfortunetely affectet the transmission. I watched the alternating colours (due to the PSK) and saw that it doesn't switch the phase as expected. Then i quickly restartet SpecLab, it was bit chaotic but now it should work again. Since the symbol length is 3 minutes it was easy to delete the first 11 symbols and start this special file at 16:33:00 UTC. All in all just the first 8 symbols are affected. 2 of them were transmitted correctly (productive), 2 of them have opposite phase (destructive) and 4 were not transmitted (not really neutral but not so dramatic). Fortunately the transmission takes 12 hours, so 24 minutes is just 3.3 % or -0.15 dB. The transmimission should now continue as expected. Just a note for those who follow it... [...] Content analysis details: (0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 HTML_MESSAGE BODY: HTML included in message X-Scan-Signature: 1bc6486c2865e7dc2ff7578e6d7fc226 Subject: Re: VLF: 300 mA on 5170 Hz Content-Type: multipart/alternative; boundary="------------000201030609070100060700" 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. --------------000201030609070100060700 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ...the message was running on the 20th, 22th and 23th. Today i made a mistake in the SpecLab settings which unfortunetely affectet the transmission. I watched the alternating colours (due to the PSK) and saw that it doesn't switch the phase as expected. Then i quickly restartet SpecLab, it was bit chaotic but now it should work again. Since the symbol length is 3 minutes it was easy to delete the first 11 symbols and start this special file at 16:33:00 UTC. All in all just the first 8 symbols are affected. 2 of them were transmitted correctly (productive), 2 of them have opposite phase (destructive) and 4 were not transmitted (not really neutral but not so dramatic). Fortunately the transmission takes 12 hours, so 24 minutes is just 3.3 % or -0.15 dB. The transmimission should now continue as expected. Just a note for those who follow it... 73, Stefan Am 20.10.2017 16:11, schrieb DK7FC: > > *f = 5170.1000 Hz > Start time: 20.October.2017 16:00:00 UTC (daily) > Symbol period: 180 s > Characters: 1 > CRC bits: 6 > Coding 8K19A > Duration: 12h > Antenna current: 300 mA* > --------------000201030609070100060700 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit ...the message was running on the 20th, 22th and 23th.

Today i made a mistake in the SpecLab settings which unfortunetely affectet the transmission.
I watched the alternating colours (due to the PSK) and saw that it doesn't switch the phase as expected. Then i quickly restartet SpecLab, it was bit chaotic but now it should work again. Since the symbol length is 3 minutes it was easy to delete the first 11 symbols and start this special file at 16:33:00 UTC. All in all just the first 8 symbols are affected. 2 of them were transmitted correctly (productive), 2 of them have opposite phase (destructive) and 4 were not transmitted (not really neutral but not so dramatic).
Fortunately the transmission takes 12 hours, so 24 minutes is just 3.3 % or -0.15 dB.
The transmimission should now continue as expected.
Just a note for those who follow it...

73, Stefan


Am 20.10.2017 16:11, schrieb DK7FC:

f = 5170.1000 Hz
Start time: 20.October.2017  16:00:00 UTC (daily)
Symbol period: 180 s
Characters: 1
CRC bits: 6
Coding 8K19A
Duration: 12h
Antenna current: 300 mA


--------------000201030609070100060700--