Eric wrote:
Tom et alÂ…Try this as a mostly software solution: If you were to feed the 200 MHz xtal into a long counter (i.e. 32 bits, with a total count of 2^32=4.3e9), the counter will "wrap" every ~ 21.5 seconds (with LSB = 5 nsec). Every so often (frequent enough so that you don't lose track of which 21+ second ambiguity cycle you are on), strobe the count into a register. The idea will be to use the integrated count (including the n*21+ second cycles) to establish the average clock rate. To give you an idea about how good a cheap GPS receiver can be as a clock, surf to http://gpstime.com/ and take a look at my various GPS timing papers (ION 2000 & the last VLBI workshop are good starting places) and at Rick's M12+ receiver evaluation. Averaging over as few as 5-10 cycles (a couple of minutes) will tell you the error in the 200 MHz clock frequency to 1:10e10.
Youse guys are going to get Jim Lux into this again! (REALLY do love your comments Jim). This is probably a do-able topic for early next year. Hey! Why not long term aging, and Loran. Not kidding. Anything is possible in software with a ‘hardware assist, including Internet NTS corrections. We have our GPS receivers poised. What we need is a designer! You game? We are NOT going for 10 mhz multiplied, but 1 cycle or so at 200 mhz!
In the SDR you already have a "handle" to correct the number cranked into the DDS to achieve a desired signal frequency -- this simply changes the phase increment number cranked into the DDS chips integrators.
With only the addition of a simple counter & register driven by the 200 MHz xtal (the jitter of it sets the phase noise floor) and a good GPS receiver, you have the ability to "steer" the master oscillator without the need for D/A converters totally in $oftware.
That's exactly what I think is the way to do it. I wouldn't even fool with driving the DDS phase increment. I'd either step the phase offset register, or, more desirable, change the software LO in the final demod/mod.
Without a GPS receiver, with a good, stable NTP server, you should be able to keep you computer's clock accurate at the 10-20 msec level. Just using it to grab a counter sample, over 1 day you will have enough resolution to "track" the 200 MHz error at a level ~1:10e7 (i.e. 10 Hz @ 100 MHz) without even using a GPS receiver. Even the grubbiest GPS receiver, not designed at all for precision timing, will provide timing at the 1 usec level (even when navigating to give a 3D position); combine this with a 15 minute average (~1000 seconds) gets you 1:10e8.
I don't know that the 200 MHz clock on the SDR1K is that stable, unless it's in a nice box. It's pretty temperature sensitive (blowing on it is good for a several ppm change). Integrating over long times will take out the aging, but not the short term (few seconds) effects. Switching back and forth from Tx to Rx also changes the frequency over time (possibly due to power supply voltage changes or thermal distribution)..
All this only leaves the sound card's sample clock as an undefined "local oscillator" in the chain and that remains as a fixed frequency offset that you take out as a constant by listening to WWV. This will continue to be an annoyance until someone comes up with an external sampling clock input for the sound card.
And that clock is really, really bad and drifts A LOT. My measurements show that the sampling clock variation is about 100-1000 times worse than the 200 MHz DDS reference (for an on-mobo sound interface).
Dividing down the 200 MHz to generate a pilot tone into the sound card might not be a bad idea.
The other thing is that the sample clock error is a multiplicative effect and the DDS error is an additive frequency error. Consider two tones at, say, 1100 and 2300 Hz. If the sample clock is wrong, they might look like 1000 and 2170 Hz. (the spacing changes)
If the DDS clock is wrong, they might look like 1000 and 2200 Hz. (i.e. the spacing is still the same)
If all you're doing is pushing it back out to speakers at the same sample rate, the sample rate errors aren't a big problem (everything scales), but if you're doing hertz accurate filtering or demodulation, it's an issue.
Spacecraft Radio Frequency Subsystems Group
Flight Communications Systems Section
Jet Propulsion Laboratory, Mail Stop 161-213
4800 Oak Grove Drive
Pasadena CA 91109
tel: (818)354-2075
fax: (818)393-6875
