From: DL4YHF@aol.com
Message-ID: <6f.101e2084.279dec99@aol.com>
Date: Mon, 22 Jan 2001 15:05:45 EST
Subject: LF: Accuracy of Soundcards, programs, and related stuff
To: rsgb_lf_group@blacksheep.org
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Sender: <majordom@post.thorcom.com>

Hello Alberto, hello group,


Concering the accuracy of the soundcard's crystal referency: There has been a 
discussion about this before, and I do not want to trigger that again.
Here are the results from a few tests I did on that. They do not have to be 
100% true for "your" PC, but I hope they are worth thinking about:

1.) The soundcard's 8000 Hz sample rate is not good on both PCs I tested. 
They were off the actual sample rate by some Hertz(!!) on my old notebook.

2.) Also stay away from all sample rates except 11025, 22050 or 44100 samples 
per second.
If you need lower sample rates, decimate the input signal by two or three. If 
the input spectrum does not contain frequencies above half of the *decimated* 
sample rate, you don't even need a proper software-based anti-alias filter (a 
quick and easy integrate-and-dump filter as used in SpecLab will do, it just 
takes a few additional nanoseconds(!) per sample. You only have to process 
every second or third sample in the FFT. The IF filter in your receiver will 
reduce the 'aliasing' frequencies above 2 kHz anyway).

3.) A possibility to check the accuracy of the sample rate is this (with some 
limitations):
Let the soundcard run at 44100 samples/second, put a pice of wire into the 
mic input (or even the line input) and turn on the TV. Use the largest FFT 
size your program supports, use the highest level of "integration". You 
should see a clear spectrum line at exactly 1/64us = 15625.0 Hz. This allows 
you to calculate a quite "exact" sample rate (for example, 44100.05 
samples/second). Chances are good, that the lower sample rates are fractions 
of this "corrected" sample rate (in this example, 22050.025 Hz and 11025.0125 
Hz ). 

In programs using the soundcard like ARGO, Spectran, and all the others, a 
small table can be included in a "configuration dialog" where the user can 
enter the corrected sampling frequency (or a correction factor for every 
supported sample rate). To say it again, most soundcards are not that bad if 
the "standard" sample rates are used. And - I guess - though they use cheap 
computer crystals, they do not drift too fast (but I must admit, I did not 
open my windows to check the soundcard's stability if the room temperature 
drops from +19°C to -5°C). If you really need an absolute milli-Hertz 
ACCURACY (and not just a mHz RESOLUTION, because you cannot find a commercial 
station with a steady carrier),  you may have to attach a small crystal oven 
to your the soundcard or -better- try to get one of those rare DSP boards. 


A (possible?) ''software solution' to improve frequency accuracy (warning, 
may contain sarcasm, but about 0.5ppm of a good idea): 

Let the card run on 44100 samp/sec in "16 bit stereo". Connect the 
TV-line-sync-signal to the soundcard's left channel. Connect the audio from 
the longwave RX (or whatever you want to analyze) to the right channel. 
Develop a sophisticated software which removes the phase jumps from the 
interlaced TV signal and/or drives an accurate software PLL . Use the 
(PLL'ed) reference signal to continously monitor the soundcard's clock 
deviation.  If you don't have your own Caesium standard for the RX, you may 
even lock your receiver's main oscillator to the software-based reference. 
Make shure that you are close enough to the TV transmitter so no phase jitter 
from a varying propagation path can affect the reference. Make sure that the 
program does not miss a single sample in a couple of days (a tough job under 
Windoze, believe me...). Etc, etc, etc.  


A personal opinion about "INI files" versus "Windoze Registry" 
(non-programmers please stop reading here, it gets boring):

I am still using the old-style INI files in my programs, because they can 
easily be copied to others PCs to transfer all the settings (remeber, they 
are plain text files which you can even modify with a simple text editor). 
You can  locate the INI files in the directory where the executable program 
is located (yes, it can be done, though almost no-one else seems to do it). 
There is no need to put all INI files into the Windoze directory !
In my humble opinion, doing so will turn the Windows diretory into a complete 
mess, and, as Alberto wrote, you always have trouble trying to find them 
later. Saving the INI file in the directory of the executable has some 
advantages (If you like to know how, drop me a line). The user can get back 
to the "very default settings" of the program by deleting the configuration 
file. The program will automatically create a new one with the 'built-in' 
default settings. I also hate the Registry because it's just another way of 
stuffing everything together in one single structure. Yucc ! ...


Info for all users of Spectrum Lab: 

A new version with image-rejecting frequency converter and some other 
'gimmicks' will be out soon. There will also be improved filters to reduce 
aliasing for very low sample rates. So if you don't really have to, do not 
download the old SpecLab V1.63.


73's from Wolf  (DL4YHF.  DF0WD mostly off air, because the TCXO hasn't 
arrived yet ..)