母板重定时
FIXME this section is outdated, from before c++ drivers.
You need a new crystal or an external oscillator. You'll need to change the
definition of
- /*!
- *
\brief return frequency of master oscillator on USRP
- */
- long fpga_master_clock_freq () const { return
64000000; }
in usrp_basic.h.
Procedure:
I purchased a 44 MHz oscillator from digi-key (p/n
300-7254-1-ND, CSX750FJC44) for $3.38. The first attempt to remove the USRP 64
MHz failed miserably with a pen iron. I purchased a heat gun from digi-key
(MA1008-ND) for $52, set it to the 1000 degree setting and the old oscillator
came up in about 10 seconds. Installed the new oscillator and checked the 44 MHz
clock with a scope. I am using the std_4rx_0tx.rbf FPGA image.
I then tried to run my customized dbs application that records 8-bit I/Q data
to a file for me from any of the 802.11b channels. I got all zeros in the data.
Then remembered Eric told me to change the clock in db_dbs_rx.py.
My code is a little older than current but here are my modifications:
In gr-usrp/src/db_dbs_rx.py
changed line 88 from
self.refclk_divisor = 16
to
self.refclk_divisor = 11
and changed line 108 from
return
64e6/self.refclk_divisor
to
return 44e6/self.refclk_divisor
then in /gr-usrp I did
make clean
make
make check
make install
Rerun my custom dbs program and it worked fine. I used a decimation of 4 so
I'm recording at 11 MSsamples per second.(#FIXME# is this correct ?)
- Is there another way to achieve 10 MSample/second without changing USRP
clock?
I have been working with fractional rate decimeter/interpolators inside the
USRP FPGA. You can put a fractional rate decimeter inside the FPGA which
decimates by 6.4.
It is a bit hard to get them to fit but you get a lot of flexibility out of
them without changing the clocks. .(#FIXME# is this correct ?)
- The file usrp_basic.h has the following member:
long fpga_master_clock_freq () const { return 64000000; }
If I want my system to work at 50 MHz, will I need to change this constant?
Yes. The idea was that there was a single place in the code
(fpga_master_clock_freq) that "knows" the actual frequency.
- I've got a USRP v4 board that I'm planning to run off of a 13 MHz
external clock. However, I'm intending to use a pair of RFX 900 daughterboards,
and I’m wondering if there are any known modifications needed to allow these
daughterboards to operate with a 13 MHz clock?
You need to go into the db_flexrf.py
and db_flexrf_mimo.py
files in the gr-usrp/src
directory. Any references to 64 MHz need to be changed to 13 MHz. You also need
to make sure that you tell the usrp object what its sampling rate is.
- What is the voltage level for the USRP external clock? Is 1.0V peak to
peak ok? Do I need to add a dc offset to my external clock to prevent the
negative swings?
Yes 1V p-p for USRP rev 4. Use 3.3V for rev 2 and 3.
- What are the limits on the USRP external clock? Will using a
“non-standard" clock frequency break any parts of Gnuradio?
You can drive the clock line anywhere between about 10MHz and 65MHz. Be sure
to edit usrp_basic: :fpga_master_clock_freq() to return the new value.
- I re-clocked my USRP from 64 to 65.536 MHz and have recently discovered
that I & Q samples are no longer orthogonal, rather they seem to be only 70
degrees or so apart. I would guess this is due to some hard coded values in the
CIC or HB filters? Is there a USRP command to correct for this phase imbalance?
That's an odd problem. Sounds like a timing issue. Keep in mind that the ADCs
are only specified to work to 64 MHz and the FPGA image is compiled to meet
timing at 64 MHz. You might need to recompile it with the stricter timing
numbers. All of the DSP stuff in the FPGA should not care about the absolute
frequency as long as it meets timing.
