Message-ID: <4F2AD231.3020005@freenet.de>
Date: Thu, 02 Feb 2012 19:13:05 +0100
From: wolf_dl4yhf <dl4yhf@freenet.de>
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> <BF4A524700075746A6467658DFC7102CB0B68CCD76@ICTS-S-EXC2-CA.luna.kuleuven.be>
In-Reply-To: <BF4A524700075746A6467658DFC7102CB0B68CCD76@ICTS-S-EXC2-CA.luna.kuleuven.be>
Subject: Re: LF: RE: Progress using WOLF on VLF
Content-Type: multipart/alternative;
 boundary="------------010901050105070703060404"
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
X-AOL-SCOLL-URL_COUNT: 0  
x-aol-sid: 3039ac1d601a4f2addb93065
X-AOL-IP: 195.171.43.25
X-AOL-SPF: domain : blacksheep.org SPF : none


This is a multi-part message in MIME format.
--------------010901050105070703060404
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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 .



--------------010901050105070703060404
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Stefan,<br>
    <br>
    about your question:<br>
    <br>
    <br>
    <blockquote
cite="mid:BF4A524700075746A6467658DFC7102CB0B68CCD76@ICTS-S-EXC2-CA.luna.kuleuven.be"
      type="cite">
      <div style="font-family: Tahoma; direction: ltr; color: rgb(0, 0,
        0); font-size: 13px;">
        <div>
          <br>
          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
          <i>about</i> the same time to get the first decode. Any
          comments?<br>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    <br>
    <blockquote
cite="mid:BF4A524700075746A6467658DFC7102CB0B68CCD76@ICTS-S-EXC2-CA.luna.kuleuven.be"
      type="cite">
      <div style="font-family: Tahoma; direction: ltr; color: rgb(0, 0,
        0); font-size: 13px;">
        <div>
          Right now i feeld that i am missing a spectrogram which i can
          show here. Just text! Odd.
          <br>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
    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. <br>
    I just wasn't aware of this when I wrote the graphic user interface
    for Stewart's WOLF decoder.<br>
    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.<br>
    <br>
    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).<br>
    <br>
    <br>
    &nbsp;&nbsp; Wolf&nbsp; DL4YHF .<br>
    <br>
    <br>
  </body>
</html>

--------------010901050105070703060404--