[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Discuss-gnuradio] Synchronising USRP2's in GRC.

From: Zohair M. Abu Shaban
Subject: RE: [Discuss-gnuradio] Synchronising USRP2's in GRC.
Date: Mon, 21 Jun 2010 16:02:55 +0100


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


> Date: Mon, 21 Jun 2010 10:05:59 -0400
> Subject: Re: [Discuss-gnuradio] Synchronising USRP2's in GRC.
> From: address@hidden
> To: address@hidden
> CC: address@hidden; address@hidden
> 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 <address@hidden> 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 Geiger
> address@hidden

Get a free e-mail account with Hotmail. Sign-up now.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]