DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=IxXi6Or8x9vm8WxQhkSA4/mYG8ZEqwLr1KQKvdHXV6P5Z2/b74Z28PJgYU7bkd9LAO
         WLUl8los0fgj9zg6cnGxq0QmX4mXSMkrliotULZElDoOe1faQq9IQfRbI18h9AXdZ63v
         BobaHLvOT8/7pqU9EU+zDejfDdPk1A6/EV0fo=
MIME-Version: 1.0
In-Reply-To: <6F4ACB3DA2BB4E338E9278EEDE300D20@JimPC>
References: <AANLkTiksDowcKxyJ86R=p-4SqvwcbAQBjQrGY1efm_jN@mail.gmail.com>
	<003201cbde72$606d6090$0401a8c0@xphd97xgq27nyf>
	<543492.45357.qm@web28102.mail.ukl.yahoo.com>
	<998C9385-2AEE-4C44-91FE-86FE85F09BA9@gmail.com>
	<6F4ACB3DA2BB4E338E9278EEDE300D20@JimPC>
Date: Thu, 10 Mar 2011 08:13:18 +0000
Message-ID: <AANLkTik6F--j+dEgRAp9kgJoWxsjrNbyvYxTcgQsiLPH@mail.gmail.com>
From: Andy Talbot <andy.g4jnt@gmail.com>
To: rsgb_lf_group@blacksheep.org
DomainKey-Status: good (testing) 
Subject: Re: LF: Re: VLF Stability and soundcard locking
Content-Type: multipart/alternative; boundary=00151773e34000569d049e1c6b56
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org


--00151773e34000569d049e1c6b56
Content-Type: text/plain; charset=ISO-8859-1

That is very much what I feared would happen.

USB interfaces run based on a  clock of 6MHz, which is unfortunately an
exact sub-multiple of the codec reference.   So the difference between the
clock in the transmitter (the codec) and the receiver (the PC) will cause a
regular slippage.

Now, soundcards communicate on USB using Isochronous mode which sacrifices
data accuracy in favor of guaranteed timing of data delivery.   Other USB
modes perform error checking and repeat failed packets, or are simple Human
Interfaces (HID) like keyboards and mice which have low occasional data rate
and no checking.

When you plug other devices into the bus, the negotiaion going on takes up
some overhead and you'll lose more data blocks.

So, we are forced to accept data  glitches and resulting sampling rate
errors in USB soundcards.

The only way to overcome this, is to force the USB to use another protocol,
which means not using a plug-and-play soundcard chip / headphone dongle, or
whatever.   This means a dedicated A/D converter, glue logic - which is
probably going to have to be FPGA based, a PIC or like probably won't be
able to hack-it - and a proper fully corrected USB link.

Such interfaces already exist and are in the mainstearm of amateur
radio. They are   *Direct Sampling SDRs*.  The SDR-IQ has a sampling rate
defined only by its on board 66.6666MHz clock (which can come from a locked
reference) and sends error corrected packets to the host.   Other radios use
Ethernet instead of USB for a faster transfer rate.

That's life.   Mind you, when I get round to it, still going to get that
chip operational with a locked reference 12MHz and accurately measure its
sampling rate.   If it is not exactly 48kHz then we know the USB channel has
to be at fault.

One thing that PCM2900 codec chip is useful for - its the only soundcard I
know of that DOESN'T  allow you to change the recording level.   Voltage in
is related to digits out - exactly.    So that makes it of inestimably more
use in soundcard based test equipment as you don't have to keep making a
level calibration check every other measurement.   As far as I recall, it is
even calibrated by design, so a 1VRMS sine (2.82V pk-pk) is full scale.

Andy
www.g4jnt.com



On 10 March 2011 01:28, James Moritz <james.moritz@btopenworld.com> wrote:

> Dear Andy, LF Group,
>
> Not sure if the first mail I sent on this topic ever got through - not to
> me, anyway...
>
> I have been using a USB sound card for VLF reception with my lap-top PC,
> and, like all the PCs/sound cardsI have tried, it shows what appear to be
> transient changes in the sample rate from time to time. It uses an
> integrated codec/usb interface chip similar to the device Andy mentioned,
> with a 12MHz clock crystal. I measured the actual clock frequency, which is
> about +47ppm from nominal. With a suitable stable calibration source, and
> 48kHz sample rate, Spec Lab indicated a sample rate error of -87ppm. The SR
> compensation facility in Spec Lab makes the indicated frequency on the
> spectrogram correct to within a fraction of 1ppm. The sample rate calibrator
> reflects exactly the slow thermal drift of the sound card crystal, less than
> 1ppm, but always with the much larger and constant offset of about 130ppm in
> total from what you would expect. Changing the sample rate to 44.1kHz gave
> an indicated sample rate error of -115ppm. I found by accident that plugging
> a USB memory stick into another USB port on the laptop caused the sample
> rate to change as well - just plugging it in gave a brief glitch of several
> ppm, but opening the folders on the USB stick resulted in an additional
> -81ppm shift, which remained until the USB stick was unplugged again, when
> the SR returned to the previous value. The actual 12MHz clock frequency was
> not noticeably affected by any of this activity.
>
> In addition to these apparently stable shifts in sample rate, transients
> occur now and again of several ppm, aparently at random, maybe once an hour
> on average. These give rise to glitches in a strong trace on a spectrogram
> with resolution about 1mHz. But on weak amateur signals these would probably
> not be visible, since the transient sidebands mostly only last for a few
> pixels and are 20 or 30dB below the main spectral line, which remains on the
> correct frequency. However, I think when one gets into the microhertz
> resolution range, it would be a problem, because the transients occur often
> enough to merge together and smear out the spectral line.
>
> Cheers, Jim Moritz
> 73 de M0BMU
>
>

--00151773e34000569d049e1c6b56
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>That is very much what I feared would happen.</div>
<div>=A0</div>
<div>USB interfaces run based on a=A0 clock of 6MHz, which is unfortunatel=
y an exact sub-multiple of the codec reference.=A0=A0 So the difference be=
tween the clock in the transmitter (the codec) and the receiver (the PC)=
 will cause a regular slippage.=A0=A0 </div>

<div>=A0</div>
<div>Now, soundcards communicate on USB using Isochronous mode which sacri=
fices data accuracy in favor of guaranteed timing of data delivery.=A0=A0=
 Other USB modes perform error checking and repeat failed packets, or are=
 simple Human Interfaces (HID) like keyboards and mice which have low occa=
sional data rate and no checking.</div>

<div>=A0</div>
<div>When you plug other devices into the bus, the negotiaion going on tak=
es up some overhead and you&#39;ll lose more data blocks.</div>
<div>=A0</div>
<div>So, we are forced to accept data=A0 glitches and resulting sampling=
 rate errors in USB soundcards.</div>
<div>=A0</div>
<div>The only way to overcome this, is to force the USB to use another pro=
tocol, which means not using a plug-and-play soundcard chip / headphone do=
ngle, or whatever.=A0=A0 This means a dedicated A/D converter, glue logic=
 - which is probably going to have to be FPGA based, a PIC or like probabl=
y won&#39;t be able to hack-it - and a proper fully corrected USB link.=A0=
=A0 </div>

<div>=A0</div>
<div>Such interfaces already exist and are in the mainstearm of amateur ra=
dio.=A0They are =A0 <u>Direct Sampling SDRs</u>.=A0 The SDR-IQ has a sampl=
ing rate defined only by its on board 66.6666MHz clock (which can come fro=
m a locked reference) and sends error corrected packets to the host.=A0=A0=
 Other radios use Ethernet instead of USB for a faster transfer rate.</div=
>

<div>=A0</div>
<div>That&#39;s life.=A0=A0 Mind you, when I get round to it, still going=
 to get that chip operational with a locked reference 12MHz and accurately=
 measure its sampling rate.=A0=A0 If it is not exactly 48kHz then we know=
 the USB channel has to be at fault.</div>

<div>=A0</div>
<div>One thing that PCM2900 codec chip is useful for - its the only soundc=
ard I know of that DOESN&#39;T=A0 allow you to change the recording level.=
=A0=A0 Voltage in is related to digits=A0out - exactly.=A0=A0=A0 So that=
 makes it of inestimably more use in soundcard based test equipment as you=
 don&#39;t have to keep making a level calibration check every other measu=
rement.=A0=A0 As far as=A0I recall, it=A0is even calibrated by design, so=
 a 1VRMS sine (2.82V pk-pk) is full scale.</div>

<div>=A0</div>
<div>Andy</div>
<div><a href=3D"http://www.g4jnt.com/">www.g4jnt.com</a></div>
<div><br><br>=A0</div>
<div class=3D"gmail_quote">On 10 March 2011 01:28, James Moritz <span dir=
=3D"ltr">&lt;<a href=3D"mailto:james.moritz@btopenworld.com">james.moritz@=
btopenworld.com</a>&gt;</span> wrote:<br>
<blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8e=
x; PADDING-LEFT: 1ex" class=3D"gmail_quote">Dear Andy, LF Group,<br><br>No=
t sure if the first mail I sent on this topic ever got through - not to me=
, anyway...<br>
<br>I have been using a USB sound card for VLF reception with my lap-top=
 PC, and, like all the PCs/sound cardsI have tried, it shows what appear=
 to be transient changes in the sample rate from time to time. It uses an=
 integrated codec/usb interface chip similar to the device Andy mentioned,=
 with a 12MHz clock crystal. I measured the actual clock frequency, which=
 is about +47ppm from nominal. With a suitable stable calibration source,=
 and 48kHz sample rate, Spec Lab indicated a sample rate error of -87ppm.=
 The SR compensation facility in Spec Lab makes the indicated frequency on=
 the spectrogram correct to within a fraction of 1ppm. The sample rate cal=
ibrator reflects exactly the slow thermal drift of the sound card crystal,=
 less than 1ppm, but always with the much larger and constant offset of ab=
out 130ppm in total from what you would expect. Changing the sample rate=
 to 44.1kHz gave an indicated sample rate error of -115ppm. I found by acc=
ident that plugging a USB memory stick into another USB port on the laptop=
 caused the sample rate to change as well - just plugging it in gave a bri=
ef glitch of several ppm, but opening the folders on the USB stick resulte=
d in an additional -81ppm shift, which remained until the USB stick was un=
plugged again, when the SR returned to the previous value. The actual 12MH=
z clock frequency was not noticeably affected by any of this activity.<br>
<br>In addition to these apparently stable shifts in sample rate, transien=
ts occur now and again of several ppm, aparently at random, maybe once an=
 hour on average. These give rise to glitches in a strong trace on a spect=
rogram with resolution about 1mHz. But on weak amateur signals these would=
 probably not be visible, since the transient sidebands mostly only last=
 for a few pixels and are 20 or 30dB below the main spectral line, which=
 remains on the correct frequency. However, I think when one gets into the=
 microhertz resolution range, it would be a problem, because the transient=
s occur often enough to merge together and smear out the spectral line.<br=
>
<br>Cheers, Jim Moritz<br>73 de M0BMU <br><br></blockquote></div><br>

--00151773e34000569d049e1c6b56--