Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lipkowski.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 X-Spam-DCC: : mailn 1480; Body=2 Fuz1=2 Fuz2=2 Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by lipkowski.org (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v09KdNWL022912 for ; Mon, 9 Jan 2017 21:39:24 +0100 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1cQgeX-0000op-P2 for rs_out_1@blacksheep.org; Mon, 09 Jan 2017 20:34:49 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1cQgdx-0000og-TH for rsgb_lf_group@blacksheep.org; Mon, 09 Jan 2017 20:34:13 +0000 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.87) (envelope-from ) id 1cQgds-00065O-UG for rsgb_lf_group@blacksheep.org; Mon, 09 Jan 2017 20:34:11 +0000 Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id D20D320BD1 for ; Mon, 9 Jan 2017 21:34:07 +0100 (CET) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 3ty6M06Zmvz108f for ; Mon, 9 Jan 2017 21:34:04 +0100 (CET) Message-ID: <5873F3BC.20403@posteo.de> Date: Mon, 09 Jan 2017 21:34:04 +0100 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: <159526aa32e-1297-2d056@webprd-m96.mail.aol.com> <5867AA75.6030603@posteo.de> <5867DFA9.5020604@abelian.org> <58691D84.9030201@posteo.de> <586A8A05.5090901@posteo.de> <586AA7C5.8070802@abelian.org> <049501d26535$dee8b370$9cba1a50$@comcast.net> <586B5BAD.7@abelian.org> <586C4F2C.1010205@posteo.de> <586D6E99.6080509@posteo.de> <586F5D60.4030309@abelian.org> <586F7C4F.3090806@posteo.de> <586F8082.4060404@abelian.org> <5870097B.7080708@posteo.de> <58701056.20008@posteo.de> <587069F3.1010407@abelian.org> <58712E8D.9050207@posteo.de> <5873825E.4090306@posteo.de> In-Reply-To: <5873825E.4090306@posteo.de> X-Scan-Signature: 783e848a630124d13ae6ef06c152f951 Subject: Re: VLF: Back on 5.17 kHz / 58 km... Content-Type: multipart/alternative; boundary="------------000900020004080405010707" 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 X-Scanned-By: MIMEDefang 2.75 Status: RO X-Status: X-Keywords: X-UID: 10161 This is a multi-part message in MIME format. --------------000900020004080405010707 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit VLF, In the event that Paul can produce no decode of my aborted transmission, i'm announcing a new attempt for the same message, but this time in shorter daily repetitions that can be added coherently (like in WOLF mode): *f = 5170.000000 Hz Start time: 10.Jan.2017 08:00:00 UTC Symbol period: 24 s Characters: 20 CRC bits: 16 Coding 8K19A Duration: 8h, 12m, 48s Antenna current: ~ 225 mA* 73, Stefan Am 09.01.2017 13:30, schrieb DK7FC: > Unfortunately the transmission has stopped at 11:26 UTC, which is 6h > 4min 40s to early. I don't know why :-(. No reason can be found in > SpecLab (no scheduled actions active). The parameter a=0.5 which means > that the transmission is off, so it was stopped by software. But there > is no reason why a was set to 0.5 it this time. I also checked that > the txt file has 2560 symbols. And the symbol length is correctly set > to 64s which one can also see on the first sideband minima in the 424 > uHz spectrogram which came a bit closer to +-15 mHz.Very odd! The > transmission should have run until 17:30:40 UTC. > That's a clear disadvantage of such long messages sent into a single > (non-stacked) transmission, if something happens after 70% of the TX > time, everything can be lost. > > Paul, maybe the part that was sent until now is already enough to get > a decode? This will be a very hard challenge and i'm not so optimistic :-( > Now its up to you... > > 73, Stefan > > > Am 07.01.2017 19:08, schrieb DK7FC: >> Thanks Paul (and Renato and Wolf!), very well! >> >> The carrier on 5170.001250 Hz is still on the air and will run until >> 18 UTC. >> >> Since it appears that you and Jacek are the only ones trying to >> receive my EbNaut, i'll stay at 16K25A, just to use the better code gain. >> And since the last ~ 24 hour experiment was running so well, let's >> try 48 hours! Maybe it leads to a 30 0 30 0 phase pattern: >> >> *f = 5170.000000 Hz >> Start time: 07.Jan.2017 20:00:00 UTC >> Symbol length: 64 s >> Characters: 20 >> CRC 16 >> Coding 16K25A >> Duration: 45h, 30m, 40s >> Antenna current: ~ 225 mA* >> >> The first time i used your calculator >> (http://abelian.org/ebnaut/calc.php?sndb=-63&snbws=2500&snmps=&code=16K25&sp=64&crc=16&nc=20&submit=Calculate >> ) to chosse the number of characters and the symbol length BEFORE the >> transmission :-) >> >> With your given RAM, how many characters can you decode in 16K25A? >> And how long does the decode process take then? >> >> These 2 day long transmissions mostly failed on 6.47 kHz, or gave >> poor results. Stacked single day transmissions were a better choice. >> For a 50 or 75 character message on 5170 Hz we may have to use the >> same technique. >> >> I'm often thinking about the old VLF propagation graphs >> https://dl.dropboxusercontent.com/u/19882028/VLF/fig_02_25a.png (what >> was the original paper where it comes from?) which make more and more >> sense to me! On 5170 Hz we already see a real advantage of lower QRN >> relative to 8270 Hz or 6470 Hz. According to the graphs, the optimum >> frequency should be arround 4 kHz because the QRN from far away is >> attenuated much more whereas the poor propagation on that frequency >> is not so much expressed for 'short' (1000 km) distances. And BTW, 4 >> is a very nice number, isn't it!? Sooner or later someone has to do >> something near 4 kHz! I would be curious to see how this band (e.g. >> 4270 Hz or 70 km!) behaves. I can imagine that it is the best choice, >> even in summer or especially in summer! >> When looking on the todays 'wideband' window (the upper one on >> http://www.iup.uni-heidelberg.de/schaefer_vlf/DK7FC_VLF_Grabber2.html) we >> can see that we are already diving below the QRN :-) >> >> 73, Stefan >> >> >> >> Am 07.01.2017 05:09, schrieb Paul Nicholson: >>> >>> Decoded '73 DK7FC' from Cumiana (Renato Romero, vlf15, 504.6km) >>> with constant ref phase, Eb/N0 = 0.6, S/N 16.16 dB in 11.8 uHz, >>> -67dB in 2.5kHz. >>> >>> Very strong at Bielefeld (Wolf Buescher, vlf6, 303.8km) >>> Eb/N0 11.6dB, 27.17 dB in 11.8 uHz, -56.1dB in 2.5kHz, >>> constant reference phase. >>> >>> >>> Here, improved my decode to 3.9dB when I remembered to use the >>> -a option which normalises the amplitude by the average noise. >>> >>> I am not seeing much day/night phase shift at any site. Some >>> measurements on the carrier will be the next job. >>> >>> -- >>> Paul Nicholson >>> -- >>> --------------000900020004080405010707 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit VLF,

In the event that Paul can produce no decode of my aborted transmission, i'm announcing a new attempt for the same message, but this time in shorter daily repetitions that can be added coherently (like in WOLF mode):

f = 5170.000000 Hz
Start time: 10.Jan.2017   08:00:00 UTC
Symbol period: 24 s
Characters: 20
CRC bits: 16
Coding 8K19A
Duration: 8h, 12m, 48s
Antenna current: ~ 225 mA

73, Stefan


Am 09.01.2017 13:30, schrieb DK7FC:
Unfortunately the transmission has stopped at 11:26 UTC, which is 6h 4min 40s to early. I don't know why :-(. No reason can be found in SpecLab (no scheduled actions active). The parameter a=0.5 which means that the transmission is off, so it was stopped by software. But there is no reason why a was set to 0.5 it this time. I also checked that the txt file has 2560 symbols. And the symbol length is correctly set to 64s which one can also see on the first sideband minima in the 424 uHz spectrogram which came a bit closer to +-15 mHz.Very odd! The transmission should have run until 17:30:40 UTC.
That's a clear disadvantage of such long messages sent into a single (non-stacked) transmission, if something happens after 70% of the TX time, everything can be lost.

Paul, maybe the part that was sent until now is already enough to get a decode? This will be a very hard challenge and i'm not so optimistic :-(
Now its up to you...

73, Stefan


Am 07.01.2017 19:08, schrieb DK7FC:
Thanks Paul (and Renato and Wolf!), very well!

The carrier on 5170.001250 Hz is still on the air and will run until 18 UTC.

Since it appears that you and Jacek are the only ones trying to receive my EbNaut, i'll stay at 16K25A, just to use the better code gain.
And since the last ~ 24 hour experiment was running so well, let's try 48 hours! Maybe it leads to a 30 0 30 0 phase pattern:

f = 5170.000000 Hz
Start time: 07.Jan.2017   20:00:00 UTC
Symbol length: 64 s
Characters: 20
CRC 16
Coding 16K25A
Duration: 45h, 30m, 40s
Antenna current: ~ 225 mA

The first time i used your calculator (http://abelian.org/ebnaut/calc.php?sndb=-63&snbws=2500&snmps=&code=16K25&sp=64&crc=16&nc=20&submit=Calculate ) to chosse the number of characters and the symbol length BEFORE the transmission :-)

With your given RAM, how many characters can you decode in 16K25A? And how long does the decode process take then?

These 2 day long transmissions mostly failed on 6.47 kHz, or gave poor results. Stacked single day transmissions were a better choice. For a 50 or 75 character message on 5170 Hz we may have to use the same technique.

I'm often thinking about the old VLF propagation graphs https://dl.dropboxusercontent.com/u/19882028/VLF/fig_02_25a.png (what was the original paper where it comes from?) which make more and more sense to me! On 5170 Hz we already see a real advantage of lower QRN relative to 8270 Hz or 6470 Hz. According to the graphs, the optimum frequency should be arround 4 kHz because the QRN from far away is attenuated much more whereas the poor propagation on that frequency is not so much expressed for 'short' (1000 km) distances. And BTW, 4 is a very nice number, isn't it!? Sooner or later someone has to do something near 4 kHz! I would be curious to see how this band (e.g. 4270 Hz or 70 km!) behaves. I can imagine that it is the best choice, even in summer or especially in summer!
When looking on the todays 'wideband' window (the upper one on http://www.iup.uni-heidelberg.de/schaefer_vlf/DK7FC_VLF_Grabber2.html) we can see that we are already diving below the QRN :-)

73, Stefan



Am 07.01.2017 05:09, schrieb Paul Nicholson:

Decoded '73 DK7FC' from Cumiana (Renato Romero, vlf15, 504.6km)
with constant ref phase, Eb/N0 = 0.6, S/N 16.16 dB in 11.8 uHz,
-67dB in 2.5kHz.

Very strong at Bielefeld (Wolf Buescher, vlf6, 303.8km)
Eb/N0 11.6dB, 27.17 dB in 11.8 uHz, -56.1dB in 2.5kHz,
constant reference phase.


Here, improved my decode to 3.9dB when I remembered to use the
-a option which normalises the amplitude by the average noise.

I am not seeing much day/night phase shift at any site.  Some
measurements on the carrier will be the next job.

--
Paul Nicholson
--

--------------000900020004080405010707--