I am planning to implement multiple synchronized transmitters using
USRP2 and GPS receiver. Before that I checked whether the USRP2 is
locked to external clock through following experiment.
Connect the 10MHz and 1PPS from GPS receiver (EP1S, Spectracom) to
USRP2’s REF and PPS in port, respectively. (I definitely checked the
electrical specifications…)
Generate 10MHz tone from the USRP2 using usrp2_siggen.py. I have
included following lines in python code.
self._u.config_mimo((0x0001 | 0)) <— I added this method in usrp2.i,
etc…
self._u.sync_to_pps()
Compare the 10MHz tones coming from GPS and the USRP2 through
oscilloscope (triggered to 10MHz sine wave from GPS).
I expect that timing drift of the 10 MHz sine wave from USRP2 will be
nearly 0 or at least very slow, but it is still very fast. It seems that
including “self._u.config_mimo((0x0001 | 0))” doesn’t change anything.
(I did update the fpga programming file and the firmware in SDcard.)
Am I missing something? Any comments will be appreciated.
On Wed, Feb 18, 2009 at 02:20:38AM +0100, Changkyu Seol wrote:
Generate 10MHz tone from the USRP2 using usrp2_siggen.py. I have
nearly 0 or at least very slow, but it is still very fast. It seems that
including “self._u.config_mimo((0x0001 | 0))” doesn’t change anything.
(I did update the fpga programming file and the firmware in SDcard.)
Am I missing something? Any comments will be appreciated.
Changkyu Seol
That should be sufficient. Are you sure that the config_mimo command
is getting sent? It’s easy to check using wireshark.
I am planning to implement multiple synchronized transmitters using
USRP2 and GPS receiver. Before that I checked whether the USRP2 is
locked to external clock through following experiment.
The easiest way to check for lock is to put the following line in your
firmware:
clocks_enable_test_clk(true,10);
This will output a test clock on the middle 2 pins of the 4 pin
connector right near the VCXO on the motherboard. Look at one of those
2 pins on an oscilloscope at the same time as the 10 MHz reference. You
should see the two clocks don’t drift relative to each other.
The easiest way to check for lock is to put the following line in your
firmware:
clocks_enable_test_clk(true,10);
This will output a test clock on the middle 2 pins of the 4 pin
connector right near the VCXO on the motherboard. Look at one of those
2 pins on an oscilloscope at the same time as the 10 MHz reference. You
should see the two clocks don’t drift relative to each other.
I tried as you suggested but it still drifts. I also added the following
line in the firmware to make sure.
clocks_mimo_config(MC_WE_LOCK_TO_SMA);
I tried on several different USRP2s and I got same results.
Any more suggestions?
Is the test clock supposed to be running at 5kHz? I’ve just tested this
on one of my USRP2 - it does appear to be locked with my external clock
i.e. the 5kHz signal on the pin doesn’t drift w.r.t my 10Mhz external
No, the test clock runs as 100MHz/div where div is the 2nd argument to
the function. The maximum value of div is 32.
I think you are using a digital oscilloscope to view this, and you are
seeing it alias because you turned the time per division up way too
high. Change it to 100ns per division.
Ah - that’s was the problem. Unfortunately my scope can only handle a
single channel at 100MHz, so setting the divisor >2 helps.
Unfortunately it appears the clock is not synchronized with my external
10MHz clock - any suggestions on further steps to debug why I’m having
trouble?
I don’t understand this. It works 100% of the time here. What code are
you using?
I think you are using a digital oscilloscope to view this, and you are
seeing it alias because you turned the time per division up way too
high. Change it to 100ns per division.
Matt
Ah - that’s was the problem. Unfortunately my scope can only handle a
single channel at 100MHz, so setting the divisor >2 helps.
Unfortunately it appears the clock is not synchronized with my external
10MHz clock - any suggestions on further steps to debug why I’m having
trouble?
Thanks,
Doug
I’m at svn revision 10441 - with both the firmware and fpga code built
from that (using Xilinx ISE 10.1 to make the fpga). I’ve just modified
the txrx.c code - adding:
clocks_enable_test_clk(true, 2);
clocks_mimo_config(MC_WE_LOCK_TO_SMA);
just before the while(1) loop
My rx_mimo.cc code also calls ->config_mimo(MC_WE_LOCK_TO_SMA), but
right now I’ve stepped back to just getting one USRP2 synchronized to my
external source - which in this case is a function generator with a
10MHz sine with 2V P-P.
Is it possible some of the hardware on my USRP2’s isn’t working?
I’ve tested this here in my lab, using a signal generator for the SMA
reference input.
With firmware modified to automatically set the clock source to the
external reference, and to generate a test 10 MHz output waveform, I
get a good lock when the external reference is anywhere between -13dBm
and 10 dBm (142mV p-p to 2V p-p).
This is using revision 10467 for both the FPGA and the firmware.
If you had a real email address, I would send you some code to try.
Matt
Thank you for the files.
I tested as you suggested with firmware and fpga files you sent me and
it is locked!! I used it other USRP2s and all worked fine.
I modified and compiled “txrx.c” in gnuradio (revision 10464, fedora 9)
trunk to generate “txrx.bin”. What was the problem?
Matt E. wrote:
Thank you for the files.
I tested as you suggested with firmware and fpga files you sent me and
it is locked!! I used it other USRP2s and all worked fine.
I modified and compiled “txrx.c” in gnuradio (revision 10464, fedora 9)
trunk to generate “txrx.bin”. What was the problem?
Changkyu Seol
I downloaded GNU radio by following command. (I am not used to linux.)
Ok - now that I’ve discovered I had some bad cabling - specifically a
bad T-splitter: the side going to my O-scope worked, the side going to
my USRP2’s did not - which I suppose can be chalked up to user error.
I am now able to synchronize the clocks - both with the firmware/fpga
code you sent, and the version I had built locally.
Great!
However - once I start running my code on the host PC, the clock loses
sync. I have to power down, and re-power-up the USRP2 for the clock to
lock onto my external source again. This is with the firmware/fpga from
svn r10441, and my host code. I’ve tried calling ->config_mimo and
->sync_to_pps() as soon as I create my USRP2 objects, but that didn’t
seem to help.
Sync_to_pps is all about timestamps and the pps input, so it is not
related to whether or not the clock is locked.
Just to clarify the clocking architecture on the USRP2, there are
basically 3 modes:
Free running
Locked to the external SMA reference input
Locked to the clock which comes over the MIMO cable from another
USRP2
You need to make sure you are in the 2nd one, aka “we lock to SMA”. It
sounds like whatever code you are running is setting the mode to “we
lock to MIMO connector” mode.
Sync_to_pps is all about timestamps and the pps input, so it is not
related to whether or not the clock is locked.
Right, got it.
lock to MIMO connector" mode.
Matt
You’re correct - it looks like as soon as I call config_mimo, it looses
the lock to SMA. I’m a bit confused as to why that is - I’m calling it
with MC_WE_LOCK_TO_SMA which is defined in usrp2_mimo_config.h - it
basically comes out as 0x0001 (i.e. _MC_WE_LOCK | 0, where _MC_WE_LOCK
is 0x0001).