Possible misuse of the vector sink

GNU Radio
1

I’ve been wrestling with the float vector sink for a couple of days now.
We’re trying to give our python script access to the values being output
by
our narrow filter, but no matter what happens, the vector sink block
doesn’t
seem to be giving out anything.

Our code is as follows:

from gnuradio import gr, usrp

class carrier_sense:

def __init__(self):
    self.fg = gr.flow_graph ()
    self.u = usrp.source_c()
    self.complex_mag = gr.complex_to_mag_squared()
    self.iir_filt = gr.single_pole_iir_filter_ff(0.5)
    self.dest = gr.vector_sink_f()
    self.u.tune(0, self.u.db[0][0], 2.4e9)
    #Connect all of the blocks together
    self.fg.connect(self.u, self.complex_mag, self.iir_filt,

self.dest)

def main():

testgraph = carrier_sense()
testgraph.fg.start()
print testgraph.dest.data()

if name == ‘main’:
try:
main()
except KeyboardInterrupt:
pass

Trying to run this code gives us this printed output : ()

Our logic was that since the output of the single_pole_iir_filter is a
float, we could simply attach the vector_sink_c block to the end of it.
We
get the same results when attaching the sink to the complex_mag block,
or a
complex vector sink to the usrp board.

2

On Mon, Sep 18, 2006 at 10:47:23PM -0500, Michael F. wrote:

def main():
pass

Trying to run this code gives us this printed output : ()

Your program starts the graph and then immediately exits, quite
possibly before the graph even gets the first data from the USRP.
(You call main, it starts the graph, then returns)

Take a look at
gnuradio-examples/python/gnuradio/usrp_wfm_rcv_nogui.py for the
general setup of a non-gui application.

Our logic was that since the output of the single_pole_iir_filter is a
float, we could simply attach the vector_sink_c block to the end of it. We
get the same results when attaching the sink to the complex_mag block, or a
complex vector sink to the usrp board.

vector_sink_* was really expected to be used only for QA testing.
If you write infinite data to it, it will try to allocate infinite
memory.

If you’re just trying to look at the output of your power measurement,
try writing the output to a file using gr.file_sink(xxx, yyy).

What are you really trying to do?
What is it that you are trying to communicate back to the python?
How often to you want the python to get the data?
What will it do with it?

Also, have you looked at how
gnuradio-examples/python/gmsk2/receive_path.py handles power
measurement?

FYI, tunnel.py (same directory) implements a CSMA MAC.

Eric

3

We’ve been working with receive_path.py for a while now. As you’ve more
than
likely guessed, Ben is working with me. I guess he had an older build of
the
gnuradio package, because his carrier_sensed() function just had a
comment
that said FIX ME, and I haven’t been working on carrier stuff for a bit

thanx for pointing that out. Ben was actually trying to implement the
functionality that gr_probe_avg_mag_sqrd_c provides - we’re trying to
get a
running history of the carrier in order to decide which part of the
2.4GHzband to use, so we’ll actually be calling this function quite a
bit.