[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [linrad] Sound card clock accuracy
- Subject: Re: [linrad] Sound card clock accuracy
- Date: Wed, 4 Dec 2002 19:05:16 -0800 (PST)
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
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
> 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
> should take exactly 125 seconds. I am measuring how off from 125
> seconds 1
> million samples takes and from the difference I calculate the
> clock error. I am relying on the Linux system clock, so there will be
> additional error, but it should not interfere much with the
> Does any one see a problem with the way the measurement is being
> performed? Any suggestion for improvements?
> -- Edson, 7n4ncl
Home: 310-376-1029 chrisalbertson90278@xxxxxxxxx
Office: 310-336-5189 Christopher.J.Albertson@xxxxxxxx
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.