Return-Path: Received: from mtain-dd05.r1000.mx.aol.com (mtain-dd05.r1000.mx.aol.com [172.29.64.145]) by air-dd02.mail.aol.com (v129.4) with ESMTP id MAILINDD024-86aa4d7910c2144; Thu, 10 Mar 2011 12:56:18 -0500 Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by mtain-dd05.r1000.mx.aol.com (Internet Inbound) with ESMTP id E61C838000AEA; Thu, 10 Mar 2011 12:56:14 -0500 (EST) Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1Pxk54-0006wU-71 for rs_out_1@blacksheep.org; Thu, 10 Mar 2011 17:55:22 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1Pxk53-0006wL-OX for rsgb_lf_group@blacksheep.org; Thu, 10 Mar 2011 17:55:21 +0000 Received: from mout7.freenet.de ([195.4.92.97]) by relay1.thorcom.net with esmtp (Exim 4.63) (envelope-from ) id 1Pxk51-0006Hj-Tw for rsgb_lf_group@blacksheep.org; Thu, 10 Mar 2011 17:55:21 +0000 Received: from [195.4.92.28] (helo=18.mx.freenet.de) by mout7.freenet.de with esmtpa (ID dl4yhf@freenet.de) (port 25) (Exim 4.72 #3) id 1Pxk51-0005I8-I1 for rsgb_lf_group@blacksheep.org; Thu, 10 Mar 2011 18:55:19 +0100 Received: from blfd-4db0e330.pool.mediaways.net ([77.176.227.48]:2516 helo=[192.168.0.101]) by 18.mx.freenet.de with esmtpsa (ID dl4yhf@freenet.de) (TLSv1:CAMELLIA256-SHA:256) (port 465) (Exim 4.72 #3) id 1Pxk51-00053g-6N for rsgb_lf_group@blacksheep.org; Thu, 10 Mar 2011 18:55:19 +0100 Message-ID: <4D791085.6000304@freenet.de> Date: Thu, 10 Mar 2011 18:55:17 +0100 From: wolf_dl4yhf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: rsgb_lf_group@blacksheep.org References: <003201cbde72$606d6090$0401a8c0@xphd97xgq27nyf> <543492.45357.qm@web28102.mail.ukl.yahoo.com> <998C9385-2AEE-4C44-91FE-86FE85F09BA9@gmail.com> <6F4ACB3DA2BB4E338E9278EEDE300D20@JimPC> In-Reply-To: <6F4ACB3DA2BB4E338E9278EEDE300D20@JimPC> X-Spam-Score: 1.4 (+) X-Spam-Report: autolearn=disabled,RATWARE_GECKO_BUILD=1.426 Subject: Re: LF: Re: VLF Stability and soundcard locking Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none 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: 3039ac1d40914d7910be3d2c X-AOL-IP: 195.171.43.25 X-AOL-SPF: domain : blacksheep.org SPF : none X-Mailer: Unknown (No Version) Hello Jim, Andy, and group, Many thanks for the detailed analysis - having an easy-to-build GPSDS (GPS-disciplined soundcard) would have been really nice. Anyway, if you have a GPS receiver with 1-pps-output, it can be connected to the 2nd input of the soundcard. By examining the pps-signal, a software could detect 'missing samples', and -if the NMEA sentences are fed to the same input- even compensate dropouts which last longer than a second by simply inserting 'silence' into the sample stream which enters the FFT. Not perfect, a bit tricky in software, but minimum hardware requirements. For example, the Garmin GPS 18x "VLC" which I use here at the moment sends the NMEA string in the middle of the second-period, so both (serial data and sync pulse) could be added with a passive network. I am still working on the best way to reconstruct the pps-position with a resolution better than the sampling interval. At the moment, the pulse is turned into a ramp with a simple RC lowpass, but I'm not sure if this is the best way to do it. All the best, Wolf . Am 10.03.2011 02:28, schrieb James Moritz: > 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 > > >