Controlling USRP From Inside General Gnuradio Block

GNU Radio
1

Hi,

If :
u = usrp.source_c(0)

then if I passed the usrp source instance (u) to a gnuradio block, what
is
the class (type) that should be used in the c++ code to receive (define)
this instance ?

I thought at first we can define it as a class of usrp_standard_rx, but
I
was totally wrong.

What I’m trying to do, is to control the usrp directly from inside a
general
gnuradio block. The reason for this is that in usrp_spectrum_sense.py,
the
call from inside bin_statistics block (C++) to the tune function
(python)
takes so much time for each center frequency change.

If I passed the usrp source instance to the bin_statistics block, then,
I
will be able to control the DDC frequency of the USRP directly without
the
need to call the python code every time. Thanks.

Firas,

–
View this message in context:
http://www.nabble.com/Controlling-USRP-From-Inside-General-Gnuradio-Block-tp14302901p14302901.html
Sent from the GnuRadio mailing list archive at Nabble.com.

2

On Wed, Dec 12, 2007 at 12:08:24PM -0800, Firas A. wrote:

What I’m trying to do, is to control the usrp directly from inside a general
gnuradio block. The reason for this is that in usrp_spectrum_sense.py, the
call from inside bin_statistics block (C++) to the tune function (python)
takes so much time for each center frequency change.

Are you sure the delay you’re seeing isn’t caused by the tune_delay
and dwell_delay parameters of the gr_bin_statistics block? The
overhead of getting to and from python is almost certainly less than
the settling time of the front end.

Eric

3

Hi,

Yes I’m sure, when I remove (or mark //) [d_center_freq =
d_tune->calleval(0);] in enter_tune_delay () of bin_statistics.cc, the
scanning speed increases rapidly.

Is there away to solve this problem and control the USRP directly from
the bin_statistics block?

Regards,
Firas

Eric B. [email protected] wrote: On Wed, Dec 12, 2007 at 12:08:24PM
-0800, Firas A. wrote:

What I’m trying to do, is to control the usrp directly from inside a general
gnuradio block. The reason for this is that in usrp_spectrum_sense.py, the
call from inside bin_statistics block (C++) to the tune function (python)
takes so much time for each center frequency change.

Are you sure the delay you’re seeing isn’t caused by the tune_delay
and dwell_delay parameters of the gr_bin_statistics block? The
overhead of getting to and from python is almost certainly less than
the settling time of the front end.

Eric