Message-ID: <4DC95DAD.4050302@freenet.de>
Date: Tue, 10 May 2011 17:45:49 +0200
From: wolf_dl4yhf <dl4yhf@freenet.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: rsgb_lf_group@blacksheep.org
References: <4DC572F2.9050003@telus.net> <4DC5AB0F.4090507@iup.uni-heidelberg.de> <4DC85118.6060408@freenet.de> <4DC90515.5010203@iup.uni-heidelberg.de> <002d01cc0efc$28f4c8a0$4001a8c0@lark> <4DC91E37.6030406@iup.uni-heidelberg.de> <8CDDD31928FFEDD-DC8-61A7@webmail-d136.sysops.aol.com>
In-Reply-To: <8CDDD31928FFEDD-DC8-61A7@webmail-d136.sysops.aol.com>
Subject: Re: LF: Spectrum Lab Filtering...
Content-Type: multipart/alternative;
 boundary="------------020603080506010407020907"
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org


--------------020603080506010407020907
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Markus and group,

Am 10.05.2011 15:59, schrieb Markus Vester:
> Hi there,
> I think Wolf's idea is to lock to 1 pps pulses from the GPS, and use 
> the NMEA data to uniquely identify the second of each pulse. This will 
> allow SpecLab to brigde data outages or sound buffer overflows on 
> receive.
Exactly, that's one of the motivations. You will need a GPS receiver 
with NMEA *and* sync pulse ("pps") output. Both signals are added with a 
passive combiner, fed into the soundcard, and the software does the 
rest. The timing jitter for the NMEA strings doesn't matter at all.

Markus wrote:
> I do not know if that technique could be used to stabilize sound 
> output for transmitting as well. One would probably have to monitor 
> the output, and then apply phase corrections if necessary.

Yes, the problem will be the unknown, and possibly not constant 'output 
latency' of the soundcard, and its driver software.

Cheers,
    Wolf .


--------------020603080506010407020907
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Typ=
e">
    <title></title>
  </head>
  <body bgcolor=3D"#ffffff" text=3D"#000000">
    Hi Markus and group,<br>
    <br>
    Am 10.05.2011 15:59, schrieb Markus Vester:
    <blockquote        cite=3D"mid:8CDDD31928FFEDD-DC8-61A7@webmail-d136.s=
ysops.aol.com"        type=3D"cite"><font color=3D"black" face=3D"arial"=
 size=3D"2">
        <div>Hi there,</div>
        <div>=C2=A0</div>
        <div>I think Wolf's idea is to=C2=A0lock to 1 pps pulses from the
          GPS, and use the NMEA data to uniquely identify=C2=A0the second=
 of
          each pulse. This will allow=C2=A0SpecLab to brigde=C2=A0data out=
ages or
          sound buffer overflows on receive. </div>
      </font></blockquote>
    Exactly, that's one of the motivations. You will need a GPS receiver
    with NMEA *and* sync pulse ("pps") output. Both signals are added
    with a passive combiner, fed into the soundcard, and the software
    does the rest. The timing jitter for the NMEA strings doesn't matter
    at all. <br>
    <br>
    Markus wrote:<br>
    <blockquote        cite=3D"mid:8CDDD31928FFEDD-DC8-61A7@webmail-d136.s=
ysops.aol.com"        type=3D"cite"><font color=3D"black" face=3D"arial"=
 size=3D"2">
        <div>I do not know=C2=A0if that technique could be=C2=A0used to
          stabilize=C2=A0sound output=C2=A0for transmitting as well. One=
 would
          probably have to monitor the output, and then apply phase
          corrections if necessary.</div>
      </font></blockquote>
    <br>
    Yes, the problem will be the unknown, and possibly not constant
    'output latency' of the soundcard, and its driver software.<br>
    <br>
    Cheers,<br>
    =C2=A0=C2=A0 Wolf .<br>
    <br>
  </body>
</html>

--------------020603080506010407020907--