USRP2 and external clock (from GPS receiver)


#1

Hi!

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.

  1. 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…)

  2. 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()

  1. 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.

Changkyu Seol


#2

On Wed, Feb 18, 2009 at 02:20:38AM +0100, Changkyu Seol wrote:

  1. 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.

Eric


#3

Changkyu Seol wrote:

Hi!

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.

Matt


#4

Matt E. wrote:

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?


#5

Changkyu Seol wrote:

Matt E. wrote:

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?

Are you sure you have a 10 MHz reference and not some other frequency?

Matt


#6

Douglas G. wrote:

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.

Matt


#7

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matt E. wrote:


Discuss-gnuradio mailing list
removed_email_address@domain.invalid
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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
      source.
      Thanks,
      Doug

Doug G.
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
removed_email_address@domain.invalid
removed_email_address@domain.invalid
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJnZtMgfOzzR5bXIgRAlD2AJ4358ZGT8PbPAfp3S6F5LKBEBFG1QCeKy6+
WEBFDTXjvLgtogJazqwQWjE=
=bvvj
-----END PGP SIGNATURE-----


#8

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?

Matt


#9

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matt E. wrote:

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


Doug G.
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
removed_email_address@domain.invalid
removed_email_address@domain.invalid
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJndsRgfOzzR5bXIgRAlZzAJ4wjTzE05MUZPXn2CfUFbnIJPRDqgCfcPKJ
iSyctrCGAqKnewNpclJmwls=
=+lqY
-----END PGP SIGNATURE-----


#10

Douglas G. wrote:

10MHz sine with 2V P-P.

Is it possible some of the hardware on my USRP2’s isn’t working?

Unlikely, since it was tested before shipping.

I will send you code to run in a separate email.

Matt


#11

Matt E. wrote:

Are you sure you have a 10 MHz reference and not some other frequency?

Matt

Yes.

I also have tested with a function generator.

Changkyu Seol


#12

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matt E. wrote:

Matt

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?

Thanks,
Doug


Doug G.
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
removed_email_address@domain.invalid
removed_email_address@domain.invalid
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJnd3vgfOzzR5bXIgRArCiAJ94oanfG0zxukks37qgQnImsqV90ACgqTku
kEdLWYUjrAfR0ZrGhohxUIY=
=kdz8
-----END PGP SIGNATURE-----


#13

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.

Johnathan C.
Corgan Enterprises LLC


#14

Changkyu Seol wrote:

Changkyu Seol

If you had a real email address, I would send you some code to try.

Matt


#15

Matt E. wrote:

Changkyu Seol wrote:

If you had a real email address, I would send you some code to try.

Matt

I sent you an email in order to let you know my email address.

Changkyu Seol


#16

Matt E. wrote:

Changkyu Seol wrote:

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?

Changkyu Seol


#17

Changkyu Seol wrote:

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.)

$ svn co http://gnuradio.org/svn/gnuradio/trunk gnuradio

“txrx.c” included seems to be very old version. Where can I get the
latest firmware/fpga source codes?


#18

Douglas G. wrote:

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.

Matt


#19

On Fri, Feb 20, 2009 at 06:52:43AM +0100, Changkyu Seol wrote:

I downloaded GNU radio by following command. (I am not used to linux.)

$ svn co http://gnuradio.org/svn/gnuradio/trunk gnuradio

“txrx.c” included seems to be very old version. Where can I get the
latest firmware/fpga source codes?

The trunk is the latest development code.

Eric


#20

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matt E. wrote:

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).


Doug G.
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
removed_email_address@domain.invalid
removed_email_address@domain.invalid
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJnwaQgfOzzR5bXIgRAi2hAKCBOY2ijc1wo2MF/jFBRAEAqQpCigCgsEeS
xqHAjKz3SoLMYFG4JK2sefo=
=+Ulx
-----END PGP SIGNATURE-----