Synchronising USRP2's in GRC

GNU Radio
#1

Hi everyone,

I need to use several USRP2’s in the same GRC programme (MIMO). Is there
a
way to sychronise them to the same clock in GRC itself?

Best,

Zoh

View this message in context:
http://old.nabble.com/Synchronising-USRP2's-in-GRC.-tp28947018p28947018.html
Sent from the GnuRadio mailing list archive at Nabble.com.

#2

For the old(er) USRP2 driver (i.e. in the current released version of
GNURadio) - the C++ block supports the functionality to synchronize
the clock, and they are available in python as well, but I don’t
believe the GRC block exposes this functionality. It would be
relatively trivial to add a drop-down in the block configuration to
select a clock reference. Setting the clock time is a little trickier,
but is do-able in GRC. All the modifications need to be done in the
usrp2_sink_xxxx.xml and usrp2_source_xxxx.xml files (

I’ve been taking a look at doing this with the new UHD driver (i.e.
for the next GNURadio release). The low-level UHD driver supports
synchronizing the LO to the reference clock, and setting the time
according to the PPS (or just according to when you tell it to via the
set_time_now()), however the gr-uhd block does not yet. Adding this
functionality is relatively trivial for the C++ code, but I’ve run
into a problem with SWIG-izing the calls (for use with GRC) due to the
UHD’s use of boost::uint32_t in the time_spec_t structure. As I’m not
a SWIG expert, any advice on how to deal with this would be
appreciated. I do expect to be able to share the patch when I get it
working.

The particular problem I run into is that time_spec_t is defined to
want a boost::uint32_t in the constructor (for the number of seconds),
along with a double (for fractional seconds) - but SWIG apparently
doesn’t recognize boost::uint32_t is a typedef for an integer type, so
while I don’t get compile-time errors, by the time I fire up python to
test out the function call (set_type_next_pps(const uhd::time_spec_t
&time_spec) in this case) - and try to construct a time_spec_t object
to pass, python throws an error as it doesn’t believe I’m passing the
correct type.

Doug

On Mon, Jun 21, 2010 at 7:02 AM, Zohair [email protected] wrote:

Hi everyone,

I need to use several USRP2’s in the same GRC programme (MIMO). Is there a
way to sychronise them to the same clock in GRC itself?

Best,

Zoh

–
Doug G.
[email protected]

#3

On Mon, Jun 21, 2010 at 10:05 AM, Douglas G.
[email protected] wrote:

Of course shortly after sending this, I figure out a solution - adding
some typedefs to the SWIG .i file.
It may not be the most elegant, but I do have something to work with
now.
Doug

–
Doug G.
[email protected]

#4

Doug,

Thanks for sharing your solution. I will try it and see what happens.

Cheers,
Zoh

#5

hmmmm, I am using two computers to do my work, one of them has gnuradio
3.3
and the other has 3.3.1. In the later, there are some options in the
USRP2
source blocks:
Clock source:

  • internal
  • external SMA
  • external MIMO

I think I should use one of these, but don’t know how. Any help or
explanation of these three options, please??

Cheers,

Zohair

Zohair wrote:

Hi everyone,

I need to use several USRP2’s in the same GRC programme (MIMO). Is there a
way to sychronise them to the same clock in GRC itself?

Best,

Zoh

–
View this message in context:
http://old.nabble.com/Synchronising-USRP2's-in-GRC.-tp28947018p28965758.html
Sent from the GnuRadio mailing list archive at Nabble.com.

#6

So guys, I want try to to modify the xml of the already existing
usrp2_source_xxxx by adding these line at the end of the tag:
self.$(id).set_time_at_next_pps(time_spec_t(0,0))
time.sleep(1);
self.$(id).start_rx_streaming(0,time_spec_t(4,0))

So i set the time to zero at the next PPS, and make sure this happens by
waiting for a second, then start streaming at time 4 seconds. Of course,
this will be done for all USRP2’s used.

Is this going to solve the issue? Any further suggestions?

Douglas G.-2 wrote:

&time_spec) in this case) - and try to construct a time_spec_t object
Doug G.
[email protected]

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

–
View this message in context:
http://old.nabble.com/Synchronising-USRP2's-in-GRC.-tp28947018p29008563.html
Sent from the GnuRadio mailing list archive at Nabble.com.