Another problem with soundcards is that of timebase accuracy, and in
some cases even stability. Many cases of severe errors were identified
by G3PLX during the development of PSK31
In the better cards (real Soundblaster compatibles) the frequencies are
derived from dedicated correct frequency crystals so the CD sampling
rates derived from 44100 Hz are exact (well, within crystal accuracy
anyway). The 8 kHz rate is a different matter though. This cannot be
derived exactly from the same xtal as the 44k1 rates, and an
approximation is often taken by selecting the nearest integer divide
ratio. Errors seen here amount to several Hz at 8 kHz depending on the
individual chip set in use. The best cards have a separate xtal for
this rate and the exact frequency is generated.
Some SB hardware built onto PC motherboards uses whatever crystal is in
the PC (often the 14.318 MHz one) to generate the SB sampling rates.
Again with integer dividers errors of several Hz can be seen.
The worst, according to Peter, is a CR controlled system. I have never
seen anything this bad and the story may be apocryphal, but he has had
errors of many 10s of Hz at 8kHz reported.
I have checked the following :
1) Older 16 bit true Soundblaster - all sampling rates exact
(meaning within about 10 parts per million of the true values)
2) Newer PCI bus compatible true Soundblaster - ditto.
3) Onboard SB hardware on a wide range of Dell pentiums (Pentia ?
:-) - 44k1 derivatives 'exact'. Errors from 0 to 6 Hz on the 8 kHz
rate depending on age / type of machine.
4) Toshiba satellite laptop - 44k1 derivatives 'exact' , 8 kHz
rate - 7 Hz error
PSK31 has a calibration routine built in to take out this sampling rate
error and store the calibration constant. But with the temperature
ranges that PCs go through from turn on to several hours of operation,
the crude packaged oscillators they use can easily move a few 10s of
PPM. At 8 kHz this drift alone is several times the minimum Sprectran
resolution and a few Hz initial error is off the scale without
calibration !
Andy G4JNT
>>Further I noticed that launching another application while running
Spectran
>>caused a kind of 'frequency shift' (see screenshot at my webpage).
>>
>Alberto found this same problem, but he says that debugging will be
difficult,
>and will probably take some time. Incidentally, he is releasing a new
"beta"
>version (beta3).
Just to straigthen things a bit up : we are talking of two different
problems :
1) The frequency error Marco is talking about, is known to me since
some time,
and it is caused by a wrong initial design assumption of Spectran,
i.e. that the
frequency ruler scale must start at an integral multiple of 1 Hz.
This because at
that time Spectran was meant for EME use, where sub-Hertz
resolutions are not
needed. Now that with beta 3 we can do down to 21 milliHz, this
must revised.
2) The frequency shift observed and reported by Rik and Alan, is a
completely new
thing, for which, at the moment, I have no explanation. I saw, one
time only, a shift
of 0.5 Hz, which I attributed to my RX. I wasn't launching or
using any other
application at the moment. As this shift has been signalled by
more than one person,
and on signals locked to some standards, then I must investigated
into it.
Thanks for those reports, and don't be shy to send others. The very
first reason for
putting out a beta before the final release was just to receive this
kind of reports.
73s
Alberto I2PHD
-----------------
--
The Information contained in this E-Mail and any subsequent correspondence
is private and is intended solely for the intended recipient(s).
For those other than the recipient any disclosure, copying, distribution,
or any action taken or omitted to be taken in reliance on such information is
prohibited and may be unlawful.
|
