Return-Path: Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by mtain-dh01.r1000.mx.aol.com (Internet Inbound) with ESMTP id 138113800009A; Fri, 3 Feb 2012 15:02:31 -0500 (EST) Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1RtPKB-0008SF-Sh for rs_out_1@blacksheep.org; Fri, 03 Feb 2012 20:01:35 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1RtPKA-0008S6-Li for rsgb_lf_group@blacksheep.org; Fri, 03 Feb 2012 20:01:34 +0000 Received: from mout0.freenet.de ([195.4.92.90]) by relay1.thorcom.net with esmtp (Exim 4.63) (envelope-from ) id 1RtPK9-0001aX-0e for rsgb_lf_group@blacksheep.org; Fri, 03 Feb 2012 20:01:34 +0000 Received: from [195.4.92.140] (helo=mjail0.freenet.de) by mout0.freenet.de with esmtpa (ID dl4yhf@freenet.de) (port 25) (Exim 4.76 #1) id 1RtMJA-0001QG-Ni for rsgb_lf_group@blacksheep.org; Fri, 03 Feb 2012 17:48:23 +0100 Received: from localhost ([::1]:47459 helo=mjail0.freenet.de) by mjail0.freenet.de with esmtpa (ID dl4yhf@freenet.de) (Exim 4.76 #1) id 1RtMJK-0003tu-8z for rsgb_lf_group@blacksheep.org; Fri, 03 Feb 2012 17:48:30 +0100 Received: from [195.4.92.26] (port=40075 helo=16.mx.freenet.de) by mjail0.freenet.de with esmtpa (ID dl4yhf@freenet.de) (Exim 4.76 #1) id 1RtMGr-0001Wg-9V for rsgb_lf_group@blacksheep.org; Fri, 03 Feb 2012 17:45:57 +0100 Received: from blfd-4db01883.pool.mediaways.net ([77.176.24.131]:3482 helo=[192.168.178.22]) by 16.mx.freenet.de with esmtpsa (ID dl4yhf@freenet.de) (TLSv1:CAMELLIA256-SHA:256) (port 465) (Exim 4.76 #1) id 1RtMGq-0008Or-PZ for rsgb_lf_group@blacksheep.org; Fri, 03 Feb 2012 17:45:57 +0100 Message-ID: <4F2C0F43.4050209@freenet.de> Date: Fri, 03 Feb 2012 17:45:55 +0100 From: wolf_dl4yhf User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 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> <4F2ADBF6.9090605@iup.uni-heidelberg.de> In-Reply-To: <4F2ADBF6.9090605@iup.uni-heidelberg.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="------------090909020604090204040104" 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:388123904:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d41154f2c3d56292f X-AOL-IP: 195.171.43.25 X-AOL-SPF: domain : blacksheep.org SPF : none This is a multi-part message in MIME format. --------------090909020604090204040104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Stefan, Integrate WOLF in SpecLab - too much overkill. The program (SL) is, imo, already too overloaded with functions as it grew over the years. Maybe, after everything inside SL uses GPS-based timestamps (like Paul Nicholson's VLF RX Tools), there will be a simple interface to feed the resampled audio stream (which would then have *exactly* 24000, 32000, or 48000 samples / second plus a timestamp for each sample with an accuracy in the microsecond range) towards other programs, using a TCP/IP based method, or a shared memory buffer (as in Paul's VLF RX Toolchain). THEN, after all that being finished, the WOLF GUI would be one of the first external applications which would make use of the system described above. Together with Paul I am currently comparing different algorithms for the resampling / interpolation. Some of them look attractive and simple on first glance, but give too much phase noise when one gets closer to the Nyquist frequency. But details about that would be way off-topic here. All the best, Wolf DL4YHF . Am 02.02.2012 19:54, schrieb Stefan Schäfer: > 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 . >> >> --------------090909020604090204040104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Stefan,

Integrate WOLF in SpecLab - too much overkill. The program (SL) is, imo, already too overloaded with functions as it grew over the years. Maybe, after everything inside SL uses GPS-based timestamps (like Paul Nicholson's VLF RX Tools), there will be a simple interface to feed the resampled audio stream (which would then have *exactly* 24000, 32000, or 48000 samples / second plus a timestamp for each sample with an accuracy in the microsecond range) towards other programs, using a TCP/IP based method, or a shared memory buffer (as in Paul's VLF RX Toolchain). THEN, after all that being finished, the WOLF GUI would be one of the first external applications which would make use of the system described above.

Together with Paul I am currently comparing different algorithms for the resampling / interpolation. Some of them look attractive and simple on first glance, but give too much phase noise when one gets closer to the Nyquist frequency. But details about that would be way off-topic here.

All the best,
    Wolf   DL4YHF .

Am 02.02.2012 19:54, schrieb Stefan Schäfer:
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 .



--------------090909020604090204040104--