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: Eric Blossom
Subject: Re: [Discuss-gnuradio] Possible misuse of the vector sink
Date: Mon, 18 Sep 2006 21:42:39 -0700
User-agent: Mutt/1.5.9i

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]