Controlling USRP From Inside General Gnuradio Block

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.

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

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

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