Return-Path: Received: from mtain-dd02.r1000.mx.aol.com (mtain-dd02.r1000.mx.aol.com [172.29.64.142]) by air-dd03.mail.aol.com (v129.4) with ESMTP id MAILINDD031-86094d78ada1c6; Thu, 10 Mar 2011 05:53:21 -0500 Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by mtain-dd02.r1000.mx.aol.com (Internet Inbound) with ESMTP id 3CB33380001E0; Thu, 10 Mar 2011 05:53:19 -0500 (EST) Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1PxdTv-0000t3-D6 for rs_out_1@blacksheep.org; Thu, 10 Mar 2011 10:52:35 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1PxdTu-0000su-Fn for rsgb_lf_group@blacksheep.org; Thu, 10 Mar 2011 10:52:34 +0000 Received: from imr-da03.mx.aol.com ([205.188.105.145]) by relay1.thorcom.net with esmtp (Exim 4.63) (envelope-from ) id 1PxdTt-0006oJ-8m for rsgb_lf_group@blacksheep.org; Thu, 10 Mar 2011 10:52:34 +0000 Received: from imo-da02.mx.aol.com (imo-da02.mx.aol.com [205.188.169.200]) by imr-da03.mx.aol.com (8.14.1/8.14.1) with ESMTP id p2AAqPu3019751 for ; Thu, 10 Mar 2011 05:52:25 -0500 Received: from MarkusVester@aol.com by imo-da02.mx.aol.com (mail_out_v42.9.) id l.ee9.119b4178 (43964) for ; Thu, 10 Mar 2011 05:52:21 -0500 (EST) Received: from smtprly-db03.mx.aol.com (smtprly-db03.mx.aol.com [205.188.249.154]) by cia-dd02.mx.aol.com (v129.9) with ESMTP id MAILCIADD025-5c3e4d78ad64396; Thu, 10 Mar 2011 05:52:21 -0500 Received: from webmail-m047 (webmail-m047.sim.aol.com [64.12.101.230]) by smtprly-db03.mx.aol.com (v129.9) with ESMTP id MAILSMTPRLYDB034-5c3e4d78ad64396; Thu, 10 Mar 2011 05:52:20 -0500 References: <003201cbde72$606d6090$0401a8c0@xphd97xgq27nyf><543492.45357.qm@web28102.mail.ukl.yahoo.com><998C9385-2AEE-4C44-91FE-86FE85F09BA9@gmail.com><6F4ACB3DA2BB4E338E9278EEDE300D20@JimPC> To: rsgb_lf_group@blacksheep.org Date: Thu, 10 Mar 2011 05:52:20 -0500 In-Reply-To: X-MB-Message-Source: WebUI MIME-Version: 1.0 From: Markus Vester X-MB-Message-Type: User X-Mailer: AOL Webmail 33356-STANDARD Received: from 194.138.39.55 by webmail-m047.sysops.aol.com (64.12.101.230) with HTTP (WebMailUI); Thu, 10 Mar 2011 05:52:20 -0500 Message-Id: <8CDAD285D1CFF01-CA8-63FE@webmail-m047.sysops.aol.com> X-Spam-Flag:NO X-AOL-SENDER: MarkusVester@aol.com X-Spam-Score: 1.2 (+) X-Spam-Report: autolearn=disabled,FORGED_AOL_TAGS=0.281,HTML_10_20=0.945,HTML_MESSAGE=0.001,UNPARSEABLE_RELAY=0.001 Subject: Re: LF: Re: VLF Stability and soundcard locking Content-Type: multipart/alternative; boundary="--------MB_8CDAD285D372E21_CA8_E926_webmail-m047.sysops.aol.com" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=FORGED_AOL_TAGS, HTML_FONTCOLOR_UNKNOWN,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-sid: 3039ac1d408e4d78ad9f0a69 X-AOL-IP: 195.171.43.25 X-AOL-SPF: domain : blacksheep.org SPF : none ----------MB_8CDAD285D372E21_CA8_E926_webmail-m047.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Andy, Jim, I am actually using a little USB plugin soundcard ("3D Sound" for 2.60 Eur= o) for my VLF grabber at 48 ks/s. Locking to GQD shows that samplerate has= remained fairly stable within a few tens of a ppm over the weeks. One interesting thing I noticed is that the samplerate seems to be control= led by the PC rather than the soundcard's onboard 12 MHz crystal. When I= plug a second soundcard of the same brand into the same PC, I get exactly= the same samplerate offset. The very same soundcard in a different PC giv= es a different offset. It looks as if the samplerate of these devices woul= d be controlled by the USB master clock. Best 73, Markus (DF6NM) -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Andy Talbot An: rsgb_lf_group@blacksheep.org Verschickt: Do., 10. Mrz. 2011, 9:13 Thema: Re: LF: Re: VLF Stability and soundcard locking That is very much what I feared would happen. =20 USB interfaces run based on a clock of 6MHz, which is unfortunately an ex= act 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. =20 =20 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 Hum= an Interfaces (HID) like keyboards and mice which have low occasional data= rate and no checking. =20 When you plug other devices into the bus, the negotiaion going on takes up= some overhead and you'll lose more data blocks. =20 So, we are forced to accept data glitches and resulting sampling rate err= ors in USB soundcards. =20 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. =20 =20 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 refer= ence) and sends error corrected packets to the host. Other radios use Et= hernet instead of USB for a faster transfer rate. =20 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. =20 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. Voltag= e in is related to digits out - exactly. So that makes it of inestimabl= y more use in soundcard based test equipment as you don't have to keep mak= ing a level calibration check every other measurement. As far as I recal= l, it is even calibrated by design, so a 1VRMS sine (2.82V pk-pk) is full= scale. =20 Andy www.g4jnt.com =20 On 10 March 2011 01:28, James Moritz 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 integr= ated codec/usb interface chip similar to the device Andy mentioned, with= a 12MHz clock crystal. I measured the actual clock frequency, which is ab= out +47ppm from nominal. With a suitable stable calibration source, and 48= kHz sample rate, Spec Lab indicated a sample rate error of -87ppm. The SR= compensation facility in Spec Lab makes the indicated frequency on the sp= ectrogram 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 accide= nt that plugging a USB memory stick into another USB port on the laptop ca= used 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 unp= lugged 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 ho= ur on average. These give rise to glitches in a strong trace on a spectrog= ram with resolution about 1mHz. But on weak amateur signals these would pr= obably 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 remai= ns on the correct frequency. However, I think when one gets into the micro= hertz resolution range, it would be a problem, because the transients occu= r often enough to merge together and smear out the spectral line. Cheers, Jim Moritz 73 de M0BMU=20 ----------MB_8CDAD285D372E21_CA8_E926_webmail-m047.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Hi Andy, Jim,
 
I am actually using a little USB plugin soundcard ("3D= Sound" for 2.60 Euro) for my VLF grabber at 48 ks/s. Locking to GQD shows= that samplerate has remained fairly stable within a few tens of a ppm ove= r the weeks.

One interesting thing I noticed is that the samplerate seems to be control= led by the PC rather than the soundcard's onboard 12 MHz crystal. When I= plug a second soundcard of the same brand into the same PC, I get ex= actly the same samplerate offset. The very same soundcard in a different= PC gives a different offset. It looks as if the samplerate = ;of these devices would be controlled by the USB master clock.
 
Best 73,
Markus (DF6NM)
-----Urspr=C3=BCngliche Mitteilung-----
Von: Andy Talbot <andy.g4jnt@gmail.com>
An: rsgb_lf_group@blacksheep.org
Verschickt: Do., 10. Mrz. 2011, 9:13
Thema: Re: LF: Re: VLF Stability and soundcard locking

That is very much what I feared would happen.
 
USB interfaces run based on a  clock of 6MHz, which is unfortuna= tely an exact sub-multiple of the codec reference.   So the diff= erence 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 sacri= fices data accuracy in favor of guaranteed timing of data delivery. &= nbsp; 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 tak= es up some overhead and you'll lose more data blocks.
 
So, we are forced to accept data  glitches and resulting samplin= g rate errors in USB soundcards.
 
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.   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 ra= dio. They are   Direct Sampling SDRs.  The SDR-IQ ha= s 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 ho= st.   Other radios use Ethernet instead of USB for a faster tran= sfer rate.
 
That's life.   Mind you, when I get round to it, still goin= g to get that chip operational with a locked reference 12MHz and accuratel= y 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 soundc= ard I know of that DOESN'T  allow you to change the recording level.&= nbsp;  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 ever= y 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@btope= nworld.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 integr= ated codec/usb interface chip similar to the device Andy mentioned, with= a 12MHz clock crystal. I measured the actual clock frequency, which is ab= out +47ppm from nominal. With a suitable stable calibration source, and 48= kHz sample rate, Spec Lab indicated a sample rate error of -87ppm. The SR= compensation facility in Spec Lab makes the indicated frequency on the sp= ectrogram 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 accide= nt that plugging a USB memory stick into another USB port on the laptop ca= used 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 unp= lugged 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 ho= ur on average. These give rise to glitches in a strong trace on a spectrog= ram with resolution about 1mHz. But on weak amateur signals these would pr= obably 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 remai= ns on the correct frequency. However, I think when one gets into the micro= hertz resolution range, it would be a problem, because the transients occu= r often enough to merge together and smear out the spectral line.

Cheers, Jim Moritz
73 de M0BMU


----------MB_8CDAD285D372E21_CA8_E926_webmail-m047.sysops.aol.com--