Re: [linrad] Sound card clock accuracy

[edson@xxxxxxxxxxxxxxxx>]

Hi Chris,

I have the system clock already syncronized via NTP. So the system clock 
error should be small.

Your suggestion of suing an external generator and analysing the frequency 
and spectrum would be better than what I am doing, but I don't have a good 
signal generator in hand.

So far, I am finding mixed results with different sound cards using the 
measurement methos I've described. For example:

! 124.999779
! 124.999832
! 125.000076
! 124.999847
! 125.000076
! 124.999863
! 125.000069
! 124.999878
! 124.999901
! 125.000046
! 126.248909 <- ?
! 123.751038 <- ?
! 126.020233 <- ?
! 125.228722
! 124.761238
! 125.010040
! 124.986298
! 124.997009
! 125.001129
! 124.998131
! 125.000763
! 124.998695
! 125.000549
! 124.999054
! 124.999420
! 125.000259
! 124.999535
! 125.000206
! 124.999619
! 125.000175
! 124.999672

The figures above is provided by a machine (P-III 1.2 GHz) using the
a cheap sound card and the OSS-free C-Media CMI9738 sound driver.

! 126.023323
! 123.976028
! 125.000076
! 125.000092
! 125.000107
! 125.000130
! 125.000160
! 126.012695
! 125.485916
! 123.501068
! 125.000084
! 125.000099
! 125.000122
! 125.000145
! 126.008385
! 125.021347
! 123.969788
! 125.000084
! 125.000092
! 125.000114
! 125.000130
! 126.006180
! 125.008499
! 123.984879
! 125.000076
! 125.000084
! 125.000099
! 125.000122
! 126.004822
! 125.004662
! 125.032608
! 123.957573

The figures above is provided by a machine (P-III 1.2 GHz) using the 
SB-Live sound card and the alsa emu10k1 sound driver. 

Each figure represents the ammount of time to sample /dev/dsp 1,000,000
times at 8 kHz. The results are strange. The SB card, if the measurements 
are acceptable, is very inaccurate.

What I'm trying to do is to see which of my card is best suited for linrad
and JT44, which will be depended on good sampling accuracy. Small
variations that averages out over time should not cause much problems, but
if the error is cumulative, then there may be a problem.

73,

-- Edson

On Wed, 4 Dec 2002, Chris Albertson wrote:

> 
> The average sample rate is likey quite stable.  (Or at least
> stable if the temperature inside the PC chassis is constant.)
> However, I wonder if the interval between samples is stable?
> The interval could be quite unstable but yet the time to
> make 1E6 samples would be always the same.  After all, the
> average of 1,000,000 small random errors would ted to be
> a constant.
> 
> 
> possably a good test would be to first find a very good
> signal generator and sample a 1Khz sine wave for a few
> seconds.  Next compute the spectrum of the samples using DFT.
> If you see frequency other then 1khz you can then try and track
> down the cause.  noise on the analog signal, noise in the sample
> period,...  Linrad itself could do this.  Put in a known good
> signal and see what comes out.
> 
> If you are very concerned about the speed of your PC's clock
> you can servo it to GPS.  No, I don't mean re-setting the time
> to match GPS, I mean keep the _rate_ adjusted to match the 
> GPS signal.  You need a GPS unit, data cable and some software
> You can see www.ntp.org for the software but NTP comes with
> most linux/unix systems.  The error in my PC's clock rate  before
> it was corrected using NTP was about 83PPM.  Depends on the
> xtal on the main board.
> 
> 
> 
> --- Edson Pereira <edson@xxxxxxxxxxxxx> wrote:
> > 
> > I'm trying to measure the accuracy of sound card clocks running under
> > Linux and would like to discuss with people on the list about a
> > posible
> > method of measurement.
> > 
> > An indirect measurement I am using is to sample /dev/dsp at 8 kHz
> > 1,000,000 times and compare time stamps (with millisecond resolution
> > --
> > ftime()) taken before and after the samplings. 1 million samples at 8
> > kHz
> > should take exactly 125 seconds. I am measuring how off from 125
> > seconds 1
> > million samples takes and from the difference I calculate the
> > relative
> > clock error. I am relying on the Linux system clock, so there will be
> > some
> > additional error, but it should not interfere much with the
> > measurement.
> > 
> > Does any one see a problem with the way the measurement is being 
> > performed? Any suggestion for improvements?
> > 
> > 73,
> > 
> > -- Edson, 7n4ncl
> > 
> > 
> > 
> 
> 
> =====
> Chris Albertson 
>   Home:   310-376-1029  chrisalbertson90278@xxxxxxxxx
>   Cell:   310-990-7550
>   Office: 310-336-5189  Christopher.J.Albertson@xxxxxxxx
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 



LINRADDARNIL