Return-Path: Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by mtain-md02.r1000.mx.aol.com (Internet Inbound) with ESMTP id E3303380000B5; Thu, 2 Feb 2012 14:47:14 -0500 (EST) Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1Rt1oT-0000FK-LH for rs_out_1@blacksheep.org; Thu, 02 Feb 2012 18:55:17 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1Rt1oT-0000FA-5h for rsgb_lf_group@blacksheep.org; Thu, 02 Feb 2012 18:55:17 +0000 Received: from relay.uni-heidelberg.de ([129.206.100.212]) by relay1.thorcom.net with esmtp (Exim 4.63) (envelope-from ) id 1Rt1oS-0006FP-L0 for rsgb_lf_group@blacksheep.org; Thu, 02 Feb 2012 18:55:17 +0000 Received: from freitag.iup.uni-heidelberg.de (freitag.iup.uni-heidelberg.de [129.206.29.204]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id q12ItFk4014297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Feb 2012 19:55:15 +0100 Received: from [129.206.22.206] (pc206.iup.uni-heidelberg.de [129.206.22.206]) by freitag.iup.uni-heidelberg.de (8.12.11.20060308/8.11.2) with ESMTP id q12ItFHI024085 for ; Thu, 2 Feb 2012 19:55:15 +0100 Message-ID: <4F2ADBF6.9090605@iup.uni-heidelberg.de> Date: Thu, 02 Feb 2012 19:54:46 +0100 From: =?ISO-8859-1?Q?Stefan_Sch=E4fer?= 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: <000001cce062$f75dfad0$e619f070$@broadpark.no> <8CEAED202205706-C78-2162B@webmail-stg-m04.sysops.aol.com> <4F2929BD.4070308@charter.net> <4F2946AE.6040205@iup.uni-heidelberg.de>,<4F2AC269.7090605@iup.uni-heidelberg.de> <4F2AD231.3020005@freenet.de> In-Reply-To: <4F2AD231.3020005@freenet.de> X-Spam-Score: 1.4 (+) X-Spam-Report: autolearn=disabled,HTML_MESSAGE=0.001,RATWARE_GECKO_BUILD=1.426 Subject: Re: LF: RE: Progress using WOLF on VLF Content-Type: multipart/alternative; boundary="------------080004000701080102070905" 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 x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:446858848:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d60564f2ae84241aa X-AOL-IP: 195.171.43.25 X-AOL-SPF: domain : blacksheep.org SPF : none This is a multi-part message in MIME format. --------------080004000701080102070905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Wolf, Thank you. And what about WOLF included within SpecLab? This would help a lot, regarding the drift and offset compensation, especially for the receive stations. Do you think it could be implemented into the digimode terminal? 73, Stefan Am 02.02.2012 19:13, schrieb wolf_dl4yhf: > Hi Stefan, > > about your question: > > >> >> Then i've done several tests using different frequency tolerance >> values (above: t = 0.3 Hz). After calibrating the soundcard by using >> the shown offset, the offset was 0, consequencial ;-) But even if a >> tolerance of 0.002 Hz was choosen, it still took /about/ the same >> time to get the first decode. Any comments? >> > > The reason is, the WOLF decoder processes an entire band > simultaneously. It's like having a bunch of receivers working in > parallel, each of them looking on its own frequency. This is the > reason why the CPU load from the decoder increases dramatically when > using a larger frequency tolerance. > > >> Right now i feeld that i am missing a spectrogram which i can show >> here. Just text! Odd. >> > > One possibility to have a spectrogram-like display would be to square > the 'downconverted' (baseband) WOLF signal. The spectrum of the > squared signal should show distinct lines as already mentioned by Markus. > I just wasn't aware of this when I wrote the graphic user interface > for Stewart's WOLF decoder. > In the normal spectrum, you will indeed hardly notice the WOLF signal, > which renders the display quite useless as the indicator for the > 'presence' of a signal. The trace gets invisible in the spectrogram > long before it drops below the level for successful decoding. > > All the best and good luck with the VLF tests, it's very interesting. > Especially when considering the possibilities with GPS-based > synchronisation (which, of course, does *not* exist in the present > implementations of the decoder). > > > Wolf DL4YHF . > > --------------080004000701080102070905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Wolf,

Thank you.
And what about WOLF included within SpecLab? This would help a lot, regarding the drift and offset compensation, especially for the receive stations. Do you think it could be implemented into the digimode terminal?

73, Stefan

Am 02.02.2012 19:13, schrieb wolf_dl4yhf:
Hi Stefan,

about your question:



Then i've done several tests using different frequency tolerance values (above: t = 0.3 Hz). After calibrating the soundcard by using the shown offset, the offset was 0, consequencial ;-) But even if a tolerance of 0.002 Hz was choosen, it still took about the same time to get the first decode. Any comments?


The reason is, the WOLF decoder processes an entire band simultaneously. It's like having a bunch of receivers working in parallel, each of them looking on its own frequency. This is the reason why the CPU load from the decoder increases dramatically when using a larger frequency tolerance.


Right now i feeld that i am missing a spectrogram which i can show here. Just text! Odd.


One possibility to have a spectrogram-like display would be to square the 'downconverted' (baseband) WOLF signal. The spectrum of the squared signal should show distinct lines as already mentioned by Markus.
I just wasn't aware of this when I wrote the graphic user interface for Stewart's WOLF decoder.
In the normal spectrum, you will indeed hardly notice the WOLF signal, which renders the display quite useless as the indicator for the 'presence' of a signal. The trace gets invisible in the spectrogram long before it drops below the level for successful decoding.

All the best and good luck with the VLF tests, it's very interesting. Especially when considering the possibilities with GPS-based synchronisation (which, of course, does *not* exist in the present implementations of the decoder).


   Wolf  DL4YHF .


--------------080004000701080102070905--