On Thu, Jan 10, 2008 at 08:46:09AM -0600, LRK wrote:
>
> While the 'right' fix would be to supply a stable frequency source to
> the USRP, it would be difficult.
Not impossibly difficult... it would, however, have been nice to
have a VCXO option for the USRP-1 that would have allowed external phase
locking circuitry to phase lock the 64 MHz to something without
significantly impacting phase noise (AKA clock jitter) of the 64 MHz
when not phased locked (or for that matter, when phase locked). It is
quite a bit easier to use some fairly straightforward external PLL
hardware to lock a 64 MHz clock by tweaking an EFC DC voltage input than
it is to actually generate a clean, low phase noise external 64 MHz
clock and import it correctly to the USRP so clock jitter (and thus S/N
of the ASC sampling) is as good as with the current oscillator.
>
> Next best would be an 'offset' or 'calibration' value in the environment
> which would be included in the frequency calculations. This should be an
> indication of the error at 64 MHz and scaled. Thus '+914.125 Hz' at 64 MHz
> would cause a 914.125 x 35.15625 = +32137 Hz correction at 2250 MHz
> (which is what I need at this moment :).
>
This change is acutely needed... and everything that computes a
frequency based on the 64 MHz timebase should use it...
> And best in the future would be a source on the USRP which could just
> lock itself to a 1PPS signal from a GPS at 0-5 volt levels.
I'm not sure I want Matt and Eric to do an entire GPSDO as part
of a new USRP... much better to just build a USRP clock generator that
takes the universal standard reference frequency of 10 MHz as an input
like most all of the world's current test equipment and many radios and
most satellite and telecom gear... 10 MHz GPSDOs are a standard item -
readily available and highly accurate (and even pretty cheap on Ebay)
and no other reference frequency is as widely used. And one can find
cheap surplus ex-telcom rubidiums that will supply 10 MHz within parts
in 10^10th or so if one doesn't want to (or can't) use GPS as a reference
but still needs accurate frequency.
A hack I have thought about adding to the USRP FPGA code (but
not implemented yet) would allow collection of the count in a
continuously rolling 64 MHz counter driven by the current 64 MHz clock
on a rising or falling edge of a 1 PPS signal brought in on some spare
pin and stuff this value in a register that could be read via the I2C
mechanism. I think this takes few enough FPGA resources to be doable
with the current USRP code, but again I haven't tried it yet. This
would allow software in gnuradio to compute frequency error every second
(or whatever rate the ticks came in at) by determining whether the time
stamp on the 1 PPS edge was early or late relative to the count of 64
MHz clocks.
A while back I proposed a more general and less inelegant
approach involving passing back time stamp messages in the data stream
in the new message passing format based on such external pin events as
a 1 PPS and I hope this eventually gets implemented, but simply
providing a register that contains the clock count sampled on the last
rising (or falling) edge of an input signal is pretty simple and should
allow real time compensation for frequency error and drift of the TXCO
clock at a rate sufficient to solve the frequency error problem for many
applications - if not all of them - provided one has a suitable source
of an accurate reference clock at some useful frequency (typically 1
PPS, but other values like 1 or 10 KHz are possible).
--
Dave Emery N1PRE/AE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
'For Rent' sign still vainly flapping outside on the weed encrusted pole - in
celebration of what could have been, but wasn't and is not to be now either."
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
