Syncronising multiple USRP2 boards

I would like to synchronise multiple USRP2 boards together. I know I
need a
10Mhz reference clock and a synchronous 1PPS signal but have a few
questions
regarding the specifics of this,

1.) The USRP2 FAQ suggests to use a GPS clock but has anybody managed to
successfully use anything else such as a function generator or other
common
lab equipment?
2.) Does the reference clock need to be a sine wave or can it be square
etc…?
3.) What function should the PPS signal be?
4.) Do I need to modify the FPGA firmware to enable locking from the
external signal?
4.) Is an active splitter absolutely necessary to use or can i get by
with
passive?
5.) Is there a good way to test whether I have correct synchronisation?

Marc.

View this message in context:
http://old.nabble.com/Syncronising-multiple-USRP2-boards-tp27338003p27338003.html
Sent from the GnuRadio mailing list archive at Nabble.com.

actually with our configuration we simply synchronize using the MIMO
cable and setting one of the USRP2s to slave its clock to whatever the
other one is using (I forget exactly how this is done but we do pretty
much everything with GRC, so I think it’s just in the source block for
the USRP2 - I am not at the location with our system at the moment so
I can’t give you a better answer).

I’m pretty sure we are not using an external clock at all. of course
our configuration is specific to our application requirements - we use
the second (slave) usrp2 to read a signal which is a function of the
master’s receive signal and its transmit signal (I am being
deliberately vague). I know that if I transmit from the master our
system doesn’t work (because I tried it).

-Tom

MarcW wrote:

I would like to synchronise multiple USRP2 boards together. I know I need a
10Mhz reference clock and a synchronous 1PPS signal but have a few questions
regarding the specifics of this,

1.) The USRP2 FAQ suggests to use a GPS clock but has anybody managed to
successfully use anything else such as a function generator or other common
lab equipment?

I have done this with with two function generators: one to provide a
10Mhz sine wave (I believe the USRP2 can lock to either a sinusoid or a
square wave - I can’t recall if I just had an easier time with the sine
wave, or if that’s just what I tried first and got working). The second
generator was setup to provide a ‘faux’ 1PPS, but really all you need is
a trigger that provides the rising edge at the right time, and at the
right voltage levels (I believe you want to go from 0V to some positive
voltage less than some value - to make sure you don’t let out the magic
smoke - I think the FAQ tells you what voltage that is). I was able to
both lock onto the 10Mhz reference, and reset the internal clock with
the generated 1PPS.
More recently I use a GPS-locked OCXO (can be had for ~$1000 these days
I think).

2.) Does the reference clock need to be a sine wave or can it be square
etc…?

I believe the FAQ addresses this - I don’t believe I ever tried with a
square wave, but maybe I did and I just don’t remember anymore…

3.) What function should the PPS signal be?

I think the FAQ talks a little bit about this - the main things are:
don’t overdrive the USRP2, and I believe you want to go from 0V to
+<some_positive_value>V, and the rising edge is used as the trigger. I
believe I ended up setting up the function generator to create a square
pulse with <50% duty cycle at 1Hz, and with a positive voltage offset.
Maybe +/- 1.5V, so with the offset it was 0V-3V? Can’t recall right now.

4.) Do I need to modify the FPGA firmware to enable locking from the
external signal?

In the released code you call config_mimo(<MC_LOCK_TO_SMA or similar to
that effect>) to lock to the 10Mhz reference, and sync_to_pps() to reset
the internal counter on next pulse (there is also a sync_every_pps(),
but you probably don’t want that). In the usrp2_vrt branch this has
changed to clock_config (or config_clock), and you have to create and
pass by reference is config_clock (I may have reversed the names).

4.) Is an active splitter absolutely necessary to use or can i get by with
passive?

I believe this ends up depending on how many USRP2’s you want to drive -
I don’t have any problem using a passive BNC tee with two, and I believe
I’ve tested up to three at a time (at least with the 10Mhz clock).

5.) Is there a good way to test whether I have correct synchronisation?

You can send the clock to the debug pins on the daughterboard, and watch
them on a 2-channel o-scope, with the reference clock on the other
input. Once you call config_mimo they should not be drifting in relation
to each other. The easiest way is to modify the firmware code to enable
this - a search of the mailing list should reveal the correct
incantation to put in txrx.c.
To check that the PPS worked, watch the timestamps coming out of the
USRP2: shortly after the call to sync_to_pps() they should reset to zero
and start climbing again.

Marc.

Good luck,
Doug


Douglas G.
Code 5545
U.S. Naval Research Laboratory
Washington, DC 20375
(202) 767-9048
[email protected]

Sorry im new at this - replied to message in wrong way.

Basically asked Tom whether he made any modifications to the firmware at
all
and said I am interested in splitting the MIMO expansion signal from the
master 3+ ways possibly.

-Marc.

Tom G.-3 wrote:

the second (slave) usrp2 to read a signal which is a function of the

a
3.) What function should the PPS signal be?
http://old.nabble.com/Syncronising-multiple-USRP2-boards-tp27338003p27338003.html


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


View this message in context:
http://old.nabble.com/Syncronising-multiple-USRP2-boards-tp27338003p27343252.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Marc (to answer your question about synchronizing 4 usrp2s, to the
whole list, not just a private message :slight_smile: ),

I guess you’ll need that MIMO hub that is supposed to be in the works.

I imagine you saw this thread:

http://old.nabble.com/USRP2-questions-td19522195.html

the mimo “synchronization” we use with the cable, such as it is, works
with consumer off-the-shelf firmware.

I am however tinkering with the firmware and host software to try to
expose support for two receiver channels in the USRP2 largely so we
can avoid having to go with 4 synchronized USRP2s, which is I believe
the configuration that the genius who is designing this system, (not
me!), would like to do. We haven’t quite reached that point in our
development.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs