Received-SPF: neutral (google.com: 195.171.43.25 is neither permitted nor denied by best guess record for domain of owner-rsgb_lf_group@blacksheep.org) client-ip=195.171.43.25;
Message-ID: <5310AEE1.3090209@freenet.de>
Date: Fri, 28 Feb 2014 16:44:33 +0100
From: wolf_dl4yhf <dl4yhf@freenet.de>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: rsgb_lf_group@blacksheep.org
References: <a3ab7a8e59cc48f5a6714915278e05f6@kabelmail.de> <B113BF3D526D426DB240EE3730BB1C54@White> <B288B88E668242CAA91FC4A2F15EA298@Extensa>
In-Reply-To: <B288B88E668242CAA91FC4A2F15EA298@Extensa>
Subject: Re: LF: SL. 47 uHz vs. 16 uHz @ 8270.005 Hz
Content-Type: multipart/alternative;
 boundary="------------080900030801060700060401"
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org

This is a multi-part message in MIME format.
--------------080900030801060700060401
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Hi Peter and all,

Am 28.02.2014 16:21, schrieb PA1SDB, Peter:
> Hello VLF.
> Just a experience message !
> It seems that there is somewhere a perfect setting in "Width of 
> FFT-bin", but where ?

A good question.. and not easily answered. I'd say "it all depends".
In this case, it depends on the soundcard's oscillator stability, 
despite stabilisation from the GPS sync pulse.
At 16 uHz frequency we seem to have reached a limit (for this type of 
oscillator drift compensation).

The next logical step would be building an A/D converter, or modifying a 
USB audio device to take the samping clock directly off a low-noise 
'rock-solid reference' (a good GPS disciplined OCXO for example).
I have fragments for such a project laying on the workbench (a low-cost 
Cortex-M3 microcontroller development kit) but no time yet to put the 
bits (bytes) and pieces together.
At least, one would know of the Ionosphere (stability of the path 
length) or whatever else is the limiting factor.


GL and all the best,
   Wolf .


--------------080900030801060700060401
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi Peter and all,<br>
      <br>
      Am 28.02.2014 16:21, schrieb PA1SDB, Peter:<br>
    </div>
    <blockquote cite="mid:B288B88E668242CAA91FC4A2F15EA298@Extensa"
      type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      <meta name="GENERATOR" content="MSHTML 8.00.6001.19088">
      <style></style>
      <div><font face="Georgia">Hello VLF.</font></div>
      <div><font face="Georgia">Just a experience message !</font></div>
      <div> </div>
      <div><font face="Georgia">It seems that there is somewhere a
          perfect setting in "Width of FFT-bin", but where ?</font></div>
    </blockquote>
    <br>
    A good question.. and not easily answered. I'd say "it all depends".<br>
    In this case, it depends on the soundcard's oscillator stability,
    despite stabilisation from the GPS sync pulse.<br>
    At 16 uHz frequency we seem to have reached a limit (for this type
    of oscillator drift compensation).<br>
    <br>
    The next logical step would be building an A/D converter, or
    modifying a USB audio device to take the samping clock directly off
    a low-noise 'rock-solid reference' (a good GPS disciplined OCXO for
    example).<br>
    I have fragments for such a project laying on the workbench (a
    low-cost Cortex-M3 microcontroller development kit) but no time yet
    to put the bits (bytes) and pieces together.<br>
    At least, one would know of the Ionosphere (stability of the path
    length) or whatever else is the limiting factor.<br>
    <br>
    <br>
    GL and all the best,<br>
      Wolf .<br>
    <br>
  </body>
</html>

--------------080900030801060700060401--