Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

Re: LF: Re: VLF Stability and soundcard locking

To: [email protected]
Subject: Re: LF: Re: VLF Stability and soundcard locking
From: wolf_dl4yhf <[email protected]>
Date: Thu, 10 Mar 2011 18:55:17 +0100
In-reply-to: <6F4ACB3DA2BB4E338E9278EEDE300D20@JimPC>
References: <[email protected]> <003201cbde72$606d6090$0401a8c0@xphd97xgq27nyf> <[email protected]> <[email protected]> <6F4ACB3DA2BB4E338E9278EEDE300D20@JimPC>
Reply-to: [email protected]
Sender: [email protected]
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9

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






<Prev in Thread] Current Thread [Next in Thread>