discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Possible misuse of the vector sink


From: Michael Ford
Subject: Re: [Discuss-gnuradio] Possible misuse of the vector sink
Date: Tue, 19 Sep 2006 00:22:58 -0500

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.4GHz band to use, so we'll actually be calling this function quite a bit.

On 9/18/06, Eric Blossom <address@hidden > wrote:
On Mon, Sep 18, 2006 at 10:47:23PM -0500, Michael Ford wrote:
> 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 : ()

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


reply via email to

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